--- 1/draft-ietf-roll-nsa-extension-04.txt 2019-11-04 16:13:35.336023828 -0800 +++ 2/draft-ietf-roll-nsa-extension-05.txt 2019-11-04 16:13:35.368024641 -0800 @@ -1,22 +1,22 @@ ROLL R. Koutsiamanis, Ed. Internet-Draft G. Papadopoulos Intended status: Standards Track N. Montavont -Expires: January 9, 2020 IMT Atlantique +Expires: May 7, 2020 IMT Atlantique P. Thubert Cisco - July 8, 2019 + November 4, 2019 Common Ancestor Objective Functions and Parent Set DAG Metric Container Extension - draft-ietf-roll-nsa-extension-04 + draft-ietf-roll-nsa-extension-05 Abstract Implementing 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. This document also describes Objective Functions @@ -31,21 +31,21 @@ 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 January 9, 2020. + This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 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 @@ -117,22 +117,22 @@ 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 is among the responsibilities of the RPL Objective Function (OF), needs to have specific path information. This document describes OFs which implement multi-path routing for PRE and specifies the transmission of this specific path information. For the OFs, this document specifies a group of OFs called Common 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 - for forwarding packets is selected. This specification defines new - Objective Code Points (OCPs) for these CA OFs. + for forwarding packets is selected. This specification defines a new + shared Objective Code Point (OCP) for these CA OFs. For the path information, 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 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 @@ -173,25 +173,27 @@ a node will select an AP node close to its PP node to allow the operation of overhearing between parents. For more details about 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. The OFs described here are an extension of the The Minimum Rank with Hysteresis Objective Function [RFC6719] (MRHOF) OF. In general, - these OFs extend MRHOF by specifying how an AP is selected. The - selection of the PP is kept the same as in MRHOF. + these OFs extend MRHOF by specifying how an AP is selected. + 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 - manner follows: + manner follows in detail: 3. The Minimum Rank with Hysteresis Objective Function: Same as MRHOF extended to AP selection. Minimum Rank path selection and switching applies correspondingly to the AP with the extra CA requirement of having some match between ancestors, depending on the specific variant of CA OF used. 3.1. Computing the Path Cost: Same as MRHOF extended to AP selection. If a candidate neighbor does not fulfill the CA requirement then the path through that neighbor SHOULD be set to @@ -245,32 +247,33 @@ 6.1. Device Configuration: Same as MRHOF. 6.2. Device Monitoring: Same as MRHOF. Three OFs are defined which perform AP selection based on common ancestors, named Common Ancestor Strict, Common Ancestor Medium, and Common Ancestor Relaxed, depending on how restrictive the selection process is. A more restrictive method will limit flooding but might 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 filter the list of candidate neighbours in the alternative parent 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. 3.1. Common Ancestor Strict - In the CA Strict OF, represented with Objective Code Point (OCP) - TBD1, the node will check if its Preferred Grand Parent (PGP), the PP - of its PP, is the same as the PP of the potential AP. + In the CA Strict OF the node will check if its Preferred Grand Parent + (PGP), the PP of its PP, is the same as the PP of the potential AP. ( R ) root . PS(S) = {A, B, C, D} . PP(S) = C . PP(PP(S)) = Y . PS(A) = {W, X} ( W ) ( X ) ( Y ) ( Z ) PP(A) = X ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ | \ // | \ // || \ / || PS(B) = {W, X, Y} @@ -299,62 +302,63 @@ 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)) node S can decide to use node B as its AP node, since PP(PP(S)) = Y = PP(B). 3.2. Common Ancestor Medium - In the CA Medium OF, represented with Objective Code Point (OCP) - TBD2, the node will check if its Preferred Grand Parent (PGP), the PP - of its PP, is contained in the PS of the potential AP. + In the CA Medium OF the node will check if its Preferred Grand Parent + (PGP), the PP of its PP, is contained in the PS of the potential AP. 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). 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 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 node S can decide to use node B or D as its AP node. 3.3. Common Ancestor Relaxed - In the CA Relaxed OF, represented with Objective Code Point (OCP) - TBD3, the node will check if the Parent Set (PS) of its Preferred - Parent (PP) has a node in common with the PS of the potential AP. + In the CA Relaxed OF the node will check if the Parent Set (PS) of + its Preferred Parent (PP) has a node in common with the PS of the + potential AP. 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 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 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} node S can decide to use node A, B or D as its AP node. 3.4. Usage The PS information can be used by any of the described AP selection methods or other ones not described here, depending on requirements. - It is optional for all nodes to use the same AP selection method. - Different nodes may use different AP selection 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. + It is optional for all nodes to use the same AP selection method, and + because the CA OFs share the same OCP, they can do that withing the + same RPL Instance. Different nodes may use different AP selection + 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 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 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. @@ -418,42 +422,46 @@ 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 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 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 address(es)) in bytes. 4.1. Usage The PS SHOULD be used in the process of parent selection, and especially in AP selection, since it can help the alternative path to not significantly deviate from the preferred path. The Parent Set is information local to the node that broadcasts it. 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 PRE is very helpful when the aim is to increase reliability for a certain path, however its use creates additional traffic as part of the replication process. It is conceivable that not all paths have stringent reliability requirements. Therefore, a way to control whether PRE is applied to a path's packets SHOULD be implemented. + For example, a traffic class label can be used to determine this behavior per flow type as described in Deterministic Networking Architecture [I-D.ietf-detnet-architecture]. 6. 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. @@ -452,35 +460,34 @@ Architecture [I-D.ietf-detnet-architecture]. 6. 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. 7. IANA Considerations - This proposal requests the allocation of new values TBD1, TBD2, TBD3 - from the "Objective Code Point (OCP)" sub-registry of the "Routing - Protocol for Low Power and Lossy Networks (RPL)" registry. This - proposal also requests the allocation of a new value TBD4 for the - "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-registry - from IANA. + This proposal requests the allocation of a new value TBD1 from the + "Objective Code Point (OCP)" sub-registry of the "Routing Protocol + for Low Power and Lossy Networks (RPL)" registry. This proposal also + requests the allocation of a new value TBD2 for the "Parent Set" TLV + from the Routing Metric/Constraint TLVs sub-registry from IANA. 8. References 8.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-24 (work - in progress), July 2019. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work + in progress), October 2019. [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-13 (work in progress), May 2019. [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-