< draft-thubert-roll-eliding-dio-information-01.txt   draft-thubert-roll-eliding-dio-information-02.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) R.A. Jadhav
Intended status: Standards Track Orange Labs Intended status: Standards Track Huawei Tech
Expires: 19 April 2020 R.A. Jadhav Expires: 27 April 2020 L. Zhao
Huawei Tech Cisco Systems
17 October 2019 D. Barthel
Orange Labs
25 October 2019
Eliding and Querying RPL Information Eliding and Querying RPL Information
draft-thubert-roll-eliding-dio-information-01 draft-thubert-roll-eliding-dio-information-02
Abstract Abstract
This document presents a method to safely elide a group of global RPL This document presents a method to safely elide a group of RPL
options by synchonizing the state associated with each of these options in a DIO message by synchonizing the state associated with
options between parent and child using a new sequence counter in DIO each of these options between parent and child using a new sequence
messages. A child that missed a DIO message with an update of any of counter in DIO or DAO messages. A child that missed a DIO message
those protected options detects it by the change of sequence counter with an update of any of those protected options detects it by the
and queries the update with a DIS Message. change of sequence counter and queries the update with a DIS Message.
The draft also provides a method to fully elide the options in a DAO
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.
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 19 April 2020. This Internet-Draft will expire on 27 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
skipping to change at page 2, line 14 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 5 4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 6
4.2. Updated DIS Base Object . . . . . . . . . . . . . . . . . 6 4.2. Updated DIS Base Object . . . . . . . . . . . . . . . . . 6
4.3. New Abbreviated Option Option . . . . . . . . . . . . . . 7 4.3. New Abbreviated Option Option . . . . . . . . . . . . . . 7
4.4. Updated DAO Base Object . . . . . . . . . . . . . . . . . 8
5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8 5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 8 5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 9
5.2. RCSS Freshness and Parent selection . . . . . . . . . . . 9 5.2. RCSS Freshness and Parent selection . . . . . . . . . . . 10
5.3. RCSS of an Option . . . . . . . . . . . . . . . . . . . . 10 5.3. RCSS of an Option . . . . . . . . . . . . . . . . . . . . 10
6. Synchronizing Options . . . . . . . . . . . . . . . . . . . . 11 6. Synchronizing Options . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Abbreviating the DAO Message . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. New DODAG Information Object Flags . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. New RPL Control Message Option . . . . . . . . . . . . . 12 9.1. New DODAG Information Solicitation Flags . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. New DODAG Advertisement Object Flag . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 12 9.3. New RPL Control Message Option . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
12. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 the last the last sequence of the LSDB it is synchronizing with. If the last
known sequence number is older than the current, the node needs to known sequence number is older than the current, the node needs to
learn one by one all the state changes between the last known and the learn one by one all the state changes between the last known and the
current state. current state.
skipping to change at page 5, line 31 skipping to change at page 5, line 38
This document adds a new field called RCSS to the DIO message. The This document adds a new field called RCSS to the DIO message. The
RCSS is a sequence counter set by the Root and operated as specified RCSS is a sequence counter set by the Root and operated as specified
in Section 7 of [RPL], more in Section 5. in Section 7 of [RPL], more in Section 5.
This document also introduces a new RPL Control Message Option called This document also introduces a new RPL Control Message Option called
the Abbreviated Option Option (AOO). The AOO is the compressed the Abbreviated Option Option (AOO). The AOO is the compressed
replacement of a protected option that indicates the RCSS of the last replacement of a protected option that indicates the RCSS of the last
change of that option, but elides its content, more in Section 4.3. change of that option, but elides its content, more in Section 4.3.
This document modifies the DIS Base Objectto enable the individual This document modifies the DIS Base Object to enable the individual
query of the protected options by a node that missed a change, more query of the protected options by a node that missed a change, more
in Section 4.2. in Section 4.2.
4. Message Formats This document also enables to abbreviate a full DAO message when all
the options are unchanged from the previous DAO message that was
positively acknowledged. In that case the DAO is resent with the
same DAOSequence and all the options are elided. A new flag in the
DAO Base Object indicates that this is an abbreviated DAO message,
more in Section 7.
4. Message Formats
4.1. Updated DIO Base Object 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 reserved in [RPL]. This specification uses a 8th octet that was reserved in
[RPL] 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 |
skipping to change at page 7, line 20 skipping to change at page 7, line 26
O O
One Bit, indicates that the GCO is requested One Bit, indicates that the GCO is requested
Last Synchronized RCSS Last Synchronized RCSS
One Byte, indicates the freshest RCSS to which the querier was One Byte, indicates the freshest RCSS to which the querier was
synchronized synchronized
4.3. New Abbreviated Option Option 4.3. New Abbreviated Option Option
When a protected option is unchanged from the previous DIOs, the Root The abbreviated version of an option is a replacement for any option.
MAY replace it with its abbreviated version. The abbreviated version It does not advertise the content of the option but indicates the
of an option is transported in a 4-bytes long Abbreviated Option sender's value for the RCSS of that option. It is transported in a
Option (AOO). The AOO indicates the RCSS at which the protected 4-bytes long Abbreviated Option Option (AOO) with a format as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Abbrev. opt. | Last Mod RCSS | | Option Type | Option Length | Abbrev. opt. | Last Mod RCSS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 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 2 in One byte indicating "Abbreviated Option", see Table 3 in
Section 8.2 Section 9.3
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 abbreviated 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
4.4. Updated DAO Base Object
The format of the DAO Base Object is defined in section 6.4.1 of
[RPL]. This specification adds a 'A' flag in to indicate the DAO
options eliding.
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 |K|D|A| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 4: Updated DAO Base Object
Updated fields:
A
One Bit, indicates DAO in abbreviated version
5. RCSS Operation 5. RCSS Operation
Settings and updates to network-wide parameters are initiated by the Settings and updates to network-wide parameters are initiated by the
Root and propagated down the DODAG in RPL Control Message Options in Root and propagated down the DODAG in RPL Control Message Options in
DIO messages. The DIO messages arrive asynchronously via different DIO messages. The DIO messages arrive asynchronously via different
parents and may confuse a child. The RCSS allows the child to keep parents and may confuse a child. The RCSS allows the child to keep
synchronized to the latest settings network-wide parameters that are synchronized to the latest settings network-wide parameters that are
propagated in protected options. propagated in protected options.
The RCSS is a sequence number that is operated as specified in The RCSS is a sequence number that is operated as specified in
skipping to change at page 8, line 37 skipping to change at page 9, line 17
parents with a consistent state of network-wide parameters, more in parents with a consistent state of network-wide parameters, more in
Section 5.2. Section 5.2.
By extension, the RCSS is also defined for each protected option. A By extension, the RCSS is also defined for each protected option. A
child associates an option with the values of the RCSS indicated in 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 DIO Messages in which the option is advertised and uses it to assess
the relative freshness of different versions of an option, more in the relative freshness of different versions of an option, more in
Section 5.3. Section 5.3.
Unchanged options may be sent in full, elided, or in the abbreviated Unchanged options may be sent in full, elided, or in the abbreviated
form specified in Section 4.3. Eliding an option is NOT RECOMMENDED form specified in Section 4.3. Which form to use depends on the
as it may cause multiple children to resynchronize the option even if RCSS, more in Section 5.3
it was not changed.
If the link MTU does not permit to send a single DIO message with all 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 the options packaged then the options may be spread over multiple
consecutive DIO messages with the same RCSS that are sent in a rapid consecutive DIO messages with the same RCSS that are sent in a rapid
sequence. sequence.
5.1. Updating the RCSS 5.1. Updating the RCSS
The RCSS is incremented by the Root using a lollipop technique as The RCSS is incremented by the Root using a lollipop technique as
specified in section 7.2 of [RPL]. RCSS values are comparable if specified in section 7.2 of [RPL]. RCSS values are comparable if
skipping to change at page 9, line 30 skipping to change at page 10, line 9
The Root SHOULD jump rapidly away from the straight part once the The Root SHOULD jump rapidly away from the straight part once the
network has sufficiently settled by resetting the RCSS to 0, which network has sufficiently settled by resetting the RCSS to 0, which
places the RCSS in the circular region of the lollipop, where the places the RCSS in the circular region of the lollipop, where the
protected options MAY be elided or abbreviated. protected options MAY be elided or abbreviated.
5.2. RCSS Freshness and Parent selection 5.2. RCSS Freshness and Parent selection
A child node maintains the freshest RCSS received from its parents in 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 each of the RPL Instances that it participates to, and uses that RCSS
for its own DIO messages. for its own DIO messages once it has all the protected options
synchronized to it.
A child and a candidate parent are out-of-sync when the RCSS values 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 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 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 available, in which case it MAY align its RCSS and resynchronize to
that parent. that parent.
When a child receives from a candidate parent a DIO with an RCSS that 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 is fresher than the one it is using, the child MUST synchronize the
state relative to the protected options with that parent. The child state relative to the protected options with that parent. The child
skipping to change at page 10, line 7 skipping to change at page 10, line 33
that RCSS. When it is fully synchronized, the child may then use that RCSS. When it is fully synchronized, the child may then use
that parent and the new RCSS. that parent and the new RCSS.
Using a back-level parent may cause packets to be dropped, Using a back-level parent may cause packets to be dropped,
misunderstood or misrouted. The child SHOULD refrain from using a misunderstood or misrouted. The child SHOULD refrain from using a
parent that exposes an older RCSS if the change causes an parent that exposes an older RCSS if the change causes an
incompatibility issue. incompatibility issue.
5.3. RCSS of an Option 5.3. RCSS of an Option
By extension, the RCSS of an option is maintained by a child as the By extension, the RCSS of an option is maintained by all nodes and is
freshest RCSS indicated by a DIO message from a candidate parent in defined for all but the root as the freshest RCSS indicated by a DIO
which the option was present in the abbreviated form or in full. A message from a candidate parent in which the option was present, in
child maintains a state for the freshest RCSS received for each of the abbreviated form or in full. A child maintains a state for the
the protected options and synchronizes its state for each option to RCSS of each of the protected options and synchronizes its state for
the freshest RCSS of that option. the options by comparing that RCSS with the one found in new DIO
messages for the option.
Protected options may be sent in full, elided, or in the abbreviated
form. Which form to use depends on the RCSS of the option that a
parent maintains:
* A parent MAY use either form when the RCSS is not changed from a
previous DIO; eliding options is PREFERRED in stable conditions to
save resources.
* When a protected option is updated, the RCSS is mechanically
incremented, and the new option MUST be sent in full on the first
DIO that advertises that new RCSS and the corresponding AOO SHOULD
NOT be added.
* When the RCSS is updated but a protected option is unchanged, the
parent SHOULD NOT fully elide the option as it may cause multiple
children to resynchronize it to no avail. The use of AOO is
RECOMMENDED unless it may cause a desynchronization for that
option, in which case the option SHOULD be placed in full more in
Section 5.3.
When a child receives a DIO from a candidate parent, for each 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 If the Option is advertised in the abbreviated form then the RCSS
that the DIO advertises for the option is the Last Modification that the DIO advertises for the option is the Last Modification
RCSS of the AOO, else RCSS of the AOO, else
If the Option is advertised in full then the RCSS that the DIO If the Option is advertised in full then the RCSS that the DIO
advertises for the option is the RCSS of the DIO, else advertises for the option is the RCSS of the DIO, else
skipping to change at page 10, line 48 skipping to change at page 11, line 46
advertise it in the abbreviated form while another sends the option 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 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 indicates that the option is either the same or carries a more recent
update than the one with an older RCSS. update than the one with an older RCSS.
The RCSS of an option may be obtained from a DIO message that carries 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 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 across parents, as long as the RCSS of the DIO is fresher than the
current one for that option. current one for that option.
If current value of the maintained RCSS for an given option is not as If the current value of the maintained RCSS for a given option is not
fresh or fresher than that advertised in a DIO message, then the fresher or as fresh as that advertised in a DIO message, then the
child MUST update its state for that option as specified in child MUST update its state for that option as specified in
Section 6. Section 6.
6. Synchronizing Options 6. Synchronizing Options
As the value of the RCSS progresses, it is NOT RECOMMENDED for a
child to attempt to resynchronize to an intermediate value of a RCSS
with a parent that is already back level vs. the lastest known RCSS
or the RCSS that this child is currently using, or a parent that is
out-of-sync with self. The child MAY only do so if it lost
reachability to all the candidate parents that advertise a fresher
and not out-of-sync value of RCSS.
A child can resynchronize any of the protected options to the latest A child can resynchronize any of the protected options to the latest
RCSS by sending a DIS Message to a candidate parent that advertises RCSS by sending a DIS Message to a candidate parent that advertises
that RCSS in DIO messages. The child MUST set the desired that RCSS in DIO messages. The child MUST set the desired
combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the 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 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 Synchronized RCSS field of the DIS the freshest value of RCSS for
which it was fully synchronized, or a conventional value of OUT-OF- 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 SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with
the parent. the parent.
The DIO message that is sent in response MUST contain in full all the 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 options that are requested and that were updated since the Last
Synchronized RCSS in the DIS Message. This means all of the Synchronized RCSS in the DIS Message. This means all of the
protected options of the child was never synchronized or is out-of- protected options of the child was never synchronized or is out-of-
sync with the parent. The other options MUST be added in the sync with the parent. The other options MUST be added in the
abbreviated form. The options MAY be spread over more than one DIO abbreviated form. The options MAY be spread over more than one DIO
message sent in a quick sequence and the child SHOULD wait a message sent in a quick sequence. It is possible that the DIS is not
reasonable technology-dependent time before it retries the request. received by the parent or that a DIO that carries all or subset of
the requested options is lost in return. In that case the child MUST
resend a DIS with the bits associated to the options that are still
missing after a reasonable technology-dependent time before it
retries the request. The child MAY use any parent that advertises
the RCSS to get any of the options up to that level.
7. Security Considerations 7. Abbreviating the DAO Message
TBD When a node receives a positive DAO-ACK upon a DAO message for a
given DAOSequence, The DAO-ACK indicates that the DAO was fully
processed by its destination (parent or Root). Until there's a
change in one of the DAO options since that DAOSequence, the next DAO
messages merely refresh the lifetime of the routes. In that case,
increasing the DAOSequence creates undesirable churn up the DODAG for
no added value.
8. IANA Considerations This specification enables a node to refresh the state in a
destination that is associated to one or more DAO message(s) that
were acknowledged by that destination without resending the DAO
message(s) in full. Instead, the node MAY use a single abbreviated
DAO message that is sent to the same destination and with the same
DAOSequence as the DAO message(s) that it refreshes, and with the 'A'
flag set (see Section 4.4) to signal it is an abbreviated DAO.
8.1. New DODAG Information Object Flags This can be more than one message if the node could not package all
its state in a single message, e.g., due to MTU restrictions. In
that case the DAO state that is refreshed is the aggregation of the
DAO messages that were acknowledged for the provided DAOSequence by
that destination.
Upon the abbreviated DAO, the destination refreshes the state
associated to the original DAO message(s) received with that
DAOSequence, typically by extending the lifetimes of the routes that
were advertised with the same duration.
A node MAY also unset 'K' flag in the abbreviated DAP message and not
expect a DAO-ACK, if the node can assume the risk that the DAO is
lost, e.g., if the routes will be refreshed again before the lifetime
expires.
Only the DAO message(s) with the last (freshest) DAOSequence can be a
abbreviated. A nod MUST NOT use an abbreviated DAO with a
DAOSequence that is not the freshest and it MUST NOT use the
abbreviated form of the DAO until the destination has acknowledged
all state associated with that DAOSequence. If a destination
receives an abbreviated DAO with a DAOSequence that is not the
freshest from that node, or the destination does not have a state for
that node, then MUST send a DAO-ACK with a DAO Status indicating an
error. The destination MAY use a new Status of 'Out-of-Sync' in
which case the node MUST resent the DAO Message(s) in full with its
freshest DAOSequence and the destination resynchronizes to that
level.
It is RECOMMENDED to use an abbreviated DAO messages whenever
possible, because a smaller DAO message consumes less energy and
bandwidth and has better chances of delivery. In Non-Storing Mode
the benefits increases with the number of hops to the Root, and in
Storing Mode with the amount of state that is implicitely refreshed.
8. Security Considerations
TBD
9. IANA Considerations
9.1. New DODAG Information Solicitation Flags
5 new bits are allocated in the Registry for the DODAG Information 5 new bits are allocated in the Registry for the DODAG Information
Object (DIO) Flags defined for [RPL]. Solicitation (DIS) Flags defined for [RPL].
+------------+----------------------------+--------------+ +------------+----------------------------+--------------+
| Bit Number | Capability description | Defining RFC | | Bit Number | Capability description | Defining RFC |
+============+============================+==============+ +============+============================+==============+
| 0 | 'R' bit "RIO requested" | THIS RFC | | 0 | 'R' bit "RIO requested" | THIS RFC |
+------------+----------------------------+--------------+ +------------+----------------------------+--------------+
| 1 | 'D' bit "DCO requested" | THIS RFC | | 1 | 'D' bit "DCO requested" | THIS RFC |
+------------+----------------------------+--------------+ +------------+----------------------------+--------------+
| 2 | 'P' bit "PIO(s) requested" | THIS RFC | | 2 | 'P' bit "PIO(s) requested" | THIS RFC |
+------------+----------------------------+--------------+ +------------+----------------------------+--------------+
| 3 | 'M' bit "MOPex requested" | THIS RFC | | 3 | 'M' bit "MOPex requested" | THIS RFC |
+------------+----------------------------+--------------+ +------------+----------------------------+--------------+
| 4 | 'O' bit "GCO irequested" | THIS RFC | | 4 | 'O' bit "GCO irequested" | THIS RFC |
+------------+----------------------------+--------------+ +------------+----------------------------+--------------+
Table 1: New DIO Flags Table 1: New DIS Flags
8.2. New RPL Control Message Option 9.2. New DODAG Advertisement Object Flag
1 new bit is allocated in the Registry for the Destination
Advertisement Object(DAO) Flags defined for[RPL].
+------------+---------------------------+--------------+
| Bit Number | Capability description | Defining RFC |
+============+===========================+==============+
| 2 | 'A' bit "DAO abbreviated" | THIS RFC |
+------------+---------------------------+--------------+
Table 2: New DAO Flag
9.3. New RPL Control Message Option
A new entry is required for the new option of type "Abbreviated A new entry is required for the new option of type "Abbreviated
Option", from the "RPL Control Message Options" space defined for Option", from the "RPL Control Message Options" space defined for
[RPL]. [RPL].
+----------+--------------------+--------------+ +----------+--------------------+--------------+
| Code | Description | Defining RFC | | Code | Description | Defining RFC |
+==========+====================+==============+ +==========+====================+==============+
| TBD IANA | Abbreviated Option | THIS RFC | | TBD IANA | Abbreviated Option | THIS RFC |
+----------+--------------------+--------------+ +----------+--------------------+--------------+
Table 2: New Option Type Table 3: New Option Type
9. Acknowledgments
10. Normative References 10. Acknowledgments
[MOPEX-CAP] 11. Normative References
Jadhav, R. and P. Thubert, "Mode of Operation extension
and Capabilities", Work in Progress, Internet-Draft,
draft-ietf-roll-mopex-cap-00, 9 August 2019,
<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
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[MOPEX-CAP]
Jadhav, R. and P. Thubert, "Mode of Operation extension
and Capabilities", Work in Progress, Internet-Draft,
draft-ietf-roll-mopex-cap-00, 9 August 2019,
<https://tools.ietf.org/html/draft-ietf-roll-mopex-cap-
00>.
[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", Work in IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-31, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-31,
7 August 2019, <https://tools.ietf.org/html/draft-ietf- 7 August 2019, <https://tools.ietf.org/html/draft-ietf-
roll-useofrplinfo-31>. roll-useofrplinfo-31>.
11. Informative References 12. 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
Email: pthubert@cisco.com Email: pthubert@cisco.com
Dominique Barthel
Orange Labs
28 chemin du Vieux Chêne
38243 Meylan
France
Email: dominique.barthel@orange.com
Rahul Arvind Jadhav Rahul Arvind Jadhav
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore 560037 Bangalore 560037
Karnataka Karnataka
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Li Zhao
China
200233
SHANGHAI
Xinsi Building, No. 926 Yi Shan Rd
Cisco Systems, Inc
Email: liz3@cisco.com
Dominique Barthel
Orange Labs
28 chemin du Vieux Chêne
38243 Meylan
France
Email: dominique.barthel@orange.com
 End of changes. 37 change blocks. 
87 lines changed or deleted 218 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/