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

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

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-flow-information-model-14" ipr="trust200902">

<!-- ***** FRONT MATTER ***** number="9016" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->

<front>
    <title abbrev="DetNet Flow Information Model">DetNet Flow Model">Flow and Service Information Model</title> Model for Deterministic Networking (DetNet)</title>
    <seriesInfo name="RFC" value="9016"/>
    <author fullname="Bal&aacute;zs fullname="Balázs Varga" initials="B." surname="Varga">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar tudosok korutja 11</street> 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 korutja 11</street> Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>janos.farkas@ericsson.com</email>
      </address>
    </author>
    <author fullname="Rodney Cummings" initials="R." surname="Cummings">
      <organization>National Instruments</organization>
      <address>
        <postal>
          <street>11500 N. Mopac Expwy</street>
         <street>Bldg. C</street>
             <city>Austin, TX</city>
         <country>USA</country>
	  <extaddr>Bldg. C</extaddr>
          <city>Austin</city>
          <region>TX</region>
          <country>United States of America</country>
          <code>78759-3504</code>
        </postal>
        <email>rodney.cummings@ni.com</email>
      </address>
    </author>
    <author fullname="Yuanlong Jiang" initials="Y." surname="Jiang">
   <organization>Huawei Technologies Co., Ltd.</organization>
      <organization abbrev="Huawei">Huawei</organization>
      <address>
        <postal>
          <street>Bantian, Longgang district</street>
         <street> </street>
          <city>Shenzhen</city>
          <country>China</country>
          <code>518129</code>
        </postal>
        <email>jiangyuanlong@huawei.com</email>
      </address>
    </author>
    <author fullname="Don Fedyk" initials="D." surname="Fedyk">
   <organization>LabN
      <organization abbrev="LabN Consulting">LabN Consulting, L.L.C.</organization>
      <address>
        <email>dfedyk@labn.net</email>
      </address>
    </author>
    <date year="2021" month="March" />
    <area>Routing</area>
    <workgroup>DetNet</workgroup>

<keyword>DetNet, Flow
    <keyword>DetNet</keyword>
    <keyword>Flow and Service Information Model</keyword>
    <abstract>
      <t>This document describes the flow and service information model for Deterministic Networking (DetNet).
        These models are defined for IP and MPLS DetNet data planes</t> planes.</t>
    </abstract>
  </front>

<!-- ***** MIDDLE MATTER ***** -->
<middle>

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++              INTRODUCTION               +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        Deterministic Networking (DetNet) provides a capability 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 Detnet Flow DetNet flow and Service Information Model. service information model.
        For reference reference, <xref target="RFC3444"/> target="RFC3444" format="default"/> describes the rationale behind Information
	Models information
	models in general. This document describes the Flow flow and Service service information
	models for operators and users to understand Detnet services, DetNet services and for implementors
        as a guide to the functionality required by Detnet DetNet services.
      </t>
      <t>
        The DetNet Architecture architecture treats the DetNet related DetNet-related data plane functions
        decomposed 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 provides
        resource allocation (to ensure low loss, assured latency, and limited
        out-of-order delivery) and leverages Traffic Engineering traffic engineering mechanisms.
      </t>
      <t>
        DetNet service utilizes IP or MPLS MPLS, and DetNet is currently
        defined for IP and MPLS networks networks, as shown in Figure 1 based on
	<xref target="dn_svc_encaps" format="default"/>, which is a reprint of Figure 2
        and Figure 3 of
        from <xref target="RFC8938"/>. target="RFC8938" format="default"/>.
        IEEE 802.1 Time Sensitive Time-Sensitive Networking (TSN) utilizes Ethernet and
        is defined over Ethernet networks.  A DetNet flow includes one or more
        App-flow(s)
        application-level flow (App-flow) as payload. App-flows can be Ethernet, MPLS, or IP flows,
        which impacts which header fields are utilized to identify a flow.
        DetNet flows are identified by the DetNet encapsulation of App-flow(s) (e.g.,
        MPLS labels, IP 6-tuple 6-tuples, etc.). In some scenarios scenarios, App-flow and DetNet
        flow look similar on the wire (e.g., L3 Layer 3 (L3) App-flow over a DetNet IP
        network).  </t>
      <figure anchor="dn_svc_encaps" align="center"
        title="DetNet anchor="dn_svc_encaps">
        <name>DetNet Service Examples as per Data Plane Framework"> Framework</name>
<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                          +-----+
                          | TSN |
     +-------+          +-+-----+-+
     | DN IP |          | DN MPLS |
  +--+--+----+----+   +-+---+-----+-+
  | TSN | DN MPLS |   | TSN | DN IP |
  +-----+---------+   +-----+-------+
]]></artwork>
      </figure>
      <t>
        As shown in <xref target="dn_svc_encaps"/> target="dn_svc_encaps" format="default"/> and as per described in
	<xref
                target="RFC8938"/> target="RFC8938" format="default"/>, a DetNet flow
        can be treated as an application level flow (App-flow) App-flow, e.g., at DetNet
        flow aggregation or in a sub-network that interconnects DetNet nodes.
      </t>
      <t>
        The DetNet flow and service information model provided by this document
        contains both DetNet flow DetNet-flow- and App-flow specific App-flow-specific information in an
        integrated fashion.
      </t>
      <t>In a given network scenario scenario, three information models can be distinguished:

    <list style="symbols">

    <t>
      </t>
      <ul spacing="normal">
        <li>
        Flow information models that describe characteristics of data flows. These models
        describe
        describe, in detail detail, all relevant aspects of a flow that are needed to
        support the flow properly by the network between the source and the
        destination(s).
     </t>
        <t>
     </li>
        <li>
        Service information models that describe characteristics of services being provided
        for data flows over a network. These models can be treated as a an information model that is
	network operator independent information model.
       </t>
        <t> independent.
       </li>
        <li>
        Configuration information models that describe describe, in detail detail, the settings required on
        network nodes to provide proper service to a data flow proper service.
       </t>
       </list>
       </t> flow.
       </li>
      </ul>
      <t>
         Service and flow information models are used between the user and the
         network operator. Configuration information models are used between
         the management/control plane entity of the network and the network
         nodes. They are shown in <xref target="fig_infomodels"/>. target="fig_infomodels" format="default"/>.
      </t>
      <figure title="Usage anchor="fig_infomodels">
        <name>Usage of Information models (flow, service Models (Flow, Service, and configuration)" anchor="fig_infomodels">
<artwork><![CDATA[ Configuration)</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
   User                  Network Operator
           flow/service
    /\      info model    +---+
   /  \ <---------------> | X |    management/control
   ----                   +-+-+       plane entity
                            ^
                            |   configuration
                            |     info model
                     +------------+
                     v      |     |
                    +-+     |     v  Network  network
                    +-+     v    +-+  nodes
                           +-+   +-+
                           +-+
]]></artwork>
      </figure>
      <t>
        The DetNet flow and service information model is based on <xref
                target="RFC8655"/> target="RFC8655"
	format="default"/> and on the concept of the
        data model specified by <xref target="IEEE8021Qcc"/>.
		<!-- Furthermore, the
		DetNet flow and service information models described in this document
		are based on <xref target="IEEE8021Qcc"/>. --> target="IEEE8021Qcc" format="default"/>.
		In addition to
        the TSN data model, <xref target="IEEE8021Qcc"/> target="IEEE8021Qcc" format="default"/> also specifies
        configuration of TSN features (e.g., traffic scheduling specified by
        <xref target="IEEE8021Qbv"/>). target="IEEE8021Qbv" format="default"/>). The common architecture and flow
        model, information
        model allow configured features to be consistent in certain deployment
        scenarios, e.g., when the network that provides the DetNet service
        includes both L3 and L2 network segments.
      </t>
      <section title="Goals"> numbered="true" toc="default">
        <name>Goals</name>
        <t>
          As expressed in the DetNet WG Charter <xref target="IETFDetNet"/> Charter, target="IETFDetNet" format="default"/>, the DetNet
          WG collaborates with IEEE 802.1 TSN in order to define a common
          architecture for both Layer Layers 2 and Layer 3. This is beneficial for
          several reasons, e.g., in order to simplify implementations and
          maintain consistency across diverse networks. The flow and service
          information models are also aligned for those reasons. Therefore, the
          DetNet flow and service information models described in this document
          are based on <xref target="IEEE8021Qcc"/>, target="IEEE8021Qcc" format="default"/>, which is an amendment to
          <xref target="IEEE8021Q"/>.</t> target="IEEE8021Q" format="default"/>.</t>
        <t>
               This document specifies flow and service information models only.
        </t>
      </section>
      <section title="Non Goals"> numbered="true" toc="default">
        <name>Non-Goals</name>
        <t>
           This document does not specify flow data models or
           DetNet configuration. Therefore, the goals of this document
           differ from the goals of <xref target="IEEE8021Qcc"/>, target="IEEE8021Qcc" format="default"/>, which also
           specifies the TSN data model and configuration of certain TSN features.
        </t>
        <t>The DetNet specific DetNet-specific YANG data model is described in
		   <xref target="I-D.ietf-detnet-yang"/>. target="I-D.ietf-detnet-yang" format="default"/>.
        </t>
      </section>
    </section>

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++       CONFORMANCE CONVENTIONS           +++++++ -->
<!-- +++++++             TERMINOLOGY                 +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
 <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <section title="Terms 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 the DetNet Data Plane
   Framework data plane
   framework <xref target="RFC8938"/>. target="RFC8938" format="default"/>. The reader
   is assumed to be familiar with these documents and any terminology defined
   therein.  The DetNet &lt;=&gt; TSN dictionary of <xref
           target="RFC8655"/> target="RFC8655" format="default"/> is used to perform
   translation from <xref target="IEEE8021Qcc"/> target="IEEE8021Qcc" format="default"/> to this document.
        </t>
        <t>
   The following terminology is used in accordance with <xref target="RFC8655"/>:
   <list style="hanging" hangIndent="14">
     <t hangText="App-flow"> target="RFC8655" format="default"/>:
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>App-flow</dt>
          <dd>
       The payload (data) carried over a DetNet service.
     </t>
     <t hangText="DetNet flow">
     </dd>
          <dt>DetNet flow</dt>
          <dd>
           A DetNet flow is a sequence of packets which that conform uniquely
           to a flow identifier, identifier and to which the DetNet service is to
           be provided.  It includes any DetNet headers added to support
           the DetNet service and forwarding sub-layers.
     </t>
    </list>
   </t>

  <t>
   The
     </dd>
        </dl>
        <t>The following terminology is introduced in this document:
   <list style="hanging" hangIndent="14">
     <t hangText="Source"> document:</t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>Source</dt>
          <dd>
            Reference point for an App-flow, where the flow starts.
     </t>

     <t hangText="Destination">
     </dd>
          <dt>Destination</dt>
          <dd>
            Reference point for an App-flow, where the flow terminates.
     </t>

     <t hangText="DN Ingress">
     </dd>
          <dt>DN Ingress</dt>
          <dd>
            Reference point for the start of a DetNet flow. Networking
            technology specific technology-specific
	    encapsulation may be added here to the served App-flow(s).
     </t>

     <t hangText="DN Egress">
     </dd>
          <dt>DN Egress</dt>
          <dd>
            Reference point for the termination end of a DetNet flow. Networking
            technology specific technology-specific
	    encapsulation may be removed here from the served App-flow(s).
     </t>

    </list>
   </t>
     </dd>
        </dl>
      </section>
      <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="DetNet">Deterministic Networking.</t>
    <t hangText="DN">DetNet.</t>
    <t hangText="MPLS">Multiprotocol
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>DetNet</dt>
          <dd>Deterministic Networking</dd>
          <dt>DN</dt>
          <dd>DetNet</dd>
          <dt>MPLS</dt>
          <dd>Multiprotocol Label Switching.</t>
    <t hangText="PSN">Packet Switching</dd>
          <dt>PSN</dt>
          <dd>Packet Switched Network.</t>
    <t hangText="TSN">Time-Sensitive Networking.</t>
   </list>
  </t> Network</dd>
          <dt>TSN</dt>
          <dd>Time-Sensitive Networking</dd>
        </dl>
      </section>
      <section title="Naming Conventions"> numbered="true" toc="default">
        <name>Naming Conventions</name>
        <t>
        The following naming conventions were used for naming information model
        components in this document. It is recommended that extensions of the
        model use the same conventions.

        <list style="symbols">
        <t>Descriptive

        </t>
        <ul spacing="normal">
          <li>Descriptive names are used.</t>
        <t>Names used.</li>
          <li>Names start with uppercase letters.</t>
        <t> letters.</li>
          <li>
        Composed names use capital letters for the first letter of each
        component. All other letters are lowercase, even for acronyms. abbreviations.
        Exceptions are made for acronyms abbreviations containing a mixture of lowercase and
        capital letters, such as IPv6. Example composed names are SourceMacAddress and
        DestinationIPv6Address.  </t>
        </list>
        </t>  </li>
        </ul>
      </section>
    </section>  <!-- end of terminology -->

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++          DETNET DOMAIN MODELING         +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec_modeling" title="DetNet numbered="true" toc="default">
      <name>DetNet Domain and its Modeling"> Its Modeling</name>
      <section anchor="sec_soverview" title="DetNet numbered="true" toc="default">
        <name>DetNet Service Overview"> Overview</name>
        <t>
          The DetNet service can be defined as a service that provides a
          capability to carry a unicast or a multicast data flow for an
          application with constrained requirements on network performance,
          e.g., low packet loss rate and/or latency.
        </t>
        <t>
          Figure
          Figures 5 and Figure 8 in <xref
                  target="RFC8655"/> target="RFC8655" format="default"/> show the
	  DetNet
          service related service-related reference points and main components.
        </t>
      </section>
      <section anchor="sec_srefpoints" title="Reference numbered="true" toc="default">
        <name>Reference Points Used in Modeling"> Modeling</name>
        <t>
          From service design perspective a service-design perspective, a fundamental question is the
          location of the service/flow endpoints, i.e., where the service/flow
          starts and ends.
        </t>
        <t>
          App-flow specific
          App-flow-specific reference points are the Source source (where it starts)
          and the Destination destination (where it terminates). Similarly Similarly, a DetNet flow
          has reference points termed DN Ingress "DN Ingress" (where a DetNet flow starts) and DN
          Egress "DN
          Egress" (where a DetNet flow ends). These reference points may coexist in the
          same node (e.g., in a DetNet IP end system). DN Ingress and DN Egress
          reference points are intermediate reference points for a served
          App-flow.
        </t>
        <t>
          All
          In this document, all reference points are assumed in this document to be packet-based
          reference points. A DN Ingress may add and a DN Egress may remove
          networking technology specific technology-specific encapsulation to/from the served
          App-flow(s) (e.g., MPLS label(s), UDP UDP, and IP headers).
        </t>
      </section>
      <section anchor="sec_sinfoelements" title="Information Elements"> numbered="true" toc="default">
        <name>Information Elements</name>
        <t>
         The DetNet flow information model and the service information model relies rely on
         three groups of information elements:
         <list style="symbols">
         <t>
           App-flow related parameters: these
        </t>
        <dl newline="false" spacing="normal">
          <dt>App-flow-related parameters:</dt>
	  <dd>These describe the App-flow
           characteristics (e.g., identification, encapsulation, traffic
           specification, endpoints, status, etc.) and the App-flow
           service expectations (e.g., delay, loss, etc.).
         </t>
         <t>
           DetNet flow related parameters: these etc.).</dd>
          <dt>DetNet flow-related parameters:</dt>
	  <dd>These describe the DetNet flow
           characteristics (e.g., identification, format, traffic
           specification, endpoints, rank, etc.).
         </t>
         <t>
           DetNet service related parameters: these etc.).</dd>
          <dt>DetNet service-related parameters:</dt>
	  <dd>These describe the expected
           service characteristics (e.g., delivery type, connectivity
           delay/loss, status, rank, etc.).
          </t>
         </list>
        </t> etc.).</dd>
        </dl>
        <t>
          In the information model model, a DetNet flow contains one or more (aggregated) App-flows
          (N:1 mapping). During DetNet aggregation aggregation, the aggregated DetNet flows
          are treated simply as App-flows and the aggregate is the DetNet flow, which
          provides N:1 mapping. Similarly, there is an aggregated many to one many-to-one relationship for
          the DetNet flow(s) to the DetNet Service. service.
        </t>
      </section>
    </section> <!-- end detnet domain modeling -->

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++                APP-FLOW                 +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec_appflow" title="App-flow Related Parameters"> numbered="true" toc="default">
      <name>App-Flow-Related Parameters</name>
      <t>
        When Deterministic DetNet service is required by time/loss sensitive time-/loss-sensitive
        application(s) running on an end system during communication with its
        peer(s), the resulting data exchange has various requirements on delay
        and/or loss parameters.
      </t>
      <section anchor="sec_appflowchar" title="App-flow Characteristics"> numbered="true" toc="default">
        <name>App-Flow Characteristics</name>
        <t>App-flow characteristics are described by the following parameters:
           <list style="symbols">
              <t>FlowID: a
        </t>
        <dl  newline="false" spacing="normal" indent="14">
          <dt>FlowID:</dt>
	  <dd>a unique (management) identifier of the App-flow.
                  It App-flow, which can be used
	  to define the N:1 mapping of App-flows to a DetNet flow.</t>
              <t>FlowType: set flow</dd>
          <dt>FlowType:</dt>
	  <dd>set by the encapsulation format of the flow.
                  It flow, which can be Ethernet
	  (TSN), MPLS, or IP.</t>
              <t>DataFlowSpecification: a IP</dd>
          <dt>DataFlowSpecification:</dt>
	  <dd>a flow descriptor, defining which packets
                  belongs to a flow, using specific packet header fields fields, such as
                  src-addr, dst-addr, label, VLAN-ID, etc.</t>
              <t>TrafficSpecification: a etc.</dd>
          <dt>TrafficSpecification:</dt>
	  <dd>a flow descriptor, defining traffic
                 parameters
                 parameters, such as packet size, transmission time
                 interval, and maximum packets per time interval.</t>
              <t>FlowEndpoints: delineate interval</dd>
          <dt>FlowEndpoints:</dt>
	  <dd>delineates the start and termination end reference
                 points of the App-flow by pointing to the source
                 interface/node and destination interface(s)/node(s).</t>
              <t>FlowStatus: indicates interface(s)/node(s)</dd>
          <dt>FlowStatus:</dt>
	  <dd>indicates the status of the App-flow with respect to
                 the establishment of the flow by the connected network, e.g.,
                 ready, failed, etc.</t>
              <t>FlowRank: indicates etc.</dd>
          <dt>FlowRank:</dt>
	  <dd>indicates the rank of this flow relative to other
                 flows in the connected network.</t>
            </list>
        </t>
        <t>
		  Note: network</dd>
        </dl>
	<aside>
          <t>Note: When defining the N:1 mapping of App-flows to a DetNet flow,
		  the App-flows must have the same FlowType and different
		  DataFlowSpecification parameters
        </t> parameters.</t>
	</aside>
      </section>
      <section anchor="sec_appflowreq" title="App-flow Requirements"> numbered="true" toc="default">
        <name>App-Flow Requirements</name>
        <t>App-flow requirements are described by the following parameters:
           <list style="symbols">
              <t>FlowRequirements: defines
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>FlowRequirements:</dt>
	  <dd>defines the attributes of the App-flow regarding
                  bandwidth, latency, latency variation, loss, and misordering tolerance.</t>
              <t>FlowBiDir: defines tolerance</dd>
          <dt>FlowBiDir:</dt>
	  <dd>defines the data path requirement of the App-flow
                 whether it must share the same data path and physical
                 path for both directions through the network, e.g., to
                 provide congruent paths in the two directions. </t>
           </list>
           </t> directions</dd>
        </dl>
      </section>
    </section> <!-- end App-flow modeling -->

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++              DETNET-FLOW                +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec_dnflow" title="DetNet Flow Related Parameters"> numbered="true" toc="default">
      <name>DetNet Flow-Related Parameters</name>
      <t>
        The Data data model specified by <xref target="IEEE8021Qcc"/> target="IEEE8021Qcc" format="default"/> describes data
        flows using TSN service as periodic flows with fixed packet size (i.e.,
        Constant Bit Rate Bitrate (CBR) flows) or with variable packet size. The same
        concept is applied for flows using DetNet service.
      </t>
      <t>
        Latency and loss parameters are correlated because the effect of late
        delivery can result in data loss for an application. However, not all
        applications require hard limits on both latency and loss.
        For example, some real-time applications allow graceful degradation if
        loss happens (e.g., sample-based data processing, processing and media distribution). Some
        other applications may require high-bandwidth connections that make use of
        packet replication techniques which that are economically challenging or even
        impossible. Some applications may not tolerate loss, loss but are not
        delay sensitive (e.g., bufferless sensors). Time Time- or loss sensitive loss-sensitive
        applications may have somewhat special requirements requirements, especially for loss
        (e.g., no loss over two consecutive communication cycles; cycles, very low outage
        time, etc.).</t>

<?rfc subcompact="yes" ?>
      <t>DetNet flows have the following attributes:
                <list style="letters">
                <t>DnFlowID
      </t>
      <ol spacing="compact" type="a">
	<li>DnFlowID (<xref target="sec_dnflowid"/>)</t>
                <t>DnPayloadType target="sec_dnflowid" format="default"/>)</li>
        <li>DnPayloadType (<xref target="sec_dnpayloadtype"/>)</t>
                <t>DnFlowFormat target="sec_dnpayloadtype" format="default"/>)</li>
        <li>DnFlowFormat (<xref target="sec_dnflowformat"/>)</t>
                <t>DnFlowSpecification target="sec_dnflowformat" format="default"/>)</li>
        <li>DnFlowSpecification (<xref target="sec_dnflowspec"/>)</t>
                <t>DnTrafficSpecification target="sec_dnflowspec" format="default"/>)</li>
        <li>DnTrafficSpecification (<xref target="sec_dntrafficspec"/>)</t>
                <t>DnFlowEndpoints target="sec_dntrafficspec" format="default"/>)</li>
        <li>DnFlowEndpoints (<xref target="sec_dnflowendp"/>)</t>
                <t>DnFlowRank target="sec_dnflowendp" format="default"/>)</li>
        <li>DnFlowRank (<xref target="sec_dnflowrank"/>)</t>
                <t>DnFlowStatus target="sec_dnflowrank" format="default"/>)</li>
        <li>DnFlowStatus (<xref target="sec_dnflowstatus"/>)</t>
                </list>
        </t> target="sec_dnflowstatus" format="default"/>)</li>
      </ol>
      <t>DetNet flows have the following requirement attributes:
             <list style="symbols">
                <t>DnFlowRequirements
      </t>
      <ol spacing="compact" type="a">
        <li>DnFlowRequirements (<xref target="sec_dnflowreq"/>)</t>
                <t>DnFlowBiDir target="sec_dnflowreq" format="default"/>)</li>
        <li>DnFlowBiDir (<xref target="sec_dnflowbidir"/>)</t>
                </list>
        </t> target="sec_dnflowbidir" format="default"/>)</li>
      </ol>
      <t>Flow attributes are described in the following sections.</t>
      <section anchor="sec_dnflowid" title="Management numbered="true" toc="default">
        <name>Management ID of the DetNet Flow"> Flow</name>
        <t>A unique (management) identifier is needed for each DetNet flow within the
        DetNet domain. It is specified by DnFlowID. It can be used to define the N:1
        mapping of DetNet flows to a DetNet service.</t>
      </section>
      <section anchor="sec_dnpayloadtype" title="Payload type numbered="true" toc="default">
        <name>Payload Type of the DetNet Flow"> Flow</name>
        <t>The DnPayloadType attribute is set according to the encapsulated App-flow format.
        The attribute can be Ethernet, MPLS, or IP.</t>
      </section>
      <section anchor="sec_dnflowformat" title="Format numbered="true" toc="default">
        <name>Format of the DetNet Flow"> Flow</name>
        <t>The DnFlowFormat attribute is set according to the DetNet PSN technology.
        The attribute can be MPLS or IP.</t>
      </section>
      <section anchor="sec_dnflowspec" title="Identification numbered="true" toc="default">
        <name>Identification and Specification of DetNet Flows"> Flows</name>
        <t>Identification options for DetNet flows at the Ingress/Egress and within the DetNet
          domain are specified as follows; see <xref target="sec_flowspecmpls"/> target="sec_flowspecmpls" format="default"/> for
          DetNet MPLS flows and <xref target="sec_flowspecip"/> target="sec_flowspecip" format="default"/> for DetNetw DetNet IP flows.</t>

<!-- +++++++ DETNET MPLS FLOW ID & SPEC +++++++ -->
      <section anchor="sec_flowspecmpls" title="DetNet numbered="true" toc="default">
          <name>DetNet MPLS Flow Identification and Specification"> Specification</name>
          <t>
          The identification of DetNet MPLS flows within the DetNet domain is
          based on the MPLS context in the service information model. The
          attributes are specific to the MPLS forwarding paradigm within the
          DetNet domain <xref target="I-D.ietf-detnet-mpls"/>. target="RFC8964" format="default"/>.  DetNet MPLS
          flows can be identified and specified by the following attributes:
          <list style="letters">
                   <t>SLabel</t>
                   <t>FLabelStack</t>
                    </list>
          </t>
          <ol spacing="compact" type="a">
	    <li>SLabel</li>
            <li>FLabelStack</li>
          </ol>
        </section>
<!-- +++++++ DETNET IP FLOW ID & SPEC +++++++ -->
      <section anchor="sec_flowspecip" title="DetNet numbered="true" toc="default">
          <name>DetNet IP Flow Identification and Specification"> Specification</name>
          <t>DetNet IP flows can be identified and specified by the following attributes
          <xref target="RFC8939"/>:
                <list style="letters">
                   <t>SourceIpAddress</t>
                   <t>DestinationIpAddress</t>
                   <t>IPv6FlowLabel</t>
                   <t>Dscp (attribute)</t>
                   <t>Protocol</t>
                   <t>SourcePort</t>
                   <t>DestinationPort</t>
                   <t>IPSecSpi</t>
                    </list> target="RFC8939" format="default"/>:
          </t>
          <ol spacing="compact" type="a">
	    <li>SourceIpAddress</li>
            <li>DestinationIpAddress</li>
            <li>IPv6FlowLabel</li>
            <li>Dscp</li>
            <li>Protocol</li>
            <li>SourcePort</li>
            <li>DestinationPort</li>
            <li>IPSecSpi</li>
          </ol>
          <t>The IP 6-tuple that is used for DetNet IP flow identification consists
			 of items a, b, d, e, f, and g.  Items c and h are additional attributes
			 that can be used for DetNet flow identification in addition to the 6-tuple.
			 The 6-tuple and use of wild cards for these attributes are specified in
			 <xref target="RFC8939"/>. target="RFC8939" format="default"/>.
          </t>
        </section>
      </section> <!-- +++++++ FLOW SPEC +++++++ -->
<?rfc subcompact="no" ?>

<!-- +++++++ TRAFFIC SPEC +++++++ -->
   <section anchor="sec_dntrafficspec" title="Traffic numbered="true" toc="default">
        <name>Traffic Specification of the DetNet Flow">
      <t>DnTrafficSpecification Flow</name>
        <t>The DnTrafficSpecification attributes specify how the DN Ingress transmits packets
	for the DetNet flow.
          This is effectively the promise/request of the DN Ingress to the network. The network uses
          this traffic specification to allocate resources and adjust queue parameters in network
          nodes.</t>
        <t>TrafficSpecification has the following attributes:
            <list style="letters">
                <t>
        </t>
        <ol spacing="normal" type="a">
	  <li>
	          Interval: the period of time in which the traffic
                  specification is specified.
                </t>
                <t> specified
                </li>
          <li>
                  MaxPacketsPerInterval: the maximum number of packets that the
                  Ingress will transmit in one Interval.
                </t>
                <t> Interval
                </li>
          <li>
                  MaxPayloadSize: the maximum payload size that the Ingress
                  will transmit.
                </t>
                <t> transmit
                </li>
          <li>
                  MinPayloadSize: the minimum payload size that the Ingress
				  will transmit.
                </t>
                <t> transmit
                </li>
          <li>
                  MinPacketsPerInterval: the minimum number of packets that the
				  Ingress will transmit in one Interval.
                </t>
             </list>
          </t> Interval
                </li>
        </ol>
        <t>
          These attributes can be used to describe any type of traffic (e.g.,
          CBR, VBR, Variable Bitrate (VBR), etc.) and can be used during resource allocation to
          represent worst case worst-case scenarios. Intervals are specified as an integer
		  number of nanoseconds. PayloadSizes are specified in octets.
        </t>
        <t>
		  Flows exceeding the traffic specification (i.e., having more traffic
		  than defined by the maximum attributes) may receive a different
		  network behavior than the DetNet network has been engineered for.
		  Excess traffic due to malicious or malfunctioning devices can be
		  prevented or mitigated (e.g., through the use of existing mechanisms mechanisms,
		  such as policing and shaping).
        </t>
        <t>
          When MinPayloadSize and MinPacketsPerInterval parameters are used,
		  then
		  all packets less than the MinPayloadSize will be counted as
		  being of the size MinPayloadSize during packet processing when
		  packet size matters, e.g., when policing; and all flows having less
		  than MinPacketsPerInterval will be counted as having
		  MinPacketsPerInterval when the number of packets per interval
		  matters, e.g., during resource reservation. However, flows having
		  less than MinPacketsPerInterval may result in a different network
		  behavior than the DetNet network has been engineered for.
		  MinPayloadSize and MinPacketsPerInterval parameters, for example,
		  may be used when engineering the latency bounds of a DetNet flow
		  when POF Packet Ordering Function (POF) is applied to the given DetNet flow.
        </t>
        <t> Further optional
          attributes can be considered to achieve more efficient resource allocation.
          Such optional attributes might be worth for flows with soft requirements (i.e.,
          the flow is only loss sensitive or only delay sensitive, sensitive but not both
          delay-and-loss
          delay and loss sensitive). Possible options about how to extend
          DnTrafficSpecification attributes is for further discussion.
        </t>
      </section> <!-- +++++++ TRAFFIC SPEC +++++++ -->
   <section anchor="sec_dnflowendp" title="Endpoints numbered="true" toc="default">
        <name>Endpoints of the DetNet Flow"> Flow</name>
        <t>
        The DnFlowEndpoints attribute defines the starting start and termination end
        reference points of the DetNet flow by pointing to the ingress
        interface/node and egress interface(s)/node(s). Depending on the
        network scenario scenario, it defines an interface or a node. Interface can be
        defined
        defined, for example example, if the App-flow is a TSN Stream Stream, and it is received
        over a well defined UNI (User-to-Network Interface). well-defined User-to-Network Interface (UNI). For example, for App-flows with MPLS
        encapsulation
        encapsulation, defining an ingress node is more common when per platform a per-platform
        label space is used.
        </t>
      </section>
      <section anchor="sec_dnflowrank" title="Rank numbered="true" toc="default">
        <name>Rank of the DetNet Flow"> Flow</name>
        <t>
       The DnFlowRank attribute provides the rank of this flow relative to other flows in the
       DetNet domain.  Rank (range: 0-255) is used by the DetNet domain to
       decide which flows can and cannot exist when network resources reach
       their limit. Rank is used to help to determine which flows can be
       bumped (i.e., removed from node configuration thereby releasing its
       resources) if if, for example example, a port of a node becomes oversubscribed (e.g.,
       due to network re-configuration). reconfiguration). DnFlowRank value 0 is the highest priority.
        </t>
      </section>
      <section anchor="sec_dnflowstatus" title="Status numbered="true" toc="default">
        <name>Status of the DetNet Flow">
        <t>DnFlowStatus Flow</name>
        <t>The DnFlowStatus attribute provides the status of the DetNet flow with respect to the
        establishment of the flow by the DetNet domain. </t>

<?rfc subcompact="yes" ?>
        <t>The DnFlowStatus
        <t>DnFlowStatus includes the following attributes:
                <list style="letters">
        </t>
        <ol spacing="normal" type="a"><li>
            <t>
                  DnIngressStatus is an enumeration for the status of the
                  flow&acute;s
                  flow's Ingress reference point:
                  <list style="symbols">
                      <t>None: no Ingress.</t>
                      <t>Ready: Ingress is ready.</t>
                      <t>Failed: Ingress failed.</t>
                      <t>OutOfService: Administratively blocked.</t>
<?rfc subcompact="no" ?>
                 </list>
            </t>
            <dl newline="false" spacing="compact">
              <dt>None:</dt> <dd>No Ingress.</dd>
              <dt>Ready:</dt> <dd>Ingress is ready.</dd>
              <dt>Failed:</dt> <dd>Ingress failed.</dd>
              <dt>OutOfService:</dt> <dd>Administratively blocked.</dd>
            </dl>
          </li>
          <li>
            <t>
                    DnEgressStatus is an enumeration for the status of the
                    flow&acute;s
                    flow's Egress reference points:
                    <list style="symbols">
<?rfc subcompact="yes" ?>
                      <t>None: no Egress.</t>
                      <t>Ready: all
            </t>
            <dl newline="false" spacing="compact">
              <dt>None:</dt> <dd>No Egress.</dd>
              <dt>Ready:</dt> <dd>All Egresses are ready.</t>
                      <t>PartialFailed: One ready.</dd>
              <dt>PartialFailed:</dt> <dd>One or more Egress is ready, and one or
                         more Egress failed.  The DetNet flow can be used
                         if the Ingress is Ready.</t>
                      <t>Failed: All Ready.</dd>
              <dt>Failed:</dt> <dd>All Egresses failed.</t>
                      <t>OutOfService: All failed.</dd>
              <dt>OutOfService:</dt> <dd>All Egresses are administratively blocked.</t>
<?rfc subcompact="no" ?>
                   </list>
                        </t>
                        <t>
                        FailureCode: A non-zero blocked.</dd>
            </dl>
          </li>
          <li>
                        FailureCode is a nonzero code that specifies the error
                        if the DetNet flow encounters a failure (e.g., packet
                        replication and elimination is requested but not
                        possible,
                        possible or DnIngressStatus is Failed, or
                        DnEgressStatus is Failed, or DnEgressStatus is
                        PartialFailed).
                    </t>
             </list>
          </t>
                    </li>
        </ol>
        <t>
          Defining FailureCodes for DetNet is out-of-scope in out of scope for this document.
		  Table 46-1 of <xref target="IEEE8021Qcc"/> target="IEEE8021Qcc" format="default"/> describes TSN failure codes.
        </t>
      </section>

<!-- +++++++ DETNET FLOW REQUIREMENTS +++++++ -->
   <section anchor="sec_dnflowreq" title="Requirements numbered="true" toc="default">
        <name>Requirements of the DetNet Flow"> Flow</name>
        <t>
             The DnFlowRequirements attribute specifies requirements to ensure the service level
             desired for the DetNet flow.
        </t>

<?rfc subcompact="yes" ?>
          <t>The DnFlowRequirements
        <t>DnFlowRequirements includes the following attributes:
             <list style="letters">
                <t>MinBandwidth(<xref target="sec_flowminband"/>)</t>
                <t>MaxLatency(<xref target="sec_flowmaxlatency"/>)</t>
                <t>MaxLatencyVariation(<xref target="sec_flowmaxlatencyvari"/>)</t>
                <t>MaxLoss(<xref target="sec_flowmaxloss"/>)</t>
                <t>MaxConsecutiveLossTolerance(<xref target="sec_flowmaxconsloss"/>)</t>
                <t>MaxMisordering(<xref target="sec_flowmaxmisorder"/>)</t>
             </list>
        </t>
        <ol spacing="compact" type="a">
	  <li>MinBandwidth (<xref target="sec_flowminband" format="default"/>)</li>
          <li>MaxLatency (<xref target="sec_flowmaxlatency" format="default"/>)</li>
          <li>MaxLatencyVariation (<xref target="sec_flowmaxlatencyvari" format="default"/>)</li>
          <li>MaxLoss (<xref target="sec_flowmaxloss" format="default"/>)</li>
          <li>MaxConsecutiveLossTolerance (<xref target="sec_flowmaxconsloss" format="default"/>)</li>
          <li>MaxMisordering (<xref target="sec_flowmaxmisorder" format="default"/>)</li>
        </ol>
        <section anchor="sec_flowminband" title="Minimum numbered="true" toc="default">
          <name>Minimum Bandwidth of the DetNet Flow"> Flow</name>
          <t>
          MinBandwidth is the minimum bandwidth that has to be guaranteed for
          the DetNet flow. MinBandwidth is specified in octets per second.
          </t>
        </section>
        <section anchor="sec_flowmaxlatency" title="Maximum numbered="true" toc="default">
          <name>Maximum Latency of the DetNet Flow"> Flow</name>
          <t>
          MaxLatency is the maximum latency from Ingress to Egress(es) for a
          single packet of the DetNet flow. MaxLatency is specified as an
          integer number of nanoseconds.
          </t>
        </section>
        <section anchor="sec_flowmaxlatencyvari" title="Maximum numbered="true" toc="default">
          <name>Maximum Latency Variation of the DetNet Flow"> Flow</name>
          <t>
         MaxLatencyVariation is the difference between the minimum and the
         maximum end-to-end end-to-end, one-way latency. MaxLatencyVariation is specified as an
         integer number of nanoseconds.
          </t>
        </section>
        <section anchor="sec_flowmaxloss" title="Maximum numbered="true" toc="default">
          <name>Maximum Loss of the DetNet Flow"> Flow</name>
          <t>
         MaxLoss defines the maximum Packet Loss Ratio Rate (PLR) requirement for
         the DetNet flow between the Ingress and Egress(es) and the loss
		 measurement interval.
          </t>
        </section>
        <section anchor="sec_flowmaxconsloss" title="Maximum numbered="true" toc="default">
          <name>Maximum Consecutive Loss of the DetNet Flow"> Flow</name>
          <t>
           Some applications have special loss requirement, requirements, such as
           MaxConsecutiveLossTolerance.  The maximum consecutive loss tolerance
           parameter describes the maximum number of consecutive packets whose
           loss can be tolerated. The maximum consecutive loss tolerance can be
           measured
           measured, for example example, based on sequence number.
          </t>
        </section>
        <section anchor="sec_flowmaxmisorder" title="Maximum numbered="true" toc="default">
          <name>Maximum Misordering Tolerance of the DetNet Flow"> Flow</name>
          <t>
           MaxMisordering describes the tolerable maximum number of packets
           that can be received out of order. The value zero for the maximum
		   allowed misordering indicates that in order in-order delivery is required, required;
		   misordering cannot be tolerated.
          </t>
          <t>
		   The maximum allowed misordering can be measured measured, for example example, based
		   on sequence numbers. When a packet arrives at the egress after a
		   packet with a higher sequence number, the difference between the
		   sequence number values cannot be bigger than
		   "MaxMisordering + 1".
          </t>
        </section>
      </section> <!-- end DETNET FLOW REQUIREMENTS -->
   <section anchor="sec_dnflowbidir" title="BiDir requirement numbered="true" toc="default">
        <name>BiDir Requirement of the DetNet Flow"> Flow</name>
        <t>
           The DnFlowBiDir attribute defines the requirement that the flow and
           the corresponding reverse direction flow must share the same path
           (links and nodes) through the routed or switch network in the DetNet
           domain, e.g., to provide congruent paths in the two directions that
           share fate and path characteristics.
        </t>
      </section>
    </section> <!-- end DetNet flow modeling -->

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++            DETNET SERVICE               +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec_servicemodel" title="DetNet Service Related Parameters">

        <t>DetNet numbered="true" toc="default">
      <name>DetNet Service-Related Parameters</name>
      <t>The DetNet service have has the following attributes:
             <list style="letters">
                <t>DnServiceID attributes:</t>
      <ol spacing="compact" type="a">
	<li>DnServiceID (<xref target="sec_dnserviceid"/>)</t>
                <t>DnServiceDeliveryType target="sec_dnserviceid" format="default"/>)</li>
        <li>DnServiceDeliveryType (<xref target="sec_dnservdelivtype"/>)</t>
                <t>DnServiceDeliveryProfile target="sec_dnservdelivtype" format="default"/>)</li>
        <li>DnServiceDeliveryProfile (<xref target="sec_dnservdelivprof"/>)</t>
                <t>DNServiceConnectivity target="sec_dnservdelivprof" format="default"/>)</li>
        <li>DNServiceConnectivity (<xref target="sec_dnservcon"/>)</t>
                <t>DnServiceBiDir target="sec_dnservcon" format="default"/>)</li>
        <li>DnServiceBiDir (<xref target="sec_dnservbidir"/>)</t>
                <t>DnServiceRank target="sec_dnservbidir" format="default"/>)</li>
        <li>DnServiceRank (<xref target="sec_dnservrank"/>)</t>
                <t>DnServiceStatus target="sec_dnservrank" format="default"/>)</li>
        <li>DnServiceStatus (<xref target="sec_dnservstat"/>)</t>
                </list>
        </t> target="sec_dnservstat" format="default"/>)</li>
      </ol>
      <t>Service attributes are described in the following sections.</t>
      <section anchor="sec_dnserviceid" title="Management numbered="true" toc="default">
        <name>Management ID of the DetNet service"> Service</name>
        <t>
             A
             The DnServiceId attribute is a unique (management) identifier for each DetNet service within
             the DetNet domain.  It can be used to define the many to one many-to-one
             mapping of DetNet flows to a DetNet service.
        </t>
      </section>
      <section anchor="sec_dnservdelivtype" title="Delivery numbered="true" toc="default">
        <name>Delivery Type of the DetNet service"> Service</name>
        <t>
             The DnServiceDeliveryType attribute is set according to the payload of
             the served DetNet flow (i.e., the encapsulated App-flow format).
             The attribute can be Ethernet, MPLS, or IP.
        </t>
      </section>

<!-- +++++++ DETNET SERVICE REQUIREMENTS +++++++ -->
   <section anchor="sec_dnservdelivprof" title="Delivery numbered="true" toc="default">
        <name>Delivery Profile of the DetNet Service">

          <t>DnServiceDeliveryProfile Service</name>
        <t>The DnServiceDeliveryProfile attribute specifies the delivery profile to ensure proper serving of
          the DetNet flow.</t>

          <t>The DnServiceDeliveryProfile
        <t>DnServiceDeliveryProfile includes the following attributes:
             <list style="letters">
                <t>MinBandwidth(<xref target="sec_minband"/>)</t>
                <t>MaxLatency(<xref target="sec_maxlatency"/>)</t>
                <t>MaxLatencyVariation(<xref target="sec_maxlatencyvari"/>)</t>
                <t>MaxLoss(<xref target="sec_maxloss"/>)</t>
		<t>MaxConsecutiveLossTolerance(<xref target="sec_maxlconsloss"/>)</t>
		<t>MaxMisordering(<xref target="sec_maxmisorder"/>)</t>
             </list>
        </t>
        <ol spacing="compact" type="a">
	  <li>MinBandwidth (<xref target="sec_minband" format="default"/>)</li>
          <li>MaxLatency (<xref target="sec_maxlatency" format="default"/>)</li>
          <li>MaxLatencyVariation (<xref target="sec_maxlatencyvari" format="default"/>)</li>
          <li>MaxLoss (<xref target="sec_maxloss" format="default"/>)</li>
          <li>MaxConsecutiveLossTolerance (<xref target="sec_maxlconsloss" format="default"/>)</li>
          <li>MaxMisordering (<xref target="sec_maxmisorder" format="default"/>)</li>
        </ol>
        <section anchor="sec_minband" title="Minimum numbered="true" toc="default">
          <name>Minimum Bandwidth of the DetNet Service"> Service</name>
          <t>
           MinBandwidth is the minimum bandwidth that has to be guaranteed for
           the DetNet service. MinBandwidth is specified in octets per second
		   and excludes additional DetNet header (if any).
          </t>
        </section>
        <section anchor="sec_maxlatency" title="Maximum numbered="true" toc="default">
          <name>Maximum Latency of the DetNet Service"> Service</name>
          <t>
          MaxLatency is the maximum latency from Ingress to Egress(es) for a
          single packet of the DetNet flow. MaxLatency is specified as an
          integer number of nanoseconds.
          </t>
        </section>
        <section anchor="sec_maxlatencyvari" title="Maximum numbered="true" toc="default">
          <name>Maximum Latency Variation of the DetNet Service"> Service</name>
          <t>
         MaxLatencyVariation is the difference between the minimum and the
         maximum end-to-end end-to-end, one-way latency. MaxLatencyVariation is specified
         as an integer number of nanoseconds.
          </t>
        </section>
        <section anchor="sec_maxloss" title="Maximum numbered="true" toc="default">
          <name>Maximum Loss of the DetNet Service"> Service</name>
          <t>
         MaxLoss defines the maximum Packet Loss Ratio Rate (PLR) parameter for the
         DetNet service between the Ingress and Egress(es) of the DetNet
         domain.
          </t>
        </section>
        <section anchor="sec_maxlconsloss" title="Maximum numbered="true" toc="default">
          <name>Maximum Consecutive Loss of the DetNet Service"> Service</name>
          <t>
           Some applications have a special loss requirement, such as
           MaxConsecutiveLossTolerance.  The maximum consecutive loss tolerance
           parameter describes the maximum number of consecutive packets whose
           loss can be tolerated. The maximum consecutive loss tolerance can be
           measured
           measured, for example example, based on sequence number.
          </t>
        </section>
        <section anchor="sec_maxmisorder" title="Maximum numbered="true" toc="default">
          <name>Maximum Misordering Tolerance of the DetNet Service"> Service</name>
          <t>
           MaxMisordering describes the tolerable maximum number of packets
           that can be received out of order. The maximum allowed misordering
           can be measured measured, for example example, based on sequence number. The value zero
           for the maximum allowed misordering indicates that in order in-order delivery
           is required, required; misordering cannot be tolerated.
          </t>
        </section>
      </section> <!-- end DETNET SERVICE REQUIREMENTS -->
   <section anchor="sec_dnservcon" title="Connectivity numbered="true" toc="default">
        <name>Connectivity Type of the DetNet Service"> Service</name>
        <t>
          Two connectivity types are distinguished: point-to-point (p2p) and
		  point-to-multipoint (p2mp).  Connectivity type p2mp may be created by
		  a forwarding function (e.g., p2mp LSP).  (Note:  (Note that from a service
		  perspective
		  perspective, mp2mp connectivity can be treated as a superposition of
		  p2mp connections.)
        </t>
      </section>
      <section anchor="sec_dnservbidir" title="BiDir requirement numbered="true" toc="default">
        <name>BiDir Requirement of the DetNet Service"> Service</name>
        <t>
           The DnServiceBiDir attribute defines the requirement that the flow and
           the corresponding reverse direction flow must share the same path
           (links and nodes) through the routed or switch network in the DetNet
           domain, e.g., to provide congruent paths in the two directions that
           share fate and path characteristics.
        </t>
      </section>
      <section anchor="sec_dnservrank" title="Rank numbered="true" toc="default">
        <name>Rank of the DetNet Service"> Service</name>
        <t>
          The DnServiceRank attribute provides the rank of a service instance
          relative to other services in the DetNet domain. DnServiceRank
          (range: 0-255) is used by the network in case of network resource
          limitation scenarios. DnServiceRank value 0 is the highest priority.
        </t>
      </section>
      <section anchor="sec_dnservstat" title="Status numbered="true" toc="default">
        <name>Status of the DetNet Service"> Service</name>
        <t>
         The DnServiceStatus information group includes elements that specify the
         status of the service specific service-specific state of the DetNet domain. This
         information group informs the user whether or not the service is ready
         for use.
        </t>

        <t> The DnServiceStatus
        <t>DnServiceStatus includes the following attributes:
<?rfc subcompact="yes" ?>
             <list style="letters"> attributes:</t>
        <ol spacing="normal" type="a"><li>
            <t>DnServiceIngressStatus is an enumeration for the status of the service&acute;s service's Ingress:
                   <list style="symbols">
                      <t>None: no Ingress.</t>
                      <t>Ready: Ingress is ready.</t>
                      <t>Failed: Ingress failed.</t>
                      <t>OutOfService: Administratively blocked.</t>
<?rfc subcompact="no" ?>
                   </list>
            </t>
            <dl newline="false" spacing="compact">
              <dt>None:</dt> <dd>No Ingress.</dd>
              <dt>Ready:</dt> <dd>Ingress is ready.</dd>
              <dt>Failed:</dt> <dd>Ingress failed.</dd>
              <dt>OutOfService:</dt> <dd>Administratively blocked.</dd>
            </dl>
          </li>
          <li>
            <t>DnServiceEgressStatus is an enumeration for the status of the service&acute;s service's Egress:
                   <list style="symbols">
<?rfc subcompact="yes" ?>
                      <t>None: no Egress.</t>
                      <t>Ready: all
            </t>
            <dl newline="false" spacing="compact">
              <dt>None:</dt> <dd>No Egress.</dd>
              <dt>Ready:</dt> <dd>All Egresses are ready.</t>
                      <t>PartialFailed: One ready.</dd>
              <dt>PartialFailed:</dt> <dd>One or more Egress is ready, and one or more Egress failed.
                                  The DetNet flow can be used if the Ingress is Ready.</t>
                      <t>Failed: All Ready.</dd>
              <dt>Failed:</dt> <dd>All Egresses failed.</t>
                      <t>OutOfService: Administratively blocked.</t>
<?rfc subcompact="no" ?>
                   </list>
                        </t>
                   <t>
                        DnServiceFailureCode: A non-zero failed.</dd>
              <dt>OutOfService:</dt> <dd>Administratively blocked.</dd>
            </dl>
          </li>
          <li>
                        DnServiceFailureCode is a nonzero code that specifies
                        the error if the DetNet service encounters a failure
                        (e.g., packet replication and elimination is requested
                        but not possible, possible or DnServiceIngressStatus is Failed,
                        or
                        DnServiceEgressStatus is Failed, or
                        DnServiceEgressStatus is PartialFailed).
                </t>
             </list>
          </t>
                </li>
        </ol>
        <t>
             Defining DnServiceFailureCodes for DetNet service is out-of-scope
			 in out of scope
			 for this document. Table 46-1 of <xref target="IEEE8021Qcc"/> target="IEEE8021Qcc" format="default"/>
			 describes TSN failure codes.
        </t>
      </section>
    </section> <!-- end DetNet service modeling -->

<section anchor="sec_flowspecoper" title="Flow Specific Operations"> numbered="true" toc="default">
      <name>Flow-Specific Operations</name>
      <t>The DetNet flow information model relies on three high level high-level information groups:
           <list style="symbols">
                   <t>
              DnIngress: The
      </t>
      <dl newline="false" spacing="normal">
        <dt>DnIngress:</dt>
	<dd>The DnIngress information group includes elements that
              specify the source for a single DetNet flow. This information
              group is applied from the user of the DetNet service to the
              network.
              </t>
              <t>
              DnEgress: The
              network.</dd>
        <dt>DnEgress:</dt>
	      <dd>The DnEgress information group includes elements that
              specify the destination for a single DetNet flow.  This
              information group is applied from the user of the DetNet
              service to the network.
              </t>
              <t>
              DnFlowStatus: The status network.</dd>
        <dt>DnFlowStatus:</dt>
	<dd>The DnFlowStatus information group includes elements that
              specify the status of the flow in the network. This information
              group is applied from the network to the user of the DetNet
              service. This information group informs the user whether or not
              the DetNet flow is ready for use.
              </t>
             </list>
        </t> use.</dd>
      </dl>
      <t>
             There are three possible operations for each DetNet flow with
             respect to its DetNet service at a DN Ingress or a DN Egress
             (similarly
             (similar to App-flows at a Source source or a Destination):
<?rfc subcompact="yes" ?>
             <list style="symbols">
              <t>Join: DN destination):

      </t>
      <dl newline="false" spacing="compact">
        <dt>Join:</dt>
	<dd>DN Ingress/DN Egress intends to join the flow.</t>
              <t>Leave: DN flow.</dd>
        <dt>Leave: </dt>
	<dd>DN Ingress/DN Egress intends to leave the flow.</t>
              <t>Modify: DN flow.</dd>
        <dt>Modify:</dt>
	<dd>DN Ingress/DN Egress intends to change the flow.</t>
           </list>
<?rfc subcompact="no" ?>
        </t> flow.</dd>
      </dl>
      <section anchor="sec_flowjoin" title="Join Operation"> numbered="true" toc="default">
        <name>Join Operation</name>
        <t>
          For the join operation, the DnFlowSpecification, DnFlowRank,
          DnFlowEndpoint, and DnTrafficSpecification are included within
          the DnIngress or DnEgress information group. groups. For the join operation,
          the DnServiceRequirements groups can be included.
        </t>
      </section>
      <section anchor="sec_flowleave" title="Leave Operation"> numbered="true" toc="default">
        <name>Leave Operation</name>
        <t>For the leave operation, the DnFlowSpecification and DnFlowEndpoint are
  included within the DnIngress or DnEgress information group.</t> groups.</t>
      </section>
      <section anchor="sec_flowmodify" title="Modify Operation"> numbered="true" toc="default">
        <name>Modify Operation</name>
        <t>For the modify operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint,
        and DnTrafficSpecification are included within the DnIngress or DnEgress
        information group. For the join operation, the DnServiceRequirements groups
        can be included.
        </t>
        <t>
        The Modify operation can be considered to address cases when a flow is
        slightly changed, e.g., only MaxPayloadSize (<xref
                target="sec_dntrafficspec"/>) target="sec_dntrafficspec" format="default"/>) has been changed. The advantage
        of having a Modify is that it allows initiation of a change of flow spec
        while leaving the current flow is operating until the change is
        accepted. If there is no linkage between the Join and the Leave, then
        while figuring out whether the new flow spec can be supported, the
        controller entity has to assume that the resources committed to the
        current flow are in use. By using Modify Modify, the controller entity knows that
        the resources supporting the current flow can be available for
        supporting the altered flow. Modify is considered to be an optional
        operation due to possible controller plane limitations.
        </t>
  <t></t>
      </section>
    </section>

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++                 SUMMARY                 +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec_sum" title="Summary"> numbered="true" toc="default">
      <name>Summary</name>
      <t>This document describes the DetNet flow information model and the service
		information model for DetNet IP networks and DetNet MPLS networks.
		These models are used as input for creating the DetNet specific DetNet-specific
		YANG model. module.
      </t>
    </section>

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++                  IANA                   +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="IANA" title="IANA Considerations">
    <t>N/A.</t> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- +++++++                SECURITY                 +++++++ -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	The external interfaces of the DetNet domain need to be subject to
	appropriate confidentiality. Additionally, knowledge of which flows/services
	are provided to a customer or delivered by a network operator may supply
	information that can be used in a variety of security attacks.
    Security considerations for DetNet are described in detail in
    <xref target="I-D.ietf-detnet-security"/>. target="I-D.ietf-detnet-security" format="default"/>. General security considerations
    are described in <xref target="RFC8655"/>. target="RFC8655" format="default"/>.
	This document discusses modeling the information, not how it is
    exchanged.
      </t>
    </section>
  </middle>

<!--  *****BACK MATTER ***** -->
<back>

<references title="Normative References">
    <!--    <?rfc include='reference.RFC.6003'?> -->
        <?rfc include='reference.RFC.8655'?>
        <?rfc include='reference.I-D.ietf-detnet-mpls'?>
        <?rfc include='reference.RFC.8939'?>

<displayreference target="I-D.ietf-detnet-security" to="DETNET-SECURITY"/>
<displayreference target="I-D.ietf-detnet-yang" to="DETNET-YANG"/>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.8964.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>

        <reference anchor="IEEE8021Qcc" target="https://ieeexplore.ieee.org/document/8514112/">
          <front>
            <title>IEEE Std 802.1Qcc-2018: IEEE Standard for Local and metropolitan area networks - Bridges Metropolitan Area Networks--Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements</title>
            <author>
            <organization>IEEE Standards Association</organization>
              <organization>IEEE</organization>
            </author>
	    <date year="2018" /> month="October" year="2013"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8514112"/>
	  <seriesInfo name="IEEE" value="802.1Qcc-2018"/>
        </reference>
      </references>

<references title="Informative References">

        <?rfc include='reference.RFC.8938'?>
        <?rfc include="reference.I-D.ietf-detnet-security"?>
        <?rfc include="reference.I-D.ietf-detnet-yang"?>
        <?rfc include='reference.RFC.3444'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-security.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-detnet-yang.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml"/>

        <reference anchor="IETFDetNet" target="https://datatracker.ietf.org/wg/detnet/charter/">
          <front>
          <title>IETF Deterministic
            <title>Deterministic Networking (DetNet) Working Group</title> (detnet)</title>
            <author>
              <organization>IETF</organization>
            </author>
          <date />
            <date/>
          </front>
        </reference>

        <reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document/8403927">
          <front>
            <title>IEEE Std 802.1Q-2018 IEEE Standard for Local and metropolitan area networks - Bridges Metropolitan Area Networks--Bridges and Bridged Networks</title>
            <author>
                  <organization>IEEE Standards Association</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2018" /> month="July" year="2018"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
	  <seriesInfo name="IEEE" value="802.1Q-2018"/>
        </reference>

        <reference anchor="IEEE8021Qbv" target="https://ieeexplore.ieee.org/document/7572858/"> target="https://ieeexplore.ieee.org/document/8613095">
          <front>
            <title>IEEE Std 802.1Qbv-2015 IEEE Standard for Local and metropolitan area networks - -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic</title>
            <author>
                                  <organization>IEEE Standards Association</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2015" /> month="March" year="2016"/>
            </front>
	    <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.8613095"/>
	    <seriesInfo name="IEEE" value="802.1Qbv-2015"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>