<?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-papadopoulos-raw-pareo-reqs-01">


<front> 

    <title abbrev="PAREO Requirements in RAW">
    Exploiting Packet Replication and Elimination in Complex Tracks in LLNs
    </title>
   
   
    <author initials="G.Z." surname="Papadopoulos" fullname="Georgios Papadopoulos" role="editor">
      <organization>IMT Atlantique</organization>
      <address>         
        <postal>            
           <street>Office B00 - 102A</street>
           <street>2 Rue de la Ch&acirc;taigneraie</street>
           <city>Cesson-S&eacute;vign&eacute; - 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="R.-A." surname="Koutsiamanis" fullname="Remous-Aris Koutsiamanis">
      <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="N." surname="Montavont" fullname="Nicolas Montavont">
      <organization>IMT Atlantique</organization>
      <address>
         <postal>
            <street>Office B00 - 106A</street>
            <street>2 Rue de la Ch&acirc;taigneraie</street>
            <city>Cesson-S&eacute;vign&eacute; - 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>RAW</workgroup>

   <abstract>
   <t>
        The Packet Replication and Elimination (PRE) mechanism 
        duplicates data packets into several paths in the network
        to increase reliability and provide low jitter. 
        PRE may be used to complement layer-2 Automatic Repeat reQuest (ARQ) and 
        receiver-end Ordering to form the PAREO functions.
        Over a wireless medium, this technique can take advantage of communication
        Overhearing, when parallel transmissions over two adjacent
        paths are scheduled. This document presents the concept and
        details the required changes to the current specifications that
        will be necessary to enable the PAREO functions.
   </t>
   </abstract>
   

</front>

<middle>



<!--section title="TEMPORARY EDITORIAL NOTES">

   <t>
        This document is an Internet Draft, so it is work-in-progress by nature.
           It contains the following work-in-progress elements:
   </t>    
              
   <t>
       <list style="symbols">
        <t>"TODO" statements are elements which have not yet been written by the authors 
        for some reason (lack of time, ongoing discussions with no clear consensus, etc).
        The statement does indicate that the text will be written at some time.</t>
       </list>
   </t>
            
</section --> 



<section title="Introduction">
    <t>
        This draft describes industrial use cases which require deterministic flows over 
        wireless multi-hop paths.
    </t>

    <t>
        The RAW use cases explicitly do not propose any specific solution or 
        design for the RAW architecture or protocols. 
        These are the subjects of other RAW drafts.
        The RAW use cases are not considered to be concrete requirements by the RAW Working 
        Group.
    </t>
    
    <t>
        The industrial use cases covered in this draft are professional audio, wireless 
        for industrial applications and amusement parks.
    </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 6TiSCH architecture introduces the concept of
        Tracks in <xref
        target="I-D.ietf-6tisch-architecture">6TiSCH
        Architecture</xref>. A simple track is composed of a
        sequence of cells (a combination of a transmitter, a
        receiver and a given channel offset) to ensure the
        transmission of a single packet from a source
        node to a destination node across a multihop path.
    </t>
</section>

<section title="Complex Tracks">
    <t>
        A Complex Track is designed as a directed acyclic graph from a source node 
        towards a destination node to support multi-path forwarding, as introduced in 
        <xref target="I-D.ietf-6tisch-architecture">6TiSCH Architecture</xref>. 
        By employing <xref target="I-D.ietf-detnet-architecture">DetNet</xref>
        Packet Replication and Elimination (PRE) functions, several paths may be computed, 
        and these paths may be more or less independent. For example, a complex Track may 
        branch off and rejoin over non-congruent paths (branches).
        <!-- [XV] this is not clear. What are the requirements to compute that paths? 
are they feasible given the restrictions of a 6TiSCH network. Could you detail more how 
this paths may be computed? what is the information that is required and how this information 
is made available to the nodes in the network? Is this a L4 task?  or is handled at the L2.5?
[GP] please allow me to reply to this comment in the new version. We have referred to these requirements in the "Requirements Related to Cell Reservation" section in the new version. We also address this a bit further down in this version in section 4 "PRE model can be implemented in ...". (DONE).  -->
    </t>
    
    <t>
        Some more details for Deterministic Network 
        PRE techniques are presented in the following Section. 
    </t>
</section>

</section>


<section title="Packet Replication and Elimination principles">

    <t>
        In a nutshell, PRE establishes several paths in a
        network to provide redundancy and parallel transmissions to
        bound the end-to-end delay to traverse the network. 
        Optionally, promiscuous listening between paths is possible, such that the nodes
        on one path may overhear transmissions along the other path.
        Considering the scenario shown in <xref
        target="fig_ladder"/>, 
        many different paths are possible for S to reach R. A simple
        way to benefit from this topology could be to use the
        two independent paths via nodes A, C, E and via B, D, F.  But
        more complex paths are possible by interleaving transmissions
        from the lower level of the path to the upper level.
    </t>         
        
        
    <t>         
         PRE may also take advantage of
         the shared properties of the wireless medium to compensate for the
         potential loss that is incurred with radio transmissions.
         For instance, when the source sends to A, B may listen also and
         get a second chance to receive the frame without an
         additional transmission. Note that B would not have to listen if it
         already received that particular frame at an earlier timeslot in a dedicated transmission towards B.
<!-- [->] This is assuming some sort of implicit knowledge in B. Not sure if this is  -->
<!-- possible without specific signaling.   -->
<!-- [GP] Yes, we may need additional 6P transactions from the source to B, or  -->
<!-- multicast 6P transaction from the source to both A and B. However, this  -->
<!-- need to be discussed and defined. We have referred to these requirements in the "Requirements Related to Cell Reservation" section in the upcoming version.  (DONE) -->
    </t>


      <figure anchor="fig_ladder" align="center" title="A Typical Ladder Shape with Two Parallel Paths Toward the Destination">
         <artwork align="center"><![CDATA[
 
                 (A)   (C)   (E)   
                                                
   source (S)                       (R) (root)
                                                
                 (B)   (D)   (F)  

        ]]></artwork>
     </figure>

    <t>
        The PRE model can be implemented in both centralized and distributed scheduling 
        approaches. 
        In the centralized approach, a Path Computation Element (PCE) scheduler calculates 
        the routes and schedules the communication among the nodes along a circuit such 
        as a Label switched path. 
        In the distributed approach, each node selects its route to the destination, 
        typically using a source routing header. 
        <!-- This specification focuses on the distributed path diversity. -->
        In both cases, at each node in the paths, a default parent and alternative parent(s) should
        be selected to set up complex tracks.
    </t>
    


    <t>
        In the following Subsections, all the required operations 
        defined by PRE, namely, Alternative Path Selection, Packet Replication, Packet 
        Elimination and Promiscuous Overhearing, are described.
    </t>



<section title="Packet Replication">

    <t>
        The objective of PRE is to provide deterministic networking properties:
        high reliability and bounded latency. 
        To achieve this goal, determinism in every hop of the forwarding paths MUST be 
        guaranteed. 
<!-- NM - Not clear what is a level. Not clear to me if it is a "should be"-->
<!-- GP: is it clear now? -->
        By employing a Packet Replication procedure, each node forwards 
        a copy of each data packet to multiple parents: its Default Parent (DP) and multiple Alternative Parents (APs). 
        To do so, each node (i.e., source and intermediate node) transmits the 
        data packet multiple times in unicast to each parent. 
        For instance, in <xref target="fig_replication"/>, the source node S is 
        transmitting the packet to both parents, nodes A and B, in two different 
        timeslots within the same TSCH slotframe. An example TSCH schedule is shown in <xref target="fig_replication_schedule"/>.
        Thus, the packet eventually obtains parallel paths to the destination.
    </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) => (E) === 
             //        \\//   \\//       \\
   source (S)          //\\   //\\         (R) (root)
             \\       //  \\ //  \\      //
               ===> (B) => (D) => (F) ===

            ]]></artwork>
        </figure>
        
        <figure anchor="fig_replication_schedule" align="center"
            title="Packet Replication: Sample TSCH schedule">
            <artwork align="center"><![CDATA[
                                Timeslot                 
+---------++------+------+------+------+------+------+------+
| Channel || 0    | 1    | 2    | 3    | 4    | 5    | 6    |
+---------++======+======+======+======+======+======+======+
| 0       || S->A | S->B | B->C | B->D | C->F | E->R | F->R |
+---------++------+------+------+------+------+------+------+
| 1       ||      | A->C | A->D | C->E | D->E | D->F |      |
+---------++------+------+------+------+------+------+------+

            ]]></artwork>
        </figure>        
        
<!-- [XV] here you are only considering duplication at the source. While would be better IMHO to duplicate before those links that show lower performance. Would you also consider duplication at inner hops?  -->
<!-- [GP] Yes, definitely, there is replication (duplication) at inner hops.  -->
<!-- For instance, A will transmit both to its default parent C and alternative B. -->
<!-- The Figure 2 and the text in 4.1 is updated. (Modified, DONE) -->
<!-- As far as only duplicating at lower performance links, this is a very good point and a nice optimisation target. This needs to be discussed further -->

<!-- [GP] Do you think a Figure with the TSCH schedule representation would be helpful?         -->
<!-- [RK] Yes, I do. Added  fig_replication_schedule -->
            
</section>



<section title="Packet Elimination">

    <t>
        The replication operation increases the traffic load in the
        network, due to packet duplications.  Thus, a Packet Elimination
        operation SHOULD be applied at each RPL DODAG level to reduce
        the unnecessary traffic. To this aim, once a node receives the 
        first copy of a data packet, it discards the subsequent copies. <!-- see Figure X
        (TODO) --> Because the first copy that reaches a node is the
        one that matters, it is the only copy that will be
        forwarded upward. Then, once a node performs the Packet Elimination operation,
        it will proceed with the Packet Replication operation to forward the packet 
        toward the RPL DODAG Root.
<!-- [xv] Will this node duplicate it again? -->
<!-- [GP] Yes, it will replicate when it will forward it. Text is updated.(Modified, DONE) -->

<!-- [GP] Do you think a Figure is necessary, or it is clear enough?         -->
<!-- [RK] I think this is clear enough and no Figure is really needed here (DONE) -->
    </t>

</section>



<section title="Promiscuous Overhearing">

    <t>
        Considering that the wireless medium is broadcast by nature, any neighbor of 
        a transmitter may overhear a transmission. 
        By employing the Promiscuous Overhearing operation, a DP and some AP(s) eventually have more 
        chances to receive the data packets. 
        In <xref target="fig_overhearing"/>, when node A is transmitting to its DP 
        (node C), the AP (node D) and its sibling (node B) may decode this data packet as 
        well. 
        As a result, by employing corellated paths, a node may have multiple 
        opportunities to receive a given data packet. 
        This feature not only enhances the end-to-end reliability but also it reduces the 
        end-to-end delay and increases energy efficiency.
    </t>
    
    
        <figure anchor="fig_overhearing" align="center"
            title="Unicast to DP with Overhearing: by employing Promiscuous Overhearing, 
            DP, AP and the sibling nodes have more opportunities to receive the same data 
            packet.">
            <artwork align="center"><![CDATA[
 
               ===> (A) ====> (C) ====> (E) ==== 
             //     ^ | \\                      \\
   source (S)       | |   \\                      (R) (root)
             \\     | v     \\                  //
               ===> (B) ====> (D) ====> (F) ====

            ]]></artwork>
        </figure>

</section>


<!--
<section title="Summary">
   
    <t>
        PRE mechanism is only useful if replication and elimination is taking place 
        in the network. 
        It has capabilities to:
        <list style="symbols">
          <t>provide deterministic and predictable data packet transmissions, by 
          introducing alternative and parallel paths.</t>
          <t>achieve network reliability above 99%, by employing replication and 
          elimination operations.</t>
          <t>ultra-low jitter performance, by employing promiscuous overhearing 
          procedure.</t>
      </list>
    </t>
    
</section>
-->

</section>


<!-- <section title="Implementation Status">
   
        <t>
            A research-stage implementation of the LeapFrog Collaboration for a 6TiSCH IoT 
            use case is developed at IMT Atlantique.  
            It is implemented on top of COOJA, the network simulator distributed as part 
            of the Contiki OS, and emulating the Z1 motes.
        </t>
        
        <t>
               Links:
               <list>
                   <t>
                       github: TODO.
                   </t>
                   <t>
                    Contiki OS: http://www.contiki-os.org/start.html
                </t>
                <t>
                    Z1 motes: http://zolertia.io/z1
                </t>
            </list>
        </t>   
    
</section> -->


<section title="Requirements">

<section title="Requirements Related to Alternative Parent Selection">
    <t>
        To perform the Packet Replication procedure, it is necessary
        to define the Alternative Parent(s) and, consequently,
        the path to the destination node, for each node
        in the wireless network. An AP can be selected in many
        different ways, and is dependent on the implementation. 
    </t>
    

    <t>
        The requirements are:
    </t>
    

    <t>    
        <list style="hanging" hangIndent="6">
            <t hangText="Req1.1:">
                The routing protocol SHOULD be extended to allow for each node to select AP(s) in addition to the DP.
                This enables packet replication to multiple parents.
            </t>
<!-- Proposed answer:
[GP] I agree that the core routing protocol already supports selecting the N best parents. This part does not require changing.
However, constraining the paths for higher efficiency requires a more complicated way of ranking the parents.
For example, if you just take the 2 best parents based on ETX, the paths typically diverge (i.e. disjoint paths), resulting in:
a) flooding, because Packet Elimination is not possible,
b) compromising determinism, by not controlling the number of hops to the destination (i.e. risking low jitter performance).
Thus, I think that we will need to define a new RPL Objective Function for PRE.
(DONE)

Others:
[GP] Is it implementation only? I mean, be default yes RPL will give you the N best based on ETX for instance. But the questions is: should the Alternative Parent to be Defined based on 2nd best ETX? For instance, in draft-ietf-roll-nsa-extension-01, we define Alternative Parent Selection based on common ancestor with ultimate goal the traffic to go through parallel paths and not disjoint. 
While with 1st and 2nd best ETX you may end up with disjoint paths, which may risk the deterministic behavior. 

Alternative answer:
[RK] Selecting AP(s) is indeed taking the first N lowest ranked parents from the parent set.
However, converting the AP selection method into a rank for each potential parent such that somewhat complex conditions are met is not necessarily trivial. Therefore, we can avoid changing core parts of the routing protocol, but at a minimum a new objective function which performs theses checks is required. Ideally one that can fallback to the "standard" MRHOF behaviour when no alternative parents are required or available.
For instance, in draft-ietf-roll-nsa-extension-01, we define Alternative Parent Selection based on common ancestor with ultimate goal the traffic to go through parallel paths and not disjoint. 
DONE: simplify and more clear. Elimination not available with 2 ETX. 
[GP] I agree that the core routing protocol already supports selecting the N best parents. This part does not require changing.
However, constraining the paths for higher efficiency requires a more complicated way of ranking the parents.
For example, if you just take the 2 best parents based on ETX, the paths typically diverge, and flooding results because Packet Elimination is not possible.
I think that we will need to define a new Objective Function for PRE.
 -->



<!-- [XV] what is specific in duplicating a packet that needs to be known at L3? Does L3 need to know this is a duplicate packet? or this is something that  -->
<!-- is handled at L4-7?  -->
<!-- [GP] I updated this part of the sentence. Thanks. -->
<!-- [RK] L3 does need to know because that is where packet elimination is also perfomed at. -->


<!-- [GP] Note that the current Subsection is extended to two new subsections, i.e., 5.1 and 5.2, respectively.  -->
<!-- (Modified, TODO) -->
            
            <t hangText="Req1.2:">
                Considering that the Packet Replication procedure significantly increases the traffic in a network, when proposing solutions for Alternative Parent Selection, they should be efficient enough to mitigate the potential uncontrolled packet duplications.
            </t>
            <t hangText="Req1.3:">
                The topology SHOULD be defined when proposing solutions for Alternative Parent Selection.
                For instance, the ladder topology should be defined explicitly e.g., number of parallel paths, density.
            </t>
        </list>                
    </t>

</section>



<section title="Requirements Related to Propagated Information">
    <t>
        For Alternative Parent(s) selection, nodes MAY need additional information about the network topology.
<!--         This is especially important when the multi-path transmission is performed in a distributed manner. -->
        This draft does not prescribe the information required for AP selcetion or how it is to be propagated to the nodes that need to select AP(s).
        TODO: To be discussed.
    </t>
    
         
    <t>
        The requirement is:
    </t>
        
    <t>
        <list style="hanging" hangIndent="6">
            <t hangText="Req2.1:">
                Nodes MUST have a way of receiving the required information for efficient Alternative Parent Selection.
            </t>
        </list>
    </t>
         
    <t>
        As an example, it is possible to use and extend the <xref target="RFC6550">RPL</xref> DODAG Information Object (DIO) Control Message to allow nodes to propagate information about themselves to potential children.
        For instance, <xref target="I-D.ietf-roll-nsa-extension">"RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type extension"</xref> focuses on extending the <xref target="RFC6551">DAG Metric Container</xref> by defining a new type-length-value (TLV), entitled Parent Set (PS) which can be carried in the Node State and Attribute (NSA) object.        
<!--         In <xref target="fig_dio"/>, DIO control message with a DAG Metric Container option is illustrated. However, <xref target="RFC6550">RPL</xref>, does 
        not indicates how to propagate parent set related information. 
 -->    
    </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>
        <list style="hanging" hangIndent="6">
            <t hangText="Req2.1:">
                DIO control messages can include multiple options.
                <xref target="RFC6551">DAG Metric Container option</xref> is structurally suitable for transferring parent node set information.
                Therefore, to enable PRE, nodes MUST broadcast their parent node set to their potential children through the extended DIO control message. 
                For instance, <xref target="I-D.ietf-roll-nsa-extension">"RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type extension"</xref> focuses on extending the <xref target="RFC6551">DAG Metric Container</xref> by defining new type-length-value (TLV), entitled Parent Set (PS) which CAN be carried in the Node State and Attribute (NSA) object.
            </t>
        </list>
    </t>
 -->
 <!-- 
[XV] What information? a node receives DIOs from different neighbors. Could that information be used without modyfing the DIO?
[GP] Please check the new 5.2 subsection. At ROLL WG we propose an alternative parent selection mechanism. This requires that we need to update the DIO control packet accordingly.  (DONE, Modified)      
    
NM: I don't like the way this requirement is writtent, because it is strongly linked to a solution. We cannot start by saying DIO can include multiple options, we should start with the requirement itself, which I am not sure I undesrtand...
[RK]: I agree, there are two ways to do this, either prescribe a specific solution, e.g. using ietf-roll-nsa-extension, or leave it more general. If we prescribe the more specific one, then we can't be general and vice versa.
RK DONE: say information for AP selection PRE *is required*. Do not specify how that is received. 
 -->        
</section>



<section title="Requirements Related to Promiscuous Overhearing">
    <t>
        As stated previously, to further increase the network reliability and to  achieve deterministic packet deliveries at the destination node, Promiscuous Overhearing can be considered. 
    </t>
    

    <t>    
        As it is described in <xref target="RFC8180">BCP 210</xref>, in TSCH mode, the data frames are transmitted in unicast mode and are acknowledged by the receiving neighbor. 
        To perform the promiscuous overhearing procedure, there SHOULD be an option for the transmitted frames, i.e., in unicast, to be overheard by the potential neighborhood node.
    </t>
    
    <t>
        Destination address filtering is performed at the Medium Access Control (MAC) layer. For example, according to IEEE std. 802.15.4 <xref target="IEEE802154-2015"/>, a node receiving a packet with a destination address different than its own and different to 0xFF discards the packet.
        A change is needed to be able to receive packets whose destination address is neither multicast nor the overhearing node's MAC address. 
    </t>

    <t>
        The requirements are:
    </t>


    <t>
        <list style="hanging" hangIndent="6">
            <t hangText="Req3.1:">
                <!--Note that this functionality can even be automatically performed by hardware in some MCUs. comment by Xavi-->
                The MAC implementation MUST be able to disable MAC address filtering to <!--programmatically/hardcoded--> accept the overheard frame.
            </t>

            <t hangText="Req3.2:">
                The  <xref target="RFC8480">6top Protocol</xref> specification MUST be extended to indicate disabling MAC filtering in a receiving cell. 
                This can be achieved by reserving a bit in the 6P CellOptions Bitmap (Section 6.2.6 <xref target="RFC8480"/>) for this purpose.
            </t>
                <!--then we can talk about what 6P should provide to support it.-->
<!-- 
[RK] We cannot use anycast/multicast destination address if we want an ACK, in 802.15.4
6.7.4 Use of acknowledgments and retransmissions
A Data frame or MAC command shall be sent with the AR field set appropriately for the frame. A Beacon
frame or Ack frame shall always be sent with the AR field set to indicate no acknowledgment requested.
Similarly, any frame that is broadcast or has a group address as the extended destination address, as defined
in IEEE Std 802, shall be sent with its AR field set to indicate no acknowledgment requested.
 -->                
<!--             
            <t hangText="Req3.2:">
                The <xref target="RFC8480">6top Protocol</xref> SHOULD be extended to possibly allow a cell reservation with two receivers, i.e., DP and AP.
                Considering that each frame may be transmitted twice in unicast to each parent, then depending the transmission, either DP will acknowledge the frame or AP will.
            </t>
 -->
 <!-- 
[XV] this is an interesting requirement. The destination address filtering is performed by the MAC layer,  usually a node receiving a packet with a destination address different than its own and different to 0xFF  discards the packet immediatelly. Note that this functionality can even be automatically performed by hardware in some MCUs.
[RK] DONE: Does 6P allow shared cells negotiation. Yes normally. 

[GP] Good point. A new Req3.1 is added, many thanks.

If we assume that a 15.4 implementation can baypass this filtering, either by using an anycast/multicast address as  destination or by programmatically forcing to accept such a frame, then we can talk about what 6P should provide to support it.  

[GP] nice point! Please see my following response/comment.

Given that consideration and assuming that the MAC Layer is the responsible of handling the reception of a non-matching destination address, 6P can simply support that traffic pattern through the use of a TX cell at the transmitter side and a RX cell at the reception side (in both DP and AP) right ? 

[GP] If we are going for anycast/multicast, I am afraid then we have the problem of the reliability. I mean, example: Source S transmits in anycast/multicast to its Parents Default A and Alternative B, who is going to ACK here?

[GP] Note that his requirement is moved to new 5.3.   (Modified, DONE) 
 -->            
<!--             <t hangText="Req3.3:">
                Next, to request the overhearing cells, the 6P ADD Request Format SHOULD be transmitted either twice to each parent, i.e., DP and AP, or once in multicast to both parents.
                This procedure SHOULD be considered in <xref target="RFC8480">6top Protocol</xref> specification.
            </t>
 -->
 <!-- 
[XV] Sending it twice is fine. Not need to complicate 6P with multicast.
[GP] Yes, it can be done by transmitting twice. But don't we consume too much energy like this? (TODO)   
[RK] For a small number of APs (1-2) the overhead should be OK. We might want something more intelligent for more APs than that, though. We can leave this unaddressed for now though.
 -->
 
<!-- 
              <t hangText="Req3.2:">
                The  <xref target="RFC8480">6top Protocol</xref> specification.
            </t>
 -->
 
            <t hangText="Req3.3:">
                The overhearing node can be configured with the timeslot set to shared reception, thus, there will be no acknowledgement from it.
                However, there is the security issue that needs to be considered.
                Since the overhearing case implies that it is not possible to have per-pair keying, there MUST be a key that the overhearing node will be aware of.
                Hence, the <xref target="I-D.ietf-6tisch-architecture">Minimal Security Framework for 6TiSCH</xref> specification should consider such a scenario.
            </t>
 
         </list>
    </t>
</section>

        <!-- TODO: Distributed or Centralized scheduling? -->


<!-- <section title="Requirements Related to Cells without ACKs">
    <t>
        As stated in <xref target="RFC8180">BCP 210</xref>, each date frame is acknowledged by the receiving node. 
        However, by employing promiscuous overhearing operation, particular attention should be given to who will acknowledge a transmission, i.e., the DP, and / or 
        one of the AP(s) 

    </t>

    <t>
        The requirements are:
    </t>

    <t>
     
        <list style="hanging" hangIndent="6">
-->
<!-- 
            <t hangText="Req4.1:">
                To avoid the ACK collision, the TSCH Schedule as per <xref target="RFC8180">BCP 210</xref>, only the destination node of a packet MUST acknowledge the data packet.
            </t>
 -->
 <!-- 
[XV] which may happen as the AP will detect that the destination address does not match its address and hence does not ACK. 
   this is an implementation decision in my opinion. 
[GP] Yes, I agree.
[GP] I added another Requirement here. (DONE, Modified)    
 -->

<!--
             <t hangText="Req4.1:">
                The overhearing node can be configured with the timeslot set to shared, thus, there will be no acknowledgement from it.
                However, there is the security issue that needs to be considered.
                Since, the overhearing case imply that it is not possible to have per-pair keying, thus, there MUST be a key that the overhearing node will be aware of.
                Hence, <xref target="I-D.ietf-6tisch-architecture">Minimal Security Framework for 6TiSCH</xref> specification should consider such scenario.
            </t>
        </list>
    </t>
 -->    
<!-- 
    <t>
        Req4.3: Optionally, to achieve further consistency the overheard transmission
        need be acknowledged by both parents, i.e., DP and AP. To do so, 
        MAC layer operation MUST be extended accordingly. 
    </t>    
[XV] This will require major changes in the MAC layer operation. I see it unfeasible
[GP] I agree it requires changes in the MAC. I updated the text to optionally. 
Let me know if "optionally sounds better", otherwise I may remove it completely, thus,
considering explicitly ACK from the Default Parent. (Modified, DONE)
</section>
 -->


<section title="Requirements Related to Packet Elimination">
    <t>
        By employing Packet Replication, the wireless network is expected to also perform Packet Elimination <!-- along a complex Track --> to restrict the number of the duplicated packets, i.e., the unnecessary traffic.
        As per the <xref target="I-D.ietf-6tisch-architecture">6TiSCH Architecture</xref>, 6TiSCH has no position about how the sequence numbers would be tagged in the packet.
        
    </t>


    <t>
        The requirement is:
    </t>    

    <t>
        <list style="hanging" hangIndent="6">
            <t hangText="Req4.1:">        
                To perform Packet Elimination the packet copies MUST contain a sequence number which allows identifying the copies.
                 
<!--                 However, it comes with Tagging Packets for Flow Identification.  -->
<!--                 More specifically, a wireless network expects that timeslots corresponding to copies of a same frame along a complex Track are correlated by configuration and, thus, does not need to process the sequence numbers. -->
                
                <!-- TODO: A sequence number in data packets allow to identify the duplicates. -->
                <!-- [RK]In Contiki we have added a field in the IPv6 Extension Heder called Hop-By-Hop Options containing the sequence number. -->
            </t>
        </list>
    </t>
</section>


</section>



<section title="Security Considerations">
   
        <t>
            TODO.
        </t>
    
</section>



<section title="IANA Considerations">
   
        <t>
            This document has no IANA considerations.
        </t>
    
</section>



  <?rfc compact="yes" ?>

<!-- <section title="Acknowledgements">
          <t>
              TODO: We are grateful to XXXX YYYYY and KKKK LLLL for their comments that 
              lead to many improvements to this document. 
          </t>
</section> -->





</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.8180"?>                         <!-- 6TiSCH: Minimal 6TiSCH Configuration -->
        <?rfc include="reference.RFC.6551"?>                        <!-- Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks -->
        <?rfc include='reference.I-D.ietf-6tisch-architecture'?>    <!-- 6TiSCH: 6TiSCH architecture -->
        <?rfc include='reference.RFC.8480'?>    <!-- 6TiSCH: 6top protocol -->
<!--        <?rfc include='reference.I-D.ietf-6tisch-minimal-security'?>     Minimal Security Framework for 6TiSCH -->
         <?rfc include='reference.I-D.ietf-roll-nsa-extension'?>        <!-- ROLL: DIO NSA Extension -->
        <?rfc include='reference.I-D.ietf-detnet-architecture'?>    <!-- 6TiSCH: 6TiSCH architecture -->
  </references>
  
  
  <references title="Other Informative References">
      <reference anchor="IEEE802154-2015">
        <front>
            <title>IEEE standard for Information Technology, "IEEE Std 
            802.15.4-2015 Standard for Low-Rate Wireless Personal Area 
            Networks (WPANs)", December 2015
            </title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date/>
        </front>
    </reference>
  </references>
  
 
</back> 
</rfc>
