< draft-thubert-roll-eliding-dio-information-02.txt   draft-thubert-roll-eliding-dio-information-03.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550 (if approved) R.A. Jadhav Updates: 6550 (if approved) R.A. Jadhav
Intended status: Standards Track Huawei Tech Intended status: Standards Track Huawei Tech
Expires: 27 April 2020 L. Zhao Expires: 20 May 2020 L. Zhao
Cisco Systems Cisco Systems
D. Barthel D. Barthel
Orange Labs Orange Labs
25 October 2019 17 November 2019
Eliding and Querying RPL Information Eliding and Querying RPL Information
draft-thubert-roll-eliding-dio-information-02 draft-thubert-roll-eliding-dio-information-03
Abstract Abstract
This document presents a method to safely elide a group of RPL This document presents a method to safely elide a group of RPL
options in a DIO message by synchonizing the state associated with options in a DIO message by synchronizing the state associated with
each of these options between parent and child using a new sequence each of these options between parent and child using a new sequence
counter in DIO or DAO messages. A child that missed a DIO message counter in DIO messages. A child that missed a DIO message with an
with an update of any of those protected options detects it by the update of any of those protected options detects it by the change of
change of sequence counter and queries the update with a DIS Message. sequence counter and queries the update with a DIS Message. The
The draft also provides a method to fully elide the options in a DAO draft also provides a method to fully elide the options in a DAO
message. 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 27 April 2020. This Internet-Draft will expire on 20 May 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 6 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 4.4. Updated DAO Base Object . . . . . . . . . . . . . . . . . 8
5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8 5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 9 5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 9
5.2. RCSS Freshness and Parent selection . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 12 6. Synchronizing Options . . . . . . . . . . . . . . . . . . . . 12
7. Abbreviating the DAO Message . . . . . . . . . . . . . . . . 12 7. Abbreviating the DAO Message . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. New DODAG Information Solicitation Flags . . . . . . . . 14 9.1. New DODAG Information Solicitation Flags . . . . . . . . 14
9.2. New DODAG Advertisement Object Flag . . . . . . . . . . . 14 9.2. New DODAG Advertisement Object Flag . . . . . . . . . . . 14
9.3. New RPL Control Message Option . . . . . . . . . . . . . 14 9.3. New RPL Control Message Option . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
12. Informative References . . . . . . . . . . . . . . . . . . . 15 12. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 3, line 31 skipping to change at page 3, line 31
of the DIO options may be needed to decide whether a node can join a of the DIO options 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 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 or the address selection. It is thus critical that each node
maintains its state to the freshest and selects parents that are also maintains its state to the freshest and selects parents that are also
synchronized to the freshest. synchronized to the freshest.
[RPL] allows a parent to elide options in the DIO messages that it [RPL] allows a parent to elide options in the DIO messages that it
sends repeatedly, to conserve battery and save bandwidth. When it sends repeatedly, to conserve battery and save bandwidth. When it
does so, a newcomer child that missed DIOs that contained the does so, a newcomer child that missed DIOs that contained the
configuration option may operate on default or partial information. configuration option may operate on default or partial information.
If it is pessimistic, it may query all possible the information even If it is pessimistic, it may query all possible information even when
when it is not needed. Conversely, a node that slept may have missed it is not needed. Conversely, a node that slept may have missed a
a DIO with a change in some critical information and may not be even 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 aware of it, so it may fail to query for the update and operate on
deprecated parameters. deprecated parameters.
This document uses a new sequence counter called RCSS to synchronize This document uses a new sequence counter called RCSS to synchronize
the state in a child node with that of its parent, and recursively 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. with that of the whole network, to the latest setting from the Root.
The protected options are: The protected options are:
1. The Route Information Option (RIO) defined in section 6.7.5 of 1. The Route Information Option (RIO) defined in section 6.7.5 of
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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
and DIS messages are defined in the "RPL: IPv6 Routing Protocol for and DIS messages are defined in the "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RPL] specification. Low-Power and Lossy Networks" [RPL] specification.
This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware This document uses the terms RPL Leaf, RPL Aware Leaf (RAL), RPL-
Leaf (RAL) consistently with [USE_OF_RPL_INFO]. Aware Node (RAN) and RPL-Unaware Leaf (RUL) as defined in section 2
of [USE_OF_RPL_INFO].
The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses A RPL-Unaware Leaf (RUL) thus refers to a host that does not
a RPL router (without necessarily knowing it) as 6LR and depends on understand RPL but uses a RPL router (without necessarily knowing it)
that router to obtain reachability for its addresses inside the RPL as 6LR and depends on that router to obtain reachability for its
domain. On the contrary, the term RPL-Aware Node (RAN) is used to addresses inside the RPL domain. On the contrary, the term RPL-Aware
refer to a RAL or a RPL router that participates to RPL and Node (RAN) is used to refer to a node that participates to RPL and
advertises its addresses of prefixes by itself. advertises its addresses or 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
RS Router Solicitation RS Router Solicitation
RCSS RPL Configuration State Sequence 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
skipping to change at page 6, line 4 skipping to change at page 6, line 6
in Section 4.2. in Section 4.2.
This document also enables to abbreviate a full DAO message when all This document also enables to abbreviate a full DAO message when all
the options are unchanged from the previous DAO message that was the options are unchanged from the previous DAO message that was
positively acknowledged. In that case the DAO is resent with the positively acknowledged. In that case the DAO is resent with the
same DAOSequence and all the options are elided. A new flag in 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, DAO Base Object indicates that this is an abbreviated DAO message,
more in Section 7. more in Section 7.
4. Message Formats 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]. In order to transport the RCSS, this specification uses an
[RPL] to transport the RCSS. 8th octet that was reserved in [RPL].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 12, line 28 skipping to change at page 12, line 30
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 if 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. It is possible that the DIS is not message sent in a quick sequence. It is possible that the DIS is not
received by the parent or that a DIO that carries all or subset of 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 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 resend a DIS with the bits associated to the options that are still
missing after a reasonable technology-dependent time before it missing after a reasonable technology-dependent time before it
retries the request. The child MAY use any parent that advertises retries the request. The child MAY use any parent that advertises
the RCSS to get any of the options up to that level. the RCSS to get any of the options up to that level.
skipping to change at page 14, line 4 skipping to change at page 14, line 6
possible, because a smaller DAO message consumes less energy and possible, because a smaller DAO message consumes less energy and
bandwidth and has better chances of delivery. In Non-Storing Mode bandwidth and has better chances of delivery. In Non-Storing Mode
the benefits increases with the number of hops to the Root, and in the benefits increases with the number of hops to the Root, and in
Storing Mode with the amount of state that is implicitely refreshed. Storing Mode with the amount of state that is implicitely refreshed.
8. Security Considerations 8. Security Considerations
TBD TBD
9. IANA Considerations 9. IANA Considerations
9.1. New DODAG Information Solicitation Flags 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
Solicitation (DIS) Flags defined for [RPL]. Solicitation (DIS) Flags defined for [RPL].
+------------+----------------------------+--------------+ +------------+----------------------------+-----------+
| Bit Number | Capability description | Defining RFC | | Bit Number | Capability description | Reference |
+============+============================+==============+ +============+============================+===========+
| 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 DIS Flags Table 1: New DIS Flags
9.2. New DODAG Advertisement Object Flag 9.2. New DODAG Advertisement Object Flag
1 new bit is allocated in the Registry for the Destination 1 new bit is allocated in the Registry for the Destination
Advertisement Object(DAO) Flags defined for[RPL]. Advertisement Object(DAO) Flags defined for[RPL].
+------------+---------------------------+--------------+ +------------+---------------------------+-----------+
| Bit Number | Capability description | Defining RFC | | Bit Number | Capability description | Reference |
+============+===========================+==============+ +============+===========================+===========+
| 2 | 'A' bit "DAO abbreviated" | THIS RFC | | 2 | 'A' bit "DAO abbreviated" | THIS RFC |
+------------+---------------------------+--------------+ +------------+---------------------------+-----------+
Table 2: New DAO Flag Table 2: New DAO Flag
9.3. New RPL Control Message Option 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 | Reference |
+==========+====================+==============+ +==========+====================+===========+
| TBD IANA | Abbreviated Option | THIS RFC | | TBD IANA | Abbreviated Option | THIS RFC |
+----------+--------------------+--------------+ +----------+--------------------+-----------+
Table 3: New Option Type Table 3: New Option Type
10. Acknowledgments 10. Acknowledgments
11. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 15, line 35 skipping to change at page 15, line 43
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[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>.
[MOPEX-CAP] [MOPEX-CAP]
Jadhav, R. and P. Thubert, "Mode of Operation extension Jadhav, R., Thubert, P., and M. Richardson, "Mode of
and Capabilities", Work in Progress, Internet-Draft, Operation extension and Capabilities", Work in Progress,
draft-ietf-roll-mopex-cap-00, 9 August 2019, Internet-Draft, draft-ietf-roll-mopex-cap-01, 2 November
<https://tools.ietf.org/html/draft-ietf-roll-mopex-cap- 2019, <https://tools.ietf.org/html/draft-ietf-roll-mopex-
00>. cap-01>.
[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>.
12. Informative References 12. Informative References
 End of changes. 24 change blocks. 
58 lines changed or deleted 61 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/