<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
     docName="draft-ietf-detnet-data-plane-framework-06" number="8938"
     ipr="trust200902"
     submissionType="IETF"> submissionType="IETF" consensus="true" obsoletes=""
     updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
     version="3">

<!-- xml2rfc v2v3 conversion 2.46.0 -->

  <front>
    <title abbrev="DetNet Data Plane Framework">
    DetNet
 Deterministic Networking (DetNet) Data Plane Framework</title>

    <seriesInfo name="RFC" value="8938"/>
    <author role="editor" fullname="Bal&aacute;zs fullname="Balázs Varga" initials="B." surname="Varga">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>balazs.a.varga@ericsson.com</email>
      </address>
    </author>
    <author fullname="J&aacute;nos fullname="János Farkas" initials="J." surname="Farkas">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>janos.farkas@ericsson.com</email>
      </address>
    </author>
    <author fullname="Lou Berger" initials="L." surname="Berger">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
        <email>lberger@labn.net</email>
      </address>
    </author>
    <author fullname="Andrew G. Malis" initials="A.G." initials="A." surname="Malis">
      <organization>Malis Consulting</organization>
      <address>
        <email>agmalis@gmail.com</email>
      </address>
    </author>
    <author fullname="Stewart Bryant" initials="S." surname="Bryant">
      <organization>Futurewei Technologies</organization>
      <address>
        <email>stewart.bryant@gmail.com</email>
      </address>
    </author>

    <!--    <author fullname="Jouni Korhonen" initials="J." surname="Korhonen">
      //organization abbrev="Nordic">Nordic Semiconductor</organization
      <address>
        <email>jouni.nospam@gmail.com</email>
        <email>sb@stewartbryant.com</email>
      </address>
    </author> -->
    <date />
    <workgroup>DetNet</workgroup> month="November" year="2020"/>

    <abstract>
      <t>
        This document provides an overall framework for the DetNet Deterministic
        Networking (DetNet)
        data plane.  It covers concepts and considerations that
        are generally common to any Deterministic Networking DetNet data plane
        specification. It describes related controller plane Controller Plane
        considerations as well.
      </t>
    </abstract>
  </front>

<!--
***********************************************
IESG review comment resolutions in this version:

DONE
- Sabrina Tanamal, IANA, (03-12), OK
- Christer Holmberg, (03-15), Ready with Nits
- Yoshifumi Nishida, (04-07), Ready with Nits
- Murray Kucherawy (04-12), Editorial nits mostly
- Barry Leiba, (04-15), Editorial comments

To be discussed:
- Chris Lonvick, (03-13), Ready with Issues (Ready, as soon as
I-D.ietf-detnet-security is reviewed and becomes an RFC.)

***********************************************
-->
  <middle>
    <section title="Introduction" anchor="sec_intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        DetNet (Deterministic Networking) provides a capability the ability to carry
        specified unicast or multicast data flows for real-time applications
        with extremely low packet loss rates and assured maximum end-to-end
        delivery latency.  A description of the general background and concepts
        of DetNet can be found in <xref target="RFC8655"/>. target="RFC8655" format="default"/>.
      </t>
      <t>
        This document describes the concepts needed by any DetNet data plane
        specification (i.e., the DetNet-specific use of packet header fields)
        and provides considerations for any corresponding
        implementation.  It covers the building blocks that provide the DetNet
        service, the DetNet service sub-layer sub&nbhy;layer, and the DetNet forwarding
        sub-layer
        sub&nbhy;layer functions as described in the DetNet Architecture. architecture
        <xref target="RFC8655"/>.
      </t>
      <t>
        The DetNet Architecture architecture models the DetNet related DetNet-related data plane functions
        as being decomposed into two sub-layers: sub&nbhy;layers: a service sub-layer sub&nbhy;layer and a forwarding
        sub-layer.
        sub&nbhy;layer.  The service sub-layer sub&nbhy;layer is used to provide DetNet service
        protection and reordering. The forwarding sub-layer sub&nbhy;layer leverages Traffic
        Engineering traffic
        engineering mechanisms and provides congestion protection (low loss,
        assured latency, and limited out-of-order delivery).  A particular
        forwarding sub-layer sub&nbhy;layer may have capabilities that are not available on
        other forwarding-sub layers. forwarding sub&nbhy;layers. DetNet makes use of the existing
        forwarding sub-layers sub&nbhy;layers with their respective capabilities and does not
        require 1:1 equivalence between different forwarding sub-layer sub&nbhy;layer
        capabilities.
      </t>
      <t>
        As part of the service sub-layer sub&nbhy;layer functions, this document describes
        typical DetNet node data plane operation. It describes the functionality
        and operation of the Packet Replication Function (PRF), the Packet
        Elimination Function (PEF), and the Packet Ordering Function (POF) functions within the service
        sub-layer.
        sub&nbhy;layer. Furthermore, it describes the forwarding sub-layer. sub&nbhy;layer.
      </t>
      <t>
        As defined in <xref target="RFC8655"/>, target="RFC8655" format="default"/>,
        DetNet flows may be carried over network technologies that can provide
        the DetNet required
        service characteristics. characteristics required by DetNet.  For example, DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive Network Time-Sensitive
  Networking (TSN) sub-networks <xref
                target="IEEE802.1TSNTG"/> sub-networks. target="IEEE802.1TSNTG"
  format="default"/>. However, IEEE 802.1 TSN support is not required in
  DetNet. TSN frame preemption is an example of a forwarding layer capability
  that is typically not replicated in other forwarding technologies. Most of DetNet
  DetNet's benefits can be gained by running over a data link data-link layer that has
  not been specifically enhanced to support all TSN capabilities capabilities, but for such
  networks and traffic
        mixes mixes, delay and jitter performance may vary due to the
  forwarding
        sub-layer sub&nbhy;layer's intrinsic properties.
      </t>
      <t>
        Different application flows, such as Ethernet or IP, can be mapped
        on top of DetNet.  DetNet can optionally reuse header information
        provided by, or shared with, applications. An example of shared header
        fields can be found in <xref target="I-D.ietf-detnet-ip"/>. target="RFC8939" format="default"/>.
      </t>
      <t>
        This document also covers
        basic concepts related to the controller plane Controller Plane and Operations,
        Administration, and Maintenance (OAM).
        Data plane OAM specifics are out of scope for this document.
      </t>
    </section>
    <section title="Terminology">
      <section title="Terms numbered="true" toc="default">
      <name>Terminology</name>
      <section numbered="true" toc="default">
        <name>Terms Used in This Document"> Document</name>
        <t>
          This document uses the terminology established in the DetNet
          architecture <xref target="RFC8655"/>, target="RFC8655" format="default"/>, and
          it is assumed that the reader is assumed to be familiar with that document
          and its terminology.
        </t>
      </section>
      <?rfc subcompact="yes" ?>
      <section title="Abbreviations"> numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>
          The following abbreviations are used in this document:
          <list style="hanging" hangIndent="14">
            <t hangText="BGP">Border
        </t>
        <dl newline="false" indent="12">
          <dt>BGP</dt>
          <dd>Border Gateway Protocol.</t>
            <t hangText="d-CW">DetNet Protocol</dd>
          <dt>CoS</dt>
          <dd>Class of Service</dd>
          <dt>d-CW</dt>
          <dd>DetNet Control Word.</t>
            <t hangText="DetNet">Deterministic Networking.</t>
            <t hangText="DN">DetNet.</t>
            <t hangText="GMPLS">Generalized Word</dd>
          <dt>DetNet</dt>
          <dd>Deterministic Networking</dd>
          <dt>DN</dt>
          <dd>DetNet</dd>
          <dt>GMPLS</dt>
          <dd>Generalized Multiprotocol Label Switching.</t>
            <t hangText="GRE">Generic Switching</dd>
          <dt>GRE</dt>
          <dd>Generic Routing Encapsulation.</t>
            <t hangText="IPSec">IP Security.</t>
            <t hangText="L2">Layer 2.</t>
            <t hangText="LSP">Label Encapsulation</dd>
          <dt>IPsec</dt>
          <dd>IP Security</dd>
          <dt>L2</dt>
          <dd>Layer 2</dd>
          <dt>LSP</dt>
          <dd>Label Switched Path.</t>
            <t hangText="MPLS">Multiprotocol Path</dd>
          <dt>MPLS</dt>
          <dd>Multiprotocol Label Switching.</t>
            <t hangText="OAM">Operations, Switching</dd>
          <dt>OAM</dt>
          <dd>Operations, Administration, and Maintenance.</t>
            <t hangText="PCEP">Path Maintenance</dd>
          <dt>PCEP</dt>
          <dd>Path Computation Element Communication Protocol.</t>
            <t hangText="PEF">Packet Protocol</dd>
          <dt>PEF</dt>
          <dd>Packet Elimination Function.</t>
            <t hangText="PRF">Packet Replication Function.</t>
            <t hangText="PREOF">Packet Function</dd>
          <dt>POF</dt>
          <dd>Packet Ordering Function</dd>
          <dt>PREOF</dt>
          <dd>Packet Replication, Elimination Elimination, and Ordering Functions.</t>
            <t hangText="POF">Packet Ordering Function.</t>
            <t hangText="PSN">Packet Functions</dd>
          <dt>PRF</dt>
          <dd>Packet Replication Function</dd>
          <dt>PSN</dt>
          <dd>Packet Switched Network.</t>
            <t hangText="QoS">Quality of Service.</t>
            <t hangText="S-Label">DetNet Network</dd>
          <dt>QoS</dt>
          <dd>Quality of Service</dd>
          <dt>S-Label</dt>
          <dd>DetNet "service" label.</t>
            <t hangText="TDM">Time-Division Multiplexing.</t>
            <t hangText="TSN">Time-Sensitive Network.</t>
            <t hangText="YANG">Yet label</dd>
          <dt>TDM</dt>
          <dd>Time-Division Multiplexing</dd>
          <dt>TSN</dt>
          <dd>Time-Sensitive Networking</dd>
          <dt>YANG</dt>
          <dd>Yet Another Next Generation.</t>
          </list>
        </t> Generation</dd>
        </dl>
      </section>
    </section>  <!-- end of terminology -->
<?rfc subcompact="no" ?>
<section title="DetNet anchor="sec_dt_dp" numbered="true" toc="default">
      <name>Overview of the DetNet Data Plane Overview" anchor="sec_dt_dp"> Plane</name>
      <t>
        This document describes how application flows, or app-flows, App-flows <xref
        target="RFC8655"/>, are
        carried over DetNet networks. The DetNet Architecture architecture <xref
                target="RFC8655"/> target="RFC8655" format="default"/> models the DetNet-related
                data plane functions as decomposed into two sub-layers: sub&nbhy;layers: a service
        sub-layer
        sub&nbhy;layer and a forwarding sub-layer. sub&nbhy;layer.
      </t>
      <t>
        <xref target="ProtStack1"/>, target="ProtStack1" format="default"/>, reproduced from <xref target="RFC8655"/>, target="RFC8655" format="default"/>,
                shows a logical DetNet service with the two sub-layers. sub&nbhy;layers.

      </t>
      <figure align="center" anchor="ProtStack1"
        title="DetNet data plane protocol stack"> anchor="ProtStack1">
        <name>DetNet Data Plane Protocol Stack</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   |  packets going  |        ^  packets coming   ^
   v down the stack  v        |   up the stack    |
+-----------------------+   +-----------------------+
|        Source         |   |      Destination      |
+-----------------------+   +-----------------------+
|   Service sub-layer:  |   |   Service sub-layer:  |
|   Packet sequencing   |   | Duplicate elimination |
|    Flow replication   |   |      Flow merging     |
|    Packet encoding    |   |    Packet decoding    |
+-----------------------+   +-----------------------+
| Forwarding sub-layer: |   | Forwarding sub-layer: |
|  Resource allocation  |   |  Resource allocation  |
|    Explicit routes    |   |    Explicit routes    |
+-----------------------+   +-----------------------+
|     Lower layers      |   |     Lower layers      |
+-----------------------+   +-----------------------+
            v                           ^
             \_________________________/
        ]]></artwork>
             \_________________________/]]></artwork>
      </figure>
      <t>
         The DetNet forwarding sub-layer sub&nbhy;layer may be directly provided by the DetNet
         service sub-layer, sub&nbhy;layer -- for example example, by IP tunnels or MPLS.
         Alternatively, an overlay approach
         may be used in which the packet is natively carried between key nodes
         within the DetNet network (say (say, between PREOF nodes) nodes), and a sub-layer sub&nbhy;layer is
         used to provide the information needed to reach the next hop in the
         overlay.
      </t>
      <t>
         The forwarding sub-layer sub&nbhy;layer provides the QoS related QoS-related functions needed by
         the DetNet flow. It may do this directly through the use of queuing
         techniques and traffic engineering methods, or it may do this through
         the assistance of its underlying connectivity. For example example, it may call
         upon Ethernet TSN capabilities defined in IEEE 802.1 TSN <xref
                 target="IEEE802.1TSNTG"/>. target="IEEE802.1TSNTG" format="default"/>.  The forwarding sub-layer sub&nbhy;layer uses
         buffer resources for packet queuing, as well as reservation and
         allocation of bandwidth capacity resources.
      </t>
      <t>
         The service sub-layer sub&nbhy;layer provides additional support beyond the
         connectivity function of the forwarding sub-layer. sub&nbhy;layer. See
         <xref
         target="PREOF"/> as an example for Packet Replication, Elimination,
		 and Ordering functions. target="PREOF" format="default"/> regarding PREOF.  The ordering function (POF) POF uses sequence numbers
         added to packets packets, enabling a range of packet order protection from
         simple ordering and dropping out-of-order packets to more complex
         reordering of a fixed number of out-of-order, minimally delayed
         packets.  Reordering requires buffer resources and has an impact on the
         delay and jitter of packets in the DetNet flow.
      </t>
      <t>
         The method of instantiating each of the layers is specific to the
         particular DetNet data plane method, and more than one approach may
         be applicable to a given network type.
      </t>
      <section title="Data anchor="sec_dp_char" numbered="true" toc="default">
        <name>Data Plane Characteristics" anchor="sec_dp_char"> Characteristics</name>
        <t>
        There are
        The data plane has two major characteristics to the data plane: characteristics: the technology and
        the encapsulation, as discussed below.
        </t>
        <section title="Data anchor="sec_dp_tech" numbered="true" toc="default">
          <name>Data Plane Technology" anchor="sec_dp_tech"> Technology</name>
          <t>
         The DetNet data plane is provided by the DetNet service and forwarding
                 sub layers.         sub&nbhy;layers.
         The DetNet service sub-layer sub&nbhy;layer
         generally provides its functions for the DetNet application flows by using or applying
         existing standardized headers and/or encapsulations.  The Detnet DetNet
         forwarding sub-layer sub&nbhy;layer may provide capabilities leveraging that same
         header or encapsulation technology (e.g., DN IP or DN MPLS) MPLS), or it
         may be achieved by via other technologies technologies, as shown in <xref
                 target="dn_svc_encaps"/>.
         target="dn_svc_encaps" format="default"/> below.
         DetNet is currently defined for operation over packet-switched (IP)
          networks or label-switched (MPLS) networks.
          </t>
        </section>
        <section title="Encapsulation" anchor="sec_dp_encap"> anchor="sec_dp_encap" numbered="true" toc="default">
          <name>Encapsulation</name>
          <t>
          DetNet encodes specific flow attributes
          (flow identity and sequence number) in packets.
          For example, in DetNet IP,
          zero encapsulation is used used, and no sequence number
          is available, and available; in DetNet MPLS, DetNet-specific information may be added
          explicitly to the packets in the form of S-label an S-Label and a d-CW
          <xref target="I-D.ietf-detnet-mpls"/> . target="DetNet-MPLS" format="default"/>.
          </t>
          <t>
                 The encapsulation of a DetNet flow allows it to be sent over a
                 data plane technology other than its native type.
                 DetNet uses header information to perform traffic classification,
                 i.e., identify DetNet flows, and provide DetNet service and
                 forwarding functions. As mentioned above, DetNet may add headers,
                 as is the case for DN MPLS, or may use headers that are already
                 present, as is the case in for DN IP.
           <xref target="dn_svc_encaps"/> target="dn_svc_encaps" format="default"/> illustrates some relationships
           between the components.
          </t>
          <figure anchor="dn_svc_encaps" align="center"
        title="DetNet anchor="dn_svc_encaps">
            <name>DetNet Service Examples"> Examples</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                          +-----+
                          | TSN |
     +-------+          +-+-----+-+
     | DN IP |          | DN MPLS |
  +--+--+----+----+   +-+---+-----+-+
  | TSN | DN MPLS |   | TSN | DN IP |
  +-----+---------+   +-----+-------+

    ]]></artwork>   +-----+-------+]]></artwork>
          </figure>
          <t>
           The use of encapsulation is also required if additional information
           (metadata) is needed by the DetNet data plane and there is either (1)&nbsp;there is
           no ability to include it in the client data packet, packet or the (2)&nbsp;the
           specification of the client data plane does not permit the
           modification of the packet to include additional data. An example of
           such metadata is the inclusion of a sequence number required by the
           PREOF function.
           PREOF.
          </t>
          <t>
           Encapsulation may also be used to carry or aggregate flows for equipment with limited
           DetNet capability.
          </t>
        </section>
      </section>
      <section title="DetNet-specific Metadata" anchor="sec_dp_metadata"> anchor="sec_dp_metadata" numbered="true" toc="default">
        <name>DetNet-Specific Metadata</name>
        <t>
          The DetNet data plane can provide or carry the following metadata:
          <list style="numbers">
          <t>
            Flow-ID
        </t>
          <t>
        <ol spacing="normal" type="1">
          <li>
            Flow-ID
          </li>
          <li>
            Sequence Number
          </t>
          </list>
          </t> number
          </li>
        </ol>
        <t>
          The DetNet data plane framework supports a Flow-ID (for identification of the
          flow or aggregate flow) and/or a Sequence Number sequence number (for PREOF) for each
          DetNet flow. The Flow-ID is used by both the service and forwarding sub-layers, sub&nbhy;layers,
          but the sequence number is only used by the service layer. Metadata can also be
          used for OAM indications and instrumentation of DetNet data plane
          operation.
        </t>
        <t>
          Metadata inclusion can be implicit or explicit.  Explicit inclusions
          involve a dedicated header field that is used to include metadata
          in a DetNet packet.  In the implicit method, part of an already existing already-existing
          header field is used to encode the metadata.
        </t>
        <t>
          Explicit inclusion of metadata is possible through the use of
          IP options or IP extension headers. New IP options are almost impossible
          to get standardized or to deploy in an operational network and will
          not be discussed further in this text. IPv6 extensions extension headers are
          finding popularity in current IPv6 development work, particularly
          in connection with Segment Routing of IPv6 (SRv6) and IP OAM. The design
          of a new IPv6 extension header or the modification of an existing one is
          a technique available in the tool box toolbox of the DetNet IP data plane designer.
        </t>
        <t>
          Explicit inclusion of metadata in an IP packet is also possible
          through the inclusion of an MPLS label stack and the MPLS DetNet
          Control Word d-CW,
          using one of the methods for carrying MPLS over IP <xref
                  target="I-D.ietf-detnet-mpls-over-udp-ip"/>. target="DetNet-MPLS-over-UDP-IP" format="default"/>. This is described in more
          detail in <xref target="subnet_considerations"/>. target="subnet_considerations" format="default"/>.
        </t>
        <t>
          Implicit metadata in IP can be included through the use of the network
          programming paradigm <xref
                  target="I-D.ietf-spring-srv6-network-programming"/> target="SRv6-Network-Prog" format="default"/>, in which the
          suffix of an IPv6 address is used to encode additional information
          for use by the network of the receiving host.
        </t>
        <t>
          An MPLS example of explicit metadata is the sequence number
          used by the PREOF function, PREOF, or even the case where all the
          essential information being is included into in the DetNet over MPLS DetNet-over-MPLS
          label stack (the DetNet Control Word d-CW and the DetNet Service label). S-Label).
        </t>
      </section>
      <section title="DetNet anchor="sec_dt_ip_dp" numbered="true" toc="default">
        <name>DetNet IP Data Plane" anchor="sec_dt_ip_dp"> Plane</name>
        <t>
          An IP data plane may operate natively or through the use of an
          encapsulation.
          Many types of IP encapsulation can satisfy DetNet requirements requirements,
          and it is anticipated that more than one encapsulation
          may be deployed, deployed -- for example example, GRE, IPSec. IPsec.
        </t>
        <t>
          One method of operating an IP DetNet data plane without encapsulation
          is to use "6-tuple" based 6-tuple-based flow identification, where "6-tuple" refers
          to information carried in IP IP-layer and higher layer higher-layer protocol headers.
          General background on the use of IP headers, headers and "6-tuples", 6-tuples to
          identify flows and support Quality of Service (QoS) QoS can be found in
          <xref target="RFC3670"/>. target="RFC3670" format="default"/>. The extra field in the
	  6-tuple is the DSCP field in the packet. <xref target="RFC7657"/> target="RFC7657" format="default"/> provides
          useful background on differentiated services (DiffServ) (Diffserv)
          and "tuple" based tuple-based flow identification.  DetNet flow aggregation may
          be enabled via the use of wildcards, masks, prefixes prefixes, and ranges.  The
          operation of this method is described in detail in <xref
                  target="I-D.ietf-detnet-ip"/>. target="RFC8939" format="default"/>.
        </t>
        <t>
          The DetNet forwarding plane may use explicit route capabilities and
          traffic engineering capabilities to provide a forwarding sub-layer sub&nbhy;layer
          that is responsible for providing resource allocation and explicit
          routes.  It is possible to include such information in a native IP
          packet
          explicitly, either explicitly or implicitly.
        </t>
      </section>
      <section title="DetNet anchor="sec_dt_mpls_dp" numbered="true" toc="default">
        <name>DetNet MPLS Data Plane" anchor="sec_dt_mpls_dp"> Plane</name>
        <t>
          MPLS provides a forwarding sub-layer sub&nbhy;layer for traffic over implicit
          and explicit paths to the point in the network where the next
          DetNet service sub-layer sub&nbhy;layer action needs to take place. It does this
          through the use of a stack of one or more labels with various
          forwarding semantics.
        </t>
        <t>
          MPLS also provides the ability to identify a service instance
          that is used to process the packet through the use of a label that
          maps the packet to a service instance.
        </t>
        <t>
          In cases where metadata is needed to process an MPLS encapsulated MPLS-encapsulated
          packet at the service sub-layer, sub&nbhy;layer, the d-CW <xref target="I-D.ietf-detnet-mpls"/>,
          <xref target="RFC4385"/>
          target="DetNet-MPLS" format="default"/> can be used.  Although such d-CWs
          are frequently 32 bits long, there is no architectural constraint on
          the size of this structure, structure -- only the requirement that it is be fully
          understood by all parties operating on it in the DetNet service
          sub-layer.
          sub&nbhy;layer.  The operation of this method is described in detail in
          <xref target="I-D.ietf-detnet-mpls"/>. target="DetNet-MPLS" format="default"/>.
        </t>
      </section>
      <section title="Further anchor="further_dn_dp_consid" numbered="true" toc="default">
        <name>Further DetNet Data Plane Considerations" anchor="further_dn_dp_consid"> Considerations</name>
        <t>
    This section provides informative considerations related to
    providing DetNet service to flows which that are identified
    based on their header information.
        </t>
        <section title="Per Flow Related Functions" anchor="further_dn_dp_pf"> anchor="further_dn_dp_pf" numbered="true" toc="default">
          <name>Functions Provided on a Per-Flow Basis</name>
          <t>
        At a high level, the following functions are provided on a per flow per-flow basis.
          </t>
          <section title="Reservation numbered="true" toc="default">
            <name>Reservation and Allocation of resources"> Resources</name>
            <t>
        Resources might be reserved in order to make them available for allocation to specific DetNet
        flows. This can eliminate packet contention and packet loss for DetNet
        traffic. This also can reduce jitter for DetNet traffic.  Resources
        allocated to a DetNet flow protect it from other traffic flows. On the
        other hand, it is assumed that DetNet flows are assumed to behave in accordance with respect to the
        reserved traffic profile. It must be possible to detect misbehaving DetNet flows
                and to ensure that they do not compromise QoS of other flows.
        Queuing, policing, and shaping policies can be used to ensure
        that the allocation of resources reserved for DetNet is met.
            </t>
          </section>
          <section title="Explicit routes"> numbered="true" toc="default">
            <name>Explicit Routes</name>
            <t>
        A flow can be routed over a specific, pre-computed precomputed path. This allows control of the network
        delay by steering the packet with the ability to influence the physical
        path. Explicit routes complement reservation by ensuring that a
        consistent path can be associated with its resources for the duration
        of that path.  Coupled with the traffic mechanism, this limits
        misordering and bounds latency. Explicit route computation can
        encompass a wide set of constraints and can optimize the path for a certain
        characteristic, e.g., highest bandwidth or lowest jitter.  In these cases cases,
        the "best" path for any set of characteristics may not be a shortest
        path.  The selection of the path can take into account multiple network
        metrics. Some of these metrics are measured and distributed by the
        routing system as traffic engineering metrics.
            </t>
          </section>
          <section title="Service protection"> numbered="true" toc="default">
            <name>Service Protection</name>
            <t>
        Service protection involves the use of multiple packet streams using
        multiple paths, paths -- for example example, 1+1 or
        1:1 linear protection.  For DetNet, this primarily relates to packet
        replication and elimination capabilities.
        MPLS offers a number of protection schemes.
        MPLS hitless protection can be used to switch traffic to an already established already-established path
        in order to restore delivery rapidly after a failure.
        Path changes, even in the case of failure recovery, can lead to the out of
        order out-of-order delivery of data requiring packet ordering functions POFs either
        within the DetNet service or at a high layer in the application
        traffic.  Establishment of new paths after a failure is out of scope
        for DetNet services.
            </t>
          </section>
          <section title="Network Coding"> numbered="true" toc="default">
            <name>Network Coding</name>
            <t>
        Network Coding <xref target="nwcrg"/>, target="nwcrg" format="default"/>,
              not to be confused with network programming,
        comprises
        several techniques where multiple data flows are encoded. These
        resulting flows can then be sent on different paths. The encoding
        operation can combine flows and error recovery information.  When the
        encoded flows are decoded and recombined recombined, the original flows can be
        recovered.  Note that Network coding Coding uses an alternative to packet by
        packet
        packet-by-packet PREOF. Therefore, for certain network topologies and traffic
        loads, Network Coding can be used to improve a network's throughput,
        efficiency, latency, and scalability, as well as resilience to
        partition, attacks, and eavesdropping, as compared to traditional
        methods. DetNet could use Network coding Coding as an alternative to
        other protection means. means of protection.  Network coding Coding is often applied in wireless
        networks and is being explored for other network types.
            </t>
          </section>
          <section title="Load sharing"> numbered="true" toc="default">
            <name>Load-Sharing</name>
            <t>
        Use
        The use of packet-by-packet load sharing load-sharing of the same DetNet flow over
        multiple paths is not recommended recommended, except for the cases listed above
        where PREOF is are utilized to improve protection of traffic and maintain order.
        Packet-by-packet load sharing, load-sharing, e.g., via ECMP or UCMP, Equal-Cost Multipath (ECMP)
        or Unequal-Cost Multipath (UCMP), impacts ordering and
        possibly and,
        possibly, jitter.
            </t>
      <!-- I think this section below should refer to OAM for the various underlying
           technology the one area that may be for consideration is how detnet can identify
           specific tunneled traffic. Of course that allows for security vulnerabilities -->
  </section>
          <section title="Troubleshooting"> numbered="true" toc="default">
            <name>Troubleshooting</name>
            <t>
      Detnet
      DetNet leverages many different forwarding sub-layers, sub&nbhy;layers, each of which
          supports various tools to troubleshoot connectivity, connectivity -- for example example,
          identification of misbehaving flows. The DetNet Service service layer can
          leverage existing mechanisms to troubleshoot or monitor flows, such as
          those in use by IP and MPLS networks.  At the Application layer layer, a client
          of a DetNet service can use existing techniques to detect and monitor
          delay and loss.
            </t>
          </section>
          <section title="Flow recognition numbered="true" toc="default">
            <name>Flow Recognition for analytics"> Analytics</name>
            <t>
       Network analytics can be inherited from the technologies of the Service service
          and Forwarding sub-layers. forwarding sub&nbhy;layers.  At the DetNet service edge, packet and bit
          counters (e.g. (e.g., sent, received, dropped, and out-of-sequence) out of sequence) can be
          maintained.
            </t>
          </section>
          <section title="Correlation numbered="true" toc="default">
            <name>Correlation of events Events with flows"> Flows</name>
            <t>
      The provider of a DetNet service may provide other capabilities to
          monitor flows, such as more detailed loss statistics and time stamping timestamping
          of events.  The details of  Details regarding these capabilities are out of scope
          for this document.
            </t>
          </section>
        </section> <!-- End of Per Flow Related Functions -->
  <section title="Service Protection"> numbered="true" toc="default">
          <name>Service Protection</name>
          <t>
      Service protection allows DetNet services to increase reliability and
      maintain a DetNet Service Assurance desired level of service assurance in the case of network
      congestion or network failure.  Detnet  DetNet relies on the underlying technology capabilities
      for various protection schemes.  Protection schemes enable partial or
      complete coverage of the network paths and active protection with
      combinations of the PRF, PEF, and POF.
          </t>
          <section title="Linear numbered="true" toc="default">
            <name>Linear Service Protection"> Protection</name>
            <t>
        An example DetNet MPLS network fragment and its packet flow is are illustrated in
        <xref target="dn_protection_flow"/>. target="dn_protection_flow" format="default"/>.
            </t>
            <figure anchor="dn_protection_flow" align="center"
       title="Example anchor="dn_protection_flow">
              <name>Example of Packet Flow in DetNet Protected Network"> by DetNet</name>
              <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   1      1.1       1.1      1.2.1    1.2.1      1.2.2
CE1----EN1--------R1-------R2-------R3--------EN2-----CE2
         \           1.2.1 /                  /
          \1.2     /-----+     /------+                  /
           +------R4------------------------+
                     1.2.2
     ]]></artwork>
                     1.2.2]]></artwork>
            </figure>

            <t>
     In <xref target="dn_protection_flow"/> target="dn_protection_flow" format="default"/>, the numbers are used to identify the
     instance of a packet.  Packet 1 is the original packet, and packets 1.1, packet. Packets 1.1 and
     1.2 are two first generation first-generation copies of packet 1.  Packet 1, packet 1.2.1 is a second
     generation
     second-generation copy of packet 1.2, etc. and so on.  Note that these numbers never appear in
     the packet, packet and are not to be confused with sequence numbers, labels labels, or any
     other identifier identifiers that appears appear in the packet.  They simply indicate the
     generation number of the original packet so that its passage through the
     network fragment can be identified to for the reader.
            </t>
            <t>
     Customer Equipment device CE1 sends a packet into the DetNet enabled DetNet-enabled network.  This
     is packet (1). 1.  Edge Node EN1 encapsulates the packet as a DetNet packet and
     sends it to Relay node Node R1 (packet 1.1).  EN1 makes a copy of the packet
     (1.2), encapsulates it it, and sends this copy to Relay node Node R4.
            </t>
            <t>
Note that along the path from EN1 to R1 may be directly attached to EN1, or there may be zero one or more
nodes
     which, on the path that, for clarity, are not shown. shown in <xref
target="dn_protection_flow" format="default"/>.  The same is
holds true for any other path between two DetNet entities as shown in <xref target="dn_protection_flow"/>.
the figure.
            </t>
            <t>
     Relay node Node R4 has been configured to send one copy of the packet to Relay
     Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 1.2.2).
            </t>
            <t>
     R2 receives packet copy 1.2.1 before packet copy 1.1 arrives, arrives and, having
     been configured to perform packet elimination on this DetNet flow, forwards
     packet 1.2.1 to Relay Node R3.  Packet copy 1.1 is of no further use and so
     is discarded by R2.
            </t>
            <t>
     Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives packet
     copy 1.2.1 from R2 via relay Relay Node R3.  EN2 therefore strips any DetNet
     encapsulation from packet copy 1.2.2 and forwards the packet to CE2.  When
     EN2 receives the later packet copy 1.2.1 this later on, the copy is discarded.
            </t>
            <t>
     The above is of course illustrative of many network scenarios that can be
     configured.
            </t>
            <t>
     This example also illustrates a 1:1 protection scheme scheme, meaning there is
     traffic over each segment of the end-to-end path. Local DetNet
     relay nodes determine which packets are eliminated and which packets are
     forwarded.  A 1+1 scheme where only one path is used for traffic at a
     time could use the same topology. In this case case, there is no PRF function
<!--  we have a comment that PRF function is redundant, a F alreaady means function --> PRF,
     and traffic is switched upon detection of failure.  An OAM scheme that
     monitors the paths to detect the loss of a path or traffic is required to
     initiate the switch.  A POF may still be used in this case to
     prevent misordering of packets. In both cases cases, the protection paths are
     established and maintained for the duration of the DetNet service.
            </t>
          </section>
          <section title="Path numbered="true" toc="default">
            <name>Path Differential Delay"> Delay</name>
            <t>
     In the preceding example, proper working operation of duplicate
     elimination and the reordering of packets are dependent
     on the number of out-of-order packets that can be
     buffered and the delay difference in delay of the arriving packets.
     DetNet uses flow-specific requirements (e.g., maximum
     number of out-of-order packets, maximum latency
     of the flow) for configuration of POF-related buffers.
     If the differential delay between paths is excessively large
     or there is excessive mis-ordering misordering of the packets, then packets may
     be dropped instead of being reordered.
     Likewise, the PEF
     uses the sequence number to identify duplicate packets, and large
     differential delays combined with high numbers of packets may exceed
     the PEF's ability of the PEF to work properly.
            </t>
          </section>
          <section title="Ring numbered="true" toc="default">
            <name>Ring Service Protection"> Protection</name>
            <t>
     Ring protection may also be supported if the underlying technology
     supports it. Many of the same concepts apply, however apply; however, rings are normally
     1+1 protection for data efficiency reasons. <xref target="RFC8227"/> is target="RFC8227" format="default"/> provides an example of MPLS-TP an MPLS Transport Profile (MPLS-TP) data plane that supports Ring ring protection.
            </t>
          </section>
        </section>
        <section title="Aggregation Considerations" anchor = "aggregation"> anchor="aggregation" numbered="true" toc="default">
          <name>Aggregation Considerations</name>
          <t>
  The DetNet data plane also allows for the aggregation of DetNet flows, which
  can improve scalability by reducing the per-hop state.  How this is accomplished is data
  plane or control plane dependent.  When DetNet flows are aggregated, transit
  nodes provide service to the aggregate and not on a per-DetNet flow per-DetNet-flow basis.
  When aggregating DetNet flows, the flows should be compatible, i.e., the same or
  very similar QoS and CoS characteristics.  In this case, nodes performing
  aggregation will ensure that per-flow service requirements are achieved.
          </t>
          <t>
  If bandwidth reservations are used, the reservation should be the
  sum of all the individual reservations; in other words, the reservations
  should not add up to an over-subscription oversubscription of bandwidth reservation. If
  maximum delay bounds are used, the system should ensure that the aggregate
  does not exceed the delay bounds of the individual flows.
          </t>
          <t>
  <!-- DetNet encapsulation is a data plane mechanism that can be used to aggregate
  traffic.  Encapsulation can either be in the same service type or in a
  different service type see <xref target="dn_svc_encaps"/> for example.-->
 When
  an encapsulation is used, the choice of reserving a maximum resource level and
  then tracking the services in the aggregated service or adjusting the
  aggregated resources as the services are added is implementation and
  technology specific.
          </t>
          <t>
  DetNet flows at edges must be able to handle rejection to an aggregation
  group due to lack of resources as well as conditions where
  requirements are not satisfied.
          </t>
          <section title="IP Aggregation" anchor = "ip-agg"> anchor="ip-agg" numbered="true" toc="default">
            <name>IP Aggregation</name>
            <t>
   IP aggregation has both data plane and controller plane Controller Plane aspects. For the
   data plane, flows may be aggregated for treatment based on shared
   characteristics such as 6-tuple <xref target="I-D.ietf-detnet-ip"/>. target="RFC8939" format="default"/>.
   Alternatively, an IP encapsulation may be
   used to tunnel an aggregate number of DetNet Flows flows between relay nodes.
            </t>
          </section>
          <section title="MPLS Aggregation" anchor = "mpls-agg"> anchor="mpls-agg" numbered="true" toc="default">
            <name>MPLS Aggregation</name>
            <t>
   MPLS aggregation also has data plane and controller plane Controller Plane aspects.  MPLS
   flows are often tunneled in a forwarding sub-layer, sub&nbhy;layer, under the reservation
   associated with that MPLS tunnel.
            </t>
          </section>
        </section>
        <section title="End-System-Specific Considerations"> numbered="true" toc="default">
          <name>End-System-Specific Considerations</name>
          <t>
   Data-flows
   Data flows requiring DetNet service are generated and terminated on
   end-systems.
   end systems. Encapsulation depends on the application and its
   preferences. For example, in a DetNet MPLS domain domain, the sub-layer sub&nbhy;layer functions use the d-CWs,
   S-Labels
   S-Labels, and F-Labels <xref target="DetNet-MPLS"/> to provide DetNet services. However, an
   application may exchange further flow related flow-related parameters (e.g.,
   time-stamp), which
   timestamps) that are not provided by DetNet functions.
          </t>

          <t>
   As a general rule, DetNet domains are capable of forwarding any
   DetNet flows flows, and the DetNet domain does not mandate the
   end-system
   encapsulation format for end systems or edge node encapsulation format. nodes. Unless there is a
   proxy of
   some form of proxy is present, end-systems end systems peer with similar end-systems end systems
   using the same application encapsulation format.  For example, as
   shown in <xref target="fig_es_connect"/>, target="fig_es_connect" format="default"/>, IP applications peer with
   IP applications applications, and Ethernet applications peer with Ethernet
   applications.
          </t>
          <figure title="End-Systems anchor="fig_es_connect">
            <name>End Systems and The the DetNet MPLS Domain" anchor="fig_es_connect"> Domain</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+-----+
|  X  |                               +-----+
+-----+                               |  X  |
| Eth |               ________        +-----+
+-----+     _____    /        \       | Eth |
       \   /     \__/          \___   +-----+
        \ /                        \ /
         0======== tunnel-1 ========0_
         |                             \
          \                             |
          0========= tunnel-2 =========0
         / \                        __/ \
  +-----+   \__ DetNet MPLS domain /     \
  |  X  |      \         __       /       +-----+
  +-----+       \_______/  \_____/        |  X  |
  |  IP |                                 +-----+
  +-----+                                 |  IP |
                                          +-----+
  ]]>
    </artwork></figure>
                                          +-----+]]></artwork>
          </figure>
        </section>
        <section title="Sub-Network Considerations" anchor="subnet_considerations"> anchor="subnet_considerations" numbered="true" toc="default">
          <name>Sub-network Considerations</name>
          <t>
     Any of the DetNet service types may be transported by another
     DetNet service. MPLS nodes may be interconnected by different sub-network
     technologies, which may include point-to-point links. Each of these
     sub-network technologies needs to provide appropriate service to DetNet
     flows.  In some cases, e.g., on dedicated point-to-point links or TDM
     technologies, all that is required is for a DetNet node to appropriately
     queue its output traffic.  In other cases, DetNet nodes will need to map
     DetNet flows to the flow semantics (i.e., identifiers) and mechanisms used
     by an underlying sub-network technology.  <xref
             target="fig_dn_mpls_sn_ex"/>
     target="fig_dn_mpls_sn_ex" format="default"/> shows several examples of header
     formats
     sub-network encapsulations that can be used to carry DetNet MPLS flows over different
     sub-network technologies.  L2 represents a generic layer-2 Layer 2 encapsulation
     that might be used on a point-to-point link.  TSN represents the
     encapsulation used on an IEEE 802.1 TSN network, as described in <xref
             target="I-D.ietf-detnet-mpls-over-tsn"/>. target="DetNet-MPLS-over-TSN" format="default"/>.  UDP/IP represents the encapsulation
     used on a DetNet IP PSN, as described in <xref
             target="I-D.ietf-detnet-mpls-over-udp-ip"/>. target="DetNet-MPLS-over-UDP-IP" format="default"/>.
          </t>
          <figure title="Example anchor="fig_dn_mpls_sn_ex">
            <name>Example DetNet MPLS Sub-Network Formats" anchor="fig_dn_mpls_sn_ex"> Encapsulations in Sub-networks</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                   +------+  +------+  +------+
App-Flow
App-flow           |  X   |  |  X   |  |  X   |
             +-----+======+--+======+--+======+-----+
DetNet-MPLS        | d-CW |  | d-CW |  | d-CW |
                   +------+  +------+  +------+
                   |Labels|  |Labels|  |Labels|
             +-----+======+--+======+--+======+-----+
Sub-Network
Sub-network        |  L2  |  | TSN  |  | UDP  |
                   +------+  +------+  +------+
                                       |  IP  |
                                       +------+
                                       |  L2  |
                                       +------+
    ]]>
  </artwork></figure>
                                       +------+]]></artwork>
          </figure>
        </section>
      </section>
    </section>
<!-- ================================================================= -->
<section title="Controller anchor="cp_considerations" numbered="true" toc="default">
      <name>Controller Plane (Management and Control)
                Considerations" anchor="cp_considerations"> Considerations</name>
      <section title="DetNet anchor="control-management-requirements" numbered="true" toc="default">
        <name>DetNet Controller Plane Requirements"
             anchor="control-management-requirements"> Requirements</name>
        <t>
        The Controller Plane corresponds to the aggregation of the Control and
        Management Planes discussed in <xref target="RFC7426"/> target="RFC7426" format="default"/> and
        <xref target="RFC8655"/>. target="RFC8655" format="default"/>.  While more details of regarding any DetNet controller
        plane Controller
        Plane are out of the scope of for this document, there are particular
        considerations and requirements for such the Controller Plane that result from the unique
        characteristics of the DetNet architecture and
        data plane as defined herein.
        </t>
        <t>
        The primary requirements of the DetNet controller plane Controller Plane are
        that it must be able to:
        <list style="symbols">
          <t>
        </t>
        <ul spacing="normal">
          <li>
            Instantiate DetNet flows in a DetNet domain (which may may, for example,
            include some or all of the following: explicit path determination, link
            bandwidth reservations, restricting flows to IEEE 802.1 TSN
            links, node buffer and other resource reservations,
            specification of required queuing disciplines along the
            path, ability to manage bidirectional flows, etc.) as needed
            for a flow.
          </t>
          <t>
          </li>
          <li>
            In the case of MPLS, manage DetNet S-Label and F-Label allocation
            and distribution, distribution. In cases where the DetNet MPLS encapsulation is in use
            being used, see <xref target="I-D.ietf-detnet-mpls"/>.
          </t>
          <t> target="DetNet-MPLS" format="default"/>.
          </li>
          <li>
            Support DetNet flow aggregation.
          </t>
          <t>
          </li>
          <li>
            Advertise static and dynamic node and link resources such
            as capabilities and adjacencies to other network nodes (for
            dynamic signaling approaches) or to network controllers (for
            centralized approaches).
          </t>
          <t>
          </li>
          <li>
            Scale to handle the number of DetNet flows expected in a
            domain (which may require per-flow signaling or
            provisioning).
          </t>
          <t>
          </li>
          <li>
            Provision flow identification information at each of the nodes
            along the path. Flow identification may differ differ, depending on the
            location in the network and the DetNet functionality (e.g. (e.g., transit
            node vs. relay node).
          </t>
        </list>
      </t>
          </li>
        </ul>
        <t>
        These requirements, as stated earlier, could be satisfied using
        distributed control protocol signaling (such as RSVP-TE),
        centralized network management provisioning mechanisms (such as
        BGP, (BGP, PCEP, YANG YANG, <xref
        target="I-D.ietf-detnet-flow-information-model"/>, etc.) target="I-D.ietf-detnet-flow-information-model" format="default"/>, etc.), or hybrid
        combinations of the two, and could also make use of MPLS-based
        segment routing.
        </t>
        <t>
        In the abstract, the results of either distributed signaling
        or centralized provisioning are equivalent from a DetNet data plane
 perspective - -- flows are instantiated, explicit routes
        are determined, resources are reserved, and packets are
        forwarded through the domain using the DetNet data plane.
        </t>
        <t>
        However, from a practical and implementation standpoint, controller plane Controller Plane alternatives are not
        equivalent at all. Some approaches are more scalable than others in
        terms of signaling load on the network. Some alternatives can take advantage of
        global tracking of resources in the DetNet domain for better overall
        network resource optimization. Some solutions are more resilient than others if
        link, node, or management equipment failures occur. While a detailed
        analysis of the control plane alternatives is out of the scope of for this
        document, the requirements from this document can be used as the basis
        of a later future analysis of the alternatives.
        </t>
      </section>
      <section title="Generic anchor="gen_cp_considerations" numbered="true" toc="default">
        <name>Generic Controller Plane Considerations" anchor="gen_cp_considerations"> Considerations</name>
        <t>
      This section covers control plane considerations that are
      independent of the data plane technology used for DetNet service
      delivery.
        </t>
        <t>
      While the management plane and the control planes plane are traditionally
      considered separately, from the a data plane perspective perspective, there is no
      practical difference based on the origin of flow provisioning flow-provisioning
      information, and the DetNet architecture <xref
      target="RFC8655"/> target="RFC8655" format="default"/> refers to these collectively
      as the 'Controller Plane'. "Controller Plane".  This document therefore does not
      distinguish between information provided by distributed control plane protocols, e.g., protocols (e.g., RSVP-TE <xref target="RFC3209"/> and target="RFC3209" format="default"/> <xref
      target="RFC3473"/>, target="RFC3473" format="default"/>) or by centralized network management mechanisms,
      e.g., RestConf mechanisms
      (e.g., RESTCONF <xref target="RFC8040"/>, target="RFC8040" format="default"/>, YANG <xref
      target="RFC7950"/>, and the Path Computation Element Communication
      Protocol (PCEP) target="RFC7950" format="default"/>, PCEP <xref
      target="I-D.ietf-pce-pcep-extension-for-pce-controller"/> target="I-D.ietf-pce-pcep-extension-for-pce-controller" format="default"/>), or any
      combination thereof. Specific considerations and requirements for
      the DetNet Controller Plane are discussed in <xref
      target="control-management-requirements"/>. target="control-management-requirements" format="default"/>.
        </t>
        <t>
      Each respective data plane document also covers the control plane considerations
      for that technology.  For example, <xref target="I-D.ietf-detnet-ip"/> target="RFC8939"
      format="default"/> also covers IP
      control plane normative considerations considerations, and <xref
      target="I-D.ietf-detnet-mpls"/> target="DetNet-MPLS"
      format="default"/> also  covers MPLS control plane
      normative considerations.
        </t>
        <section title="Flow numbered="true" toc="default">
          <name>Flow Aggregation Control"> Control</name>
          <t>
        Flow aggregation means that multiple app-flows App-flows are served by a single new DetNet
        flow.  There are many techniques to achieve aggregation. For example,
                in the case of IP, IP flows that share 6-tuple attributes or flow
                identifiers at the DetNet sub-layer sub&nbhy;layer can be grouped.
                Another example includes aggregation accomplished through the use of
                hierarchical LSPs in MPLS and tunnels.
          </t>
          <t>
        Control of aggregation involves a set of procedures listed here.
        Aggregation may use some or all of these capabilities capabilities, and the order may vary:
       <list style="symbols">
         <t> Traffic
          </t>
        <dl newline="true" spacing="normal">
            <dt>Traffic engineering resource collection and distribution:
           <list style="empty">
             <t>
               Available distribution:</dt>
             <dd>Available resources are tracked through control plane or
               management plane databases and distributed amongst controllers
               or nodes that can manage resources.
             </t>
           </list>
         </t>
         <t> Path resources.</dd>
            <dt>Path computation and resource allocation:
           <list style="empty">
             <t>
               When allocation:</dt>
             <dd>When DetNet services are provisioned or requested, one or more
               paths meeting the requirements are selected and the resources
               verified and recorded.
             </t>
           </list>
       </t>
       <t> Resource recorded.</dd>
            <dt>Resource assignment and data plane co-ordination:
           <list style="empty">
             <t>
               The coordination:</dt>
             <dd>The assignment of resources along the path depends on the technology and
           includes assignment of specific links, coordination of
			   queueing,
           queuing, and other traffic management capabilities such as policing and shaping.
             </t>
           </list>
       </t>
         <t> Assigned Resource shaping.</dd>
            <dt>Assigned resource recording and updating:
           <list style="empty">
             <t>
               Depending updating:</dt>
             <dd>Depending on the specific technology, the assigned resources are
           updated and distributed in the databases, preventing over-subscription.
             </t>
           </list>
       </t>
      </list>
      </t> oversubscription.</dd>
        </dl>
        </section>
        <section title="Explicit Routes"> numbered="true" toc="default">
          <name>Explicit Routes</name>
          <t>
        Explicit routes are used to ensure that packets are routed through the
        resources that have been reserved for them, them and hence provide the
        DetNet application with the required service.  A requirement for the
        DetNet Controller Plane will be the ability to assign a particular
        identified DetNet IP flow to a path through the DetNet domain that has
        been assigned the required per-node resources.  This provides the
        appropriate traffic treatment for the flow and also includes particular
        links as a part of the path that are able to support the DetNet flow.
        For example, by using IEEE 802.1 TSN links (as discussed in
        <xref target="I-D.ietf-detnet-mpls-over-tsn"/> ) target="DetNet-MPLS-over-TSN" format="default"/>), DetNet parameters can be maintained.
        Further considerations and requirements for the DetNet Controller Plane
        are discussed in <xref target="control-management-requirements"/>. target="control-management-requirements" format="default"/>.
          </t>
          <t>
        Whether configuring, calculating calculating, and instantiating these
        routes is a single-stage or multi-stage process, or is performed in a
        centralized or distributed manner, is out of scope of for this
        document.
          </t>
          <t>
        There are several approaches that could be used to provide
        explicit routes and resource allocation in the DetNet
        forwarding sub-layer. sub&nbhy;layer. For example:
        <list style="symbols">
          <t>
          </t>
          <ul spacing="normal">
            <li>
            The path could be explicitly set up by a controller which that
            calculates the path and explicitly configures each node along that
            path with the appropriate forwarding and resource allocation
            information.
          </t>
          <t>
          </li>
            <li>
            The path could use a distributed control plane such as
            <xref target="RFC2205">RSVP</xref> target="RFC2205" format="default">RSVP</xref> or RSVP-TE <xref
            target="RFC3473"/> target="RFC3473" format="default"/> extended to support DetNet IP flows.
          </t>
          <t>
          </li>
            <li>
            The path could be implemented using IPv6-based segment
            routing when extended to support resource allocation.
          </t>
        </list>
          </li>
          </ul>
          <t>
        See <xref target="control-management-requirements"/> target="control-management-requirements" format="default"/> for
        further discussion of these alternatives. In addition,
        <xref target="RFC2386"/> target="RFC2386" format="default"/> contains useful background information
        on QoS-based routing, and <xref target="RFC5575"/> (being target="RFC5575" format="default"/>
	(which will be
        updated by <xref target="I-D.ietf-idr-rfc5575bis"/>) target="I-D.ietf-idr-rfc5575bis" format="default"/>) discusses
        a specific mechanism used by BGP for traffic flow specification
        and policy-based routing.
          </t>
        </section>
        <section title="Contention numbered="true" toc="default">
          <name>Contention Loss and Jitter Reduction"> Reduction</name>
          <t>
        As discussed in <xref target="sec_intro"/>, this
        This document does
        not specify the mechanisms needed to eliminate packet contention, contention or packet loss
        or to reduce jitter for DetNet flows at the DetNet forwarding
        sub-layer.
        sub&nbhy;layer.  The ability to manage node and link resources to
        be able to provide these functions is a necessary part of
        the DetNet controller plane. Controller Plane. It is also necessary to be
        able to control the required queuing mechanisms used to
        provide these functions along a flow's path through the
        network. See  <xref target="I-D.ietf-detnet-ip"/> target="RFC8939" format="default"/> and <xref
        target="control-management-requirements"/> target="control-management-requirements" format="default"/> for further
        discussion of these requirements. Some forms of protection
        may minimize packet loss or change
        jitter characteristics in the cases where packets are reordered when out-of-order packets are received at the service sub-layer. sub&nbhy;layer.
          </t>
        </section>
        <section title="Bidirectional Traffic"> numbered="true" toc="default">
          <name>Bidirectional Traffic</name>
          <t>
        In many cases cases, DetNet flows can be considered unidirectional and
        independent. However, there are cases where the DetNet service requires
        bidirectional traffic from a DetNet application service perspective.  IP and
        MPLS typically treat each direction separately and do not force
        interdependence of each direction.  The IETF MPLS Working Group has considered
studied bidirectional traffic requirements and the MPLS requirements. The definitions from provided in <xref
                target="RFC5654"/> target="RFC5654" format="default"/> are useful to illustrate terms such as
        associated bidirectional flows and co-routed bidirectional flows.
  MPLS
        defines a point-to-point associated bidirectional LSP as consisting of
        two unidirectional point-to-point LSPs, one from A to B and the other
        from B to A, which are regarded as providing a single logical
        bidirectional forwarding path.  This is analogous to standard IP
        routing.  MPLS defines a point-to-point co-routed bidirectional LSP as
        an associated bidirectional LSP which that satisfies the additional
        constraint that its two unidirectional component LSPs follow the same
        path (in terms of both nodes and links) in both directions.  An
        important property of co-routed bidirectional LSPs is that their
        unidirectional component LSPs share fate.  In both types of
        bidirectional LSPs, resource reservations may differ in each direction.
        The concepts of associated bidirectional flows and co-routed co&nbhy;routed
        bidirectional flows can also be applied to DetNet IP flows.
          </t>
          <t>
        While the DetNet IP data plane must support bidirectional
        DetNet flows, there are no special bidirectional features with
        respect to the data plane other than the need for the two
        directions of a co-routed co&nbhy;routed bidirectional flow to take the same
        path. That is to say that say, bidirectional DetNet flows are
        solely represented at the management plane and control plane levels,
        without specific support or knowledge within the DetNet data
        plane.  Fate sharing  Fate-sharing and associated or co-routed co&nbhy;routed
        bidirectional flows, flows can be managed at the control level.
          </t>
          <t>
        DetNet's use of PREOF may increase the complexity of using co-routing co&nbhy;routing
        bidirectional flows, since because if PREOF is are used, then the replication points
        in one direction would have to match the elimination points in the
        other direction, and vice versa. In such cases cases, the optimal points for
        these functions in one direction may not match the optimal points in
        the other, due to network and traffic constraints.
        Furthermore, due to the per packet per-packet service protection nature,
        bidirectional forwarding per packet may not be ensured.
        The first packet of received member flows is selected by the
        elimination function independently of which path it has taken
        through the network.
          </t>
          <t>
        Control and management mechanisms need to support bidirectional flows,
        but the specification of such mechanisms are is out of scope of for this
        document. Example control plane solutions for MPLS can be found in <xref
        target="RFC3473"/> , target="RFC3473" format="default"/>, <xref target="RFC6387"/> target="RFC6387" format="default"/>, and <xref
                target="RFC7551"/>. target="RFC7551" format="default"/>.  These requirements are included in <xref
        target="control-management-requirements"/>. target="control-management-requirements" format="default"/>.
          </t>
<!--
    -->
    </section>
      </section>
      <section title="Packet anchor="PREOF" numbered="true" toc="default">
        <name>Packet Replication, Elimination, and Ordering (PREOF)" anchor="PREOF"> Functions (PREOF)</name>
        <t>
        The controller plane Controller Plane protocol solution required for managing the
        PREOF
        processing of PREOF is outside the scope of this document. That
        said, it should be noted that the ability to determine, for a
        particular flow, optimal packet replication and elimination
        points in the DetNet domain requires explicit support. There may
        be existing capabilities that can be used, used or extended, extended -- for example example, GMPLS
        end-to-end recovery <xref target="RFC4872"/> target="RFC4872" format="default"/> and GMPLS segment
        recovery <xref target="RFC4873"/>. target="RFC4873" format="default"/>.
        </t>
      </section>
    </section>

    <!-- ===================================================================== -->
<section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
    Security considerations for DetNet are described in detail in
    <xref target="I-D.ietf-detnet-security"/>. target="DetNet-Security" format="default"/>. General security considerations
    for the DetNet architecture are described in <xref target="RFC8655"/>. target="RFC8655" format="default"/>. This section
    considers architecture-level DetNet security considerations applicable to all data planes.
      </t>
      <t>
        Part of what makes DetNet unique is its ability to provide specific and
        reliable quality of service QoS (delivering data flows with extremely low
        packet loss rates and bounded end-to-end delivery latency), and the
        security-related aspects of protecting that quality of service QoS are
        similarly unique.
      </t>
      <t>
     As for all communications protocols,
         the primary consideration for the data plane is to maintain
     integrity of data and delivery of the associated DetNet service traversing
     the DetNet network.
     Application flows can be protected through whatever means is
     provided by the underlying technology. For example, encryption may be
     used, such as that provided by IPSec IPsec <xref target="RFC4301"/> target="RFC4301" format="default"/> for IP
     flows and/or by an underlying sub-net sub-network using MACSec MACsec
     <xref target="IEEE802.1AE-2018"/> target="IEEE802.1AE-2018" format="default"/> for Ethernet (Layer-2) (Layer 2) flows.
      </t>
      <t>
     At the management and control level levels, DetNet flows are identified on a
     per-flow basis, which may provide controller plane Controller Plane
     attackers with additional information about the data flows (when
     compared to controller planes Controller Planes that do not include per-flow identification).
     This is an inherent property of DetNet which that has security
     implications that should be considered when determining if DetNet is
     a suitable technology for any given use case.
      </t>
      <t>
     To provide uninterrupted availability of the DetNet
     service, provisions can be made against DOS DoS attacks and delay
     attacks. To protect against DOS DoS attacks, excess traffic due to
     malicious or malfunctioning devices can be prevented or mitigated, mitigated --
     for example example, through the use of existing mechanisms such as policing and shaping applied at
     the input of a DetNet domain. To prevent DetNet packets from
     being delayed by an entity external to a DetNet domain, DetNet
     technology definition definitions can allow for the mitigation of
     Man-In-The-Middle attacks,
     man-in-the-middle attacks -- for example example, through the use of
     authentication and authorization of devices within the DetNet domain.
      </t>
      <t>
         In order to prevent or mitigate DetNet attacks on other networks via
         flow escape, edge devices can can, for example example, use existing mechanism mechanisms such
         as policing and shaping applied at the output of a DetNet domain.
      </t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
     This document makes has no IANA requests.
  </t>
</section>

<section anchor="acks" title="Acknowledgements">
    <t>
    The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David
    Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig
    Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their
    various contributions to this work.
  </t>
</section>
<section anchor="contrib" title="Contributors">
    <t>
    The following people contributed substantially to the content of this
    document:
    <?rfc subcompact="yes" ?>
    <list style="">
        <t> Don Fedyk </t>
        <t> Jouni Korhonen</t>
    </list>
    <?rfc subcompact="no" ?> actions.
      </t>
    </section>
  </middle>
  <back>
  <references title="Normative References">
   <?rfc include="reference.RFC.8655"?>

<displayreference target="I-D.ietf-pce-pcep-extension-for-pce-controller" to="PCECC"/>
<displayreference target="I-D.ietf-detnet-flow-information-model" to="DetNet-Flow-Info"/>
<displayreference target="I-D.ietf-idr-rfc5575bis" to="Flow-Spec-Rules"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
      </references>
  <references title="Informative References">
   <?rfc include="reference.RFC.3209"?>
   <?rfc include="reference.RFC.3473"?>
   <?rfc include="reference.RFC.4385"?>
   <?rfc include="reference.RFC.2205"?>
   <?rfc include="reference.RFC.2386"?>
   <?rfc include="reference.RFC.4872"?>
   <?rfc include="reference.RFC.4873"?>
   <?rfc include="reference.RFC.7657"?>
   <?rfc include="reference.RFC.3670"?>
   <?rfc include="reference.RFC.5575"?>
   <?rfc include="reference.RFC.5654"?>
   <?rfc include="reference.RFC.6387"?>
   <?rfc include="reference.RFC.7950"?>
   <?rfc include="reference.RFC.7551"?>
   <?rfc include="reference.RFC.8040"?>
   <?rfc include="reference.RFC.8227"?>
   <?rfc include="reference.RFC.4301"?>
   <?rfc include="reference.RFC.7426"?>
   <?rfc include="reference.I-D.ietf-pce-pcep-extension-for-pce-controller"?>
   <?rfc include="reference.I-D.ietf-detnet-flow-information-model"?>
   <?rfc include="reference.I-D.ietf-detnet-ip"?>
   <?rfc include="reference.I-D.ietf-detnet-mpls"?>
   <?rfc include="reference.I-D.ietf-detnet-mpls-over-tsn"?>
   <?rfc include="reference.I-D.ietf-detnet-mpls-over-udp-ip"?>
   <?rfc include="reference.I-D.ietf-detnet-security"?>
   <?rfc include="reference.I-D.ietf-idr-rfc5575bis"?>

   <!--reference anchor='I-D.ietf-detnet-ip-over-tsn'>
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2386.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4873.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7657.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3670.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5654.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6387.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8227.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>

<!-- draft-ietf-pce-pcep-extension-for-pce-controller (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-pcep-extension-for-pce-controller.xml"/>

<!-- draft-ietf-detnet-flow-information-model (Waiting for Writeup) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-flow-information-model.xml"/>

<!-- draft-ietf-detnet-ip (RFC 8939) -->
<reference anchor="RFC8939" target="https://www.rfc-editor.org/info/rfc8939">
<front>
    <title>Deterministic Networking (DetNet) Data Plane: IP</title>
    <author initials="B" surname="Varga" fullname="Balazs Varga" role="editor">
      <organization/>
    </author>
    <author initials="J" surname="Farkas" fullname="Janos Farkas">
      <organization/>
    </author>
    <author initials="L" surname="Berger" fullname="Lou Berger">
      <organization/>
    </author>
    <author initials="D" surname="Fedyk" fullname="Don Fedyk">
      <organization/>
    </author>
    <author initials="S" surname="Bryant" fullname="Stewart Bryant">
      <organization/>
    </author>
<date month='November' year='2020'/>
</front>
<seriesInfo name="RFC" value="8939"/>
<seriesInfo name="DOI" value="10.17487/RFC8939"/>
</reference>

<!-- draft-ietf-detnet-mpls (RFC-EDITOR) -->
  <!-- Have to do long way; Balazs Varga is an editor -->
        <reference anchor="DetNet-MPLS" target="https://tools.ietf.org/html/draft-ietf-detnet-mpls-13">
          <front>
            <title>DetNet Data Plane: IP MPLS</title>
            <author initials="B" surname="Varga" fullname="Balazs Varga" role="editor">
              <organization/>
            </author>
            <author initials="J" surname="Farkas" fullname="Janos Farkas">
              <organization/>
            </author>
            <author initials="L" surname="Berger" fullname="Lou Berger">
              <organization/>
            </author>
            <author initials="A" surname="Malis" fullname="Andrew Malis">
              <organization/>
            </author>
            <author initials="S" surname="Bryant" fullname="Stewart Bryant">
              <organization/>
            </author>
            <author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
              <organization/>
            </author>
            <date month="October" day="11" year="2020"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-13"/>
        </reference>

<!-- draft-ietf-detnet-mpls-over-tsn (I-D Exists) -->
  <!-- Have to do long way; Balazs Varga is an editor -->
        <reference anchor="DetNet-MPLS-over-TSN" target="https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-04">
          <front>
            <title>DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)
       </title>
       <author>
         <organization>Korhonen, J., Varga, B.</organization> (TSN)</title>
            <author initials="B" surname="Varga" fullname="Balazs Varga" role="editor">
              <organization/>
            </author>
            <author initials="J" surname="Farkas" fullname="Janos Farkas">
              <organization/>
            </author>
            <author initials="A" surname="Malis" fullname="Andrew Malis">
              <organization/>
            </author>
            <author initials="S" surname="Bryant" fullname="Stewart Bryant">
              <organization/>
            </author>
            <date year='2018' /> month="November" day="2" year="2020"/>
          </front>
   </reference-->

   <?rfc include="reference.I-D.ietf-spring-srv6-network-programming"?>

   <!--reference anchor="IEEE8021Q"
     target="http://standards.ieee.org/about/get/">
          <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-over-tsn-04"/>
        </reference>

<!-- draft-ietf-detnet-mpls-over-udp-ip (Waiting for Writeup) -->
  <!-- Have to do long way; Balazs Varga is an editor -->
        <reference anchor="DetNet-MPLS-over-UDP-IP" target="https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-udp-ip-07">
          <front>
      <title>Standard
            <title>DetNet Data Plane: MPLS over UDP/IP</title>
            <author initials="B" surname="Varga" fullname="Balazs Varga" role="editor">
              <organization/>
            </author>
            <author initials="J" surname="Farkas" fullname="Janos Farkas">
              <organization/>
            </author>
            <author initials="L" surname="Berger" fullname="Lou Berger">
              <organization/>
            </author>
            <author initials="A" surname="Malis" fullname="Andrew Malis">
              <organization/>
            </author>
            <author initials="S" surname="Bryant" fullname="Stewart Bryant">
              <organization/>
            </author>
            <date month="October" day="11" year="2020"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-over-udp-ip-07"/>
        </reference>

<!-- draft-ietf-detnet-security (Waiting for Local and metropolitan area networks-Bridges and Bridged Networks (IEEE Std 802.1Q-2014)
      </title>
     <author>
      <organization>IEEE 802.1</organization> Writeup) -->
  <!-- Have to do long way; Ethan Grossman is an editor -->
        <reference anchor="DetNet-Security" target="https://tools.ietf.org/html/draft-ietf-detnet-security-12">
          <front>
            <title>Deterministic Networking (DetNet) Security Considerations</title>
            <author initials="E" surname="Grossman" fullname="Ethan Grossman"  role="editor">
  <organization/>
	    </author>
            <author initials="T" surname="Mizrahi" fullname="Tal Mizrahi">
              <organization/>
            </author>
            <author initials="A" surname="Hacker" fullname="Andrew Hacker">
              <organization/>
            </author>
            <date year="2014"/> month="October" day="2" year="2020"/>
          </front>
    <format type="PDF" target="http://standards.ieee.org/about/get/"/>
   </reference-->
          <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-security-12"/>
        </reference>

<!-- draft-ietf-idr-rfc5575bis (MISSREF) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-idr-rfc5575bis.xml"/>

<!-- draft-ietf-spring-srv6-network-programming (ESG Eval::AD Followup) -->
  <!-- Had to do long way; 2 coauthors are also editors -->
   <reference anchor="SRv6-Network-Prog" target="https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-24">
          <front>
            <title>SRv6 Network Programming</title>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils" role="editor">
              <organization/>
            </author>
            <author initials="P" surname="Camarillo" fullname="Pablo Camarillo" role="editor">
              <organization/>
            </author>
            <author initials="J" surname="Leddy" fullname="John Leddy">
              <organization/>
            </author>
            <author initials="D" surname="Voyer" fullname="Daniel Voyer">
              <organization/>
            </author>
            <author initials="S" surname="Matsushima" fullname="Satoru Matsushima">
              <organization/>
            </author>
            <author initials="Z" surname="Li" fullname="Zhenbin Li">
              <organization/>
            </author>
            <date month="October" day="7" year="2020"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-network-programming-24"/>
        </reference>

   <reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/tsn"> target="https://1.ieee802.org/tsn/">
          <front>
     <title>IEEE 802.1 Time-Sensitive
            <title>Time-Sensitive Networking (TSN) Task Group</title>
            <author>
       <organization>IEEE Standards Association</organization>
              <organization>IEEE</organization>
            </author>
       <date></date>
            <date/>
          </front>
        </reference>

        <reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org/document/8585421">
          <front>
            <title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title> Standard for Local and metropolitan area
            networks-Media Access Control (MAC) Security</title>
            <author>
          <organization>IEEE Standards Association</organization>
              <organization>IEEE</organization>
            </author>
          <date year="2018" /> month="December" year="2018"/>
          </front>
          <seriesInfo name='IEEE Std' value='802.1AE-2018' />
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
        </reference>
        <reference anchor="nwcrg" target="https://datatracker.ietf.org/rg/nwcrg/about">
          <front>
            <title>Coding for efficient NetWork Communications Research Group (nwcrg)</title>
            <author>
              <organization>IRTF</organization>
            </author>
<!--            <date year="" /> year=""/> -->
          </front>
        </reference>

   <!--reference anchor="IEEE8021CB"
    target="http://www.ieee802.org/1/files/private/cb-drafts/d2/802-1CB-d2-1.pdf">
    <front>
        <title>Draft Standard for Local and metropolitan area networks - Seamless Redundancy</title>
        <author initials="N. F." surname="Finn"
  </references>
    </references>
    <section anchor="acks" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
    The authors wish to thank <contact fullname="Pat Thaler"/>, <contact
    fullname="Norman Finn">
            <organization>IEEE 802.1</organization>
        </author>
        <date month="December" year="2015"/>
    </front>
    <seriesInfo name="IEEE P802.1CB /D2.1" value="P802.1CB"/>
    <format type="PDF" target="http://www.ieee802.org/1/files/private/cb-drafts/d2/802-1CB-d2-1.pdf"/>
   </reference-->

   <!--reference anchor="G.8275.1"
              target="https://www.itu.int/rec/T-REC-G.8275.1/en">
     <front>
       <title>Precision time protocol telecom profile for phase/time synchronization with full timing support from the network</title>
       <author>
         <organization>International Telecommunication Union</organization>
       </author>
       <date month="June" year="2016"/>
     </front>
     <seriesInfo name="ITU-T G.8275.1/Y.1369.1" value="G.8275.1"/>
   </reference-->

   <!--reference anchor="G.8275.2"
              target="https://www.itu.int/rec/T-REC-G.8275.2/en">
     <front>
       <title>Precision time protocol telecom profile Finn"/>, <contact fullname="Loa Andersson"/>, <contact
    fullname="David Black"/>, <contact fullname="Rodney Cummings"/>, <contact
    fullname="Ethan Grossman"/>, <contact fullname="Tal Mizrahi"/>, <contact
    fullname="David Mozes"/>, <contact fullname="Craig Gunther"/>, <contact
    fullname="George Swallow"/>, <contact fullname="Yuanlong Jiang"/>, and
    <contact fullname="Carlos J. Bernardos"/> for phase/time synchronization with partial timing support from their various contributions
    to this work.
      </t>
    </section>
    <section anchor="contrib" numbered="false" toc="default">
      <name>Contributors</name>
      <t>
    The following people contributed substantially to the network</title>
       <author>
         <organization>International Telecommunication Union</organization>
       </author>
       <date month="June" year="2016"/>
     </front>
     <seriesInfo name="ITU-T G.8275.2/Y.1369.2" value="G.8275.2"/>
   </reference-->

  </references> content of this
    document:</t>
  <ul empty="true" spacing="compact">
       <li><t><contact fullname="Don Fedyk"/></t></li>
       <li><t><contact fullname="Jouni Korhonen"/></t></li>
  </ul>
    </section>
  </back>
</rfc>