<?xml version="1.0" encoding="US-ASCII"?> 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 category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-ip-over-mpls-09" number="9056" ipr="trust200902"
     submissionType="IETF"> submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="DetNet Data Plane: IP over DetNet MPLS Data Plane">
    DetNet MPLS">
    Deterministic Networking (DetNet) Data Plane: IP over MPLS</title>

    <seriesInfo name="RFC" value="9056"/>
    <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 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="Don Fedyk" initials="D." surname="Fedyk">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
        <email>dfedyk@labn.net</email>
      </address>
    </author>

<!--
    <author fullname="Andrew G. Malis" initials="A.G." surname="Malis">
      <organization>Independent</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>
        <email>sb@stewartbryant.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>
      </address>
    </author>

    <!--author fullname="Donald Fauntleroy Duck" initials="D. F." surname="Duck">
        <organization abbrev="Royal Bros.">Royal Bros.</organization>
        <address>
        <postal>
        <street>13 Paradise Road</street>
        <city>Duckburg</city>
        <region>Calisota</region>
        <country>USA</country>
        </postal>
        </address>
        </author-->

    <date year="2021" month="October" />
    <workgroup>DetNet</workgroup>

<keyword>sub-network</keyword>

    <abstract>
      <t>
     This document specifies the Deterministic Networking data plane
     when encapsulating IP over an MPLS packet switched packet-switched network.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sec_intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        Deterministic Networking (DetNet) is a service that can be offered by a
	network to DetNet flows.
        DetNet provides a capability for the delivery of data flows with
        extremely low packet loss rates and bounded end-to-end delivery
        latency.
	General background and concepts of DetNet can be found in the DetNet
	Architecture <xref target="RFC8655"/>.
      </t>
<!--      <t>
        This document specifies the DetNet data plane operation for IP
        hosts and routers that provide DetNet service to IP encapsulated
        data.  No DetNet specific encapsulation is defined to support IP
        flows, rather existing IP and higher layer protocol header information is used to support
        flow identification and DetNet service delivery.
      </t>
      <t>
        The DetNet Architecture decomposes the DetNet related data plane
        functions into two sub-layers: a service sub-layer and a forwarding
        sub-layer.  The service sub-layer is used to provide DetNet service
        protection and reordering. The forwarding sub-layer is used to
        provides congestion protection (low loss, assured latency, and
        limited reordering). Since no DetNet specific headers are added to
        support DetNet IP flows, only the forwarding sub-layer functions are
        supported using the DetNet IP defined by this document. Service
        protection can be provided on a per sub-net
        basis using technologies such as MPLS
	architecture <xref
        target="I-D.ietf-detnet-mpls"/> and IEEE802.1 TSN. target="RFC8655" format="default"/>.
      </t>
-->

      <t>
                This document specifies use of the IP DetNet encapsulation over an
                MPLS network. It maps the IP data plane encapsulation described in <xref
                target="I-D.ietf-detnet-ip"/> target="RFC8939" format="default"/> to the DetNet MPLS data plane defined in <xref
                target="I-D.ietf-detnet-mpls"/>. target="RFC8964" format="default"/>.
      </t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <section title="Terms numbered="true" toc="default">
        <name>Terms Used In in This Document"> Document</name>
        <t>
          This document uses the terminology and concepts established in the
          DetNet architecture <xref target="RFC8655"/> target="RFC8655" format="default"/> and in
          <xref target="I-D.ietf-detnet-data-plane-framework"/>, the target="RFC8938" format="default"/>. The reader is assumed to
          be familiar with these documents and their terminology.
        </t>
      </section>
      <section title="Abbreviations"> numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>
          This document uses the abbreviations defined in the DetNet
          architecture <xref target="RFC8655"/> target="RFC8655" format="default"/> and in <xref target="I-D.ietf-detnet-data-plane-framework"/>.
          target="RFC8938" format="default"/>.  This document uses the
          following abbreviations:
          <list style="hanging" hangIndent="14">
            <t hangText="CE">Customer
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>CE</dt>
          <dd>Customer Edge equipment.</t>
		    <t hangText="d-CW">DetNet (equipment)</dd>
          <dt>d-CW</dt>
          <dd>DetNet Control Word.</t>
            <t hangText="DetNet">Deterministic Networking.</t>
            <t hangText="DF">DetNet Flow.</t>
            <t hangText="DN">DetNet.</t>
            <t hangText="L2">Layer-2.</t>
            <t hangText="LSP">Label-switched path.</t>
            <t hangText="MPLS">Multiprotocol Word</dd>
          <dt>DetNet</dt>
          <dd>Deterministic Networking</dd>
          <dt>DF</dt>
          <dd>DetNet Flow</dd>
          <dt>DN</dt>
          <dd>DetNet</dd>
          <dt>L2</dt>
          <dd>Layer 2</dd>
          <dt>LSP</dt>
          <dd>Label-Switched Path</dd>
          <dt>MPLS</dt>
          <dd>Multiprotocol Label Switching.</t>
            <t hangText="PEF">Packet Switching</dd>
          <dt>PEF</dt>
          <dd>Packet Elimination Function.</t>
            <t hangText="PRF">Packet Function</dd>
          <dt>PRF</dt>
          <dd>Packet Replication Function.</t>
            <t hangText="PREOF">Packet Function</dd>
          <dt>PREOF</dt>
          <dd>Packet Replication, Elimination Elimination, and Ordering Functions.</t>
            <t hangText="POF">Packet Functions</dd>
          <dt>POF</dt>
          <dd>Packet Ordering Function.</t>
            <t hangText="PW">Pseudowire.</t>
		    <t hangText="S-Label">DetNet Function</dd>
          <dt>PW</dt>
          <dd>Pseudowire</dd>
          <dt>S-Label</dt>
          <dd>DetNet "service" label.</t>
		    <t hangText="S-PE">Switching Label</dd>
          <dt>S-PE</dt>
          <dd>Switching Provider Edge.</t>
		    <t hangText="T-PE">Terminating Edge</dd>
          <dt>T-PE</dt>
          <dd>Terminating Provider Edge.</t>
            <t hangText="TE">Traffic Engineering.</t>
            <t hangText="TSN">Time-Sensitive Networking, Edge</dd>
          <dt>TE</dt>
          <dd>Traffic Engineering</dd>
          <dt>TSN</dt>
          <dd>Time-Sensitive Networking; TSN is a Task Group of the IEEE
            802.1 Working Group.</t>
          </list>
        </t> Group</dd>
        </dl>
      </section>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>

        <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
        NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119"
        format="default"/> <xref
        target="RFC8174"/> target="RFC8174" format="default"/> when, and
        only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section title="DetNet anchor="sec_dt_dp" numbered="true" toc="default">
      <name>DetNet IP Data Plane Overview" anchor="sec_dt_dp"> Overview</name>
      <t>
        <xref target="fig_ip_detnet"/> target="fig_ip_detnet" format="default"/> illustrates an IP DetNet,
        DetNet with an MPLS based MPLS-based DetNet network as a sub-network between the
        relay nodes.  An IP flow is mapped to one or more PWs and MPLS (TE)
        LSPs.  The end systems still originate IP encapsulated IP-encapsulated traffic,
        identified as DetNet flows.  The relay nodes follow procedures defined
        in <xref target="ip-over-mpls"/> target="ip-over-mpls" format="default"/> to map each DetNet
        flow to MPLS LSPs. While not shown, relay nodes can provide service
        sub-layer functions such as PREOF using DetNet over MPLS, and this is
        indicated by the solid line for the MPLS
        facing MPLS-facing portion of the Service
        component. Note that the Transit node is MPLS (TE) LSP aware and
        performs switching based on MPLS
        labels, and labels; it need not have any
        specific knowledge of the DetNet service or the corresponding DetNet
        flow identification. See <xref target="ip-over-mpls"/> target="ip-over-mpls"
        format="default"/> for details on the mapping of IP flows to MPLS, and
        <xref target="I-D.ietf-detnet-mpls"/> target="RFC8964" format="default"/> for general support of
        DetNet services using MPLS.
      </t>

      <figure align="center" anchor="fig_ip_detnet"
              title="Architecture: anchor="fig_ip_detnet">
        <name>Architecture: DetNet IP Over over DetNet MPLS Network">
        <artwork><![CDATA[ Network</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 DetNet IP       Relay         Transit         Relay      DetNet IP
 End System      Node           Node           Node       End System

+----------+                                             +----------+
|   Appl.  |<------------- End to End Service ---------->|  Appl.   |
+----------+   .....-----+                 +-----.....   +----------+
| Service  |<--: Service |--DetNet flow ---| Service :-->| Service  |
|          |   :         |<-DN MPLS flow ->|         :   |          |
+----------+   +---------+  +----------+   +---------+   +----------+
|Forwarding|   |Fwd| |Fwd|  |Forwarding|   |Fwd| |Fwd|   |Forwarding|
+-------.--+   +-.-+ +-.-+  +----.---.-+   +-.-+ +-.-+   +---.------+
        :  Link  :    /  ,-----.  \   : Link :    /  ,-----.  \
        +........+    +-[  Sub  ]-+   +......+    +-[  Sub  ]-+
                        [Network]                   [Network]
                         `-----'                     `-----'

                     |<---- DetNet MPLS ---->|
         |<--------------------- DetNet IP ------------------>|
                         ]]></artwork>
      </figure>
    </section>

    <!-- ===================================================================== -->

    <section anchor="ip-over-mpls" title="IP numbered="true" toc="default">
      <name>DetNet IP over DetNet MPLS"> MPLS</name>
      <t>
        This section defines how IP encapsulated IP-encapsulated flows are carried over a
        DetNet MPLS data plane as defined in <xref
        target="I-D.ietf-detnet-mpls"/>. target="RFC8964"
        format="default"/>.  Since both Non-DetNet non-DetNet and DetNet IP packet packets are
        identical on the wire, this section is applicable to any node that
        supports IP over DetNet MPLS, and this section refers to both cases as
        DetNet IP over DetNet MPLS.
      </t>
      <section title="IP Over anchor="sec_ip_mpls_dt_dp_scen" numbered="true" toc="default">
        <name>DetNet IP over DetNet MPLS Data Plane Scenarios"
               anchor="sec_ip_mpls_dt_dp_scen"> Scenarios</name>
        <t>
          An example use of DetNet IP over DetNet MPLS is presented here.
        </t>
        <t>

          <xref target="fig_ip_detnet"/> target="fig_ip_detnet" format="default"/> illustrates IP DetNet
          enabled
          DetNet-enabled End Systems (hosts) connected to DetNet (DN) enabled DetNet-enabled IP networks,
          networks (DN IP), operating over a DetNet aware DetNet-aware MPLS network.  In this Figure
          figure, we have a case where the Relay relay nodes act as T-PEs and sit at
          the boundary of the MPLS domain since the non-MPLS domain is DetNet
          aware.  This case is very similar to the DetNet MPLS Network Figure (Figure
          2 in <xref
                  target="I-D.ietf-detnet-mpls"/>. target="RFC8964" format="default"/>).  However, in  <xref
                  target="I-D.ietf-detnet-mpls"/> Figure 2,
          2 of <xref target="RFC8964" format="default"/>, the T-PEs are
          located at the end system and MPLS spans the whole DetNet service.

          The primary difference in this document is that the Relay relay nodes are
          at the edges of the MPLS domain and therefore function as T-PEs, and
          that MPLS service sub-layer functions are not provided over the
          DetNet IP network.  The transit node functions shown above are
          identical to those described in <xref
          target="I-D.ietf-detnet-mpls"/>. target="RFC8964"
          format="default"/>.
        </t>

        <t>
          <xref target="fig_ip_pw_detnet"/> target="fig_ip_pw_detnet" format="default"/> illustrates how
          relay nodes can provide service protection over an MPLS domain.  In
          this case, CE1 and CE2 are IP DetNet end systems which that are
          interconnected via a an MPLS domain such as that described in <xref
          target="I-D.ietf-detnet-mpls"/>.
          target="RFC8964" format="default"/>. Note that R1 and R3 sit at the
          edges of an MPLS domain and therefore are similar to T-PEs, while R2
          sits in the middle of the domain and is therefore similar to an
          S-PE.
        </t>
        <figure align="center" anchor="fig_ip_pw_detnet"
                title="Service anchor="fig_ip_pw_detnet">
          <name>Service Protection Over over DetNet MPLS Network for DetNet IP">
          <artwork><![CDATA[ IP</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      DetNet                                         DetNet
IP    Service         Transit          Transit       Service  IP
DetNet               |<-Tnl->|        |<-Tnl->|               DetNet
End     |            V   1   V        V   2   V            |  End
System  |   +--------+       +--------+       +--------+   |  System
+---+   |   |   R1   |=======|   R2   |=======|   R3   |   |   +---+
|   |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------|   |
|CE1|   |   |    \   |       |   X    |       |   /    |   |   |CE2|
|   |   |   |     \_.|..DF2..|._/ \__.|..DF4..|._/     |   |   |   |
+---+       |        |=======|        |=======|        |       +---+
    ^       +--------+       +--------+       +--------+       ^
    |        Relay Node       Relay Node       Relay Node      |
    |          (T-PE)           (S-PE)          (T-PE)         |
    |                                                          |
    |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
    |                                                          |
    |<-------------- End to End DetNet Service --------------->|

   -------------------------- Data Flow ------------------------->

    X   = Service protection (PRF, PREOF, PEF/POF)
    DFx = DetNet member flow x over a TE LSP
]]></artwork>
        </figure>
        <t>
          <xref target="fig_ip_detnet"/> target="fig_ip_detnet" format="default"/> illustrates DetNet
          enabled End Systems
          DetNet-enabled end systems connected to DetNet DetNet-enabled (DN) enabled MPLS network.
          networks.  A similar situation occurs when end systems are not DetNet
          aware.  In this case, edge nodes sit at the boundary of the MPLS
          domain since it is also a DetNet domain boundary.  The edge nodes
          provide DetNet service proxies for the end applications by
          initiating and terminating DetNet service for the application's IP
          flows.  While the node types differ, there is essentially no
          difference in data plane processing between relay relays and edges.  There
          are likely to be differences in controller plane Controller Plane operation,
          particularly when distributed control plane protocols are used.
        </t>
        <t>
          It is still possible to provide DetNet service protection for
          non-DetNet aware
          non-DetNet-aware end systems. This case is basically the
          same as <xref target="fig_ip_pw_detnet"/>, target="fig_ip_pw_detnet" format="default"/>, with the exception
          that CE1 and CE2 are non-DetNet aware non-DetNet-aware end systems and R1 and R3
          become edge nodes.
        </t>
      </section>

      <section anchor="iom-overview"
               title="DetNet numbered="true" toc="default">
        <name>DetNet IP over DetNet MPLS Encapsulation"> Encapsulation</name>
        <t>
        The basic encapsulation approach is to treat a DetNet IP flow as an app-flow
        App-flow from the DetNet MPLS perspective. The corresponding example
        DetNet
        Sub-Network Sub-network format is shown in <xref
        target="fig_dn_ip_mpls_sn_ex"/>.
        target="fig_dn_ip_mpls_sn_ex" format="default"/>.
        </t>
      <!--
      <t>
        [Editor's note: several proposed changes on the figure.
                Intention is to clarify relationship of the various flows.]
      </t>
      -->

  <figure title="Example anchor="fig_dn_ip_mpls_sn_ex">
          <name>Example DetNet IP over MPLS Sub-Network Formats"
              anchor="fig_dn_ip_mpls_sn_ex"> Sub-network Formats</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[

           /->     +------+  +------+  +------+            ^ ^
           |       |  X   |  |  X   |  |  X   |<- App-Flow App-flow : :
           |       +------+  +------+  +------+            : :
App-Flow
App-flow <-+       |NProto|  |NProto|  |NProto|            : :(1)
 for MPLS  |       +------+  +------+  +------+            : :
           |       |  IP  |  |  IP  |  |  IP  |            : v
           \-> +---+======+--+======+--+======+-----+      :
DetNet-MPLS        | d-CW |  | d-CW |  | d-CW |            :
                   +------+  +------+  +------+            :(2)
                   |Labels|  |Labels|  |Labels|            v
               +---+======+--+======+--+======+-----+
Link/Sub-Network
Link/Sub-network   |  L2  |  | TSN  |  | UDP  |
                   +------+  +------+  +------+
                                       |  IP  |
                                       +------+
                                       |  L2  |
                                       +------+
    (1) DetNet IP Flow (or simply IP flow)
    (2) DetNet MPLS Flow
    ]]>
        </artwork>
]]></artwork>
        </figure>
        <t>
        In <xref target="fig_dn_ip_mpls_sn_ex"/> "App-Flow" target="fig_dn_ip_mpls_sn_ex" format="default"/>, "App-flow"
        indicates the payload carried by the DetNet IP data plane.  "IP" and
        "NProto" indicate the fields described in Section 5.1.1. Sections <xref
        target="RFC8939" sectionFormat="bare"
        section="5.1.1"/> (IP Header Information) and Section 5.1.2. <xref target="RFC8939"
        sectionFormat="bare" section="5.1.2"/> (Other
        Protocol Header Information) of <xref target="I-D.ietf-detnet-ip"/>, target="RFC8939"
        format="default"/>, respectively.

                "App-Flow

                "App-flow for MPLS" indicates that an individual DetNet IP
                flow is the payload from the perspective of the DetNet MPLS
                data plane defined in <xref
        target="I-D.ietf-detnet-mpls"/>. target="RFC8964"
                format="default"/>.
        </t>

        <t>
	    Per Section 5.1 of <xref target="I-D.ietf-detnet-mpls"/>, target="RFC8964" sectionFormat="of" section="5.1"
	    format="default"/>, the DetNet MPLS data plane uses a single
	    S-Label to support a single app flow. App-flow.  DetNet IP Flow
	    Identification Procedures in Section 4.4 of <xref target="I-D.ietf-detnet-ip"/> target="RFC8939"
	    sectionFormat="of" section="5.1" format="default"/> states that a
	    single DetNet flow is identified based on IP, IP- and next level protocol, next-level
	    protocol header information.
        Section 4.4. (Aggregation Considerations) of <xref
        target="I-D.ietf-detnet-ip"/> target="RFC8939"
	    sectionFormat="of" section="4.4" format="default"/> (DetNet Flow
	    Aggregation) defines the ways in which aggregation is supported
	    through the use of prefixes, wildcards, lists, and port ranges.
	    Collectively, this results in the fairly straightforward
	    procedures defined in the next section.
        </t>
        <t>
        As shown in <xref target="fig_ip_pw_detnet"/>, target="fig_ip_pw_detnet" format="default"/>, DetNet relay nodes
        are responsible for the mapping of a DetNet flow, at the service
        sub-layer, from the IP to MPLS DetNet data planes and back
        again. Their related DetNet IP over DetNet MPLS data plane
        operation is comprised of two sets of procedures: the mapping of
        flow identifiers, identifiers and ensuring proper traffic treatment.
        </t>
        <t>
      Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows.
      The six-tuple of IP is mapped to the S-Label in both cases.
      The various fields may be mapped or ignored when going from IP to MPLS.
        </t>
      </section>
    </section>
    <section anchor="iom-proc" title="IP numbered="true" toc="default">
      <name>DetNet IP over DetNet MPLS Procedures"> Procedures</name>
      <t>
        The main differences of mapping IP to DetNet MPLS (compared to plain MPLS) are
		that (1) there is a mandatory flow identification to make the forwarding
		decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet
		Control Word) is mandatory for the MPLS encapsulation encapsulation, and

(3) during forwarding over the DetNet MPLS network DetNet flow specific network, treatment specific to
DetNet flows is needed.
      </t>
      <section anchor="iom-ids"
               title="DetNet numbered="true" toc="default">
        <name>DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures">
 <!--
      <t>
        [Editor's note: several proposed changes to clarify referred
                components. Confusing usage of app-flow terminology.]
      </t>
  -->
        Procedures</name>

        <t>
          A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over
          a DetNet MPLS network
          MUST <bcp14>MUST</bcp14> map a DetNet IP flow, as
          identified in <xref target="I-D.ietf-detnet-ip"/> target="RFC8939" format="default"/>, into a
          single MPLS DetNet flow and MUST <bcp14>MUST</bcp14> process it in
          accordance to the procedures defined in <xref target="I-D.ietf-detnet-mpls"/>. target="RFC8964"
          format="default"/>.  PRF MAY <bcp14>MAY</bcp14> be supported at the MPLS
          level for DetNet IP flows sent over an a DetNet MPLS network.
          Aggregation MAY <bcp14>MAY</bcp14> be supported as defined in <xref
          target="I-D.ietf-detnet-mpls"/> Section 4.4.
          sectionFormat="of" section="4.4" target="RFC8964"
          format="default"/>. Aggregation considerations in <xref target="I-D.ietf-detnet-ip"/> MAY
          target="RFC8939" format="default"/> <bcp14>MAY</bcp14> be used to
          identify an individual DetNet IP flow. The provisioning of the
          mapping of DetNet IP flows to DetNet MPLS flows MUST <bcp14>MUST</bcp14>
          be supported via configuration, e.g., via the controller plane. Controller Plane.
        </t>
        <t>
          A DetNet relay node (egress T-PE) MAY <bcp14>MAY</bcp14> be provisioned
          to handle packets received via the DetNet MPLS data plane as DetNet
          IP flows.  A single incoming DetNet MPLS flow MAY <bcp14>MAY</bcp14> be
          treated as a single DetNet IP flow, without examination of IP
          headers. Alternatively, packets received via the DetNet MPLS data
          plane MAY <bcp14>MAY</bcp14> follow the normal DetNet IP flow
          identification procedures defined in <xref
          target="I-D.ietf-detnet-ip"/> Section 5.1. target="RFC8939"
          sectionFormat="of" section="5.1" format="default"/>.
        </t>
        <t>
          An implementation MUST <bcp14>MUST</bcp14> support the provisioning for
          handling any packet flows received via the DetNet MPLS data plane as
          DetNet IP flows via configuration.  Note that such configuration MAY
          <bcp14>MAY</bcp14> include support from PREOF on the incoming DetNet
          MPLS flow.
        </t>
 <aside>
<t>
          Note: using Layer-4 Using Layer 4 (L4) transport protocols e.g., (e.g., for multipath multipath) are
          out of scope of this document both for a single flow and aggregate
          flows.
</t>
 </aside>
      </section>
      <section anchor="iom-svc"
               title="DetNet numbered="true" toc="default">
        <name>DetNet IP over DetNet MPLS Traffic Treatment Procedures"> Procedures</name>
        <t>
          The traffic treatment required for a particular DetNet IP flow is
          provisioned via configuration or the controller plane. Controller Plane. When a DetNet
          IP flow is sent over DetNet MPLS, a DetNet relay node MUST
          <bcp14>MUST</bcp14> ensure that the provisioned DetNet IP traffic
          treatment is provided at the forwarding sub-layer as described in
          <xref target="I-D.ietf-detnet-mpls"/>
          Section 5.2. target="RFC8964" sectionFormat="of" section="5.2"
          format="default"/>. Note that the PRF function MAY
          <bcp14>MAY</bcp14> be utilized when sending IP over MPLS.
        </t>
        <t>
          Traffic treatment for DetNet IP flows received over the DetNet MPLS
          data plane MUST <bcp14>MUST</bcp14> follow Section 5.3 DetNet <xref target="RFC8939"
          sectionFormat="of" section="5.3" format="default"/> (DetNet IP
          Traffic Treatment Procedures in <xref target="I-D.ietf-detnet-ip"/>. Procedures).
        </t>
      </section>
    </section>

    <!-- ===================================================================== -->

    <section anchor="mc_summary"
             title="Management numbered="true" toc="default">
      <name>Management and Control Information Summary"> Summary</name>
      <t>
        The following summarizes the set of information that is needed to
        support DetNet IP over DetNet MPLS at the MPLS ingress node:
        <list style="symbols">
          <t>
      </t>
      <ul spacing="normal">

<li>

 Each MPLS App-Flow is identified selected from the incoming IP traffic using the IP flow
 identification information as defined in <xref
            target="I-D.ietf-detnet-ip"/>. The target="RFC8939"
 format="default"/>.  This information is summarized in Section 5.1 <xref
 target="RFC8939" sectionFormat="bare" section="5.1"/> of that document, document and
 includes all wildcards, port ranges ranges, and the ability to ignore specific IP
 fields.
          </t>
          <t>

</li>

        <li>
            The DetNet MPLS service that is to be used to send the matching IP
            traffic.  This matching information is provided in <xref
            target="I-D.ietf-detnet-mpls"/> Section 5.1,
            target="RFC8964" sectionFormat="of" section="5.1"
            format="default"/> and includes both service and traffic delivery
            information.
          </t>
        </list>
      </t>
          </li>
      </ul>
      <t>
        The following summarizes the set of information that is needed to
        support DetNet IP over DetNet MPLS at the MPLS egress node:
        <list style="symbols">
          <t>
      </t>
      <ul spacing="normal">
        <li>

	  The S-Label values value that are carrying MPLS over IP identifies the encapsulated App-flow traffic.
          </t>
          <t>

          </li>
        <li>
            For each S-Label, how the received traffic is to be handled. The
            traffic may be processed according as any other DetNet IP traffic as defined
            in this document or in <xref
            target="I-D.ietf-detnet-ip"/>, target="RFC8939" format="default"/>,
            or the traffic may be directly treated as an MPLS App-flow for
            additional processing according to <xref
            target="I-D.ietf-detnet-mpls"/>.
          </t>
        </list>
      </t> target="RFC8964"
            format="default"/>.
          </li>
      </ul>
      <t>
        It is the responsibility of the DetNet controller plane Controller Plane to
        properly provision both flow identification information and
        the flow-specific resources needed to provide the traffic
        treatment to meet each flow's service requirements.
        This applies for aggregated and individual flows.
      </t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
       General security
       considerations for DetNet are described in detail in <xref
               target="I-D.ietf-detnet-security"/>. target="RFC9055" format="default"/>.
       DetNet MPLS and DetNet IP security considerations equally apply to this document and
       are described in <xref target="I-D.ietf-detnet-mpls"/> target="RFC8964" format="default"/>
       and <xref target="I-D.ietf-detnet-ip"/>. target="RFC8939" format="default"/>.
      </t>
      <t>
       Security aspects which that are unique to DetNet are those whose aim is to
       protect the support of specific quality of service quality-of-service aspects of DetNet, which are
       primarily to deliver data flows with extremely low packet loss rates
       and bounded end-to-end delivery latency.
      </t>
      <t>
        The primary considerations for the data plane are 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 using MACSec MACsec <xref target="IEEE802.1AE-2018"/> target="IEEE802.1AE-2018"
        format="default"/> for IP over Ethernet (Layer-2) IP-over-Ethernet (Layer 2) flows.
      </t>
      <t>
        From a data plane perspective perspective, this document does not add or modify any
        header information.
      </t>
      <t>
        At the management and control level level, 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 DetNet, which 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, for example example,
        through the use of existing mechanism 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, for example
        man-in-the-middle attacks (for example, through use of authentication
        and authorization of devices within the DetNet domain. 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. actions.
      </t>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>

      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>

        <reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org/document/8585421">
          <front>
            <title>IEEE Standard for Local and metropolitan area
            networks-Media Access Control (MAC) Security</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="December" year="2018"/>
          </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
<refcontent>IEEE 802.1AE-2018</refcontent>
        </reference>

      </references>
    </references>

    <section anchor="acks" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <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 <contact fullname="Pat Thaler"/>, <contact
 fullname="Norman 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 Carlos
 <contact fullname="Carlos J. Bernardos Bernardos"/> for their various contributions to
 this work.

      </t>
    </section>
    <section anchor="contrib" title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>
        RFC7322
        RFC 7322 limits the number of authors listed on the front page of
        a draft to a
        maximum of 5. The editor wishes to thank and acknowledge the follow following
        authors for contributing text to this
        draft. document.
      </t>
      <figure> <artwork><![CDATA[
   Janos Farkas
   Ericsson
   Email: janos.farkas@ericsson.com

   Andrew

 <author fullname="János Farkas" initials="J." surname="Farkas">
      <organization>Ericsson</organization>
      <address>
        <email>janos.farkas@ericsson.com</email>
      </address>
 </author>

 <author fullname="Andrew G. Malis
   Malis Consulting
   Email: agmalis@gmail.com
   ]]></artwork>
      </figure>
<!--    </section> --> Malis" initials="A. G." surname="Malis">
      <organization>Malis Consulting</organization>
      <address>
        <email>agmalis@gmail.com</email>
      </address>
 </author>

      <t>
        Janos Farkas
        <contact fullname="János Farkas"/> contributed substantially to the content of this
        document.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative references">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8655"?>
      <?rfc include="reference.I-D.ietf-detnet-data-plane-framework"?>
          <?rfc include="reference.I-D.ietf-detnet-mpls'?>
      <?rfc include="reference.I-D.ietf-detnet-ip'?>
      <?rfc include="reference.I-D.ietf-detnet-security"?>
        </references>

    <references title="Informative references">
      <?rfc include="reference.RFC.4301"?>
      <reference anchor="IEEE802.1AE-2018"
      target="https://ieeexplore.ieee.org/document/8585421">
      <front>
        <title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>
        <author>
          <organization>IEEE Standards Association</organization>
        </author>
        <date year="2018" />
      </front>
    </reference>

    </references>

  </back>
</rfc>