< draft-ietf-roll-nsa-extension-04.txt   draft-ietf-roll-nsa-extension-05.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: January 9, 2020 IMT Atlantique Expires: May 7, 2020 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
July 8, 2019 November 4, 2019
Common Ancestor Objective Functions and Parent Set DAG Metric Container Common Ancestor Objective Functions and Parent Set DAG Metric Container
Extension Extension
draft-ietf-roll-nsa-extension-04 draft-ietf-roll-nsa-extension-05
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. This document also describes Objective Functions functionality. This document also describes Objective Functions
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
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 3, line 35 skipping to change at page 3, line 35
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 is among the responsibilities of the RPL Objective mechanism, which is among the responsibilities of the RPL Objective
Function (OF), needs to have specific path information. This Function (OF), needs to have specific path information. This
document describes OFs which implement multi-path routing for PRE and document describes OFs which implement multi-path routing for PRE and
specifies the transmission of this specific path information. specifies the transmission of this specific path information.
For the OFs, this document specifies a group of OFs called Common For the OFs, this document specifies a group of OFs called Common
Ancestor (CA) OFs. A detailed description is made of how the path Ancestor (CA) OFs. A detailed description is made of how the path
information is used within the CA OF and how the subset of parents information is used within the CA OF and how the subset of parents
for forwarding packets is selected. This specification defines new for forwarding packets is selected. This specification defines a new
Objective Code Points (OCPs) for these CA OFs. shared Objective Code Point (OCP) for these CA OFs.
For the path information, this specification focuses on the For the path information, this specification focuses on the
extensions to the DAG Metric Container [RFC6551] required for extensions to the DAG Metric Container [RFC6551] required for
providing the PRE mechanism a part of the information it needs to providing the PRE mechanism a part of the information it needs to
operate. This information is the RPL [RFC6550] parent address set of operate. This information is the RPL [RFC6550] parent address set of
a node and it must be sent to potential children of the node. The a node and it must be sent to potential children of the node. The
RPL DIO Control Message is the canonical way of broadcasting this RPL DIO Control Message is the canonical way of broadcasting this
kind of information and therefore its DAG Metric Container [RFC6551] kind of information and therefore its DAG Metric Container [RFC6551]
field is used to append a Node State and Attribute (NSA) object. The 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 node's parent address set is stored as an optional TLV within the NSA
skipping to change at page 4, line 46 skipping to change at page 4, line 46
a node will select an AP node close to its PP node to allow the a node will select an AP node close to its PP node to allow the
operation of overhearing between parents. For more details about operation of overhearing between parents. For more details about
overhearing and its use in this context see Section 4.3. overhearing and its use in this context see Section 4.3.
"Promiscuous Overhearing" in "Exploiting Packet Replication and "Promiscuous Overhearing" in "Exploiting Packet Replication and
Elimination in Complex Tracks in 6TiSCH LLNs" Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match [I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match
this condition, the AP with the lowest rank will be registered. this condition, the AP with the lowest rank will be registered.
The OFs described here are an extension of the The Minimum Rank with The OFs described here are an extension of the The Minimum Rank with
Hysteresis Objective Function [RFC6719] (MRHOF) OF. In general, Hysteresis Objective Function [RFC6719] (MRHOF) OF. In general,
these OFs extend MRHOF by specifying how an AP is selected. The these OFs extend MRHOF by specifying how an AP is selected.
selection of the PP is kept the same as in MRHOF. Importantly, the calculation of the rank of the node though each
candidate neighbor and the selection of the PP is kept the same as in
MRHOF.
The ways in which the CA OFs modify MRHOF in a section-by-section The ways in which the CA OFs modify MRHOF in a section-by-section
manner follows: manner follows in detail:
3. The Minimum Rank with Hysteresis Objective Function: Same as 3. The Minimum Rank with Hysteresis Objective Function: Same as
MRHOF extended to AP selection. Minimum Rank path selection and MRHOF extended to AP selection. Minimum Rank path selection and
switching applies correspondingly to the AP with the extra CA switching applies correspondingly to the AP with the extra CA
requirement of having some match between ancestors, depending on requirement of having some match between ancestors, depending on
the specific variant of CA OF used. the specific variant of CA OF used.
3.1. Computing the Path Cost: Same as MRHOF extended to AP 3.1. Computing the Path Cost: Same as MRHOF extended to AP
selection. If a candidate neighbor does not fulfill the CA selection. If a candidate neighbor does not fulfill the CA
requirement then the path through that neighbor SHOULD be set to requirement then the path through that neighbor SHOULD be set to
skipping to change at page 6, line 22 skipping to change at page 6, line 22
6.1. Device Configuration: Same as MRHOF. 6.1. Device Configuration: Same as MRHOF.
6.2. Device Monitoring: Same as MRHOF. 6.2. Device Monitoring: Same as MRHOF.
Three OFs are defined which perform AP selection based on common Three OFs are defined which perform AP selection based on common
ancestors, named Common Ancestor Strict, Common Ancestor Medium, and ancestors, named Common Ancestor Strict, Common Ancestor Medium, and
Common Ancestor Relaxed, depending on how restrictive the selection Common Ancestor Relaxed, depending on how restrictive the selection
process is. A more restrictive method will limit flooding but might process is. A more restrictive method will limit flooding but might
fail to select an appropriate AP, while a less restrictive one will fail to select an appropriate AP, while a less restrictive one will
more often find an appropriate AP but might increase flooding. more often find an appropriate AP but might increase flooding. The
OFs are all represented with the same Objective Code Point (OCP):
TBD1.
All three OFs apply their corresponding common ancestor criterion to All three OFs apply their corresponding common ancestor criterion to
filter the list of candidate neighbours in the alternative parent filter the list of candidate neighbours in the alternative parent
set. The AP is then selected from the alternative parent set based set. The AP is then selected from the alternative parent set based
on Rank and using hysteresis as is done for the PP in MRHOF. on Rank and using hysteresis as is done for the PP in MRHOF.
3.1. Common Ancestor Strict 3.1. Common Ancestor Strict
In the CA Strict OF, represented with Objective Code Point (OCP) In the CA Strict OF the node will check if its Preferred Grand Parent
TBD1, the node will check if its Preferred Grand Parent (PGP), the PP (PGP), the PP of its PP, is the same as the PP of the potential AP.
of its PP, is the same as the PP of the potential AP.
( R ) root ( R ) root
. PS(S) = {A, B, C, D} . PS(S) = {A, B, C, D}
. PP(S) = C . PP(S) = C
. PP(PP(S)) = Y . PP(PP(S)) = Y
. .
PS(A) = {W, X} PS(A) = {W, X}
( W ) ( X ) ( Y ) ( Z ) PP(A) = X ( W ) ( X ) ( Y ) ( Z ) PP(A) = X
^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^
| \ // | \ // || \ / || PS(B) = {W, X, Y} | \ // | \ // || \ / || PS(B) = {W, X, Y}
skipping to change at page 7, line 46 skipping to change at page 7, line 46
o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) o Node B: PS(B) = Y and therefore it is equal to PP(PP(S))
o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) o Node D: PS(D) = Z and therefore it is different than PP(PP(S))
node S can decide to use node B as its AP node, since PP(PP(S)) = Y = node S can decide to use node B as its AP node, since PP(PP(S)) = Y =
PP(B). PP(B).
3.2. Common Ancestor Medium 3.2. Common Ancestor Medium
In the CA Medium OF, represented with Objective Code Point (OCP) In the CA Medium OF the node will check if its Preferred Grand Parent
TBD2, the node will check if its Preferred Grand Parent (PGP), the PP (PGP), the PP of its PP, is contained in the PS of the potential AP.
of its PP, is contained in the PS of the potential AP.
Using the same example, in Figure 1, the CA Medium parent selection Using the same example, in Figure 1, the CA Medium parent selection
method will select an AP for node S for which PP(PP(S)) is in PS(AP). method will select an AP for node S for which PP(PP(S)) is in PS(AP).
Given that PP(PP(S)) = Y: Given that PP(PP(S)) = Y:
o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set
o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set
o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set
node S can decide to use node B or D as its AP node. node S can decide to use node B or D as its AP node.
3.3. Common Ancestor Relaxed 3.3. Common Ancestor Relaxed
In the CA Relaxed OF, represented with Objective Code Point (OCP) In the CA Relaxed OF the node will check if the Parent Set (PS) of
TBD3, the node will check if the Parent Set (PS) of its Preferred its Preferred Parent (PP) has a node in common with the PS of the
Parent (PP) has a node in common with the PS of the potential AP. potential AP.
Using the same example, in Figure 1, the CA Relaxed parent selection Using the same example, in Figure 1, the CA Relaxed parent selection
method will select an AP for node S for which PS(PP(S)) has at least method will select an AP for node S for which PS(PP(S)) has at least
one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}:
o Node A: PS(A) = {W, X} and the common nodes are {X} o Node A: PS(A) = {W, X} and the common nodes are {X}
o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y}
o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z}
node S can decide to use node A, B or D as its AP node. node S can decide to use node A, B or D as its AP node.
3.4. Usage 3.4. Usage
The PS information can be used by any of the described AP selection The PS information can be used by any of the described AP selection
methods or other ones not described here, depending on requirements. methods or other ones not described here, depending on requirements.
It is optional for all nodes to use the same AP selection method. It is optional for all nodes to use the same AP selection method, and
Different nodes may use different AP selection methods, since the because the CA OFs share the same OCP, they can do that withing the
selection method is local to each node. For example, using different same RPL Instance. Different nodes may use different AP selection
methods can be used to vary the transmission reliability in each hop. methods, since the selection method is local to each node. For
example, using different methods can be used to vary the transmission
reliability in each hop.
4. Node State and Attribute (NSA) object type extension 4. Node State and Attribute (NSA) object type extension
In order to select their AP node, nodes need to be aware of their In order to select their AP node, nodes need to be aware of their
grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG
Information Object (DIO) Control Message to broadcast information Information Object (DIO) Control Message to broadcast information
about themselves to potential children. However, RPL [RFC6550], does about themselves to potential children. However, RPL [RFC6550], does
not define how to propagate parent set related information, which is not define how to propagate parent set related information, which is
what this document addresses. what this document addresses.
skipping to change at page 10, line 27 skipping to change at page 10, line 27
The structure of the DAG Metric Container data in the form of a Node 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 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs
field is shown in Figure 3. The first 32 bits comprise the DAG field is shown in Figure 3. The first 32 bits comprise the DAG
Metric Container header and all the following bits are part of the Metric Container header and all the following bits are part of the
Node State and Attribute object body, as defined in [RFC6551]. This Node State and Attribute object body, as defined in [RFC6551]. This
document defines a new TLV, which CAN be carried in the Node State document defines a new TLV, which CAN be carried in the Node State
and Attribute (NSA) object Optional TLVs field. The TLV is named and Attribute (NSA) object Optional TLVs field. The TLV is named
Parent Set and is abbreviated as PS in Figure 3. Parent Set and is abbreviated as PS in Figure 3.
PS type: The type of the Parent Set TLV. The value is TBD4. PS type: The type of the Parent Set TLV. The value is TBD2.
PS Length: The total length of the TLV value field (PS IPv6 PS Length: The total length of the TLV value field (PS IPv6
address(es)) in bytes. address(es)) in bytes.
4.1. Usage 4.1. Usage
The PS SHOULD be used in the process of parent selection, and The PS SHOULD be used in the process of parent selection, and
especially in AP selection, since it can help the alternative path to especially in AP selection, since it can help the alternative path to
not significantly deviate from the preferred path. The Parent Set is not significantly deviate from the preferred path. The Parent Set is
information local to the node that broadcasts it. information local to the node that broadcasts it.
The PS is used only within NSA objects configured as constraints and The PS is used only within NSA objects configured as constraints and
is used as per [RFC6551]. is used as per [RFC6551]. As a result, the PS does not affect the
calculation of the rank through candidate neighbors. It is only used
with the CA OFs to remove nodes which do not fulfill the CA OF
criteria from the candidate neighbor list.
5. Controlling PRE 5. Controlling PRE
PRE is very helpful when the aim is to increase reliability for a PRE is very helpful when the aim is to increase reliability for a
certain path, however its use creates additional traffic as part of certain path, however its use creates additional traffic as part of
the replication process. It is conceivable that not all paths have the replication process. It is conceivable that not all paths have
stringent reliability requirements. Therefore, a way to control stringent reliability requirements. Therefore, a way to control
whether PRE is applied to a path's packets SHOULD be implemented. whether PRE is applied to a path's packets SHOULD be implemented.
For example, a traffic class label can be used to determine this For example, a traffic class label can be used to determine this
behavior per flow type as described in Deterministic Networking behavior per flow type as described in Deterministic Networking
Architecture [I-D.ietf-detnet-architecture]. Architecture [I-D.ietf-detnet-architecture].
6. Security Considerations 6. Security Considerations
The structure of the DIO control message is extended, within the pre- The structure of the DIO control message is extended, within the pre-
defined DIO options. Therefore, the security mechanisms defined in defined DIO options. Therefore, the security mechanisms defined in
RPL [RFC6550] apply to this proposed extension. RPL [RFC6550] apply to this proposed extension.
7. IANA Considerations 7. IANA Considerations
This proposal requests the allocation of new values TBD1, TBD2, TBD3 This proposal requests the allocation of a new value TBD1 from the
from the "Objective Code Point (OCP)" sub-registry of the "Routing "Objective Code Point (OCP)" sub-registry of the "Routing Protocol
Protocol for Low Power and Lossy Networks (RPL)" registry. This for Low Power and Lossy Networks (RPL)" registry. This proposal also
proposal also requests the allocation of a new value TBD4 for the requests the allocation of a new value TBD2 for the "Parent Set" TLV
"Parent Set" TLV from the Routing Metric/Constraint TLVs sub-registry from 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-24 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
in progress), July 2019. in progress), October 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
Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre-
 End of changes. 17 change blocks. 
33 lines changed or deleted 40 lines changed or added

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