Skip to main content

Eliding and Querying RPL Information
draft-thubert-roll-eliding-dio-information-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Pascal Thubert , Dominique Barthel , Rahul Jadhav
Last updated 2019-10-15
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-thubert-roll-eliding-dio-information-00
ROLL                                                     P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Updates: 6550 (if approved)                                   D. Barthel
Intended status: Standards Track                             Orange Labs
Expires: 17 April 2020                                       R.A. Jadhav
                                                             Huawei Tech
                                                         15 October 2019

                  Eliding and Querying RPL Information
             draft-thubert-roll-eliding-dio-information-00

Abstract

   This document presents a method to elide a group of global RPL
   options by synchonizing the state associated with each of these
   options between parent and child using a new sequence counter in DIO
   messages.  A child that missed a DIO message with an update of any of
   those protected options detects it by the change of sequence counter
   and queries the update with a DIS Message.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 April 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Thubert, et al.           Expires 17 April 2020                 [Page 1]
Internet-Draft              Eliding RPL Info                October 2019

   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  References  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . .   4
   4.  New RPL Configuration State Sequence  . . . . . . . . . . . .   4
   5.  Protected Options . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Child Operation . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Pulling Options . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   13. Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Classical Link State protocol synchronize their Link State Database
   (LSDB) by sequencing every change.  Each interested node maintains
   the last sequence of the LSDB it is synchronizing with.  If a last
   known sequence is older than the current, the node needs to learn one
   by one all the state changes between the last known and the current
   state.

   [RPL] does not operate that way.  With RPL, the routing information
   is repeated over and over in DODAG Information Object (DIO) and
   Destination Advertisement Object (DAO) messages.  There is no concept
   of synchronization.  The most recent information overrides a previous
   one and a stale state eventually times out.

   The RPL way was designed to enable routing from most nodes to most
   nodes most of the time in a Low-Power Lossy Network (LLN) where the
   quality of the links and the cost of communications does not permit
   to maintain a permanent synchronization.  This principle was applied
   to both the routing information and non-routing state such as
   configuration settings, prefix information, and node capabilities.

   This non-routing state may be needed to decide whether a node can
   join a network as a leaf or as a router, and may affect the parent

Thubert, et al.           Expires 17 April 2020                 [Page 2]
Internet-Draft              Eliding RPL Info                October 2019

   selection.  [RPL] allows a parent to elide that information in the
   DIO it sends repeatedly, but if it does so, a newcomer child may have
   missed the early DIOs that contained the configuration option and
   live with only partial information.  If it is pessimistic, it may
   query all possible information even when it is not needed.
   Conversely, a node that slept may have missed a DIO message with a
   change in some critical information and not be aware of it, so it may
   fail to query for the update and operate on deprecated parameters.

   This document uses a new sequence counter to synchronize the state in
   a child node with that of its parent, and recursively with that of
   the network.

2.  Terminology

2.1.  BCP 14

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  References

   The Terminology used in this document is consistent with and
   incorporates that described in Terms Used in Routing for Low-Power
   and Lossy Networks (LLNs).  [RFC7102].

   Other terms in use in LLNs are found in Terminology for
   Constrained-Node Networks [RFC7228].

   A glossary of classical RPL acronyms is given in Section 2.3.

   The term "byte" is used in its now customary sense as a synonym for
   "octet".

   "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO
   and DIS messages are defined in the "RPL: IPv6 Routing Protocol for
   Low-Power and Lossy Networks" [RPL] specification.

   This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware
   Leaf (RAL) consistently with [USE_OF_RPL_INFO].

   The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses
   a RPL router (without necessarily knowing it) as 6LR and depends on
   that router to obtain reachability for its addresses inside the RPL
   domain.  On the contrary, the term RPL-Aware Node (RAN) is used to

Thubert, et al.           Expires 17 April 2020                 [Page 3]
Internet-Draft              Eliding RPL Info                October 2019

   refer to a RAL or a RPL router that participates to RPL and
   advertises its addresses of prefixes by itself.

2.3.  Glossary

   This document often uses the following acronyms:

   DODAG  Destination-Oriented Directed Acyclic Graph

   LLN  Low-Power and Lossy Network

   RPI  RPL Packet Information (an Option in the Hop-By_Hop Header)

   RAL  RPL-Aware Leaf

   RAN  RPL-Aware Node, a RPL router or a RPL-Aware Leaf

   RS  Router Solicitation

   RPL  IPv6 Routing Protocol for LLNs (pronounced ripple)

   RUL  RPL-Unaware Leaf

3.  Updating RFC 6550

   This document adds a sequence counter called RPL Configuration State
   Sequence (RCSS) to the DIO message.  The RCSS is set by the root and
   operated as specified in Section 7 of [RPL], more in Section 4.

   This document introduces a new RPL Control Message Options called the
   Abbreviated Option Option (AOO).  The AOO is an empty replacement of
   an existing option that indicates the RCSS of the last change of that
   option.

   This document modifies the Solicited Information Option to enable the
   individual query of the protected options by a node that missed a
   change, more in Section 7.

4.  New RPL Configuration State Sequence

   The format of the DIO Base Object is defined in section 6.3.1 of
   [RPL].  This specification uses a 8th octet that was previously
   reserved to transport the RCSS.

Thubert, et al.           Expires 17 April 2020                 [Page 4]
Internet-Draft              Eliding RPL Info                October 2019

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID |Version Number |             Rank              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |G|0| MOP | Prf |     DTSN      |     Flags     |      RCSS     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                            DODAGID                            +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+

                     Figure 1: MOdified DIO Base Object

   Updated fields:

   RCSS
      One Byte, the RPL Configuration State Sequence

   The RCSS protects network-wide options that are set by the root and
   that are propagated without a change down the DODAG.  The RCSS MUST
   be incremented when the root sends a DIO where at least one of the
   protected options is modified.  It MUST propagated down without a
   change together with the options that it protects.

   During the straight part of the lollipop, a second reboot of the root
   might not be recognized and a same value of the RCSS may appear with
   new values in the protected options.  For that reason the protected
   options MUST be present in the DIOs during the straight part of the
   lollipop and the root SHOULD move rapidly away from the straight part
   once the network has settled by resetting the RCSS to 0, which places
   the RCSS in the circular region of the lollipop.

5.  Protected Options

   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]

Thubert, et al.           Expires 17 April 2020                 [Page 5]
Internet-Draft              Eliding RPL Info                October 2019

   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]

   When a protected option is unchanged from the previous DIOs, the root
   MAY replace it with its abbreviated version.  The abbreviated version
   of an option is transported in a 4-bytes long Abbreviated Option
   Option (AOO).  The AOO indicates the RCSS at which the protected
   option was last changed.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Type  | Option Length | Abbrev. opt.  | Last Mod RCSS |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: Abbreviated Option Option Format

   Option fields:

   Option Type
      One byte indicating "Abbreviated Option", see Table 1

   Option Length
      MUST be set to 2 indicating Option data of 2 bytes

   Abbreviated Option
      The Option Type of the option being abreviated

   Last Modification RCSS
      The RCSS at which the option was last modified

6.  Child Operation

   When a field is modified in one of the protected options in a fashion
   that may affect the routing or forwarding decision inside the DODAG,
   the root MUST send a DIO with the protected options.  Unchanged
   options may be abreviated as discussed in Section 5.

   The freshness of the protected options is asserted based on the RCSS.
   RCSS values are compared as described in section 7.2 of [RPL].  When
   a parent exposes a new RCSS, the child node SHOULD refrain from using
   that parent until it has resynchronized all the protected fields to
   the latest.  When it is resynchronized, the child SHOULD refrain from
   using other parents that expose an older RCSS.

Thubert, et al.           Expires 17 April 2020                 [Page 6]
Internet-Draft              Eliding RPL Info                October 2019

   A child MUST store the content of all the protected options and keep
   track of the RCSS of the DIO where each of these option was last seen
   in a non-abbreviated version.  If that RCSS is fresher than the Last
   Modification RCSS in the abbreviated version of the option then the
   child is up-to-date for that option.  If a protected option elided in
   a DIO and not abbreviated, and the child has a stored RCSS value for
   that option that is lower than the RCSS in the DIO, then the child
   MUST query that option from the parent to ensure that is has the
   latest.  This is done with a DIS message as indicated in Section 7.

7.  Pulling Options

8.  Security Considerations

   TBD

9.  IANA Considerations

   A new entries is required for the new option of type "Abbreviated
   Option", from the "RPL Control Message Options" space defined for
   [RPL].

               +----------+--------------------+-----------+
               | Value    | Meaning            | Reference |
               +==========+====================+===========+
               | TBD IANA | Abbreviated Option | THIS RFC  |
               +----------+--------------------+-----------+

                          Table 1: New Option Type

10.  Security Considerations

   TBD

11.  Acknowledgments

12.  Normative References

   [MOPEX-CAP]
              Jadhav, R. and P. Thubert, "Mode of Operation extension
              and Capabilities", 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
              Requirement Levels", BCP 14, RFC 2119,

Thubert, et al.           Expires 17 April 2020                 [Page 7]
Internet-Draft              Eliding RPL Info                October 2019

              DOI 10.17487/RFC2119, March 1997,
              <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
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RPL]      Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [USE_OF_RPL_INFO]
              Robles, I., Richardson, M., and P. Thubert, "Using RPL
              Option Type, Routing Header for Source Routes and IPv6-in-
              IPv6 encapsulation in the RPL Data Plane", Internet-Draft,
              draft-ietf-roll-useofrplinfo-31, 7 August 2019,
              <https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-
              31>.

13.  Informative References

Authors' Addresses

   Pascal Thubert (editor)
   Cisco Systems, Inc
   Building D, 45 Allee des Ormes - BP1200
   06254 Mougins - Sophia Antipolis
   France

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

   Dominique Barthel
   Orange Labs
   28 chemin du Vieux ChĂȘne

Thubert, et al.           Expires 17 April 2020                 [Page 8]
Internet-Draft              Eliding RPL Info                October 2019

   38243 Meylan
   France

   Email: dominique.barthel@orange.com

   Rahul Arvind Jadhav
   Huawei Tech
   Kundalahalli Village, Whitefield,
   Bangalore 560037
   Karnataka
   India

   Phone: +91-080-49160700
   Email: rahul.ietf@gmail.com

Thubert, et al.           Expires 17 April 2020                 [Page 9]