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-00
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 . . . . 5
6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Informative references . . . . . . . . . . . . . . . . . 8
9.2. Other Informative References . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
The 6TiSCH working group, focusing on IPv6 over IEEE Std.
802.15.4-TSCH, has worked on the issues previously highlighted and
Koutsiamanis, et al. Expires July 21, 2018 [Page 2]
Internet-Draft RPL MC NSA object type extension January 2018
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
allow the transmission of a single packet from a source 6TiSCH node
to a destination 6TiSCH node across a 6TiSCH multihop path.
Koutsiamanis, et al. Expires July 21, 2018 [Page 3]
Internet-Draft RPL MC NSA object type extension January 2018
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 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 what is called
RPL Default Parent (DP) and Alternative Parent (AP), nodes A and B,
in two different timeslots.
===> (A) ====> (C) ===
// \\ // \\
source (S) \\ (R) (root)
\\ // \\ //
===> (B) ====> (D) ===
Figure 1: Packet Replication: S transmits twice the same data packet,
to its DP (A) and to its AP (B).
Koutsiamanis, et al. Expires July 21, 2018 [Page 4]
Internet-Draft RPL MC NSA object type extension January 2018
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.
For instance, in Figure 1, source 6TiSCH node S must know its
grandparent sets both through node A and through node B. In this
scenario, node A and node B have the same parent sets, nodes C and D,
and therefore for node S, the grandparent set through A is the same
as the grandparent set through B.
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 5]
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 2: 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 2. The DAG Metric Container
option type (DAGMC Type in Figure 2) 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 2) expresses the the DAG Metric Container length in bytes.
DAG Metric Container data holds the actual data and is shown further
expanded in Figure 3.
Koutsiamanis, et al. Expires July 21, 2018 [Page 6]
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)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Flags |A|O| PNS type (1) | PNS Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNS IPv6 address(es) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DAG Metric Container 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 3. The DAG Metric Container fields up to
the first 48 bits (including the O flag) are defined in [RFC6551] as
part of the Node State and Attribute (NSA) object body. 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 3.
PNS type: The type of the Parent Node Set TLV. The value is 1.
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. 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.
Koutsiamanis, et al. Expires July 21, 2018 [Page 7]
Internet-Draft RPL MC NSA object type extension January 2018
9. References
9.1. Informative references
[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.
Koutsiamanis, et al. Expires July 21, 2018 [Page 8]
Internet-Draft RPL MC NSA object type extension January 2018
Authors' Addresses
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 9]