draft-ietf-roll-efficient-npdao-05.txt | draft-ietf-roll-efficient-npdao-06.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: February 25, 2019 Cisco | Expires: March 30, 2019 Cisco | |||
R. Sahoo | R. Sahoo | |||
Z. Cao | Z. Cao | |||
Huawei | Huawei | |||
August 24, 2018 | September 26, 2018 | |||
Efficient Route Invalidation | Efficient Route Invalidation | |||
draft-ietf-roll-efficient-npdao-05 | draft-ietf-roll-efficient-npdao-06 | |||
Abstract | Abstract | |||
This document describes the problems associated with the use of No- | This document describes the problems associated with the use of NPDAO | |||
Path DAO messaging in RPL and signaling changes to improve route | messaging in RPL and signaling changes to improve route invalidation | |||
invalidation efficiency. | 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 | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 February 25, 2019. | This Internet-Draft will expire on March 30, 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements Language and Terminology . . . . . . . . . . 3 | 1.1. Requirements Language and Terminology . . . . . . . . . . 3 | |||
1.2. Current No-Path DAO messaging . . . . . . . . . . . . . . 4 | 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 3 | |||
1.3. Cases when No-Path DAO may be used . . . . . . . . . . . 4 | 1.3. Why NPDAO is important? . . . . . . . . . . . . . . . . . 4 | |||
1.4. Why No-Path DAO is important? . . . . . . . . . . . . . . 5 | 2. Problems with current NPDAO messaging . . . . . . . . 5 | |||
2. Problems with current No-Path DAO messaging . . . . . 5 | ||||
2.1. Lost NPDAO due to link break to the previous parent . . . 5 | 2.1. Lost NPDAO due to link break to the previous parent . . . 5 | |||
2.2. Invalidate routes to dependent nodes of the switching | 2.2. Invalidate routes to dependent nodes . . . . . . . . . . 5 | |||
node . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Possible route downtime caused by async operation of | |||
2.3. Route downtime caused by asynchronous operation of | NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 5 | |||
NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 5 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Req#2: Dependent nodes route invalidation on parent | 3.2. Req#2: Dependent nodes route invalidation on parent | |||
switching . . . . . . . . . . . . . . . . . . . . . . . . 7 | switching . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Req#3: No impact on traffic while NPDAO operation in | 3.3. Req#3: Route invalidation should not impact data traffic 6 | |||
progress . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 6 | |||
4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7 | 4.1. Change in RPL route invalidation semantics . . . . . . . 6 | |||
4.1. Change in RPL route invalidation semantics . . . . . . . 7 | 4.2. Transit Information Option changes . . . . . . . . . . . 7 | |||
4.2. Transit Information Option format change . . . . . . . . 8 | 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 | |||
4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 | 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 | 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 | 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 9 | |||
4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 | 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 9 | |||
4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10 | 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 10 | |||
4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11 | 4.4. Other considerations . . . . . . . . . . . . . . . . . . 11 | |||
4.4. Other considerations . . . . . . . . . . . . . . . . . . 12 | 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 11 | |||
4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12 | 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 11 | |||
4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 13 | Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 12 | |||
Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
1. Introduction | 1. Introduction | |||
RPL [RFC6550] specifies a proactive distance-vector based routing | RPL [RFC6550] specifies a proactive distance-vector based routing | |||
scheme. The specification has an optional messaging in the form of | scheme. RPL has an optional messaging in the form of DAO messages | |||
DAO messages using which the 6LBR can learn route towards any of the | using which the 6LBR can learn route towards the nodes. In storing | |||
nodes. In storing mode, DAO messages would result in routing entries | mode, DAO messages would result in routing entries been created on | |||
been created on all intermediate hops from the node's parent all the | all intermediate hops from the node's parent all the way towards the | |||
way towards the 6LBR. | 6LBR. | |||
RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a | RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a | |||
routing path corresponding to the given target, thus releasing | routing path corresponding to the given target, thus releasing | |||
resources utilized on that path. A No-Path DAO is a DAO message with | resources utilized on that path. A NPDAO is a DAO message with route | |||
route lifetime of zero, originates at the target node and always | lifetime of zero, originates at the target node and always flows | |||
flows upstream towards the 6LBR, signaling route invalidation for the | upstream towards the 6LBR. This document explains the problems | |||
given target. This document explains the problems associated with | associated with the current use of NPDAO messaging and also discusses | |||
the current use of NPDAO messaging and also discusses the | the requirements for an optimized route invalidation messaging | |||
requirements for an optimized No-Path DAO messaging scheme. Further | scheme. Further a new pro-active route invalidation message called | |||
a new pro-active route invalidation message called as "Destination | as "Destination Cleanup Object (DCO)" is specified which fulfills | |||
Cleanup Object (DCO)" is specified which fulfills all mentioned | ||||
requirements of an optimized route invalidation messaging. | requirements of an optimized route invalidation messaging. | |||
6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL and | ||||
specifies use of non-storing and storing MOP for its routing | ||||
operation. Thus an improvement in route invalidation will help | ||||
optimize 6TiSCH based networks. | ||||
1.1. Requirements Language and Terminology | 1.1. Requirements Language and Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
The document only caters to the RPL's storing mode of operation | The document only caters to the RPL's storing mode of operation | |||
(MOP). The non-storing MOP does not require use of NPDAO for route | (MOP). The non-storing MOP does not require use of NPDAO for route | |||
invalidation since routing entries are not maintained on 6LRs. | invalidation since routing entries are not maintained on 6LRs. | |||
Common Ancestor node: 6LR node which is the first common node on the | Common Ancestor node: 6LR node which is the first common node on the | |||
old and new path for the child node. | old and new path for the child node. | |||
NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. | NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. | |||
DCO: Destination Cleanup Object, A new RPL control message type | DCO: Destination Cleanup Object, A new RPL control message type | |||
defined by this draft. | defined by this draft. | |||
Regular DAO: A DAO message with non-zero lifetime. | Regular DAO: A DAO message with non-zero lifetime. | |||
LLN: Low Power and Lossy Networks. | ||||
Target Node: The node switching its parent whose routing adjacencies | ||||
are updated (created/removed). | ||||
This document also uses terminology described in [RFC6550]. | This document also uses terminology described in [RFC6550]. | |||
1.2. Current No-Path DAO messaging | 1.2. Current NPDAO messaging | |||
RPL introduced No-Path DAO messaging in the storing mode so that the | RPL uses NPDAO messaging in the storing mode so that the node | |||
node switching its current parent can inform its parents and | changing it routing adjacencies can invalidate the previous route. | |||
ancestors to invalidate the existing route. Subsequently parents or | This is needed so that nodes along previous path can release any | |||
ancestors would release any resources (such as the routing entry) it | resources (such as the routing entry) it maintains on behalf of | |||
maintains on behalf of target node. The NPDAO message always | target node. | |||
traverses the RPL tree in upward direction, originating at the target | ||||
node itself. | ||||
For the rest of this document consider the following topology: | For the rest of this document consider the following topology: | |||
(6LBR) | (6LBR) | |||
| | | | |||
| | | | |||
| | | | |||
(A) | (A) | |||
/ \ | / \ | |||
/ \ | / \ | |||
skipping to change at page 4, line 44 ¶ | skipping to change at page 4, line 34 ¶ | |||
/ \ | / \ | |||
/ \ | / \ | |||
/ \ | / \ | |||
(E) (F) | (E) (F) | |||
Figure 1: Sample topology | Figure 1: Sample topology | |||
Node (D) is connected via preferred parent (B). (D) has an alternate | Node (D) is connected via preferred parent (B). (D) has an alternate | |||
path via (C) towards the BR. Node (A) is the common ancestor for (D) | path via (C) towards the BR. Node (A) is the common ancestor for (D) | |||
for paths through (B)-(G) and (C)-(H). When (D) switches from (B) to | for paths through (B)-(G) and (C)-(H). When (D) switches from (B) to | |||
(C), [RFC6550] suggests sending No-Path DAO to (B) and regular DAO to | (C), RPL allows sending NPDAO to (B) and regular DAO to (C). | |||
(C). | ||||
1.3. Cases when No-Path DAO may be used | ||||
There are following cases in which a node switches its parent and may | ||||
employ No-Path DAO messaging: | ||||
Case I: Current parent becomes unavailable because of transient or | ||||
permanent link or parent node failure. | ||||
Case II: The node finds a better parent node i.e. the metrics of | ||||
another parent is better than its current parent. | ||||
Case III: The node switches to a new parent whom it "thinks" has a | ||||
better metric but does not in reality. | ||||
The usual steps of operation when the node switches the parent is | ||||
that the node sends a No-Path DAO message via its current parent to | ||||
invalidate its current route and subsequently it tries to establish a | ||||
new routing path by sending a new DAO via its new parent. | ||||
1.4. Why No-Path DAO is important? | 1.3. Why NPDAO is important? | |||
Nodes in LLNs may be resource constrained. There is limited memory | Nodes in LLNs may be resource constrained. There is limited memory | |||
available and routing entry records are the one of the primary | available and routing entry records are one of the primary elements | |||
elements occupying dynamic memory in the nodes. Route invalidation | occupying dynamic memory in the nodes. Route invalidation helps 6LR | |||
helps 6LR nodes to decide which entries could be discarded to better | nodes to decide which entries could be discarded to better achieve | |||
achieve resource utilization in case of contention. Thus it becomes | resource utilization. Thus it becomes necessary to have efficient | |||
necessary to have efficient route invalidation mechanism. Also note | route invalidation mechanism. Also note that a single parent switch | |||
that a single parent switch may result in a "sub-tree" switching from | may result in a "sub-tree" switching from one parent to another. | |||
one parent to another. Thus the route invalidation needs to be done | Thus the route invalidation needs to be done on behalf of the sub- | |||
on behalf of the sub-tree and not the switching node alone. In the | tree and not the switching node alone. In the above example, when | |||
above example, when Node (D) switches parent, the route invalidation | Node (D) switches parent, the route invalidation needs to be done for | |||
needs to be done for (D), (E) and (F). Thus without efficient route | (D), (E) and (F). Thus without efficient route invalidation, a 6LR | |||
invalidation, a 6LR may have to hold a lot of unwanted route entries. | may have to hold a lot of stale route entries. | |||
2. Problems with current No-Path DAO messaging | 2. Problems with current NPDAO messaging | |||
2.1. Lost NPDAO due to link break to the previous parent | 2.1. Lost NPDAO due to link break to the previous parent | |||
When a node switches its parent, the NPDAO is to be sent via its | When a node switches its parent, the NPDAO is to be sent to its | |||
previous parent and a regular DAO via its new parent. In cases where | previous parent and a regular DAO to its new parent. In cases where | |||
the node switches its parent because of transient or permanent parent | the node switches its parent because of transient or permanent parent | |||
link/node failure then the NPDAO message is bound to fail. RPL | link/node failure then the NPDAO message is bound to fail. | |||
assumes communication link with the previous parent for No-Path DAO | ||||
messaging. | ||||
RPL allows use of route lifetime to remove unwanted routes in case | ||||
the routes could not be refreshed. But route lifetimes in case of | ||||
LLNs could be substantially high and thus the route entries would be | ||||
stuck for longer times. | ||||
2.2. Invalidate routes to dependent nodes of the switching node | 2.2. Invalidate routes to dependent nodes | |||
No-path DAO is sent by the node who has switched the parent but it | RPL does not specify how route invalidation will work for dependent | |||
does not work for the dependent child nodes below it. The | nodes rooted at switching node, resulting in stale routing entries of | |||
specification does not specify how route invalidation will work for | the dependent nodes. The only way for 6LR to invalidate the route | |||
sub-childs, resulting in stale routing entries on behalf of the sub- | entries for dependent nodes would be to use route lifetime expiry | |||
childs on the previous route. The only way for 6LR to invalidate the | which could be substantially high for LLNs. | |||
route entries for dependent nodes would be to use route lifetime | ||||
expiry which could be substantially high for LLNs. | ||||
In the example topology, when Node (D) switches its parent, Node (D) | In the example topology, when Node (D) switches its parent, Node (D) | |||
generates an NPDAO on its behalf. Post switching, Node (D) transmits | generates an NPDAO on its behalf. There is no NPDAO generated by | |||
a DIO with incremented DTSN so that child nodes, node (E) and (F), | these child nodes through the previous path resulting in stale | |||
generate DAOs to trigger route update on the new path for themselves. | entries on nodes (B) and (G) for nodes (E) and (F). | |||
There is no NPDAO generated by these child nodes through the previous | ||||
path resulting in stale entries on nodes (B) and (G) for nodes (E) | ||||
and (F). | ||||
2.3. Route downtime caused by asynchronous operation of NPDAO and DAO | 2.3. Possible route downtime caused by async operation of NPDAO and DAO | |||
A switching node may generate both an NPDAO and DAO via two different | A switching node may generate both an NPDAO and DAO via two different | |||
paths at almost the same time. There is a possibility that an NPDAO | paths at almost the same time. There is a possibility that an NPDAO | |||
generated may invalidate the previous route and the regular DAO sent | generated may invalidate the previous route and the regular DAO sent | |||
via the new path gets lost on the way. This may result in route | via the new path gets lost on the way. This may result in route | |||
downtime thus impacting downward traffic for the switching node. In | downtime impacting downward traffic for the switching node. | |||
the example topology, consider Node (D) switches from parent (B) to | ||||
(C) because the metrics of the path via (C) are better. Note that | ||||
the previous path via (B) may still be available (albeit at | ||||
relatively bad metrics). An NPDAO sent from previous route may | ||||
invalidate the existing route whereas there is no way to determine | ||||
whether the new DAO has successfully updated the route entries on the | ||||
new path. | ||||
3. Requirements for the No-Path DAO Optimization | In the example topology, consider Node (D) switches from parent (B) | |||
to (C). An NPDAO sent from previous route may invalidate the | ||||
existing route whereas there is no way to determine whether the new | ||||
DAO has successfully updated the route entries on the new path. | ||||
3. Requirements for the NPDAO Optimization | ||||
3.1. Req#1: Tolerant to link failures to the previous parents | 3.1. Req#1: Tolerant to link failures to the previous parents | |||
When the switching node sends the NPDAO message to the previous | When the switching node sends the NPDAO message to the previous | |||
parent, it is normal that the link to the previous parent is prone to | parent, it is normal that the link to the previous parent is prone to | |||
failure. Therefore, it is required that the NPDAO message MUST be | failure. Therefore, it is required that the NPDAO message must be | |||
tolerant to the link failure during the switching. The link referred | tolerant to the link failure. The link referred here represents the | |||
here represents the link between the node and its previous parent | link between the node and its previous parent (from whom the node is | |||
(from whom the node is now disassociating). | now disassociating). | |||
3.2. Req#2: Dependent nodes route invalidation on parent switching | 3.2. Req#2: Dependent nodes route invalidation on parent switching | |||
While switching the parent node and sending NPDAO message, it is | It should be possible to do route invalidation for dependent nodes | |||
required that the routing entries to the dependent nodes of the | rooted at the switching node. | |||
switching node will be updated accordingly on the previous parents | ||||
and other relevant upstream nodes. | ||||
3.3. Req#3: No impact on traffic while NPDAO operation in progress | 3.3. Req#3: Route invalidation should not impact data traffic | |||
While sending the NPDAO and DAO messages, it is possible that the | While sending the NPDAO and DAO messages, it is possible that the | |||
NPDAO successfully invalidates the previous path, while the newly | NPDAO successfully invalidates the previous path, while the newly | |||
sent DAO gets lost (new path not set up successfully). This will | sent DAO gets lost (new path not set up successfully). This will | |||
result into downstream unreachability to the current switching node. | result in downstream unreachability to the node switching paths. | |||
Therefore, it is desirable that the NPDAO is synchronized with the | Therefore, it is desirable that the route invalidation is | |||
DAO to avoid the risk of route downtime. | synchronized with the DAO to avoid the risk of route downtime. | |||
4. Proposed changes to RPL signaling | 4. Proposed changes to RPL signaling | |||
4.1. Change in RPL route invalidation semantics | 4.1. Change in RPL route invalidation semantics | |||
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 | |||
skipping to change at page 8, line 5 ¶ | skipping to change at page 7, line 5 ¶ | |||
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. Transit Information Option format change | 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. 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 Transit Information option to contain | The draft proposes a change in Transit Information option to contain | |||
skipping to change at page 9, line 42 ¶ | skipping to change at page 8, line 42 ¶ | |||
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 is expected to send a | K: The 'K' flag indicates that the recipient is expected to send a | |||
DCO-ACK back. | DCO-ACK back. | |||
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 flags. The field MUST be initialized to zero by the sender and | for future use. These bits MUST be initialized to zero by the sender | |||
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. | |||
DCOSequence: Incremented at each unique DCO message from a node and | DCOSequence: Incremented at each unique DCO message from a node and | |||
echoed in the DCO-ACK message. | echoed in the DCO-ACK message. | |||
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that | DODAGID (optional): 128-bit unsigned integer set by a DODAG root that | |||
uniquely identifies a DODAG. This field is only present when the 'D' | uniquely identifies a DODAG. This field is only present when the 'D' | |||
flag is set. This field is typically only present when a local | flag is set. This field is typically only present when a local | |||
skipping to change at page 12, line 30 ¶ | skipping to change at page 11, line 30 ¶ | |||
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 | |||
the proposed DCO and the existing NPDAO mechanism. | the proposed DCO and the existing NPDAO mechanism. | |||
5. Acknowledgements | 5. Acknowledgements | |||
Many thanks to Cenk Gundogan, Simon Duquennoy, and Georgios | Many thanks to Cenk Gundogan, Simon Duquennoy, Georgios | |||
Papadopoulous for their review and comments. | Papadopoulous, Peter Van Der Stok for their review and comments. | |||
6. IANA Considerations | 6. IANA Considerations | |||
IANA is requested to allocate new ICMPv6 RPL control codes in RPL | IANA is requested to allocate new ICMPv6 RPL control codes in RPL | |||
[RFC6550] for DCO and DCO-ACK messages. | [RFC6550] for DCO and DCO-ACK messages. | |||
+------+---------------------------------------------+--------------+ | +------+---------------------------------------------+--------------+ | |||
| Code | Description | Reference | | | Code | Description | Reference | | |||
+------+---------------------------------------------+--------------+ | +------+---------------------------------------------+--------------+ | |||
| 0x04 | Destination Cleanup Object | This | | | 0x04 | Destination Cleanup Object | This | | |||
skipping to change at page 15, line 16 ¶ | skipping to change at page 14, line 16 ¶ | |||
Kundalahalli Village, Whitefield, | Kundalahalli Village, Whitefield, | |||
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 560037 | Beijing | |||
China | China | |||
Email: zhencao.ietf@gmail.com | Email: zhencao.ietf@gmail.com | |||
End of changes. 36 change blocks. | ||||
153 lines changed or deleted | 111 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/ |