< draft-thubert-roll-eliding-dio-information-00.txt   draft-thubert-roll-eliding-dio-information-01.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550 (if approved) D. Barthel Updates: 6550 (if approved) D. Barthel
Intended status: Standards Track Orange Labs Intended status: Standards Track Orange Labs
Expires: 17 April 2020 R.A. Jadhav Expires: 19 April 2020 R.A. Jadhav
Huawei Tech Huawei Tech
15 October 2019 17 October 2019
Eliding and Querying RPL Information Eliding and Querying RPL Information
draft-thubert-roll-eliding-dio-information-00 draft-thubert-roll-eliding-dio-information-01
Abstract Abstract
This document presents a method to elide a group of global RPL This document presents a method to safely elide a group of global RPL
options by synchonizing the state associated with each of these options by synchonizing the state associated with each of these
options between parent and child using a new sequence counter in DIO 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 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 those protected options detects it by the change of sequence counter
and queries the update with a DIS Message. and queries the update with a DIS Message.
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.
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 17 April 2020. This Internet-Draft will expire on 19 April 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5
4. New RPL Configuration State Sequence . . . . . . . . . . . . 4 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protected Options . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 5
6. Child Operation . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Updated DIS Base Object . . . . . . . . . . . . . . . . . 6
7. Pulling Options . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. New Abbreviated Option Option . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.2. RCSS Freshness and Parent selection . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. RCSS of an Option . . . . . . . . . . . . . . . . . . . . 10
12. Normative References . . . . . . . . . . . . . . . . . . . . 7 6. Synchronizing Options . . . . . . . . . . . . . . . . . . . . 11
13. Informative References . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. New DODAG Information Object Flags . . . . . . . . . . . 11
8.2. New RPL Control Message Option . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . 12
11. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Classical Link State protocol synchronize their Link State Database Classical Link State protocol synchronize their Link State Database
(LSDB) by sequencing every change. Each interested node maintains (LSDB) by sequencing every change. Each interested node maintains
the last sequence of the LSDB it is synchronizing with. If a last the last sequence of the LSDB it is synchronizing with. If the last
known sequence is older than the current, the node needs to learn one known sequence number is older than the current, the node needs to
by one all the state changes between the last known and the current learn one by one all the state changes between the last known and the
state. current state.
[RPL] does not operate that way. With RPL, the routing information [RPL] does not operate that way. With RPL, the routing information
is repeated over and over in DODAG Information Object (DIO) and is repeated over and over in DODAG Information Object (DIO) and
Destination Advertisement Object (DAO) messages. There is no concept Destination Advertisement Object (DAO) messages. There is no concept
of synchronization. The most recent information overrides a previous of synchronization. The most recent information overrides a previous
one and a stale state eventually times out. one and a stale state eventually times out.
The RPL way was designed to enable routing from most nodes to most 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 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 quality of the links and the cost of communications does not permit
to maintain a permanent synchronization. This principle was applied to maintain a permanent synchronization.
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 This principle was applied to both the routing and non-routing
join a network as a leaf or as a router, and may affect the parent information such as configuration settings, prefix information, and
selection. [RPL] allows a parent to elide that information in the node capabilities.
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 This non-routing state is carried in RPL Messages as options. Some
a child node with that of its parent, and recursively with that of of the DIO options may be needed to decide whether a node can join a
the network. network as a leaf or as a router, and may affect the parent selection
or the address selection. It is thus critical that each node
maintains its state to the freshest and selects parents that are also
synchronized to the freshest.
[RPL] allows a parent to elide options in the DIO messages that it
sends repeatedly, to conserve battery and save bandwidth. When it
does so, a newcomer child that missed DIOs that contained the
configuration option may operate on default or partial information.
If it is pessimistic, it may query all possible the information even
when it is not needed. Conversely, a node that slept may have missed
a DIO with a change in some critical information and may not be even
aware of it, so it may fail to query for the update and operate on
deprecated parameters.
This document uses a new sequence counter called RCSS to synchronize
the state in a child node with that of its parent, and recursively
with that of the whole network, to the latest setting from the Root.
The protected options are:
1. The Route Information Option (RIO) defined in section 6.7.5 of
[RPL]
2. The DODAG Configuration Option (DCO) defined in section 6.7.6 of
[RPL]
3. The Prefix Information Option (PIO) defined in section 6.7.10 of
[RPL]
4. The Extended MOP Option (MOPex) defined in [MOPEX-CAP]
5. The Global Capabilities Option (GCO) defined in [MOPEX-CAP]
Any change in those options causes an increment of the RCSS and
enables a network-wide synchronization to the new state. If the
change impacts the routing substantially, the Root should decide to
increment the Version Number at the same time to fully rebuild the
DODAG with the new settings of the options. It must be noted that
the operation of the Version Number in itself provides no guarantee
that the non-routing state is fully resynchronized everywhere unless
all the options are present in all the DIO messages.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. References 2.2. References
The Terminology used in this document is consistent with and The Terminology used in this document is consistent with and
incorporates that described in Terms Used in Routing for Low-Power incorporates that described in Terms Used in Routing for Low-Power
and Lossy Networks (LLNs). [RFC7102]. and Lossy Networks [RFC7102].
Other terms in use in LLNs are found in Terminology for Other terms in use in LLNs are found in Terminology for
Constrained-Node Networks [RFC7228]. Constrained-Node Networks [RFC7228].
A glossary of classical RPL acronyms is given in Section 2.3. 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 The term "byte" is used in its now customary sense as a synonym for
"octet". "octet".
"RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO
skipping to change at page 4, line 12 skipping to change at page 5, line 4
that router to obtain reachability for its addresses inside the RPL that router to obtain reachability for its addresses inside the RPL
domain. On the contrary, the term RPL-Aware Node (RAN) is used to 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 refer to a RAL or a RPL router that participates to RPL and
advertises its addresses of prefixes by itself. advertises its addresses of prefixes by itself.
2.3. Glossary 2.3. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
DODAG Destination-Oriented Directed Acyclic Graph DODAG Destination-Oriented Directed Acyclic Graph
LLN Low-Power and Lossy Network LLN Low-Power and Lossy Network
RPI RPL Packet Information (an Option in the Hop-By_Hop Header) RPI RPL Packet Information (an Option in the Hop-By_Hop Header)
RAL RPL-Aware Leaf RAL RPL-Aware Leaf
RAN RPL-Aware Node, a RPL router or a RPL-Aware Leaf RAN RPL-Aware Node, a RPL router or a RPL-Aware Leaf
RS Router Solicitation RS Router Solicitation
RCSS RPL Configuration State Sequence
RPL IPv6 Routing Protocol for LLNs (pronounced ripple) RPL IPv6 Routing Protocol for LLNs (pronounced ripple)
RUL RPL-Unaware Leaf RUL RPL-Unaware Leaf
3. Updating RFC 6550 3. Updating RFC 6550
This document adds a sequence counter called RPL Configuration State This document adds a new field called RCSS to the DIO message. The
Sequence (RCSS) to the DIO message. The RCSS is set by the root and RCSS is a sequence counter set by the Root and operated as specified
operated as specified in Section 7 of [RPL], more in Section 4. in Section 7 of [RPL], more in Section 5.
This document introduces a new RPL Control Message Options called the This document also introduces a new RPL Control Message Option called
Abbreviated Option Option (AOO). The AOO is an empty replacement of the Abbreviated Option Option (AOO). The AOO is the compressed
an existing option that indicates the RCSS of the last change of that replacement of a protected option that indicates the RCSS of the last
option. change of that option, but elides its content, more in Section 4.3.
This document modifies the Solicited Information Option to enable the This document modifies the DIS Base Objectto enable the individual
individual query of the protected options by a node that missed a query of the protected options by a node that missed a change, more
change, more in Section 7. in Section 4.2.
4. New RPL Configuration State Sequence 4. Message Formats
4.1. Updated DIO Base Object
The format of the DIO Base Object is defined in section 6.3.1 of 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 [RPL]. This specification uses a 8th octet that was reserved in
reserved to transport the RCSS. [RPL] to transport the RCSS.
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 |Version Number | Rank | | RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | RCSS | |G|0| MOP | Prf | DTSN | Flags | RCSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: MOdified DIO Base Object Figure 1: Updated DIO Base Object
Updated fields: Updated fields:
RCSS RCSS
One Byte, the RPL Configuration State Sequence One Byte, the RPL Configuration State Sequence
The RCSS protects network-wide options that are set by the root and 4.2. Updated DIS Base Object
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 The DIS Base Object is use by a child to query from a parent the most
might not be recognized and a same value of the RCSS may appear with recent changes in protected options. This specification adds flags
new values in the protected options. For that reason the protected to indicate which options are requested and the freshest RCSS to
options MUST be present in the DIOs during the straight part of the which the querying node was synchronized.
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.
5. Protected Options 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|D|P[M|O| Flg | LastSync RCSS | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The protected options are: Figure 2: Updated DIS Base Object
1. The Route Information Option (RIO) defined in section 6.7.5 of Updated fields:
[RPL]
2. The DODAG Configuration Option (DCO) defined in section 6.7.6 of R
[RPL] One Bit, indicates that the RIO is requested
3. The Prefix Information Option (PIO) defined in section 6.7.10 of D
[RPL] One Bit, indicates that the DCO is requested
4. The Extended MOP Option (MOPex) defined in [MOPEX-CAP] P
One Bit, indicates that the PIO(s) is(are) requested
5. The Global Capabilities Option (GCO) defined in [MOPEX-CAP] M
One Bit, indicates that the MOPex is requested
When a protected option is unchanged from the previous DIOs, the root O
One Bit, indicates that the GCO is requested
Last Synchronized RCSS
One Byte, indicates the freshest RCSS to which the querier was
synchronized
4.3. New Abbreviated Option Option
When a protected option is unchanged from the previous DIOs, the Root
MAY replace it with its abbreviated version. The abbreviated version MAY replace it with its abbreviated version. The abbreviated version
of an option is transported in a 4-bytes long Abbreviated Option of an option is transported in a 4-bytes long Abbreviated Option
Option (AOO). The AOO indicates the RCSS at which the protected Option (AOO). The AOO indicates the RCSS at which the protected
option was last changed. option was last changed.
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 2 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 Type | Option Length | Abbrev. opt. | Last Mod RCSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Abbreviated Option Option Format Figure 3: Abbreviated Option Option Format
Option fields: Option fields:
Option Type Option Type
One byte indicating "Abbreviated Option", see Table 1 One byte indicating "Abbreviated Option", see Table 2 in
Section 8.2
Option Length Option Length
MUST be set to 2 indicating Option data of 2 bytes MUST be set to 2 indicating Option data of 2 bytes
Abbreviated Option Abbreviated Option
The Option Type of the option being abreviated The Option Type of the option being abbreviated
Last Modification RCSS Last Modification RCSS
The RCSS at which the option was last modified The RCSS at which the option was last modified
6. Child Operation 5. RCSS Operation
When a field is modified in one of the protected options in a fashion Settings and updates to network-wide parameters are initiated by the
that may affect the routing or forwarding decision inside the DODAG, Root and propagated down the DODAG in RPL Control Message Options in
the root MUST send a DIO with the protected options. Unchanged DIO messages. The DIO messages arrive asynchronously via different
options may be abreviated as discussed in Section 5. parents and may confuse a child. The RCSS allows the child to keep
synchronized to the latest settings network-wide parameters that are
propagated in protected options.
The freshness of the protected options is asserted based on the RCSS. The RCSS is a sequence number that is operated as specified in
RCSS values are compared as described in section 7.2 of [RPL]. When section 7.2 of [RPL]. The scope of an RCSS is one DODAG within one
a parent exposes a new RCSS, the child node SHOULD refrain from using RPL Instance. The RCSS applies to a DIO Message and a same value of
that parent until it has resynchronized all the protected fields to the RCSS can be used in DIO messages that are sent consecutively with
the latest. When it is resynchronized, the child SHOULD refrain from no change in the protected options.
using other parents that expose an older RCSS.
A child MUST store the content of all the protected options and keep The Root of the DODAG is autoritative to set and update the RCSS and
track of the RCSS of the DIO where each of these option was last seen the options that it protects. The RCSS and the protected options are
in a non-abbreviated version. If that RCSS is fresher than the Last propagated together down the DODAG without a change, more in
Modification RCSS in the abbreviated version of the option then the Section 5.1.
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.
7. Pulling Options The RCSS allows a child node to recognize the fresher DIO Message(s)
as received from one or more advertising parents and to use only
parents with a consistent state of network-wide parameters, more in
Section 5.2.
8. Security Considerations By extension, the RCSS is also defined for each protected option. A
child associates an option with the values of the RCSS indicated in
DIO Messages in which the option is advertised and uses it to assess
the relative freshness of different versions of an option, more in
Section 5.3.
TBD Unchanged options may be sent in full, elided, or in the abbreviated
form specified in Section 4.3. Eliding an option is NOT RECOMMENDED
as it may cause multiple children to resynchronize the option even if
it was not changed.
9. IANA Considerations If the link MTU does not permit to send a single DIO message with all
the options packaged then the options may be spread over multiple
consecutive DIO messages with the same RCSS that are sent in a rapid
sequence.
A new entries is required for the new option of type "Abbreviated 5.1. Updating the RCSS
Option", from the "RPL Control Message Options" space defined for
[RPL].
+----------+--------------------+-----------+ The RCSS is incremented by the Root using a lollipop technique as
| Value | Meaning | Reference | specified in section 7.2 of [RPL]. RCSS values are comparable if
+==========+====================+===========+ they are within a window of comparison of SEQUENCE_WINDOW increments
| TBD IANA | Abbreviated Option | THIS RFC | or one indicates a reboot.
+----------+--------------------+-----------+
Table 1: New Option Type A reboot of the Root is detected when the RCSS moves from the
circular to the straight part of the lollipop. In order to maximize
the chances of detection, the straight part should be kept very short
with a RECOMMENDED initialization at 252 or above.
10. Security Considerations 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 reappear
with different settings in the protected options. For that reason
the protected options MUST be provided in full with each increment on
the RCSS during the straight part of the lollipop.
When a field is modified in one of the protected options, the Root
MUST send a DIO with an incremented RCSS and the modified protected
option(s) in full. The Root MAY also update the Version Number to
form a new DODAG altogether.
The Root SHOULD jump rapidly away from the straight part once the
network has sufficiently settled by resetting the RCSS to 0, which
places the RCSS in the circular region of the lollipop, where the
protected options MAY be elided or abbreviated.
5.2. RCSS Freshness and Parent selection
A child node maintains the freshest RCSS received from its parents in
each of the RPL Instances that it participates to, and uses that RCSS
for its own DIO messages.
A child and a candidate parent are out-of-sync when the RCSS values
that they maintain for a RPL Instance are not comparable. A child
MUST NOT use a parent that is out-of-sync unless no other parent is
available, in which case it MAY align its RCSS and resynchronize to
that parent.
When a child receives from a candidate parent a DIO with an RCSS that
is fresher than the one it is using, the child MUST synchronize the
state relative to the protected options with that parent. The child
node MUST refrain from using that parent and the new state including
the RCSS, until it has synchronized all of the protected options to
that RCSS. When it is fully synchronized, the child may then use
that parent and the new RCSS.
Using a back-level parent may cause packets to be dropped,
misunderstood or misrouted. The child SHOULD refrain from using a
parent that exposes an older RCSS if the change causes an
incompatibility issue.
5.3. RCSS of an Option
By extension, the RCSS of an option is maintained by a child as the
freshest RCSS indicated by a DIO message from a candidate parent in
which the option was present in the abbreviated form or in full. A
child maintains a state for the freshest RCSS received for each of
the protected options and synchronizes its state for each option to
the freshest RCSS of that option.
When a child receives a DIO from a candidate parent, for each option:
If the Option is advertised in the abbreviated form then the RCSS
that the DIO advertises for the option is the Last Modification
RCSS of the AOO, else
If the Option is advertised in full then the RCSS that the DIO
advertises for the option is the RCSS of the DIO, else
If the Option is elided then the RCSS is unspecified but it is at
most as fresh as the RCSS of the DIO, and the RCSS of the DIO is
assumed for the comparison
This means that if an Option is advertised in both the abbreviated
form and in full in a same DIO message then the RCSS in the AOO has
precedence.
To keep the RCSS comparable for each option, the RCSS of an option
must lazily progress along with the global RCSS even if there was no
change in the options. Each parent including the Root MUST advertise
a new RCSS for each of the protected options at least once within a
sliding window of SEQUENCE_WINDOW increments.
When an option was not changed for a new RCSS, one parent may
advertise it in the abbreviated form while another sends the option
in full only, e.g., in response to a DIS message. A fresher RCSS
indicates that the option is either the same or carries a more recent
update than the one with an older RCSS.
The RCSS of an option may be obtained from a DIO message that carries
the option in full even if the RCSS of the DIO is not the freshest
across parents, as long as the RCSS of the DIO is fresher than the
current one for that option.
If current value of the maintained RCSS for an given option is not as
fresh or fresher than that advertised in a DIO message, then the
child MUST update its state for that option as specified in
Section 6.
6. Synchronizing Options
A child can resynchronize any of the protected options to the latest
RCSS by sending a DIS Message to a candidate parent that advertises
that RCSS in DIO messages. The child MUST set the desired
combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the
option(s) that it needs updated. The child MUST signal in the Last
Synchronized RCSS field of the DIS the freshest value of RCSS for
which it was fully synchronized, or a conventional value of OUT-OF-
SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with
the parent.
The DIO message that is sent in response MUST contain in full all the
options that are requested and that were updated since the Last
Synchronized RCSS in the DIS Message. This means all of the
protected options of the child was never synchronized or is out-of-
sync with the parent. The other options MUST be added in the
abbreviated form. The options MAY be spread over more than one DIO
message sent in a quick sequence and the child SHOULD wait a
reasonable technology-dependent time before it retries the request.
7. Security Considerations
TBD TBD
11. Acknowledgments 8. IANA Considerations
12. Normative References 8.1. New DODAG Information Object Flags
5 new bits are allocated in the Registry for the DODAG Information
Object (DIO) Flags defined for [RPL].
+------------+----------------------------+--------------+
| Bit Number | Capability description | Defining RFC |
+============+============================+==============+
| 0 | 'R' bit "RIO requested" | THIS RFC |
+------------+----------------------------+--------------+
| 1 | 'D' bit "DCO requested" | THIS RFC |
+------------+----------------------------+--------------+
| 2 | 'P' bit "PIO(s) requested" | THIS RFC |
+------------+----------------------------+--------------+
| 3 | 'M' bit "MOPex requested" | THIS RFC |
+------------+----------------------------+--------------+
| 4 | 'O' bit "GCO irequested" | THIS RFC |
+------------+----------------------------+--------------+
Table 1: New DIO Flags
8.2. New RPL Control Message Option
A new entry is required for the new option of type "Abbreviated
Option", from the "RPL Control Message Options" space defined for
[RPL].
+----------+--------------------+--------------+
| Code | Description | Defining RFC |
+==========+====================+==============+
| TBD IANA | Abbreviated Option | THIS RFC |
+----------+--------------------+--------------+
Table 2: New Option Type
9. Acknowledgments
10. Normative References
[MOPEX-CAP] [MOPEX-CAP]
Jadhav, R. and P. Thubert, "Mode of Operation extension Jadhav, R. and P. Thubert, "Mode of Operation extension
and Capabilities", Internet-Draft, draft-ietf-roll-mopex- and Capabilities", Work in Progress, Internet-Draft,
cap-00, 9 August 2019, <https://tools.ietf.org/html/draft- draft-ietf-roll-mopex-cap-00, 9 August 2019,
ietf-roll-mopex-cap-00>. <https://tools.ietf.org/html/draft-ietf-roll-mopex-cap-
00>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
skipping to change at page 8, line 30 skipping to change at page 13, line 10
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[USE_OF_RPL_INFO] [USE_OF_RPL_INFO]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPL
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Internet-Draft, IPv6 encapsulation in the RPL Data Plane", Work in
draft-ietf-roll-useofrplinfo-31, 7 August 2019, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-31,
<https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo- 7 August 2019, <https://tools.ietf.org/html/draft-ietf-
31>. roll-useofrplinfo-31>.
13. Informative References 11. Informative References
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D, 45 Allee des Ormes - BP1200 Building D, 45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
 End of changes. 50 change blocks. 
126 lines changed or deleted 332 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/