draft-ietf-roll-nsa-extension-02.txt   draft-ietf-roll-nsa-extension-03.txt 
ROLL R. Koutsiamanis, Ed. ROLL R. Koutsiamanis, Ed.
Internet-Draft G. Papadopoulos Internet-Draft G. Papadopoulos
Intended status: Standards Track N. Montavont Intended status: Standards Track N. Montavont
Expires: December 26, 2019 IMT Atlantique Expires: December 30, 2019 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
June 24, 2019 June 28, 2019
RPL DAG Metric Container Node State and Attribute object type extension RPL DAG Metric Container Node State and Attribute object type extension
draft-ietf-roll-nsa-extension-02 draft-ietf-roll-nsa-extension-03
Abstract Abstract
Implementing Packet Replication and Elimination from / to the RPL Implementing Packet Replication and Elimination from / to the RPL
root requires the ability to forward copies of packets over different root requires the ability to forward copies of packets over different
paths via different RPL parents. Selecting the appropriate parents paths via different RPL parents. Selecting the appropriate parents
to achieve ultra-low latency and jitter requires information about a to achieve ultra-low latency and jitter requires information about a
node's parents. This document details what information needs to be node's parents. This document details what information needs to be
transmitted and how it is encoded within a packet to enable this transmitted and how it is encoded within a packet to enable this
functionality. functionality.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 December 26, 2019. This Internet-Draft will expire on December 30, 2019.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Informative references . . . . . . . . . . . . . . . . . 10 8.1. Informative references . . . . . . . . . . . . . . . . . 10
8.2. Other Informative References . . . . . . . . . . . . . . 11 8.2. Other Informative References . . . . . . . . . . . . . . 11
Appendix A. Implementation Status . . . . . . . . . . . . . . . 11 Appendix A. Implementation Status . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Industrial network applications have stringent requirements on Network-enabled applications in the industrial context must provide
reliability and predictability, and typically leverage 1+1 stringent guarantees in terms of reliability and predictability. To
redundancy, aka Packet Replication and Elimination (PRE) achieve this they typically leverage 1+1 redundancy, also known as
[I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order Packet Replication and Elimination (PRE)
for wireless networks to be able to be used in such applications, the [I-D.papadopoulos-6tisch-pre-reqs]. Allowing these kinds of
principles of Deterministic Networking [I-D.ietf-detnet-architecture] applications to function over wireless networks requires the
lead to designs that aim at maximizing packet delivery rate and application of the principles of Deterministic Networking
minimizing latency and jitter. Additionally, given that the network [I-D.ietf-detnet-architecture]. This results in designs which aim at
nodes often do not have an unlimited power supply, energy consumption maximizing packet delivery rate and minimizing latency and jitter.
needs to be minimized as well. Additionally, given that the network nodes often do not have an
unlimited power supply, energy consumption needs to be minimized as
well.
As an example, to meet this goal, IEEE Std. 802.15.4 As an example, to meet this goal, IEEE Std. 802.15.4
[IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a [IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a
mode of operation which uses a fixed communication schedule to allow mode of operation which uses a common communication schedule based on
deterministic medium access as well as channel hopping to work around timeslots to allow deterministic medium access as well as channel
radio interference. However, since TSCH uses retransmissions in the hopping to work around radio interference. However, since TSCH uses
event of a failed transmission, end-to-end delay and jitter retransmissions in the event of a failed transmission, end-to-end
performance can deteriorate. delay and jitter performance can deteriorate.
Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE
Std. 802.15.4-TSCH, has worked on the issues previously highlighted Std. 802.15.4-TSCH, has worked on the issues previously highlighted
and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture]
to address that case. Building on this architecture, "Exploiting to address that case. Building on this architecture, "Exploiting
Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the
Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end Packet Delivery Ratio (PDR), to provide a hard bound to the end-to-
latency, and limit jitter. end latency, and to limit jitter.
PRE is a general method of maximizing packet delivery rate and PRE is a general method of maximizing packet delivery rate and
potentially minimizing latency and jitter, not limited to 6TiSCH. potentially minimizing latency and jitter, not limited to 6TiSCH.
More specifically, PRE achieves a controlled redundancy by laying More specifically, PRE achieves controlled redundancy by laying
multiple forwarding paths through the network and using them in multiple forwarding paths through the network and using them in
parallel for different copies of a same packet. PRE can follow the parallel for different copies of a same packet. PRE can follow the
Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL
from a node to the root. Building a multi-path DODAG can be achieved 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 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 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 for this subset to be defined, a RPL parent subset selection
mechanism, which falls within the remit of the RPL Objective Function mechanism, which is among the responsibilities of the RPL Objective
(OF), needs to have specific path information. The specification of Function (OF), needs to have specific path information. This
the transmission of this information is the focus of this document. document focuses on the specification of the transmission of this
specific path information.
More concretely, this specification focuses on the extensions to the More concretely, this specification focuses on the extensions to the
DAG Metric Container [RFC6551] required for providing the PRE DAG Metric Container [RFC6551] required for providing the PRE
mechanism a part of the information it needs to operate. This mechanism a part of the information it needs to operate. This
information is the RPL [RFC6550] parent address set of a node and it 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 must be sent to potential children of the node. The RPL DIO Control
Control Message is the canonical way of broadcasting this kind of Message is the canonical way of broadcasting this kind of information
information and therefore its DAG Metric Container [RFC6551] field is and therefore its DAG Metric Container [RFC6551] field is used to
used to append a Node State and Attribute (NSA) object. The node's append a Node State and Attribute (NSA) object. The node's parent
parent address set is stored as an optional TLV within the NSA address set is stored as an optional TLV within the NSA object. This
object. This specification defines the type value and structure for specification defines the type value and structure for the parent
this TLV. address set TLV.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The draft uses the following Terminology: The draft uses the following Terminology:
Packet Replication and Elimination (PRE): The sending of multiple Packet Replication and Elimination (PRE): A method which transmits
copies of a packet using multi-path forwarding over a multi-hop multiple copies of a packet using multi-path forwarding over a
network and the consolidation of multiple received packet copies multi-hop network and which consolidates multiple received packet
to control flooding. See "Exploiting Packet Replication and copies to control flooding. See "Exploiting Packet Replication
Elimination in Complex Tracks in 6TiSCH LLNs" and Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] for more. [I-D.papadopoulos-6tisch-pre-reqs] for more details.
Alternative Parent (AP) Selection: The problem of how to select the Alternative Parent (AP) Selection: The mechanism for choosing the
next hop target node for a packet copy to be forwarded to when next hop node to forward a packet copy when replicating packets.
performing packet replication.
3. Alternative Parent Selection 3. Alternative Parent Selection
In the RPL protocol, each node maintains a list of potential parents. In the RPL protocol, each node maintains a list of potential parents.
For PRE, the PP node is defined to be the same as the RPL DODAG For PRE, the Preferred Parent (PP) node is defined to be the same as
Preferred Parent (PP) node. Furthermore, to construct an alternative the RPL DODAG Preferred Parent node. Furthermore, to construct an
path toward the root, in addition to the PP node, each node in the alternative path toward the root, in addition to the PP node, each
network registers an AP node as well from its Parent Set (PS). There node in the network registers an AP node as well from its Parent Set
are multiple alternative methods of selecting the AP node, (PS). There are multiple alternative methods of selecting the AP
functionality which is included in the operation of the RPL Objective node. This functionality is included in the operation of the RPL
Function (OF). A scheme which allows the two paths to remain Objective Function (OF). A scheme which allows the two paths to
correlated is detailed here. More specifically, in this scheme a remain correlated is detailed here. More specifically, in this
node will select an AP node close to its PP node to allow the scheme a node will select an AP node close to its PP node to allow
operation of overhearing between parents. If multiple potential APs the operation of overhearing between parents. For more details about
match this condition, the AP with the lowest rank will be registered. overhearing and its use in this context see Section 4.3.
"Promiscuous Overhearing" in "Exploiting Packet Replication and
Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match
this condition, the AP with the lowest rank will be registered.
There are at least three methods of performing the AP selection based There are at least three methods of performing the AP selection based
on common ancestors (CA), named Common Ancestor Strict, Common on common ancestors (CA), named Common Ancestor Strict, Common
Ancestor Medium, and Common Ancestor Relaxed, depending on how Ancestor Medium, and Common Ancestor Relaxed, depending on how
restrictive the selection process is. A more restrictive method will restrictive the selection process is. A more restrictive method will
limit flooding but might fail to select an appropriate AP, while a limit flooding but might fail to select an appropriate AP, while a
less restrictive one will more often find an appropriate AP but might less restrictive one will more often find an appropriate AP but might
increase flooding. increase flooding.
3.1. Common Ancestor Strict 3.1. Common Ancestor Strict
skipping to change at page 10, line 17 skipping to change at page 10, line 17
This proposal requests the allocation of a new value TBD1 for the This proposal requests the allocation of a new value TBD1 for the
"Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry "Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry
from IANA. from IANA.
8. References 8. References
8.1. Informative references 8.1. Informative references
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-22 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-23 (work
in progress), June 2019. in progress), June 2019.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.papadopoulos-6tisch-pre-reqs] [I-D.papadopoulos-6tisch-pre-reqs]
Papadopoulos, G., Montavont, N., and P. Thubert, Papadopoulos, G., Montavont, N., and P. Thubert,
"Exploiting Packet Replication and Elimination in Complex "Exploiting Packet Replication and Elimination in Complex
skipping to change at page 13, line 26 skipping to change at page 13, line 26
| Strict | | | | | Strict | | | |
| CA | 99.66 | 13.75 | 28.86 | | CA | 99.66 | 13.75 | 28.86 |
| Medium | | | | | Medium | | | |
+----------+---------------+------------------+---------------------+ +----------+---------------+------------------+---------------------+
Links: Links:
o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa-
extension branch) [1] extension branch) [1]
o Wireshark dissectors (for the optional TLV, i.e., PS) - currently o Wireshark dissectors (for the optional PS TLV) - currently merged
merged / in master [2] / in master [2]
Authors' Addresses Authors' Addresses
Remous-Aris Koutsiamanis (editor) Remous-Aris Koutsiamanis (editor)
IMT Atlantique IMT Atlantique
Office B00 - 126A Office B00 - 126A
2 Rue de la Chataigneraie 2 Rue de la Chataigneraie
Cesson-Sevigne - Rennes 35510 Cesson-Sevigne - Rennes 35510
FRANCE FRANCE
 End of changes. 15 change blocks. 
55 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/