| Internet-Draft | Eliding RPL Info | October 2019 |
| Thubert, et al. | Expires 17 April 2020 | [Page] |
This document presents a method to elide a group of global RPL options by synchonizing the state associated with each of these options between parent and child using a new sequence counter in DIO messages. A child that missed a DIO message with an update of any of those protected options detects it by the change of sequence counter and queries the update with a DIS Message.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 April 2020.¶
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Classical Link State protocol synchronize their Link State Database (LSDB) by sequencing every change. Each interested node maintains the last sequence of the LSDB it is synchronizing with. If a last known sequence is older than the current, the node needs to learn one by one all the state changes between the last known and the current state.¶
[RPL] does not operate that way. With RPL, the routing information is repeated over and over in DODAG Information Object (DIO) and Destination Advertisement Object (DAO) messages. There is no concept of synchronization. The most recent information overrides a previous one and a stale state eventually times out.¶
The RPL way was designed to enable routing from most nodes to most nodes most of the time in a Low-Power Lossy Network (LLN) where the quality of the links and the cost of communications does not permit to maintain a permanent synchronization. This principle was applied to both the routing information and non-routing state such as configuration settings, prefix information, and node capabilities.¶
This non-routing state may be needed to decide whether a node can join a network as a leaf or as a router, and may affect the parent selection. [RPL] allows a parent to elide that information in the DIO it sends repeatedly, but if it does so, a newcomer child may have missed the early DIOs that contained the configuration option and live with only partial information. If it is pessimistic, it may query all possible information even when it is not needed. Conversely, a node that slept may have missed a DIO message with a change in some critical information and not be aware of it, so it may fail to query for the update and operate on deprecated parameters.¶
This document uses a new sequence counter to synchronize the state in a child node with that of its parent, and recursively with that of the network.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Terminology used in this document is consistent with and incorporates that described in Terms Used in Routing for Low-Power and Lossy Networks (LLNs). [RFC7102].¶
Other terms in use in LLNs are found in Terminology for Constrained-Node Networks [RFC7228].¶
A glossary of classical RPL acronyms is given in Section 2.3.¶
The term "byte" is used in its now customary sense as a synonym for "octet".¶
"RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO and DIS messages are defined in the "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RPL] specification.¶
This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware Leaf (RAL) consistently with [USE_OF_RPL_INFO].¶
The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses a RPL router (without necessarily knowing it) as 6LR and depends on that router to obtain reachability for its addresses inside the RPL domain. On the contrary, the term RPL-Aware Node (RAN) is used to refer to a RAL or a RPL router that participates to RPL and advertises its addresses of prefixes by itself.¶
This document often uses the following acronyms:¶
This document adds a sequence counter called RPL Configuration State Sequence (RCSS) to the DIO message. The RCSS is set by the root and operated as specified in Section 7 of [RPL], more in Section 4.¶
This document introduces a new RPL Control Message Options called the Abbreviated Option Option (AOO). The AOO is an empty replacement of an existing option that indicates the RCSS of the last change of that option.¶
This document modifies the Solicited Information Option to enable the individual query of the protected options by a node that missed a change, more in Section 7.¶
The format of the DIO Base Object is defined in section 6.3.1 of [RPL]. This specification uses a 8th octet that was previously reserved to transport the RCSS.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | RCSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Updated fields:¶
The RCSS protects network-wide options that are set by the root and that are propagated without a change down the DODAG. The RCSS MUST be incremented when the root sends a DIO where at least one of the protected options is modified. It MUST propagated down without a change together with the options that it protects.¶
During the straight part of the lollipop, a second reboot of the root might not be recognized and a same value of the RCSS may appear with new values in the protected options. For that reason the protected options MUST be present in the DIOs during the straight part of the lollipop and the root SHOULD move rapidly away from the straight part once the network has settled by resetting the RCSS to 0, which places the RCSS in the circular region of the lollipop.¶
The protected options are:¶
When a protected option is unchanged from the previous DIOs, the root MAY replace it with its abbreviated version. The abbreviated version of an option is transported in a 4-bytes long Abbreviated Option Option (AOO). The AOO indicates the RCSS at which the protected option was last changed.¶
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Abbrev. opt. | Last Mod RCSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option fields:¶
When a field is modified in one of the protected options in a fashion that may affect the routing or forwarding decision inside the DODAG, the root MUST send a DIO with the protected options. Unchanged options may be abreviated as discussed in Section 5.¶
The freshness of the protected options is asserted based on the RCSS. RCSS values are compared as described in section 7.2 of [RPL]. When a parent exposes a new RCSS, the child node SHOULD refrain from using that parent until it has resynchronized all the protected fields to the latest. When it is resynchronized, the child SHOULD refrain from using other parents that expose an older RCSS.¶
A child MUST store the content of all the protected options and keep track of the RCSS of the DIO where each of these option was last seen in a non-abbreviated version. If that RCSS is fresher than the Last Modification RCSS in the abbreviated version of the option then the child is up-to-date for that option. If a protected option elided in a DIO and not abbreviated, and the child has a stored RCSS value for that option that is lower than the RCSS in the DIO, then the child MUST query that option from the parent to ensure that is has the latest. This is done with a DIS message as indicated in Section 7.¶
A new entries is required for the new option of type "Abbreviated Option", from the "RPL Control Message Options" space defined for [RPL].¶
| Value | Meaning | Reference |
| TBD IANA | Abbreviated Option | THIS RFC |