<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>

<rfc category="std" ipr="trust200902" docName="draft-koutsiamanis-roll-nsa-extension-00"> 


<front> 

    <title abbrev="RPL MC NSA object type extension"> 
    RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type extension
    </title>
   
   
   

    <author initials="R.-A." surname="Koutsiamanis" fullname="Remous-Aris Koutsiamanis" role="editor">
      <organization>IMT Atlantique</organization>
      <address>         
        <postal>            
           <street>Office B00 - 126A</street>
           <street>2 Rue de la Chataigneraie</street>
           <city>Cesson-Sevigne - Rennes</city>
            <code>35510</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 299 12 70 49</phone>
    <email>aris@ariskou.com</email>
      </address>
    </author>


    <author initials="G.Z." surname="Papadopoulos" fullname="Georgios Papadopoulos">
      <organization>IMT Atlantique</organization>
      <address>
         <postal>
            <street>Office B00 - 114A</street>
            <street>2 Rue de la Chataigneraie</street>
            <city>Cesson-Sevigne - Rennes</city>
            <code>35510</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 299 12 70 04</phone>         
    <email>georgios.papadopoulos@imt-atlantique.fr</email>
      </address>
    </author>


    <author initials="N." surname="Montavont" fullname="Nicolas Montavont">
      <organization>IMT Atlantique</organization>
      <address>
         <postal>
            <street>Office B00 - 106A</street>
            <street>2 Rue de la Chataigneraie</street>
            <city>Cesson-Sevigne - Rennes</city>
            <code>35510</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 299 12 70 23</phone>
    <email>nicolas.montavont@imt-atlantique.fr</email>
      </address>
    </author>   
      
     
   <author initials="P" surname="Thubert" fullname="Pascal Thubert">   
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>
      <address>
         <postal>
            <street>Building D</street>
            <street>45 Allee des Ormes - BP1200 </street>
            <city>MOUGINS - Sophia Antipolis</city>
            <code>06254</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 497 23 26 34</phone>
         <email>pthubert@cisco.com</email>
      </address>
    </author>    

   <date/>

   <workgroup>ROLL</workgroup>

   <abstract>
   <t>
        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.
   </t>
   </abstract>
   

</front>

<middle>




<section title="Introduction">
    <t>
        Industrial network applications have stringent requirements on reliability and predictability,
        and typically leverage 1+1 redundancy, aka <xref target="I-D.papadopoulos-6tisch-pre-reqs">Packet Replication and Elimination (PRE)</xref> to achieve their goal.
        In order for wireless networks to be able to be used in such applications, 
        the principles of <xref target="I-D.ietf-detnet-architecture">Deterministic Networking</xref> 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.
    </t>


    <t>  
        To meet this goal, <xref target="IEEE802154-2015">IEEE Std. 802.15.4</xref>
        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.
   </t>
   
   
   <t>
        The 6TiSCH working group, focusing on IPv6 over IEEE Std. 802.15.4-TSCH, has worked on the issues previously
        highlighted and produced the <xref target="I-D.ietf-6tisch-architecture">"6TiSCH Architecture"</xref> to
        address that case.
        
        Building on this architecture, <xref target="I-D.papadopoulos-6tisch-pre-reqs">"Exploiting Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs"</xref>
        leverages PRE to improve the Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end latency,
        and limit jitter.
   </t>
   
   <t>
        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.
   </t>

   <t>
		More concretely, this specification focuses on the extensions to the <xref target="RFC6551">DAG Metric Container</xref> required for 
		providing the PRE mechanism a part of the information it needs to operate.
		This information is the <xref target="RFC6550">RPL</xref> 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 <xref target="RFC6551">DAG Metric Container</xref> 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.
    </t>	

</section> 

  


<section title="Terminology">

    	<t>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 <xref target="RFC2119"/>.</t>
    	

</section>



<section title="Tracks">


<section title="Tracks Overview">
	<t>
		The concept of Track is introduced in the <xref target="I-D.ietf-6tisch-architecture">"6TiSCH Architecture"</xref>,
        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.
	</t>
</section>


<section title="Complex Tracks">
	<t>
		Similarly to, but as a generalization of a simple Track, a Complex Track is defined in the <xref
		target="I-D.ietf-6tisch-architecture">"6TiSCH
		Architecture"</xref> 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 
		<xref target="I-D.papadopoulos-6tisch-pre-reqs">Packet Replication and Elimination (PRE)</xref>
		based on <xref target="I-D.ietf-detnet-architecture">DetNet</xref> principles.
		As an example, a complex Track allows for branching off and rejoining over congruent paths.
	</t>
	
	<t>
		In the following Section, we will detail Deterministic Networks 
		PRE techniques. 
	</t>
</section>

</section>



<section title="Packet Replication and Elimination principles">
    <t>
        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.
    </t>
    <t>
        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 <xref target="fig_replication"/>, 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. 
    </t>
    
    
    <figure anchor="fig_replication" align="center"
            title="Packet Replication: S transmits twice the same data packet, to its DP
                   (A) and to its AP (B).">
            <artwork align="center"><![CDATA[
 
               ===> (A) ====> (C) ===
             //         \\  //       \\
   source (S)             \\           (R) (root)
             \\         //  \\       //
               ===> (B) ====> (D) ===
           ]]></artwork>
	</figure>


    <t>
        In <xref target="I-D.papadopoulos-6tisch-pre-reqs">Exploiting Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs</xref>, 
        the concept of PRE is further expanded along with its requirements.
    </t>
		
</section>


<section title="Alternative Parent Selection Issue">
    <t>
		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 <xref target="I-D.papadopoulos-6tisch-pre-reqs">Exploiting Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs</xref>, 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.
    </t>			
	
    <t>	
		For instance, in <xref target="fig_replication"/>, 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. 
	</t>	


	<t>
    	In order to select their AP node, 6TiSCH nodes need to be aware of their grandparent node sets. 
		Within <xref target="RFC6550">RPL</xref>, the nodes use the DODAG Information Object (DIO) Control Message to broadcast information 
    	about themselves to potential children.
		However, <xref target="RFC6550">RPL</xref>, does not define how to propagate parent set related information, which is what this document addresses. 
    </t>
</section>



<section title="Node State and Attribute (NSA) object type extension">
    	<t> 
    	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 <xref target="RFC6551">DAG Metric Container option</xref> 
    	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 
    	<xref target="RFC6551">Node State and Attribute (NSA)</xref> 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 <xref target="RFC6551">Node State and Attribute (NSA)</xref> description, no TLV have been defined for use.
    	This document defines one TLV for the purpose of transmitting a node's parent node set.
    	</t>
        <figure title="Example DIO Message with a DAG Metric Container option" anchor="fig_dio">
<artwork><![CDATA[
 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                 //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>
        The structure of the DIO Control Message when a DAG Metric Container option is included is shown 
        in <xref target="fig_dio"/>.
        The DAG Metric Container option type (DAGMC Type in <xref target="fig_dio"/>) has the value 0x02 as per the 
        IANA registry for the RPL Control Message Options, and is defined in <xref target="RFC6550"/>.
        The DAG Metric Container option length (DAGMC Length in <xref target="fig_dio"/>) expresses the the DAG Metric Container length in bytes.
        DAG Metric Container data holds the actual data and is shown further expanded in <xref target="fig_dagmc"/>.
        </t>
        
        <figure title="DAG Metric Container data with Node State and Attribute (NSA) object body and a TLV" anchor="fig_dagmc">
<artwork><![CDATA[
 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) ...                               
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>
        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 <xref target="fig_dagmc"/>.
        The DAG Metric Container fields up to the first 48 bits (including the O flag) are defined in <xref target="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 <xref target="fig_dagmc"/>.
        <list style="hanging" hangIndent="6">
            <t hangText="PNS type:">
                The type of the Parent Node Set TLV.
                The value is 1.
            </t>
            <t hangText="PNS Length:">
                The total length of the TLV value field (PNS IPv6 address(es)) in bytes.
            </t>
            <t hangText="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 <xref target="RFC6550">Objective Function</xref> used by the node. 
            </t>
        </list>
        </t>
        
    <section title="Compression">
        <t>
            The PNS IPv6 address(es) field in the Parent Node Set TLV MAY be compressed using any compression method available to conserve
            space.
        </t>
    </section>    
</section>


<section title="Security Considerations">
   
    	<t>
    		TODO.
    	</t>
    
</section>



<section title="IANA Considerations">
   
        <t>
    		TBA.
    	</t>
    
</section>



  <?rfc compact="yes" ?>




</middle>




 <back>
<!--  <references title="Normative References"> 
  </references> -->


  <references title="Informative references">
        <?rfc include='reference.RFC.2119'?>
        <?rfc include="reference.RFC.6550"?> 						<!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks -->
        <?rfc include="reference.RFC.6551"?> 						<!-- Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks -->
        <!-- <?rfc include="reference.RFC.8180"?> -->			    <!-- 6TiSCH: Minimal 6TiSCH Configuration -->
		<?rfc include='reference.I-D.ietf-6tisch-architecture'?>	<!-- 6TiSCH: 6TiSCH architecture -->
		<!-- <?rfc include='reference.I-D.ietf-6tisch-6top-protocol'?> --> <!-- 6TiSCH: 6top protocol -->
		<?rfc include='reference.I-D.ietf-detnet-architecture'?>	<!-- DetNet: DetNet architecture -->
		<?rfc include='reference.I-D.papadopoulos-6tisch-pre-reqs'?>	<!-- Exploiting Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs -->
  </references>
  
  <references title="Other Informative References">
  	<reference anchor="IEEE802154-2015">
    	<front>
        	<title>
        	   IEEE Std 802.15.4-2015 Standard for Low-Rate Wireless Personal Area Networks (WPANs)
        	</title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date year="2015" month="December"/>
        </front>
    </reference>
  </references>
  

    
    
     
 </back> 
 </rfc>
