draft-ietf-roll-efficient-npdao-10.txt | draft-ietf-roll-efficient-npdao-11.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: October 29, 2019 Cisco | Expires: November 26, 2019 Cisco | |||
R. Sahoo | R. Sahoo | |||
Z. Cao | Z. Cao | |||
Huawei | Huawei | |||
April 27, 2019 | May 25, 2019 | |||
Efficient Route Invalidation | Efficient Route Invalidation | |||
draft-ietf-roll-efficient-npdao-10 | draft-ietf-roll-efficient-npdao-11 | |||
Abstract | Abstract | |||
This document describes the problems associated with No-Path | This document describes the problems associated with No-Path | |||
Destination Advertisement Object (NPDAO) messaging used in Routing | Destination Advertisement Object (NPDAO) messaging used in Routing | |||
Protocol for Low power and lossy networks (RPL) for route | Protocol for Low power and lossy networks (RPL) for route | |||
invalidation and signaling changes to improve route invalidation | invalidation and signaling changes to improve route invalidation | |||
efficiency. | efficiency. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
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 October 29, 2019. | This Internet-Draft will expire on November 26, 2019. | |||
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 15 ¶ | skipping to change at page 2, line 15 ¶ | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 NPDAO is important? . . . . . . . . . . . . . . . . . 5 | 1.3. Why NPDAO is 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 async operation of | 2.3. Possible route downtime caused by async operation of | |||
NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6 | 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 Acknowledgement (DCO-ACK) 11 | 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 10 | |||
4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 | 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11 | |||
4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 | 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 | |||
4.5. Other considerations . . . . . . . . . . . . . . . . . . 12 | 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 12 | |||
4.5.1. Dependent Nodes invalidation . . . . . . . . . . . . 12 | 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 | |||
4.5.2. NPDAO and DCO in the same network . . . . . . . . . . 13 | 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 | |||
4.5.3. DCO with multiple preferred parents . . . . . . . . . 13 | 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 4.6.3. DCO with multiple preferred parents . . . . . . . . . 14 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
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 | |||
Acknowledgement (DCO-ACK) Status field . . . . . . . . . 15 | 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) | |||
Acknowledgement Flags . . . . . . . . . . . . . . . . . . 16 | Acknowledgment Flags . . . . . . . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . 17 | 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 | |||
Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 18 | Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 18 | |||
A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 18 | A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 18 | |||
A.2. Example DCO Messaging with multiple preferred parents . . 19 | A.2. Example DCO Messaging with multiple preferred parents . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | 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 | |||
an optional messaging in the form of DAO (Destination Advertisement | an 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 7, line 51 ¶ | skipping to change at page 7, line 51 ¶ | |||
In Figure 1, when node D decides to switch the path from B to C, it | In Figure 1, when node D decides to switch the path from B to C, 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 an incremented Path Sequence. | containing target as address of D and an incremented Path Sequence. | |||
Node C will update the routing table based on the reachability | Node C will update the routing table based on the reachability | |||
information in the DAO and in turn generate another DAO with the same | information in the DAO and in turn generate another DAO with the same | |||
reachability information and forward it to H. Node H also follows | reachability information and forward it to H. Node H also follows | |||
the same procedure as Node C and forwards it to node A. When node A | 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 routing | receives the regular DAO, it finds that it already has a routing | |||
table entry on behalf of the target address of node D. It finds | table entry on behalf of the target address of node D. It finds | |||
however that the next hop information for reaching node D has changed | however that the next hop information for reaching node D has changed | |||
i.e. node D has decided to change the paths. In this case, Node A | i.e., node D has decided to change the paths. In this case, Node A | |||
which is the common ancestor node for node D along the two paths | which is the common ancestor node for node D along the two paths | |||
(previous and new), should generate a DCO which traverses downwards | (previous and new), should generate a DCO which traverses downwards | |||
in the network. | in the network. | |||
4.2. Transit Information Option changes | 4.2. Transit Information Option changes | |||
Every RPL message is divided into base message fields and additional | Every RPL message is divided into base message fields and additional | |||
Options as described in Section 6 of [RFC6550]. The base fields | Options as described in Section 6 of [RFC6550]. The base fields | |||
apply to the message as a whole and options are appended to add | apply to the message as a whole and options are appended to add | |||
message/use-case specific attributes. As an example, a DAO message | message/use-case specific attributes. As an example, a DAO message | |||
may be attributed by one or more "RPL Target" options which specify | may be attributed by one or more "RPL Target" options which specify | |||
the reachability information for the given targets. Similarly, a | the reachability information for the given targets. Similarly, a | |||
Transit Information option may be associated with a set of RPL Target | Transit Information option may be associated with a set of RPL Target | |||
options. | options. | |||
This document specifies a change in the Transit Information Option to | This document specifies a change in the Transit Information Option to | |||
contain the "Invalidate previous route" (I) bit. This I-bit signals | contain the "Invalidate previous route" (I) flag. This I-flag | |||
the common ancestor node to generate a DCO on behalf of the target | signals the common ancestor node to generate a DCO on behalf of the | |||
node. The I-bit is carried in the Transit Information Option which | target node. The I-flag is carried in the Transit Information Option | |||
augments the reachability information for a given set of RPL | which augments the reachability information for a given set of RPL | |||
Target(s). Transit Information Option should be carried in the DAO | Target(s). Transit Information Option should be carried in the DAO | |||
message with I-bit set in case route invalidation is sought for the | message with I-flag set in case route invalidation is sought for the | |||
corresponding target(s). | corresponding 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ||||
| | | ||||
+ + | ||||
| | | ||||
+ Parent Address + | ||||
| | | ||||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Updated Transit Information Option (New I flag added) | Figure 2: Updated Transit Information Option (New I flag added) | |||
I (Invalidate previous route) bit: The 'I' flag is set by the target | I (Invalidate previous route) flag: The 'I' flag is set by the target | |||
node to indicate to the common ancestor node that it wishes to | node to indicate to the common ancestor node that it wishes to | |||
invalidate any previous route between the two paths. | invalidate any previous route between the two paths. | |||
[RFC6550] allows parent address to be sent in the Transit Information | ||||
Option depending on the mode of operation. In case of storing mode | ||||
of operation the field is usually not needed. In case of DCO, the | ||||
parent address field MUST not be included. | ||||
The common ancestor node SHOULD generate a DCO message in response to | The common ancestor node SHOULD generate a DCO message in response to | |||
this I-bit when it sees that the routing adjacencies have changed for | this I-flag when it sees that the routing adjacencies have changed | |||
the target. I-bit governs the ownership of the DCO message in a way | for the target. I-flag governs the ownership of the DCO message in a | |||
that the target node is still in control of its own route | way that the target node is still in control of its own route | |||
invalidation. | invalidation. | |||
4.3. Destination Cleanup Object (DCO) | 4.3. Destination Cleanup Object (DCO) | |||
A new ICMPv6 RPL control message type is defined by this | A new ICMPv6 RPL control message type is defined by this | |||
specification called as "Destination Cleanup Object" (DCO), which is | specification called as "Destination Cleanup Object" (DCO), which is | |||
used for proactive cleanup of state and routing information held on | used for proactive cleanup of state and routing information held on | |||
behalf of the target node by 6LRs. The DCO message always traverses | behalf of the target node by 6LRs. The DCO message always traverses | |||
downstream and cleans up route information and other state | downstream and cleans up route information and other state | |||
information associated with the given target. | information associated with the given target. | |||
skipping to change at page 10, line 25 ¶ | skipping to change at page 10, line 22 ¶ | |||
in order to identify the DODAGID that is associated with the | in order to identify the DODAGID that is associated with the | |||
RPLInstanceID. | RPLInstanceID. | |||
4.3.1. Secure DCO | 4.3.1. Secure DCO | |||
A Secure DCO message follows the format in [RFC6550] Figure 7, where | A Secure DCO message follows the format in [RFC6550] Figure 7, where | |||
the base message format is the DCO message shown in Figure 3. | the base message format is the DCO message shown in Figure 3. | |||
4.3.2. DCO Options | 4.3.2. DCO Options | |||
The DCO message MUST carry atleast one RPL Target and the Transit | The DCO message MUST carry at least one RPL Target and the Transit | |||
Information Option and MAY carry other valid options. This | Information Option and MAY carry other valid options. This | |||
specification allows for the DCO message to carry the following | specification allows for the DCO message to carry the following | |||
options: | options: | |||
0x00 Pad1 | 0x00 Pad1 | |||
0x01 PadN | 0x01 PadN | |||
0x05 RPL Target | 0x05 RPL Target | |||
0x06 Transit Information | 0x06 Transit Information | |||
0x09 RPL Target Descriptor | 0x09 RPL Target Descriptor | |||
The DCO carries an RPL Target Option and an associated Transit | The DCO carries an RPL Target Option and an associated Transit | |||
Information Option with a lifetime of 0x00000000 to indicate a loss | Information Option with a lifetime of 0x00000000 to indicate a loss | |||
of reachability to that Target. The lifetime indicated in the | of reachability to that Target. | |||
Transit Information Option of the DCO message MUST be set to | ||||
0x00000000. | ||||
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 a | the regular DAO message when the DCO is generated in response to a | |||
DAO message. The Path Sequence present in the Transit Information | DAO message. Thus if a DCO is received by a 6LR and subsequently a | |||
Option of the DAO and the correspondingly triggered DCO MUST be same. | DAO is received with an old seqeunce number, then the DAO MUST be | |||
Thus if a DCO is received by a 6LR and subsequently a DAO is received | ignored. | |||
with an old seqeunce number, then the DAO MUST be ignored. | ||||
4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) | 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) | |||
The DCO-ACK message SHOULD be sent as a unicast packet by a DCO | The DCO-ACK message SHOULD be sent as a unicast packet by a DCO | |||
recipient in response to a unicast DCO message with 'K' flag set. If | recipient in response to a unicast DCO message with 'K' flag set. If | |||
'K' flag is not set then the receiver of the DCO message MAY send a | 'K' flag is not set then the receiver of the DCO message MAY send a | |||
DCO-ACK to signal an error condition. | DCO-ACK to signal an error condition. | |||
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 12, line 29 ¶ | skipping to change at page 12, line 23 ¶ | |||
same value as that of the DAO message in response to which the | same value as that of the DAO message in response to which the | |||
DCO is generated on the common ancestor node. | DCO is generated on the common ancestor node. | |||
3. A node MAY set the 'K' flag in a unicast DCO message to solicit a | 3. A node MAY set the 'K' flag in a unicast DCO message to solicit a | |||
unicast DCO-ACK in response in order to confirm the attempt. | unicast DCO-ACK in response in order to confirm the attempt. | |||
4. A node receiving a unicast DCO message with the 'K' flag set | 4. A node receiving a unicast DCO message with the 'K' flag set | |||
SHOULD respond with a DCO-ACK. A node receiving a DCO message | SHOULD respond with a DCO-ACK. A node receiving a DCO message | |||
without the 'K' flag set MAY respond with a DCO-ACK, especially | without the 'K' flag set MAY respond with a DCO-ACK, especially | |||
to report an error condition. | to report an error condition. | |||
5. A node receiving a unicast DCO message MUST verify the stored | 5. A node receiving a unicast DCO message MUST verify the stored | |||
Path Sequence in context to the given target. If the stored Path | Path Sequence in context to the given target. If the stored Path | |||
Sequence is more fresh i.e. newer than the Path Sequence received | Sequence is more fresh i.e., newer than the Path Sequence | |||
in the DCO, then the DCO MUST be dropped. | received in the DCO, then the DCO MUST be dropped. | |||
6. A node that sets the 'K' flag in a unicast DCO message but does | 6. A node that sets the 'K' flag in a unicast DCO message but does | |||
not receive DCO-ACK in response MAY reschedule the DCO message | not receive DCO-ACK in response MAY reschedule the DCO message | |||
transmission for another attempt, up until an implementation | transmission for another attempt, up until an implementation | |||
specific number of retries. | specific number of retries. | |||
7. A node receiving a unicast DCO message with its own address in | 7. A node receiving a unicast DCO message with its own address in | |||
the RPL Target Option MUST strip-off that Target Option. If this | the RPL Target Option MUST strip-off that Target Option. If this | |||
Target Option is the only one in the DCO message then the DCO | Target Option is the only one in the DCO message then the DCO | |||
message MUST be dropped. | message MUST be dropped. | |||
The scope of DCOSequence values is unique to each node. | The scope of DCOSequence values is unique to each node. | |||
4.5. Other considerations | 4.5. Unsolicited DCO | |||
4.5.1. Dependent Nodes invalidation | A 6LR may generate an unsolicited DCO to unilaterally cleanup the | |||
path on behalf of the target entry. The 6LR has all the state | ||||
information namely, the Target address and the Path Sequence, | ||||
required for generating DCO in its routing table. The conditions why | ||||
6LR may generate an unsolicited DCO is beyond the scope of this | ||||
document but some possible reasons could be: | ||||
1. On route expiry of an entry, a 6LR may decide to gracious cleanup | ||||
the entry by initiating DCO. | ||||
2. 6LR needs to entertain higher priority entries in case the | ||||
routing table is full thus resulting in an eviction of existing | ||||
routing entry. In this case the eviction can be handled | ||||
graciously using DCO. | ||||
Note that if the 6LR initiates a unilateral path cleanup using DCO | ||||
and if it has the latest state for the target then the DCO would | ||||
finally reach the target node. Thus the target node would be | ||||
informed of its invalidation. | ||||
4.6. Other considerations | ||||
4.6.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-flag 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. | |||
Dependent nodes do not have any indication regarding if any of its | Dependent nodes do not have any indication regarding if any of its | |||
parent nodes in turn have decided to switch their parent. Thus for | parent nodes in turn have decided to switch their parent. Thus for | |||
route invalidation the dependent nodes may choose to always set the | route invalidation the dependent nodes may choose to always set the | |||
'I' bit in all its DAO message's Transit Information Option. Note | 'I' flag in all its DAO message's Transit Information Option. Note | |||
that setting the I-bit is not counter productive even if there is no | that setting the I-flag is not counter productive even if there is no | |||
previous route to be invalidated. | previous route to be invalidated. | |||
4.5.2. NPDAO and DCO in the same network | 4.6.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, for example, when the route lifetime | [RFC6550] can still be used, for example, when the route lifetime | |||
expiry of the target happens or when the node simply decides to | expiry of the target happens or when the node simply decides to | |||
gracefully terminate the RPL session on graceful node shutdown. | gracefully terminate the RPL session on graceful node shutdown. | |||
Moreover a deployment can have a mix of nodes supporting the DCO and | Moreover a deployment can have a mix of nodes supporting the DCO and | |||
the existing NPDAO mechanism. It is also possible that the same node | the existing NPDAO mechanism. It is also possible that the same node | |||
supports both the NPDAO and DCO signalling. | supports both the NPDAO and DCO signaling. | |||
Section 9.8 of [RFC6550] states, "When a node removes a node from its | Section 9.8 of [RFC6550] states, "When a node removes a node from its | |||
DAO parent set, it SHOULD send a No-Path DAO message to that removed | DAO parent set, it SHOULD send a No-Path DAO message to that removed | |||
DAO parent to invalidate the existing router". This document | DAO parent to invalidate the existing router". This document | |||
introduces an alternate and more optimized way of route invalidation | introduces an alternate and more optimized way of route invalidation | |||
but it also allows existing NPDAO messaging to work. Thus an | but it also allows existing NPDAO messaging to work. Thus an | |||
implementation has two choices to make when a route invalidation is | implementation has two choices to make when a route invalidation is | |||
to be initiated: | to be initiated: | |||
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' bit 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.5.3. DCO with multiple preferred parents | 4.6.3. 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 14, line 28 ¶ | skipping to change at page 14, line 43 ¶ | |||
This documents recommends using a DelayDCO timer value of 1sec. This | This documents 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 set | Here the hypothesis is that the DAOs from all possible parent set | |||
would be received on the common ancestor within this time period. | would be received on the common ancestor within this time period. | |||
Note that there is no requirement of synchronization between DCO and | Note that there is no requirement of 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. Acknowledgements | 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 | |||
with critical review comments. | with critical review comments. | |||
6. IANA Considerations | 6. IANA Considerations | |||
IANA is requested to allocate new codes for the DCO and DCO-ACK | IANA is requested to allocate new codes for the DCO and DCO-ACK | |||
messages from the RPL Control Codes registry. | messages from the RPL Control Codes registry. | |||
+------+---------------------------------------------+--------------+ | +------+---------------------------------------------+--------------+ | |||
| Code | Description | Reference | | | Code | Description | Reference | | |||
+------+---------------------------------------------+--------------+ | +------+---------------------------------------------+--------------+ | |||
| TBD1 | Destination Cleanup Object | This | | | TBD1 | Destination Cleanup Object | This | | |||
| | | document | | | | | document | | |||
| TBD2 | Destination Cleanup Object Acknowledgement | This | | | TBD2 | Destination Cleanup Object Acknowledgment | This | | |||
| | | document | | | | | document | | |||
| TBD3 | Secure Destination Cleanup Object | This | | | TBD3 | Secure Destination Cleanup Object | This | | |||
| | | document | | | | | document | | |||
| TBD4 | Secure Destination Cleanup Object | This | | | TBD4 | Secure Destination Cleanup Object | This | | |||
| | Acknowledgement | document | | | | Acknowledgment | document | | |||
+------+---------------------------------------------+--------------+ | +------+---------------------------------------------+--------------+ | |||
IANA is requested to allocate bit 1 from the Transit Information | IANA is requested to allocate bit 1 from the Transit Information | |||
Option Flags registry for the I-bit (Section 4.2) | Option Flags registry for the I-flag (Section 4.2) | |||
6.1. New Registry for the Destination Cleanup Object (DCO) Flags | 6.1. New Registry for the Destination Cleanup Object (DCO) Flags | |||
IANA has created a registry for the 8-bit Destination Cleanup Object | IANA is requested to create a registry for the 8-bit Destination | |||
(DCO) Flags field. | Cleanup Object (DCO) Flags field. This registry should be located in | |||
existing category of "Routing Protocol for Low 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: | |||
oBit number (counting from bit 0 as the most significant bit) | o Bit number (counting from bit 0 as the most significant bit) | |||
oCapability description | o Capability description | |||
oDefining 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 | | |||
+------------+------------------------------+---------------+ | +------------+------------------------------+---------------+ | |||
DCO Base Flags | DCO Base Flags | |||
6.2. New Registry for the Destination Cleanup Object Acknowledgement | 6.2. New Registry for the Destination Cleanup Object Acknowledgment | |||
(DCO-ACK) Status field | (DCO-ACK) Status field | |||
IANA has created a registry for the 8-bit Destination Cleanup Object | IANA is requested to create a registry for the 8-bit Destination | |||
Acknowledgement (DCO-ACK) Status field. | Cleanup Object Acknowledgment (DCO-ACK) Status field. This registry | |||
should be located in existing category of "Routing Protocol for Low | ||||
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: | |||
oStatus Code | o Status Code | |||
oDescription | o Description | |||
oDefining RFC | o Defining RFC | |||
The following bits are currently defined: | The following bits 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 | | |||
| | Target found | document | | | | Target found | document | | |||
+------------+----------------------------------------+-------------+ | +------------+----------------------------------------+-------------+ | |||
DCO Status Codes | DCO Status Codes | |||
6.3. New Registry for the Destination Cleanup Object (DCO) | 6.3. New Registry for the Destination Cleanup Object (DCO) | |||
Acknowledgement Flags | Acknowledgment Flags | |||
IANA has created a registry for the 8-bit Destination Cleanup Object | IANA is requested to create a registry for the 8-bit Destination | |||
(DCO) Acknowledgement Flags field. | Cleanup Object (DCO) Acknowledgment Flags field. This registry | |||
should be located in existing category of "Routing Protocol for Low | ||||
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: | |||
oBit number (counting from bit 0 as the most significant bit) | o Bit number (counting from bit 0 as the most significant bit) | |||
oCapability description | o Capability description | |||
oDefining 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 | |||
7. Security Considerations | 7. Security Considerations | |||
This document introduces the ability for a common ancestor node to | This document introduces the ability for a common ancestor node to | |||
invalidate a route on behalf of the target node. The common ancestor | invalidate a route on behalf of the target node. The common ancestor | |||
node is directed to do so by the target node using the 'I' bit in | node is directed to do so by the target node using the 'I' flag in | |||
DCO's Transit Information Option. However, the common ancestor node | DCO's Transit Information Option. However, the common ancestor node | |||
is in a position to unilaterally initiate the route invalidation | is in a position to unilaterally initiate the route invalidation | |||
since it possesses all the required state information namely, the | since it possesses all the required state information, namely, the | |||
Target address and the correspond Path Sequence. Thus a rogue common | Target address and the corresponding Path Sequence. Thus a rogue | |||
ancestor node could initiate such an invalidation and impact the | common ancestor node could initiate such an invalidation and impact | |||
traffic to the target node. This document assumes that the security | the traffic to the target node. | |||
mechanisms as defined in [RFC6550] are followed, which means that the | ||||
common ancestor node is part of the RPL network because it has the | This document also introduces an I-flag which is set by the target | |||
required credentials. | node and used by the ancestor node to initiate a DCO if the ancestor | |||
nodes sees an update in the route adjacency. However, this flag | ||||
could be spoofed by a malicious 6LR in the path and can cause | ||||
invalidation of an existing active path. Note that invalidation will | ||||
happen only if the other conditions such as Path Sequence condition | ||||
is also met. Having said that a malicious 6LR may spoof a DAO on | ||||
behalf of the (sub) child with the I-flag set and can cause route | ||||
invalidation on behalf of the (sub) child node. | ||||
This document assumes that the security mechanisms as defined in | ||||
[RFC6550] are followed, which means that the common ancestor node and | ||||
all the 6LRs are part of the RPL network because they have the | ||||
required credentials. A non-secure RPL network needs to take into | ||||
consideration the risks highlighted in this section. | ||||
All RPL messages support a secure version of messages which allows | All RPL messages support a secure version of messages which allows | |||
integrity protection using either a MAC or a signature. Optionally, | integrity protection using either a MAC or a signature. Optionally, | |||
secured RPL messages also have encryption protection for | secured RPL messages also have encryption protection for | |||
confidentiality. | confidentiality. | |||
The document adds new messages (DCO, DCO-ACK) which are syntactically | The document adds new messages (DCO, DCO-ACK) which are syntactically | |||
similar to existing RPL messages such as DAO, DAO-ACK. Secure | similar to existing RPL messages such as DAO, DAO-ACK. Secure | |||
versions of DCO and DCO-ACK are added similar to other RPL messages | versions of DCO and DCO-ACK are added similar to other RPL messages | |||
(such as DAO, DAO-ACK). | (such as DAO, DAO-ACK). | |||
RPL supports three security modes as mentioned in Section 10.1 of | RPL supports three security modes as mentioned in Section 10.1 of | |||
[RFC6550]: | [RFC6550]: | |||
1. Unsecured: In this mode, it is expected that the RPL control | 1. Unsecured: In this mode, it is expected that the RPL control | |||
messages are secured by other security mechanisms, such as link- | messages are secured by other security mechanisms, such as link- | |||
layer security. In this mode, the RPL control messages, | layer security. In this mode, the RPL control messages, | |||
including DCO, DCO-ACK, do not have Security sections. A DCO and | including DCO, DCO-ACK, do not have Security sections. Also note | |||
DCO-ACK message which is not encrypted at link-layer MUST not be | that unsecured mode does not imply that all messages are sent | |||
handled by the RPL layer. Also all the DCO and DCO-ACK messages | without any protection. | |||
that are transmitted MUST be link-layer encrypted. | ||||
2. Preinstalled: In this mode, RPL uses secure messages. Thus | 2. Preinstalled: In this mode, RPL uses secure messages. Thus | |||
secure versions of DCO, DCO-ACK MUST be used in this mode. | secure versions of DCO, DCO-ACK MUST be used in this mode. | |||
3. Authenticated: In this mode, RPL uses secure messages. Thus | 3. Authenticated: In this mode, RPL uses secure messages. Thus | |||
secure versions of DCO, DCO-ACK MUST be used in this mode. | secure versions of DCO, DCO-ACK MUST be used in this mode. | |||
8. Normative References | 8. 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, | |||
skipping to change at page 18, line 17 ¶ | skipping to change at page 18, line 46 ¶ | |||
A.1. Example DCO Messaging | A.1. Example DCO Messaging | |||
In Figure 1, node (D) switches its parent from (B) to (C). This | In Figure 1, node (D) switches its parent from (B) to (C). This | |||
example assumes that Node D has already established its own route via | example assumes that Node D has already established its own route via | |||
Node B-G-A-6LBR using pathseq=x. The example uses DAO and DCO | Node B-G-A-6LBR using pathseq=x. The example uses DAO and DCO | |||
messaging convention and specifies only the required parameters to | messaging convention and specifies only the required parameters to | |||
explain the example namely, the parameter 'tgt', which stands for | explain the example namely, the parameter 'tgt', which stands for | |||
Target Option and value of this parameter specifies the address of | Target Option and value of this parameter specifies the address of | |||
the target node. The parameter 'pathseq', which specifies the Path | the target node. The parameter 'pathseq', which specifies the Path | |||
Sequence value carried in the Transit Information Option. The | Sequence value carried in the Transit Information Option. The | |||
parameter 'I_flag' specifies the 'I' bit in the Transit Information | parameter 'I_flag' specifies the 'I' flag in the Transit Information | |||
Option. sequence of actions is as follows: | Option. sequence of actions is as follows: | |||
1. Node D switches its parent from node B to node C | 1. Node D switches its parent from node B to node C | |||
2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated | 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated | |||
path to C | path to C | |||
3. C checks for a routing entry on behalf of D, since it cannot find | 3. C checks for a routing entry on behalf of D, since it cannot find | |||
an entry on behalf of D it creates a new routing entry and | an entry on behalf of D it creates a new routing entry and | |||
forwards the reachability information of the target D to H in a | forwards the reachability information of the target D to H in a | |||
DAO(tgt=D,pathseq=x+1,I_flag=1). | DAO(tgt=D,pathseq=x+1,I_flag=1). | |||
4. Similar to C, node H checks for a routing entry on behalf of D, | 4. Similar to C, node H checks for a routing entry on behalf of D, | |||
cannot find an entry and hence creates a new routing entry and | cannot find an entry and hence creates a new routing entry and | |||
forwards the reachability information of the target D to A in a | forwards the reachability information of the target D to A in a | |||
DAO(tgt=D,pathseq=x+1,I_flag=1). | DAO(tgt=D,pathseq=x+1,I_flag=1). | |||
5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), and checks | 5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), and checks | |||
for a routing entry on behalf of D. It finds a routing entry but | for a routing entry on behalf of D. It finds a routing entry but | |||
skipping to change at page 18, line 33 ¶ | skipping to change at page 19, line 15 ¶ | |||
3. C checks for a routing entry on behalf of D, since it cannot find | 3. C checks for a routing entry on behalf of D, since it cannot find | |||
an entry on behalf of D it creates a new routing entry and | an entry on behalf of D it creates a new routing entry and | |||
forwards the reachability information of the target D to H in a | forwards the reachability information of the target D to H in a | |||
DAO(tgt=D,pathseq=x+1,I_flag=1). | DAO(tgt=D,pathseq=x+1,I_flag=1). | |||
4. Similar to C, node H checks for a routing entry on behalf of D, | 4. Similar to C, node H checks for a routing entry on behalf of D, | |||
cannot find an entry and hence creates a new routing entry and | cannot find an entry and hence creates a new routing entry and | |||
forwards the reachability information of the target D to A in a | forwards the reachability information of the target D to A in a | |||
DAO(tgt=D,pathseq=x+1,I_flag=1). | DAO(tgt=D,pathseq=x+1,I_flag=1). | |||
5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), and checks | 5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), and checks | |||
for a routing entry on behalf of D. It finds a routing entry but | for a routing entry on behalf of D. It finds a routing entry but | |||
checks that the next hop for target D is different (i.e. Node | checks that the next hop for target D is different (i.e., Node | |||
G). Node A checks the I_flag and generates | G). Node A checks the I_flag and generates | |||
DCO(tgt=D,pathseq=x+1) to previous next hop for target D which is | DCO(tgt=D,pathseq=x+1) to previous next hop for target D which is | |||
G. Subsequently, Node A updates the routing entry and forwards | G. Subsequently, Node A updates the routing entry and forwards | |||
the reachability information of target D upstream | the reachability information of target D upstream | |||
DAO(tgt=D,pathseq=x+1,I_flag=1). | DAO(tgt=D,pathseq=x+1,I_flag=1). | |||
6. Node G receives the DCO(tgt=D,pathseq=x+1). It checks if the | 6. Node G receives the DCO(tgt=D,pathseq=x+1). It checks if the | |||
received path sequence is latest as compared to the stored path | received path sequence is latest as compared to the stored path | |||
sequence. If it is latest, Node G invalidates routing entry of | sequence. If it is latest, Node G invalidates routing entry of | |||
target D and forwards the (un)reachability information downstream | target D and forwards the (un)reachability information downstream | |||
to B in DCO(tgt=D,pathseq=x+1). | to B in DCO(tgt=D,pathseq=x+1). | |||
skipping to change at page 21, line 17 ¶ | skipping to change at page 22, line 17 ¶ | |||
Bangalore, Karnataka 560037 | Bangalore, Karnataka 560037 | |||
India | India | |||
Phone: +91-080-49160700 | Phone: +91-080-49160700 | |||
Email: rabinarayans@huawei.com | Email: rabinarayans@huawei.com | |||
Zhen Cao | Zhen Cao | |||
Huawei | Huawei | |||
W Chang'an Ave | W Chang'an Ave | |||
Beijing | Beijing | |||
China | P.R. China | |||
Email: zhencao.ietf@gmail.com | Email: zhencao.ietf@gmail.com | |||
End of changes. 51 change blocks. | ||||
94 lines changed or deleted | 130 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/ |