Skip to main content

RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type extension
draft-koutsiamanis-roll-nsa-extension-01

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 "Replaced".
Authors Remous-Aris Koutsiamanis , Georgios Z. Papadopoulos , Nicolas Montavont , Pascal Thubert
Last updated 2018-01-17
Replaces draft-pkm-roll-nsa-extension
Replaced by draft-ietf-roll-nsa-extension, draft-ietf-roll-nsa-extension, draft-ietf-roll-nsa-extension
RFC stream (None)
Formats
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-koutsiamanis-roll-nsa-extension-01
ROLL                                                R. Koutsiamanis, Ed.
Internet-Draft                                           G. Papadopoulos
Intended status: Standards Track                            N. Montavont
Expires: July 21, 2018                                    IMT Atlantique
                                                              P. Thubert
                                                                   Cisco
                                                        January 17, 2018

RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type
                               extension
                draft-koutsiamanis-roll-nsa-extension-01

Abstract

   Implementing 6TiSCH Packet Replication and Elimination from / to the
   RPL root requires the ability to forward copies of packets over
   different paths via different RPL parents.  Selecting the appropriate
   parents to achieve ultra-low latency and jitter requires information
   about a node's parents.  This document details what information needs
   to be transmitted and how it is encoded within a packet to enable
   this functionality.

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 July 21, 2018.

Copyright Notice

   Copyright (c) 2018 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

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 1]
Internet-Draft      RPL MC NSA object type extension        January 2018

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Tracks  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Tracks Overview . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Complex Tracks  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Packet Replication and Elimination principles . . . . . . . .   4
   5.  Alternative Parent Selection Issue  . . . . . . . . . . . . .   5
   6.  Node State and Attribute (NSA) object type extension  . . . .   6
     6.1.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.1.  DAG Metric Container fields . . . . . . . . . . . . .   9
       6.1.2.  Node State and Attribute fields . . . . . . . . . . .   9
     6.2.  Compression . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Informative references  . . . . . . . . . . . . . . . . .   9
     9.2.  Other Informative References  . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Industrial network applications have stringent requirements on
   reliability and predictability, and typically leverage 1+1
   redundancy, aka Packet Replication and Elimination (PRE)
   [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal.  In order
   for wireless networks to be able to be used in such applications, the
   principles of Deterministic Networking [I-D.ietf-detnet-architecture]
   lead to designs that aim at maximizing packet delivery rate and
   minimizing latency and jitter.  Additionally, given that the network
   nodes often do not have an unlimited power supply, energy consumption
   needs to be minimized as well.

   To meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides
   Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a
   fixed communication schedule to allow deterministic medium access as
   well as channel hopping to work around radio interference.  However,
   since TSCH uses retransmissions in the event of a failed
   transmission, end-to-end delay and jitter performance can
   deteriorate.

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 2]
Internet-Draft      RPL MC NSA object type extension        January 2018

   The 6TiSCH working group, focusing on IPv6 over IEEE Std.
   802.15.4-TSCH, has worked on the issues previously highlighted and
   produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to
   address that case.  Building on this architecture, "Exploiting Packet
   Replication and Elimination in Complex Tracks in 6TiSCH LLNs"
   [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the
   Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end
   latency, and limit jitter.

   PRE achieves a controlled redundancy by laying multiple forwarding
   paths through the network and using them in parallel for different
   copies of a same packet.  PRE can follow the Destination-Oriented
   Directed Acyclic Graph (DODAG) formed by RPL from a node to the root.
   Building a multi-path DODAG can be achieved based on the RPL
   capability of having multiple parents for each node in a network, a
   subset of which is used to forward packets.  In order for this subset
   to be defined, a RPL parent subset selection mechanism, which falls
   within the remit of the RPL Objective Function (OF), needs to have
   specific path information.  The specification of the transmission of
   this information is the focus of this document.

   More concretely, this specification focuses on the extensions to the
   DAG Metric Container [RFC6551] required for providing the PRE
   mechanism a part of the information it needs to operate.  This
   information is the RPL [RFC6550] parent node address set of a node
   and it must be sent to potential children nodes of the node.  The RPL
   DIO Control Message is the canonical way of broadcasting this kind of
   information and therefore its DAG Metric Container [RFC6551] field is
   used to append a Node State and Attribute (NSA) object.  The node's
   parent node address set is stored as an optional TLV within the NSA
   object.  This specification defines the type value and structure for
   this TLV.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Tracks

3.1.  Tracks Overview

   The concept of Track is introduced in the "6TiSCH Architecture"
   [I-D.ietf-6tisch-architecture], defined as a sequence of elements,
   each consisting of the 3-tuple of a transmitter, a receiver, and a
   given timeslot expressed as a slotOffset/channelOffset tuple.  A
   simple Track is intended to provide the full resources required to

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 3]
Internet-Draft      RPL MC NSA object type extension        January 2018

   allow the transmission of a single packet from a source 6TiSCH node
   to a destination 6TiSCH node across a 6TiSCH multihop path.

3.2.  Complex Tracks

   Similarly to, but as a generalization of a simple Track, a Complex
   Track is defined in the "6TiSCH Architecture"
   [I-D.ietf-6tisch-architecture] as a DODAG starting at a source 6TiSCH
   node and leading to a sink 6TiSCH node in order to support multi-path
   forwarding.  Multiple independent paths may be produced by using
   techniques for Packet Replication and Elimination (PRE)
   [I-D.papadopoulos-6tisch-pre-reqs] based on DetNet
   [I-D.ietf-detnet-architecture] principles.  As an example, a complex
   Track allows for branching off and rejoining over non-congruent
   paths.

   In the following Section, we will detail Deterministic Networks PRE
   techniques.

4.  Packet Replication and Elimination principles

   The idea behind Packet Replication and Elimination (PRE) is to
   transmit the same data packet through parallel and adjacent paths in
   a network with the aim of improving reliability and predictability
   through redundancy.

   The process of replication consists of identifying multiple potential
   paths, selecting a subset to use, and sending copies of a single
   packet through each path.  When receiving packets the process of
   elimination is required so that multiple copies of the same packet
   are not replicated again, to avoid an exponential growth in
   unnecessary traffic.  Combined together, these processes enable
   controlled redundancy which in turn can be used to achieve the
   previously stated goals of reliability (i.e., ultra-high packet
   delivery rate) and predictability (i.e., ultra-low end-to-end delay
   and jitter) in wireless networks.  For example, in Figure 1, the
   source 6TiSCH node S is sending the data packet to its RPL Default
   Parent (DP) (node A) and Alternative Parent (AP) (node B) in two
   different timeslots.

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 4]
Internet-Draft      RPL MC NSA object type extension        January 2018

                       ( R ) root
                       ^^ ^^
                      //   \\
                     //     \\
                   ( C )   ( D )
                   ^^ ^    ^ ^^
                   ||  \  /  ||
                   ||   \/   ||
                   ||   /\   ||
                   ||  /  \  ||
                   ( A )   ( B )
                   ^^      ^
                   ||     /
                   ||    /
                   ||   /
                   ||  /             ||  Preferred Parent
                   ( S ) source       |  Potential Parent

   Figure 1: Packet Replication: S transmits the same data packet twice:
                     to its DP (A) and to its AP (B).

   In "Exploiting Packet Replication and Elimination in Complex Tracks
   in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs], the concept of
   PRE is further expanded along with its requirements.

5.  Alternative Parent Selection Issue

   In the RPL protocol, each node maintains a list of potential parents.
   For PRE, the DP node is defined as the RPL DODAG preferred parent
   node.  Furthermore, to construct an alternative path toward the root,
   in addition to the DP node, each 6TiSCH node in the network registers
   an AP node as well.  There are multiple alternative methods of
   selecting the AP node, functionality which is included in operation
   of the RPL Objective Function (OF).  In "Exploiting Packet
   Replication and Elimination in Complex Tracks in 6TiSCH LLNs"
   [I-D.papadopoulos-6tisch-pre-reqs], a scheme which allows the two
   paths to remain correlated is detailed.  More specifically, in this
   scheme a 6TiSCH node will select an alternative parent node close to
   its default parent node to allow the operation of overhearing between
   parents.  To do so, the node will check if its Default Grand Parent
   (DGP), the DP of its DP, is in the set of parents of a potential AP.
   If multiple potential APs match this condition, the AP with the
   lowest rank will be registered.

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 5]
Internet-Draft      RPL MC NSA object type extension        January 2018

            (  R  ) root
            ^^ ^^ ^^
           //  ||  \\
          //   ||   \\
         //    ||    \\
        //     ||     \\
     ( C )   ( D )    ( E )
     ^^ ^    ^ ^^     ^
     ||  \  /  ||    /
     ||   \/   ||   /
     ||   /\   ||  /
     ||  /  \  || /
     ( A )   ( B )
     ^^      ^
     ||     /
     ||    /
     ||   /
     ||  /                     ||  Preferred Parent
     ( S ) source               |  Potential Parent

               Figure 2: Example Parent Selection mechanism

   For instance, in Figure 2, source 6TiSCH node S must know its
   grandparent sets both through node A and through node B.  In this
   scenario, node A has the parent set {C, D} with C as DP and node B
   has the parent set {C, D, E} with D as DP.  Therefore, node S can
   decide to use node B as its AP node, since the the DGP of S (via node
   A) is node C, and node C is in the parent set of node B ({C, D, E}).

   In order to select their AP node, 6TiSCH nodes need to be aware of
   their grandparent node sets.  Within RPL [RFC6550], the nodes use the
   DODAG Information Object (DIO) Control Message to broadcast
   information about themselves to potential children.  However, RPL
   [RFC6550], does not define how to propagate parent set related
   information, which is what this document addresses.

6.  Node State and Attribute (NSA) object type extension

   For supporting PRE, nodes need to report their parent node set to
   their potential children.  DIO messages can carry multiple options,
   out of which the DAG Metric Container option [RFC6551] is the most
   suitable structurally and semantically for the purpose of carrying
   the parent node set.  The DAG Metric Container option itself can
   carry different nested objects, out of which the Node State and
   Attribute (NSA) [RFC6551] is appropriate for transferring generic
   node state data.  Within the Node State and Attribute it is possible
   to store optional TLVs representing various node characteristics.  As
   per the Node State and Attribute (NSA) [RFC6551] description, no TLV

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 6]
Internet-Draft      RPL MC NSA object type extension        January 2018

   have been defined for use.  This document defines one TLV for the
   purpose of transmitting a node's parent node set.

    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     |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                            DODAGID                            +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DAGMC Type (2)| DAGMC Length  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   //                   DAG Metric Container data                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: Example DIO Message with a DAG Metric Container option

   The structure of the DIO Control Message when a DAG Metric Container
   option is included is shown in Figure 3.  The DAG Metric Container
   option type (DAGMC Type in Figure 3) has the value 0x02 as per the
   IANA registry for the RPL Control Message Options, and is defined in
   [RFC6550].  The DAG Metric Container option length (DAGMC Length in
   Figure 3) expresses the the DAG Metric Container length in bytes.
   DAG Metric Container data holds the actual data and is shown further
   expanded in Figure 4.

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 7]
Internet-Draft      RPL MC NSA object type extension        January 2018

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A   |  Prec | Length (bytes)| |=>MC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Res       |  Flags    |A|O|    PNS type   |   PNS Length  | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA
| PNS IPv6 address(es) ...                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: DAG Metric Container (MC) data with Node State and
                   Attribute (NSA) object body and a TLV

   The structure of the DAG Metric Container data in the form of a Node
   State and Attribute (NSA) object with a TLV in the NSA Optional TLVs
   field is shown in Figure 4.  The first 32 bits comprise the DAG
   Metric Container header and all the following bits are part of the
   Node State and Attribute object body, as defined in [RFC6551].  This
   document defines a new TLV, which CAN be carried in the Node State
   and Attribute (NSA) object Optional TLVs field.  The TLV is named
   Parent Node Set and is abbreviated as PNS in Figure 4.

   PNS type:  The type of the Parent Node Set TLV.  The value is TBD1.

   PNS Length:  The total length of the TLV value field (PNS IPv6
         address(es)) in bytes.

   PNS IPv6 address(es):  A sequence of zero or more IPv6 addresses
         belonging to a node's parent set.  Each address requires 16
         bytes.  The order of the parents in the parent set is in
         decreasing preference based on the Objective Function [RFC6550]
         used by the node.

6.1.  Usage

   The PNS SHOULD be used in the process of parent selection, and
   especially in alternative parent selection, since it can help the
   alternative path from significantly deviating from the preferred
   path.  The Parent Node Set is information local to the node that
   broadcasts it.  It does not make sense for this information to be
   aggregated due to the scalability issue created by the space required
   for many IPv6 addresses.  Therefore, the PNS MUST NOT be aggregated.

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 8]
Internet-Draft      RPL MC NSA object type extension        January 2018

6.1.1.  DAG Metric Container fields

   Given the intended usage, when using the PNS, the NSA object it is
   contained in MUST be used as a constraint in the DAG Metric
   Container.  More specifically, using the PNS places the following
   requirements on the DAG Metric Container header fields:

   o  'P' flag: MUST be cleared, since PNS is used only with
      constraints.

   o  'C' flag: MUST be set, since PNS is used only with constraints.

   o  'O' flag: Used as per [RFC6550], to indicated optionality.

   o  'R' flag: MUST be cleared, since PNS is used only with
      constraints.

   o  'A' Field: MUST be set to 0 and ignored, since PNS is used only
      with constraints.

   o  'Prec' Field: Used as per [RFC6550].

6.1.2.  Node State and Attribute fields

   For reasons of clarity, the usage of the PNS places no additional
   restrictions on the NSA flags ('A' and 'O'), which can be used as
   normally defined in [RFC6550].

6.2.  Compression

   The PNS IPv6 address(es) field in the Parent Node Set TLV MAY be
   compressed using any compression method available to conserve space.

7.  Security Considerations

   TODO.

8.  IANA Considerations

   TBA.

9.  References

9.1.  Informative references

Koutsiamanis, et al.      Expires July 21, 2018                 [Page 9]
Internet-Draft      RPL MC NSA object type extension        January 2018

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
              in progress), November 2017.

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-04 (work in progress), October 2017.

   [I-D.papadopoulos-6tisch-pre-reqs]
              Papadopoulos, G., Montavont, N., and P. Thubert,
              "Exploiting Packet Replication and Elimination in Complex
              Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre-
              reqs-01 (work in progress), December 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6550]  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>.

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012,
              <https://www.rfc-editor.org/info/rfc6551>.

9.2.  Other Informative References

   [IEEE802154-2015]
              IEEE standard for Information Technology, "IEEE Std
              802.15.4-2015 Standard for Low-Rate Wireless Personal Area
              Networks (WPANs)", December 2015.

Authors' Addresses

Koutsiamanis, et al.      Expires July 21, 2018                [Page 10]
Internet-Draft      RPL MC NSA object type extension        January 2018

   Remous-Aris Koutsiamanis (editor)
   IMT Atlantique
   Office B00 - 126A
   2 Rue de la Chataigneraie
   Cesson-Sevigne - Rennes  35510
   FRANCE

   Phone: +33 299 12 70 49
   Email: aris@ariskou.com

   Georgios Papadopoulos
   IMT Atlantique
   Office B00 - 114A
   2 Rue de la Chataigneraie
   Cesson-Sevigne - Rennes  35510
   FRANCE

   Phone: +33 299 12 70 04
   Email: georgios.papadopoulos@imt-atlantique.fr

   Nicolas Montavont
   IMT Atlantique
   Office B00 - 106A
   2 Rue de la Chataigneraie
   Cesson-Sevigne - Rennes  35510
   FRANCE

   Phone: +33 299 12 70 23
   Email: nicolas.montavont@imt-atlantique.fr

   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   FRANCE

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

Koutsiamanis, et al.      Expires July 21, 2018                [Page 11]