ROLL R. Koutsiamanis, Ed.
Internet-Draft G. Papadopoulos
Intended status: Standards Track N. Montavont
Expires: April 25, 2019 IMT Atlantique
P. Thubert
Cisco
October 22, 2018
RPL DAG Metric Container Node State and Attribute object type extension
draft-koutsiamanis-roll-nsa-extension-03
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 April 25, 2019.
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
publication of this document. Please review these documents
Koutsiamanis, et al. Expires April 25, 2019 [Page 1]
Internet-Draft RPL MC NSA object type extension October 2018
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. Node State and Attribute (NSA) object type extension . . . . 4
3.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. DAG Metric Container fields . . . . . . . . . . . . . 6
3.1.2. Node State and Attribute fields . . . . . . . . . . . 6
3.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Informative references . . . . . . . . . . . . . . . . . 7
6.2. Other Informative References . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
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"
Koutsiamanis, et al. Expires April 25, 2019 [Page 2]
Internet-Draft RPL MC NSA object type extension October 2018
[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 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 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].
The draft uses the following Terminology:
Track A sequence of 6TiSCH schedule resources to support a single-
path multi-hop transmission of a packet. See "6TiSCH
Architecture" [I-D.ietf-6tisch-architecture] for more.
Complex Track A Track which supports a multi-path multi-hop
transmission of a packet. See "6TiSCH Architecture"
[I-D.ietf-6tisch-architecture] for more.
Packet Replication and Elimination (PRE) The sending of multiple
copies of a packet using multi-path forwarding over a multi-hop
network and the consolidation of multiple received packet copies
to control flooding. See "Exploiting Packet Replication and
Koutsiamanis, et al. Expires April 25, 2019 [Page 3]
Internet-Draft RPL MC NSA object type extension October 2018
Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] for more.
Alternative Parent (AP) Selection The problem of how to select the
next hop target node for a packet copy to be forwarded to when
performing packet replication. See "Exploiting Packet Replication
and Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] for more.
3. Node State and Attribute (NSA) object type extension
For supporting PRE, nodes need to report their parent 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
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 has been
defined for use. This document defines one TLV for the purpose of
transmitting a node's parent 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 1: Example DIO Message with a DAG Metric Container option
Koutsiamanis, et al. Expires April 25, 2019 [Page 4]
Internet-Draft RPL MC NSA object type extension October 2018
Figure 1 shows the structure of the DIO Control Message when a DAG
Metric Container option is included. The DAG Metric Container option
type (DAGMC Type in Figure 1) 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 1) expresses the DAG Metric Container length in bytes. DAG
Metric Container data holds the actual data and is shown expanded in
Figure 2.
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| PS type | PS Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA
| PS IPv6 address(es) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: 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 2. 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 Set and is abbreviated as PS in Figure 2.
PS type: The type of the Parent Set TLV. The value is TBD1.
PS Length: The total length of the TLV value field (PS IPv6
address(es)) in bytes.
PS 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.
3.1. Usage
The PS 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
Koutsiamanis, et al. Expires April 25, 2019 [Page 5]
Internet-Draft RPL MC NSA object type extension October 2018
path. The Parent Set is information local to the node that
broadcasts it.
3.1.1. DAG Metric Container fields
Given the intended usage, when using the PS, the NSA object it is
contained in MUST be used as a constraint in the DAG Metric
Container. More specifically, using the PS places the following
requirements on the DAG Metric Container header fields:
o 'P' flag: MUST be cleared, since PS is used only with constraints.
o 'C' flag: MUST be set, since PS is used only with constraints.
o 'O' flag: Used as per [RFC6550], to indicated optionality.
o 'R' flag: MUST be cleared, since PS is used only with constraints.
o 'A' Field: MUST be set to 0 and ignored, since PS is used only
with constraints.
o 'Prec' Field: Used as per [RFC6550].
3.1.2. Node State and Attribute fields
For clarity reasons, the usage of the PS places no additional
restrictions on the NSA flags ('A' and 'O'), which can be used as
normally defined in [RFC6550].
3.2. Compression
The PS IPv6 address(es) field in the Parent Set TLV add overhead due
to their size. Therefore, compression is highly desirable in order
for this extension to be usable. To meet this goal, a good
compression method candidate is [RFC8138] 6LoWPAN Routing Header
(6LoRH). Furthermore, the PS IPv6 address(es) belong by definition
to nodes in the same RPL DODAG and are stored in the form of a list
of addresses. This makes this field a good candidate for the use of
the same compression as in Source Routing Header 6LoRH (SRH-6LoRH),
achieving efficiency and implementation reuse. Therefore, the PS
IPv6 address(es) field SHOULD be compressed using the compression
method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138].
4. Security Considerations
The structure of the DIO control message is extended, within the pre-
defined DIO options. Therefore, the security mechanisms defined in
RPL [RFC6550] apply to this proposed extension.
Koutsiamanis, et al. Expires April 25, 2019 [Page 6]
Internet-Draft RPL MC NSA object type extension October 2018
5. IANA Considerations
This proposal requests the allocation of a new value TBD1 for the
"Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry
from IANA.
6. References
6.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-15 (work
in progress), October 2018.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-08 (work in progress), September 2018.
[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-02 (work in progress), July 2018.
[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>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
Koutsiamanis, et al. Expires April 25, 2019 [Page 7]
Internet-Draft RPL MC NSA object type extension October 2018
6.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
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
Koutsiamanis, et al. Expires April 25, 2019 [Page 8]
Internet-Draft RPL MC NSA object type extension October 2018
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 April 25, 2019 [Page 9]