DetNet                                                         J. Farkas
Internet-Draft                                                  B. Varga
Intended status: Standards Track                                Ericsson
Expires: September 12, 2019 January 9, 2020                                     R. Cummings
                                                    National Instruments
                                                                Y. Jiang
                                           Huawei Technologies Co., Ltd.
                                                          March 11,
                                                           July 08, 2019

                     DetNet Flow Information Model
              draft-ietf-detnet-flow-information-model-03
              draft-ietf-detnet-flow-information-model-04

Abstract

   This document describes flow and service information model for
   Deterministic Networking (DetNet).  The DetNet service is provided
   either for a Layer 3 or a Layer 2 flow.  This document provides
   DetNet flow and service information model both  These models are defined for Layer 3 IP
   and Layer
   2 flows in an integrated fashion. MPLS DetNet data planes

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2019. January 9, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  ToDo list . .  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction
     1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Goals . .   5
     1.2.  Non Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Non Goals
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Conventions
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   5
   4.  Terminology and Definitions
     2.2.  Abbreviations . . . . . . . . . . . . . . . . .   5
   5.  Naming Conventions . . . . .   6
     2.3.  Naming Conventions  . . . . . . . . . . . . . . . .   6
   6.  Service model . . .   6
     2.4.  Requirements Language . . . . . . . . . . . . . . . . . .   7
   3.  DetNet Domain and its Modeling  . . .   6
     6.1.  Service overview . . . . . . . . . . . .   7
     3.1.  DetNet Service Overview . . . . . . . .   6
     6.2.  Service parameters . . . . . . . . .   7
     3.2.  Reference Points Used in Modeling . . . . . . . . . .   6
     6.3.  Reference Points . .   7
     3.3.  Information Elements  . . . . . . . . . . . . . . . . . .   8
     6.4.  Service scenarios .
   4.  App-flow Related Parameters . . . . . . . . . . . . . . . . .   8
     4.1.  App-flow Characteristics  . .   9
   7.  End System and DetNet domain . . . . . . . . . . . . . .   8
     4.2.  App-flow Requirements . .   9
   8.  DetNet flows . . . . . . . . . . . . . . . .   9
   5.  DetNet Flow Related Parameters  . . . . . . . .  11
     8.1.  Identification and Specification of Flows . . . . . . .   9
     5.1.  Management ID of the DetNet Flow  .  11
       8.1.1.  IP flow Identification and Specification at UNI . . .  12
       8.1.2.  L2 Flow Identification and Specification at UNI . . .  12
       8.1.3.  DetNet Flow Identification and Specification . . . .  13
     8.2.  Traffic Specification .  10
     5.2.  Payload type of the DetNet Flow . . . . . . . . . . . . .  10
     5.3.  Format of the DetNet Flow . . . .  13
     8.3.  Flow Rank . . . . . . . . . . . .  10
     5.4.  Identification and Specification of DetNet Flows  . . . .  10
       5.4.1.  DetNet MPLS Flow Identification and Specification . .  11
       5.4.2.  DetNet IP Flow Identification and Specification . . .  11
     5.5.  Traffic Specification of the DetNet Flow  . . .  15
   9.  Source . . . . .  11
     5.6.  Endpoints of the DetNet Flow  . . . . . . . . . . . . . .  12
     5.7.  Rank of the DetNet Flow . . . . . . . .  15
   10. Destination . . . . . . . . .  12
     5.8.  Status of the DetNet Flow . . . . . . . . . . . . . . . .  16
   11. Common Attributes  12
     5.9.  Requirements of Source and Destination the DetNet Flow . . . . . . . . .  16
     11.1.  End System Interfaces . . . .  13
       5.9.1.  Minimum Bandwidth of the DetNet Flow  . . . . . . . .  14
       5.9.2.  Maximum Latency of the DetNet Flow  . . . . .  16
     11.2.  Interface Capabilities . . . .  14
       5.9.3.  Maximum Latency Variation of the DetNet Flow  . . . . . . . . . . . . .  16
     11.3.  User to Network Requirements . . . .  14
       5.9.4.  Maximum Loss of the DetNet Flow . . . . . . . . . .  17
   12. Ingress .  14
       5.9.5.  Maximum Consequtive Loss of the DetNet Flow . . . . .  14
       5.9.6.  Maximum Misordering Tolerance of the DetNet Flow  . .  14
     5.10. BiDir requirement of the DetNet Flow  . . . . . . . . . .  14
   6.  DetNet Service Related Parameters . . . . . . . . .  18
   13. Egress . . . . .  15
     6.1.  Management ID of the DetNet service . . . . . . . . . . .  15
     6.2.  Delivery Type of the DetNet service . . . . . . . . . . .  18
   14.  15
     6.3.  Delivery Profile of the DetNet Domain Service  . . . . . . . . .  15
       6.3.1.  Minimum Bandwidth of the DetNet Service . . . . . . .  16
       6.3.2.  Maximum Latency of the DetNet Service . . . . . . . .  18
     14.1.  16
       6.3.3.  Maximum Latency Variation of the DetNet Domain Capabilities . Service . . .  16
       6.3.4.  Maximum Loss of the DetNet Service  . . . . . . . . .  16
       6.3.5.  Maximum Consequtive Loss of the DetNet Service  . .  19
   15. Flow-status .  16
       6.3.6.  Maximum Misordering Tolerance of the DetNet Service .  16
     6.4.  Connectivity Type of the DetNet Service . . . . . . . . .  16
     6.5.  BiDir requirement of the DetNet Service . . . . . . . . .  17
     6.6.  Rank of the DetNet Service  . . . . .  19
     15.1.  Status Info . . . . . . . . . .  17
     6.7.  Status of the DetNet Service  . . . . . . . . . . . .  20
     15.2.  Interface Configuration . .  17
   7.  Flow Specific Operations  . . . . . . . . . . . . . .  21
     15.3.  Failed Interfaces . . . .  18
     7.1.  Join Operation  . . . . . . . . . . . . . . .  21
   16. Service Rank . . . . . .  18
     7.2.  Leave Operation . . . . . . . . . . . . . . . . . .  22
   17. Service-status . . .  19
     7.3.  Modify Operation  . . . . . . . . . . . . . . . . . . . .  22
   18.  19
   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   19.  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   20.  19
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   21.  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     21.1.  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     21.2.  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  23  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24  21

1.  ToDo list

   These further actions are due on the draft:

   o  Align with updated architecture and data plane documents (partly
      done).

   o  App-flow parameters will not be defined in detail (add references
      only, e.g., 802.1Qcc).  We focus on DetNet flows.

   o  Clarification on relationship between DetNet flow model and DetNet
      service model.

   o  Parameter set needs finalization, some re-org of the set may be
      needed.

   o  Sort out which parameter belongs to DetNet flow model and which to
      DetNet service model.

   o  Clarify relationship between App-flow and DetNet flow (N:1 vs
      1:1).

2.  Introduction

   A Deterministic Networking (DetNet) service 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.  The DetNet service is provided either for
   a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network,
   see, e.g., [I-D.ietf-detnet-dp-sol-mpls].  Similarly, Time-Sensitive
   Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged
   network.  DetNet and TSN have common architecture as
   expressed in [IETFDetNet] and [I-D.ietf-detnet-architecture].  The
   DetNet service is provided for DetNet flows via the DetNet service
   and forwarding sub-layers.

   DetNet service is IP or MPLS and DetNet is currently defined for IP
   and MPLS networks as shown in Figure 1 based on Figure 2 and Figure 3
   of [I-D.ietf-detnet-data-plane-framework].  A DetNet flow includes
   one or more App-flow(s) as payload.  App-flows can be leveraged both by L3 and L2 Ethernet, MPLS,
   or IP flows, i.e., by which impacts what header fields are use in order to
   identify a flow.  DetNet L3 flows are created by DetNet encapsulation of
   App-flow(s) (e.g., with added MPLS labels, etc.).  In some scenarios
   App-flow and DetNet L2 flows.  Therefore, flow look similar on the wire (e.g., L3 App-flow
   over a DetNet IP network).

                                             +-----+
                                             | TSN |
                        +-------+          +-+-----+-+
                        | DN IP |          | DN MPLS |
                     +--+--+----+----+   +-+---+-----+-+
                     | TSN | DN MPLS |   | TSN | DN IP |
                     +-----+---------+   +-----+-------+

       Figure 1: DetNet Service Examples as per Data Plane Framework

   As shown in Figure 1 as per [I-D.ietf-detnet-data-plane-framework] a
   DetNet flow can be treated as an application level flow (App-flow)
   e.g., at DetNet flow aggregation or in a sub-network that
   interconnects DetNet nodes.

   The DetNet flow and service information model provided by this
   document covers contains both DetNet L3 flows flow and
   DetNet L2 flows App-flow specific information
   in an integrated fashion.

   In a given network scenario three information models can
   distinguished:

   o  Flow models describe characteristics of data flows.  These models
      describe in 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).

   o  Service models describe characteristics of services being provided
      for data flows over a network.  These models can be treated as a
      network operator independent information model.

   o  Configuration models describe in detail the settings required on
      network nodes to serve a data flow properly.

   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 Figure 1. 2.

      User                  Network Operator
              flow/service
       /\      info model    +---+
      /  \ <---------------> | X |    management/control
      ----                   +-+-+       plane entity
                               ^
                               |   configuration
                               |     info model
                        +------------+
                        v      |     |
                       +-+     |     v  Network
                       +-+     v    +-+  nodes
                              +-+   +-+
                              +-+

         Figure 1: 2: Usage of Information models (flow, service and
                              configuration)

   DetNet flow and service information model is based on
   [I-D.ietf-detnet-architecture] and on the concept of data model
   specified by [IEEE8021Qcc].  Furthermore, the starting point of the
   DetNet flow information model relies
   on was the flow identification
   possibilities described in [IEEE8021CB], which is used by
   [IEEE8021Qcc] as well.  In addition to TSN data model, [IEEE8021Qcc]
   also specifies configuration of TSN features (e.g., traffic
   scheduling specified by [IEEE8021Qbv]).  Due to the common
   architecture and flow model, configuration features can be leveraged
   in certain deployment scenarios, e.g., when the network that provides
   the DetNet service includes both L3 and L2 network segments.

   Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see
   Section 4), this document (this revision) only considers

1.1.  Goals

   As it is expressed in the
   Centralized Network / Distributed User Model out of Charter [IETFDetNet], the models
   specified by [IEEE8021Qcc].  That is, there is DetNet WG
   collaborates with IEEE 802.1 TSN in order to define a User-Network
   Interface (UNI) between an end system and a network.  Furthermore,
   there is a central entity for the control of the network.  For
   instance, the central entity implements a Path Computation Element
   (PCE) for the calculation and establishment of paths needed for
   packet replication and elimination, if any.

2.1.  Goals

   As it is expressed in the Charter [IETFDetNet], the DetNet WG
   collaborates with IEEE 802.1 TSN in order to define a common
   architecture for both Layer 2 common
   architecture for both Layer 2 and Layer 3, which is beneficial for
   various reasons, e.g., in order to simplify implementations.  The
   flow and service information models should be also common aligned along
   those lines.  As the TSN flow information/data model specified by
   [IEEE8021Qcc] is mature,  Therefore, the DetNet flow and service information
   models described in this document are based on [IEEE8021Qcc], which
   is an amendment to [IEEE8021Q].

   This document intends to specify flow and service information models
   only.

2.2.

1.2.  Non Goals

   This document (this revision) does not intend to specify either flow
   data model or DetNet configuration.  From these aspects, the goals of
   this document differ from the goals of [IEEE8021Qcc], which also
   specifies data model and configuration of certain TSN features.

3.  Conventions

2.  Terminology

2.1.  Terms Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The lowercase forms with an initial capital "Must", "Must Not",
   "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional"
   in this document are to be interpreted in the sense defined in
   [RFC2119], but are used where the normative behavior is defined in
   documents published by SDOs other than the IETF.

4.  Terminology and Definitions

   This document uses the terminology established in Section 2 of the DetNet
   architecture document [I-D.ietf-detnet-architecture]. [I-D.ietf-detnet-architecture] and the the DetNet Data
   Plane Framework [I-D.ietf-detnet-data-plane-framework].  The reader
   is assumed to be familiar with these documents and any terminology
   defined therein.  The DetNet <=> TSN dictionary of
   [I-D.ietf-detnet-architecture] is used to perform translation from
   [IEEE8021Qcc] to this document.
   Application level flows (app-flow) can be L2 or L3 flows, what may
   impact what header fields are use in order

   The following terminology is used according to identify
   [I-D.ietf-detnet-architecture]:

   App-flow      The payload (data) carried over a flow. DetNet flows are created by proper service.

   DetNet encapsulation flow   A DetNet flow is a sequence of app-
   flow(s) (e.g., with added MPLS labels, etc.).  In some scenarios App- packets which conform
                 uniquely to a flow identifier, and to which the DetNet flow looks similar on
                 service is to be provided.  It includes any DetNet
                 headers added to support the wire (e.g., L3 App-flow
   over a DetNet IP network).

5.  Naming Conventions service and
                 forwarding sub-layers.

   The following naming conventions were used for naming information
   model terminology is introduced in this document:

   Source        Reference point for an App-flow, where the flow starts.

   Destination   Reference point for an App-flow, where the flow
                 terminates.

   DN Ingress    Reference point for DetNet flow, where it starts.
                 Networking technology specific encapsulation may be
                 added here to the served App-flow(s).

   DN Egress     Reference point for DetNet flow, where it terminates.
                 Networking technology specific encapsulation may be
                 removed here from the served App-flow(s).

2.2.  Abbreviations

   The following abbreviations are used in this document:

   DetNet        Deterministic Networking.

   DN            DetNet.

   MPLS          Multiprotocol Label Switching.

   PSN           Packet Switched Network.

   TSN           Time-Sensitive Networking.

2.3.  Naming Conventions

   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.

   o  Names SHOULD be descriptive.

   o  Names MUST start with uppercase letters.

   o  Composed names MUST use capital letters for the first letter of
      each component.  All other letters are lowercase, even for
      acronyms.  Exceptions are made for acronyms containing a mixture
      of lowercase and capital letters, such as IPv6.  Examples are
      SourceMacAddress and DestinationIPv6Address.

6.  Service model

6.1.

2.4.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  DetNet Domain and its Modeling

3.1.  DetNet Service overview Overview

   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.

   The simplest DetNet service is to provide bridging over the DN domain
   (i.e., tunneling for L2), where the connected hosts are in the same
   broadcast (BC) domain.  Forwarding over the DetNet domain is based on
   L2 (MAC) addresses (i.e. dst-MAC).  Somewhat more sophisticated is
   DetNet Routing service that provides routing, so available only for
   L3 hosts that are in different BC domains.  Forwarding over the
   DetNet domain is based on L3 (IP) addresses (i.e. dst-IP).

   Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the
   DetNet service related reference points and main components.

6.2.  Service parameters

   A DetNet network receives DetNet flows via a UNI as shown in Figure 5
   in [I-D.ietf-detnet-architecture].  The DetNet network connects the
   UNIs via tunnels in order to provide DetNet service as shown in
   Figure 8

3.2.  Reference Points Used in [I-D.ietf-detnet-architecture].

   The DetNet Modeling

   From service attributes are the following:

   o  Service type
      It design perspective a fundamental question is the flow type (L2 or L3) using the DetNet service.

   o  Bandwidth
      It is
   location of the minimum bandwidth guaranteed for service/flow endpoints, i.e., where the DetNet service.

   o  Delay parameters
      The are two delay parameters for a DetNet service:

      *  Maximum latency, which is the maximum end-to-end one-way
         latency for the DetNet service.

      *  Packet Delay Variation (PDV), which is the difference between
         the minimum and the maximum end-to-end one-way latency.  The
         PDV parameter describes the maximum packet delay variation for
         the DetNet service.  (Note that PDV is sometimes referred to as
         jitter.)

   o  Loss parameters

      *  The maximum Packet Loss Ratio (PLR) parameter describes the
         maximum packet loss ratio for the DetNet service between the
         edges of the DetNet network.

      *  Some applications have special loss requirement.  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 based on
         sequence number.

   o  Maximum allowed misordering
      Maximum allowed misordering describes the tolerable maximum number
      of packets that can be received out of order.  The maximum allowed
      misordering can be measured based on sequence number.  The value
      zero for the maximum allowed misordering indicates that in order
      delivery is required, misordering cannot be tolerated.

   o  Connectivity type
      Two connectivity types are distinguished: point-to-point (p2p) and
      point-to-multipoint (p2mp).  Connectivity type p2mp is created by
      a transport layer function (e.g., p2mp LSP).  (Note: mp2mp
      connectivity is a superposition of p2mp connections.)

   o  Service rank
      Service rank provides the rank of a service instance relative to
      other services in the network.  Rank is used by the network in
      case of network resource limitation scenarios.

6.3.  Reference Points

   From service model design perspective a fundamental question is the
   location of the service endpoints, i.e., where the service starts and
   ends.

                                 +--------+
                                 |        |
                                 | X    X |
                                 |  ____  |
                                 | /    \ |
                                 |        |
                                 |/\/\/\/\|

                                To be ADDED
                               404 Not Found

               Figure 2: FIGURE Placeholder Reference Points

   Note: Further discussion is needed based on data plane encapsulation
   results what reference points should be defined.  Only some possible
   examples listed here:

   o  App-flow endpoint: End system's internal reference point for the
      native data flow.

   o  DetNet-UNI: UNI interface ("U") on a DetNet edge node.

   o  DetNet-NNI: NNI interface ("N") between DetNet domains.

   [[NOTE: Contributions are welcome whether we should define or
   distinguish internal reference point(s) for DetNet-aware end-systems
   as well. ]]

   DetNet-UNI and DetNet-NNI are assumed in this document to be packet-
   based reference points and provide connectivity over the packet
   network and between domains.  A DetNet-UNI may add networking
   technology specific encapsulation to the data flow in order to
   transport it over the network.

   [[NOTE: Differences between the service over end-systems internal
   reference points and DetNet-UNI is for further discussions.  For
   example, in-order delivery is expected in end system internal
   reference points, whereas it is considered optional over the DetNet-
   UNI. ]]

6.4.  Service scenarios

   Using the above defined reference points, two major service scenarios
   can be identified:

   o  End-to-End-Service: the service reaches out to final source or
      destination nodes, so it is an e2e service between application
      hosting devices (end systems).

   o  DetNet-Service: the service connects networking islands, so it is
      a service between the borders of network domain(s).

   [[NOTE: we may consider to define further scenarios based on the
   result of reference point related discussions. ]]

7.  End System and DetNet domain

   Deterministic service is required by time/loss sensitive
   application(s) running on an end system during communication with its
   peer(s).  Such a data exchange has various requirements on delay and/
   or loss parameters.

   The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes
   two kinds of end systems: Source and Destination.  The same
   distinction is applied for the DetNet flow information model.  In
   addition to the end systems interested in a flow, the status
   information of the flow is also important.  Therefore, the DetNet
   flow information model relies on three high level groups:

   o  Source: an end system capable of sourcing a DetNet flow.  The
      Source information group includes elements that specify the Source
      for a single flow.  This information group is applied from the
      user to the network.

   o  Destination: an end system that is a destination of a DetNet flow.
      The Destination information group includes elements that specify
      the Destination for a single flow.  This information group is
      applied from the user to the network.

   o  Flow-Status: the status of a DetNet flow.  The status 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.  This information group informs the user whether or not
      the flow is ready for use.

   From service perspective two kinds of edge nodes can be
   distinguished: Ingress service/flow
   starts and Egress.  In addition the technology of ends.

   App-flow specific reference points are the
   DetNet domain Source (where it starts)
   and the status of the service are also important.

   Therefore, the DetNet service information model relies on four high
   level groups:

   o  Ingress: an edge system receiving Destination (where it terminates).  Similarly a DetNet flow from a Source.
      The
   have reference points named as DN Ingress information group includes elements that specify the
      entry point for a single flow.  This information group is applied
      from the network to the user.

   o  Egress: an edge system sending traffic towards a Destination of a
      DetNet flow.  The (where it starts) and DN
   Egress information group includes elements that
      specify (where it ends).  These reference points may coexist in the egress point for
   same node (e.g., in a single flow.  This information
      group is applied from the network to the user.

   o  DetNet Domain: an administrative domain providing the DetNet
      service.  The DetNet domain information group includes elements
      that specify the forwarding capabilities IP end system).  DN Ingress and methods DN
   Egress reference points are intermediate reference points for a single
      flow.  This information group is applied within the network.

   o  Service-Status: the status of
   served App-flow.

   All reference points are assumed in this document to be packet-based
   reference points.  A DN Ingress may add and a DetNet service. DN Egress may remove
   networking technology specific encapsulation to/from the served App-
   flow(s) (e.g., MPLS label(s), UDP and IP headers).

3.3.  Information Elements

   The status DetNet flow information group includes elements that specify the status of model and the service specific state model relies on
   three groups of the network.  This information group is
      applied from the network to the user.  This information group
      informs elements:

   o  App-flow related paramaters: they describe the user whether or not App-flow
      characteristics (e.g., identification, encapsulation, traffic
      specification, endpoints, status, etc.) and the service is ready for use.

   There are three operations for each flow with respect to a Source or
   a Destination (and an Ingress or an Egress): App-flow
      requirements (e.g., delay, loss, etc.).

   o  Join: Source/Destination request to join  DetNet flow related parameters: they describe the flow. DetNet flow
      characteristics (e.g., identification, format, traffic
      specification, endpoints, rank, etc.).

   o  Leave: Source/Destination request to leave  DetNet service related parameters: they describe the flow.

   o  Modify: Source/Destination request to change expected
      service characteristics (e.g., delivery type, connectivity delay/
      loss, status, rank, etc.).

   In the flow.

   Modify operation can be considered to address cases when a flow is
   slightly changed, e.g., only MaxPayloadSize (Section 8.2) has been
   changed.  The advantage of having a Modify is that it allows to
   initiate information model a change of DetNet flow spec while leaving contains one or more App-flows
   (N:1 mapping).  During DetNet aggregation the current flow is
   operating until aggregated DetNet flows
   are treated as App-flows and the change aggregate is accepted.  If the DetNet flow, which
   provides N:1 mapping.  Similarly, there is no linkage
   between the Join a M:1 relationship of
   DetNet flow(s) and a DetNet Service.

4.  App-flow Related Parameters

   Deterministic service is required by time/loss sensitive
   application(s) running on an end system during communication with its
   peer(s).  Such a data exchange has various requirements on delay and/
   or loss parameters.

4.1.  App-flow Characteristics

   App-flow characteristics are described with the Leave, then in figuring out whether following parameters:

   o  FlowID: it is a unique (management) identifier of the new
   flow spec App-flow.
      It can be supported, the central entity has used to assume that define the
   resources committed N:1 mapping of App-flows to a DetNet
      flow.

   o  FlowType: it is set according to the current flow are in use.  Via Modify the
   central entity knows that the resources supporting encapsulation format of the current flow
      flow.  It can be available for supporting the altered flow.  Modify Ethernet (TSN), MPLS, or IP.

   o  DataFlowSpecification: it is
   considered a flow descriptor, defining which
      packets belongs to be an optional operation due a flow using, e.g., FlowType specific packet
      header fields like src-addr, dst-addr, label, VLAN-ID, etc.

   o  TrafficSpecification: it is a flow descriptor, defining traffic
      parameters like packet size, interval, and max. packets per
      interval.

   o  FlowEndpoints: it defines the start and termination reference
      points of the App-flow by pointing to possible control-plane
   limitations.

   As the DetNet UNI can provide service for both L3 source interface/node
      and L2 app-flows,
   end systems may not need destination interface(s)/node(s).

   o  FlowStatus: it provides the status of the App-flow with respect to implement
      the L3 <=> L2 Transfer Function
   specified establishment of the flow by [IEEE8021CB] (see, e.g., subclause 6.3; see also
   subclause 46.1 in [IEEE8021Qcc]).  A DetNet edge node may implement a
   function similar to the Transfer Function, see, network, e.g., ready, failed,
      etc.

   o  FlowRank: it provides the Svc Proxy
   in Figure 3 in [I-D.ietf-detnet-architecture].

8.  DetNet flows

   The app-flows leveraging DetNet service can be unicast or multicast
   data rank of this flow relative to other
      flows in the network.

4.2.  App-flow Requirements

   App-flow requirements are described with the following parameters:

   o  FlowRequirements: it defines the requirement of an application the App-flow
      regarding bandwidth, latency, latency variation, loss, and
      misorder tolerance.

   o  FlowBiDir: it defines the requirement of the App-flow whether it
      has to be routed together with constrained requirements on network
   performance, other App-flow(s) through the
      network, e.g., low packet loss rate and/or latency.  Flows can
   require different connectivity types: point-to-point (p2p) or point-
   to-multipoint (p2mp).  The p2mp connectivity is created to provide congruent paths in the two directions.

5.  DetNet Flow Related Parameters

   Data model specified by a
   transport layer function (e.g., p2mp LSP)
   [I-D.ietf-detnet-dp-sol-mpls].  (Note that mp2mp connectivity is a
   superposition of p2mp connections.)

   Many [IEEE8021Qcc] describes data flows using DetNet TSN
   service are as periodic flows with fix packet size (i.e., Constant Bit
   Rate (CBR) flows), flows) or periodic with variable packet size.

   Delay  The same concept is
   applyed for flows using DetNet service.

   Latency and loss parameters are correlated because the effect of late
   delivery can result data loss for an application.  However, not all
   applications require hard limits on both parameters (delay (latency and
   loss).  For example, some real-time applications allow graceful
   degradation if loss happens (e.g., sample-based processing, media
   distribution).  Some others may require high-bandwidth connections
   that make the usage of techniques like packet replication
   economically challenging or even impossible.  Some applications may
   not tolerate loss, but are not delay latency sensitive (e.g., bufferless
   sensors).  Time/loss sensitive applications may have somewhat special
   requirements especially for loss (e.g., no loss in two consecutive
   communication cycles; very low outage time, etc.).

   Flows

   DetNet flows have the following attributes:

   a.  DataFlowSpecification  DnFlowID (Section 8.1) 5.1)

   b.  TrafficSpecification  DnPayloadType (Section 8.2) 5.2)

   c.  FlowRank  DnFlowFormat (Section 5.3)

   d.  DnFlowSpecification (Section 5.4)

   e.  DnTrafficSpecification (Section 5.5)

   f.  DnFlowEndpoints (Section 5.6)

   g.  DnFlowRank (Section 5.7)

   h.  DnFlowStatus (Section 5.8)

   DetNet flows have the following requirement attributes:

   o  DnFlowRequirements (Section 8.3) 5.9)

   o  DnFlowBiDir (Section 5.10)

   Flow attributes are described in the following sections.

8.1.

5.1.  Management ID of the DetNet Flow

   A unique (management) identifier is needed for each DetNet flow
   within the DetNet domain.  It is specified in DnFlowID.  It can be
   used to define the M:1 mapping of DetNet flows to a DetNet service.

5.2.  Payload type of the DetNet Flow

   DnPayloadType attribute is set according to encapsulated App-flow
   format.  The attribute can be Ethernet, MPLS, or IP.

5.3.  Format of the DetNet Flow

   DnFlowFormat attribute is set according to DetNet PSN technology.
   The attribute can be MPLS or IP.

5.4.  Identification and Specification of DetNet Flows

   Identification options for DetNet flows at the UNI Ingress/Egress and
   within the DetNet domain are specified as follows; see Section 8.1.1 for DetNet
   L3 flows (at UNI), Section 8.1.2 5.4.1
   for DetNet L2 MPLS flows (at UNI) and Section 8.1.3 5.4.2 for DetNetwork flows (within the network).

8.1.1. DetNetw IP flow Identification and Specification at UNI

   L3 data flows can be identified and specified by the following
   attributes:

   a.  SourceIpAddress

   b.  DestinationIpAddress

   c.  IPv6FlowLabel

   d.  Dscp

   e.  Protocol

   f.  SourcePort

   g.  DestinationPort

8.1.2.  L2 Flow Identification and Specification at UNI

   L2 data flows can be identified and specified by the following
   attributes:

   a.  DestinationMacAddress

   b.  SourceMacAddress

   c.  Pcp

   d.  VlanId

   e.  EtherType

   Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q]
   uses StreamID to match Talker registrations with their corresponding
   Listener registrations, i.e., to identify Streams (L2 TSN flows).
   The StreamID includes the following subcomponents:

   o  A 48-bit MAC Address associated with the Talker sourcing the
      stream to the bridged network.

   o  A 16-bit unsigned integer value, Unique ID, used to distinguish
      among multiple streams sourced by the same Talker.

8.1.3. flows.

5.4.1.  DetNet MPLS Flow Identification and Specification

   Identification of DetNet MPLS flows within the DetNet domain are used
   in the service information model.  The attributes are specific to the
   MPLS forwarding paradigm within the DetNet domain.  DetNetwork domain
   [I-D.ietf-detnet-mpls].  DetNetwork MPLS flows can be identified and
   specified by the following attributes:

   a.  SLabel

   b.  FLabelStack

5.4.2.  DetNet IP Flow Identification and Specification

   DetNet IP flows can be identified and specified by the following attributes:
   attributes (6-tuple) [I-D.ietf-detnet-ip]:

   a.  SourceIpAddress

   b.  DestinationIpAddress

   c.  IPv6FlowLabel

   d.  DSCP  Dscp

   e.  Protocol

   f.  SourcePort

   g.  DestinationPort

   h.  MplsLabel

8.2.

5.5.  Traffic Specification

   TrafficSpecification specifies of the DetNet Flow

   DnTrafficSpecification attributes specify how the Source DN Ingress
   transmits packets for the DetNet flow.  This is effectively the
   promise/request of the Source DN Ingress to the network.  The network uses
   this traffic specification to allocate resources and adjust queue
   parameters in network nodes.

   TrafficSpecification has the following attributes:

   a.  Interval: the period of time in which the traffic specification
       cannot be exceeded.

   b.  MaxPacketsPerInterval: the maximum number of packets that the
       Source
       Ingress will transmit in one Interval.

   c.  MaxPayloadSize: the maximum payload size that the Source Ingress will
       transmit.

   [[NOTE (to be removed from a future revision):

   These attributes can be used to describe any type of traffic (e.g.,
   CBR, VBR, etc.) and can be used during resource allocation to
   represent worst case scenarios.

   [[Editor's note (to be removed from a future revision): 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, but not both delay-and-loss d elay-and-loss sensitive).
   Possible options how to extend TrafficSpecification DnTrafficSpecification attributes is
   for further discussion.  Identified options are
   described in the following notes.]]

   [[NOTE1: Based on the already defined attributes the most similar
   additional attributes for VBR type flows can be defined as follows:

   o  AveragePacketsPerInterval: the average number ]]

5.6.  Endpoints of packets that the
      Source will transmit in one Interval.

   o  AveragePayloadSize: DetNet Flow

   DnFlowEndpoints attribute defines the average payload size that starting and termination
   reference points of the Source will
      transmit.

   ]]

   [[NOTE2: another alternative DetNet flow by pointing to deal better with various traffic
   types can rely the ingress
   interface/node and egress interface(s)/node(s).  Depending on [RFC6003], which describes the support of Metro
   Ethernet Forum (MEF) Ethernet traffic parameters for using for
   resource reservation purposes.  Such
   network scenario it defines an interface or a Bandwidth Profile node.  Interface can be also
   adapted to describe the set of traffic parameters
   defined for a Detnet flow.
   Committed Rate indicates the rate at which traffic commits to be sent
   by the source (described in terms of the CIR (Committed Information
   Rate) and CBS (Committed Burst Size) attributes.)  Excess Rate
   indicates the extent by which the traffic sent by the source exceeds example if the committed rate.  The Excess Rate App-flow is described in terms of the EIR
   (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]]

   [[NOTE3: a third alternative is to define application based traffic
   models such as [GPP22885] defines periodic and event-driven traffic
   model, TSN Stream and 5G PPP work defines traffic model for MTC (Machine Type
   Communication) use cases [I-D.ietf-detnet-use-cases].  Periodic
   traffic type it is usually for status update between devices or devices
   transmit status report to
   received over a central unit in regular basis.
   TrafficPeriod, defines the period of the status update message.
   DataSize, defines the data size of the massage which is constant.
   3GPP also defines approximately-periodic transmission with variations
   on period and uncertainty in the time arrival of the packets.  Event-
   triggered traffic type corresponds traffic being triggered by an MTC
   device event.  MinIntervalBetweenEvent, defines the minimum interval
   between two events.  Event-triggered transmission will not happen all
   the time, whenever well defined UNI interface.  For exampe for App-flows
   with MPLS encapsulation defining an alert ingress node is sent, it waits until the issue being
   solved to be able to send another alert.  MaxPacketPerEvent, defines
   the max number more common when
   per platform label space is used.

5.7.  Rank of packets within one message. ]]

8.3. the DetNet Flow Rank

   FlowRank

   DnFlowRank provides the rank of this flow relative to other flows in
   the network.  This rank is used to determine success/failure of flow
   establishment. DetNet domain.  Rank (boolean) (range: 0-255) is used by the network 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 dropped (i.e., removed from node configuration) if for example a
   port of a node becomes oversubscribed (e.g., due to network reconfiguration).  The true
   value is more important than the false value (i.e., flows with false
   are dropped first).

9.  Source

   The Source object specifies:

   o  The behavior of the Source for the flow (how/when the Source
      transmits).

   o  The requirements of the Source from the network.

   o  The capabilities of the interface(s) re-
   configuration).

5.8.  Status of the Source.

   The Source object includes the following attributes:

   a.  DataFlowSpecification (Section 8.1)

   b.  TrafficSpecification (Section 8.2)

   c.  FlowRank (Section 8.3)

   d.  EndSystemInterfaces (Section 11.1)

   e.  InterfaceCapabilities (Section 11.2)

   f.  UserToNetworkRequirements (Section 11.3)

   For the join operation, the DataFlowSpecification, FlowRank,
   EndSystemInterfaces, and TrafficSpecification SHALL be included
   within the Source.  For the join operation, the
   UserToNetworkRequirements and InterfaceCapabilities groups MAY be
   included within the Source.

   For the leave operation, the DataFlowSpecification and
   EndSystemInterfaces SHALL be included within the Source.

   For the modify operation, the same object SHALL and MAY included as
   for the join operation.

10.  Destination

   The Destination object includes the following attributes:

   a.  DataFlowSpecification (Section 8.1)

   b.  EndSystemInterfaces (Section 11.1)

   c.  InterfaceCapabilities (Section 11.2)

   d.  UserToNetworkRequirements (Section 11.3)

   For the join operation, the DataFlowSpecification and
   EndSystemInterfaces SHALL be included within the Destination.  For
   the join operation, the UserToNetworkRequirements and
   InterfaceCapabilities groups MAY be included within the Destination.

   For the leave operation, the DataFlowSpecification and
   EndSystemInterfaces SHALL be included within the Destination.

   For the modify operation, the same object SHALL and MAY included as
   for the join operation.

   [[NOTE (to be removed from a future revision): Adding a general
   EndpointRank?  That would define the endpoint importance (source,
   destination).  It is only partly covered by FlowRank ...  For
   example, it could distinguish the importance of Destinations if DetNet Flow

   DnFlowStatus provides the
   flow cannot be provided for all Destinations.]]

11.  Common Attributes status of Source and Destination

   Source and Destination end systems have the following common
   attributes in addition DetNet flow with respect to DataFlowSpecification (Section 8.1).

11.1.  End System Interfaces

   EndSystemInterfaces is a list
   the establishment of identifiers, one for each physical
   interface (port) in the end system acting as a Source or Destination.
   An interface is identified by an IP or a MAC address.

   EndSystemInterfaces can refer also to logical sub-Interfaces if
   supported flow by the end system, e.g., based on IfIndex parameter.

11.2.  Interface Capabilities

   InterfaceCapabilities specifies DetNet domain.

   The DnFlowStatus SHALL include the network capabilities following attributes:

   a.  DnIngressStatus is an enumeration for the status of all
   interfaces (ports) contained in the EndSystemInterfaces object
   (Section 11.1).  These capabilities may be configured via flow's
       Ingress reference point:

       *  None: no Ingress.

       *  Ready: Ingress is ready.

       *  Failed: Ingress failed.

       *  OutOfService: Administratively blocked.

   b.  DnEgressStatus is an enumeration for the
   InterfaceConfiguration object (Section 15.2) status of the Status object
   (Section 15).

   Note that an end system may have multiple interfaces with different
   network capabilities.  In this case, each interface should be
   specified in a distinct top-level Source flow's
       Egress reference points:

       *  None: no Egress.

       *  Ready: all Egresses are ready.

       *  PartialFailed: One or Destination object (i.e., more Egress ready, and one entry in EndSystemInterfaces (Section 11.1)).  Use of multiple
   entries in EndSystemInterfaces or more
          Egress failed.  The DetNet flow can be used if the Ingress is intended for network capabilities
          Ready.

       *  Failed: All Egresses failed.

       *  OutOfService: Administratively blocked.

   c.  FailureCode: A non-zero code that span multiple interfaces specifies the problem if the
       DetNet flow encounters a failure (e.g., packet replication and
   elimination).";.

   InterfaceCapabilities attributes:

   a.  SubInterfaceCapable (sub-interface capable)

   b.  PREF-Capable (packet replication and
       elimination capable)

   c.  POF-Capable (packet ordering capable)

   [[NOTE is requested but not possible, or DnIngressStatus is
       Failed, or DnEgressStatus is Failed, or DnEgressStatus is
       PartialFailed).

   [[Editor's note (to be removed from a future revision): InterfaceCapabilities
   attributes are FailureCodes
   to be defined.  For information, [IEEE8021Qcc]
   specifies the following attributes:

   o  VlanTagCapable (Customer VLAN Tag capable)

   o  CB-Capable (frame replication and elimination capable)

   o  CB-StreamIdenTypeList (a list defined for DetNet.  Table 46-1 of the optional Stream
      Identification types supported by the interface as specified in
      [IEEE8021CB].)

   o  CB-SequenceTypeList (a list [IEEE8021Qcc] describes TSN
   failure codes.]]

5.9.  Requirements of the optional Sequence Encode/Decode
      types supported by the interface as specified in [IEEE8021CB].)

   ]]

11.3.  User to Network Requirements

   UserToNetworkRequirements DetNet Flow

   DnFlowRequirements specifies user requirements for the flow,
   such as latency and reliability. to ensure proper serving of
   the DetNet flow.

   The UserToNetworkRequirements object DnFlowRequirements includes the following attributes:

   a.  MinBandwidth

   b.  MaxLatency

   c.  MaxLatencyVariation

   d.  MaxLoss

   e.  MaxConsecutiveLossTolerance
   f.  MaxMisordering

5.9.1.  Minimum Bandwidth of the DetNet Flow

   MinBandwidth is the minimum bandwidth that has to be guaranteed for
   the DetNet flow.

5.9.2.  Maximum Latency of the DetNet Flow

   MaxLatency is the maximum latency from Source Ingress to Destination(s) Egress(es) for a
   single packet of the DetNet flow.  MaxLatency is specified as an
   integer number of nanoseconds.  When this requirement is specified by

5.9.3.  Maximum Latency Variation of the
   Source, it must be satisfied for all Destinations.  When this
   requirement DetNet Flow

   MaxLatencyVariation is specified by a Destination, it must be satisfied for
   that particular Destination only.  If the UserToNetworkRequirements
   group is not provided within difference between the Source or Destination object, then
   value zero SHALL be used for this element.  Value zero represents a
   special use for minimum and the
   maximum latency requirement.  Value zero locks-
   down the initial latency that the network provides in the
   AccumulatedLatency parameter end-to-end one-way latency.

5.9.4.  Maximum Loss of the Status object (Section 15) after DetNet Flow

   MaxLoss defines the successful configuration of maximum Packet Loss Ratio (PLR) requirement for
   the flow, such that any subsequent
   increase in DetNet flow between the latency beyond that initial value causes Ingress and Egress(es).

5.9.5.  Maximum Consequtive Loss of the flow to
   fail.

   [[NOTE-1 (to be removed from a future revision): Should we add a DetNet Flow

   Some applications have special loss requirement, like
   MaxConsecutiveLossTolerance.  The maximum consecutive loss tolerance
   parameter to specify describes the maximum packet number of consecutive packets whose
   loss rate that can be
   tolerated for the flow?]]

   [[NOTE-2 (to be removed from a future revision): TrafficSpecification
   (Section 8.2) specifies the Peak Information Rate (PIR) of the flow,
   which is a kind of user requirement to the network.  Should we add
   Committed Information Rate (CIR), i.e., the minimum rate the user
   requests to tolerated.  The maximum consecutive loss tolerance can be guaranteed
   measured for example based on sequence number.

5.9.6.  Maximum Misordering Tolerance of the flow by the network?]]

12.  Ingress

   Placeholder ...

13.  Egress

   Placeholder ...

14.  DetNet Domain

   The DetNet Domain may change Flow

   MaxMisordering describes the encapsulation tolerable maximum number of a DetNet L2 or L3
   flow at the UNI.  That impacts not only how a flow packets that
   can be recognised
   inside the DetNet domain but also the resource reservation
   calculations. received out of order.  The DetNet Domain object specifies:

   o maximum allowed misordering can be
   measured for example based on sequence number.  The behavior of value zero for
   the flow (how/when it maximum allowed misordering indicates that in order delivery is transmited).

   o  The requirements
   required, misordering cannot be tolerated.

5.10.  BiDir requirement of the flow from DetNet Flow

   DnFlowBiDir attribute defines the network.

   o  The capabilities requirement whether the served
   packets have to be routed together with packets of other flows
   through the DetNet domain.

   The domain, e.g., to provide congruent paths in the
   two directions.

6.  DetNet domain object includes Service Related Parameters

   DetNet service have the following attributes:

   a.  DataFlowSpecification  DnServiceID (Section 8.1) 6.1)

   b.  TrafficSpecification  DnServiceDeliveryType (Section 8.2) 6.2)

   c.  ServiceRank  DnServiceDeliveryProfile (Section 16) 6.3)

   d.  DetnetDomainCapabilities  DNServiceConnectivity (Section 14.1) 6.4)

   e.  UserToNetworkRequirements  DnServiceBiDir (Section 6.5)

   f.  DnServiceRank (Section 6.6)

   g.  DnServiceStatus (Section 11.3)

14.1. 6.7)

   Service attributes are described in the following sections.

6.1.  Management ID of the DetNet Domain Capabilities

   DetnetDomainCapabilities specifies service

   A unique (management) identifier is needed for each DetNet service
   within the network capabilities, which DetNet domain.  It is specified in DnServiceID.  It can be
   used to provide DetNet service.  DetNet Edge nodes may change define the encapsulation M:1 mapping of a flow according DetNet flows to the data plane used inside
   the a DetNet domain.

   DetnetDomainCapabilities object includes the following attributes:

   a.  EncapsulationFormat (data plane specific encapsulation)

   b.  PREF-Capable (packet replication and elimination capable)

15.  Flow-status

   The FlowStatus object is provided by the network each Source and
   Destination of the flow.  The Status object provides the status service.

6.2.  Delivery Type of the flow with respect DetNet service

   DnServiceDeliveryType attribute is set according to the establishment payload of
   the served DetNet flow by (i.e., the
   network. encapsulated App-flow format).  The Status object is delivered via
   attribute can be Ethernet, MPLS, or IP.

6.3.  Delivery Profile of the corresponding UNI DetNet Service

   DnServiceDeliveryProfile specifies delivery profile to
   each Source and Destination end system ensure proper
   serving of the DetNet flow.

   The Status is
   distinct for each Source or Destination because the
   AccumulatedLatency and InterfaceConfiguration objects are distinct,
   see below.

   The Status object SHALL include DnServiceDeliveryProfile includes the attributes a), b), c); and MAY
   include attributes d), e): following attributes:

   a.  DataFlowSpecification (Section 8.1)  MinBandwidth

   b.  StatusInfo (Section 15.1)

   c.  AccumulatedLatency (this section below)

   d.  InterfaceConfiguration (Section 15.2)

   e.  FailedInterfaces (Section 15.3)
   DataFlowSpecification identifies the flow for which status is
   provided.  DataFlowSpecification is described in (Section 8.1) If  MaxLatency

   c.  MaxLatencyVariation

   d.  MaxLoss

   e.  MaxConsecutiveLossTolerance
   f.  MaxMisordering

6.3.1.  Minimum Bandwidth of the
   Status object DetNet Service

   MinBandwidth is provided without a Source or Destination object in a
   protocol message via a UNI, then the DataFlowSpecification object
   SHALL minimum bandwidth that has to be included within the Status object guaranteed for both join and leave
   operations.  If the Status object immediately follows a Source or
   Destination object in the protocol message, then
   the
   DataFlowSpecification object is obtained from DetNet service.

6.3.2.  Maximum Latency of the Source/Destination
   object, and therefore DataFlowSpecification DetNet Service

   MaxLatency is not required within
   the Status object.

   AccumulatedLatency provides the worst-case maximum latency that from Ingress to Egress(es) for a
   single packet of the flow can encounter along its current path(s) in the
   network.  When provided to a Source, AccumulatedLatency is the worst-
   case latency for all Destinations (worst path).  AccumulatedLatency DetNet flow.  MaxLatency is specified as an
   integer number of nanoseconds.

6.3.3.  Maximum Latency Variation of the DetNet Service

   MaxLatencyVariation is
   measured using the time at which difference between the data frame's message timestamp
   point passes minimum and the reference plane marking
   maximum end-to-end one-way latency.

6.3.4.  Maximum Loss of the DetNet Service

   MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the boundary
   DetNet service between the
   network media Ingress and PHY. Egress(es) of the DetNet
   domain.

6.3.5.  Maximum Consequtive Loss of the DetNet Service

   Some applications have special loss requirement, like
   MaxConsecutiveLossTolerance.  The message timestamp point is specified by
   IEEE Std 802.1AS [IEEE8021AS] 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 for various media.  For example based on sequence number.

6.3.6.  Maximum Misordering Tolerance of the DetNet Service

   MaxMisordering describes the tolerable maximum number of packets that
   can be received out of order.  The maximum allowed misordering can be
   measured for example based on sequence number.  The value zero for
   the maximum allowed misordering indicates that in order delivery is
   required, misordering cannot be tolerated.

6.4.  Connectivity Type of the DetNet Service

   Two connectivity types are distinguished: point-to-point (p2p) and
   point-to-multipoint (p2mp).  Connectivity type p2mp is created by a successful
   Status, the network returns
   transport layer function (e.g., p2mp LSP).  (Note: mp2mp connectivity
   is a value less than or equal to the
   MaxLatency superposition of the UserToNetworkRequirements (Section 11.3).  If the
   NumReplicationTrees p2mp connections.)

6.5.  BiDir requirement of the UserToNetworkRequirements (Section 11.3)
   is one, then the AccumlatedLatency SHALL provide the worst latency
   for DetNet Service

   DnServiceBiDir attribute defines the current path from requirement whether the Source served
   packets have to each Destination.  If be routed together with packets of other service
   instances through the
   path is changed (e.g., due DetNet domain, e.g., to rerouting), then provide congruent paths
   in the AccumulatedLatency
   changes accordingly.  If two directions.

6.6.  Rank of the DetNet Service

   DnServiceRank attribute provides the NumReplicationTrees rank of a service instance
   relative to other services in the
   UserToNetworkRequirements (Section 11.3) DetNet domain.  DnServiceRank
   (range: 0-255) is greater than one,
   AccumlatedLatency SHALL provide used by the worst latency for all paths network in
   use from the Source to each Destination.

15.1. case of network resource
   limitation scenarios.

6.7.  Status Info

   StatusInfo provides of the DetNet Service

   DnServiceStatus information regarding group includes elements that specify the
   status of a flow's
   configuration in the network. service specific state of the DetNet domain.  This
   information group informs the user whether or not the service is
   ready for use.

   The StatusInfo object MAY DnServiceStatus SHALL include the following attributes:

   a.  SourceStatus  DnServiceIngressStatus is an enumeration for the status of the flow's
       Source:
       service's Ingress:

       *  None: no Source Ingress.

       *  Ready: Source Ingress is ready ready.

       *  Failed: Source failed Ingress failed.

       *  OutOfService: Administratively blocked.

   b.  DestinationStatus  DnServiceEgressStatus is an enumeration for the status of the flow's
       Destinations:
       service's Egress:

       *  None: no Destination Egress.

       *  Ready: all Destinations Egresses are ready ready.

       *  PartialFailed: One or more Destinations Egress ready, and one or more
          Listeners
          Egress failed.  The DetNet flow can be used if the Source Ingress is
          Ready.

       *  Failed: All Destinations Egresses failed.

       *  OutOfService: Administratively blocked.

   c.  FailureCode:  DnServiceFailureCode: A non-zero code that specifies the problem
       if the
       flow DetNet service encounters a failure (e.g., packet
       replication and elimination is requested but not possible, or SourceStatus
       DnServiceIngressStatus is Failed, or DestinationStatus DnServiceEgressStatus is
       Failed, or DestinationStatus DnServiceEgressStatus is PartialFailed).

   [[NOTE

   [[Editor's note (to be removed from a future revision): FailureCodes
   DnServiceFailureCodes to be defined for DetNet. DetNet service.  Table 46-1
   of [IEEE8021Qcc] describes TSN failure codes.]]

15.2.  Interface Configuration

   InterfaceConfiguration provides

7.  Flow Specific Operations

   The DetNet flow information model relies on three high level
   information groups:

   o  DnIngress: 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.

   o  DnEgress: 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.

   o  DnFlowStatus: The status information about group includes elements that
      specify the status of interfaces the flow in the Source/Destination. network.  This configuration related information
   assists
      group is applied from the network in meeting to the requirements user of the flow.  The
   InterfaceConfiguration object is according to DetNet
      service.  This information group informs the capabilities of user whether or not
      the
   interface.  InterfaceConfiguration can be distinct DetNet flow is ready for use.

   There are three possible operations for each DetNet flow with respect
   to its DetNet service at a DN Ingress or a DN Egress (similarly to
   App-flows at a Source or
   Destination of each a Destination):

   o  Join: DN Ingress/DN Egress intends to join the flow.  If

   o  Leave: DN Ingress/DN Egress intends to leave the InterfaceConfiguration object is
   not provided within flow.

   o  Modify: DN Ingress/DN Egress intends to change the Status object, then flow.

7.1.  Join Operation

   For the network join operation, the DnFlowSpecification, DnFlowRank,
   DnFlowEndpoint, and DnTrafficSpecification SHALL assume
   zero elements as be included within
   the default (no interface configuration).

   The InterfaceConfiguration object MAY include one DnIngress or more DnEgress information group.  For the
   following attributes:

   a.  MAC join operation,
   the DnServiceRequirements groups MAY be included.

7.2.  Leave Operation

   For the leave operation, the DnFlowSpecification and DnFlowEndpoint
   SHALL be included within the DnIngress or IP Address to identify DnEgress information group.

7.3.  Modify Operation

   For the interface

   b.  DataFlowSpecification (Section 8.1)

15.3.  Failed Interfaces

   FailedInterfaces provides a list of one modify operation, the DnFlowSpecification, DnFlowRank,
   DnFlowEndpoint, and DnTrafficSpecification SHALL be included within
   the DnIngress or more physical interfaces
   (ports) in DnEgress information group.  For the failed node join operation,
   the DnServiceRequirements groups MAY be included.

   Modify operation can be considered to address cases when a failure occurs in the network. flow is
   slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been
   changed.  The FailedInterface object includes the following attributes:

   a.  MAC or IP Address advantage of having a Modify is that it allows to identify
   initiate a change of flow spec while leaving the interface

   b.  InterfaceName

   InterfaceName current flow is
   operating until the name of change is accepted.  If there is no linkage
   between the interface (port) within Join and the Leave, then in figuring out whether the node.
   This interface name SHALL new
   flow spec can be persistent, and unique within supported, the node.

16.  Service Rank

   ServiceRank provides controller entity has to assume that
   the rank of this service instance relative resources committed to
   other services the current flow are in use.  Via Modify
   the network.  This rank is used to determine
   success/failure of service instance establishment.  Rank (boolean) is
   used by controller entity knows that the network to decide which services can and cannot exist
   when network resources reach their limit.  Rank is used to help to
   determine which services supporting the current
   flow can be dropped (i.e., removed from node
   configuration) if a port of a node becomes oversubscribed (e.g., due
   to network reconfiguration).  The true value is more important than available for supporting the false value (i.e., services with false are dropped first).

   [[NOTE: relationship between ServiceRank and FlowRank needs further
   discussions.  A 1:N relationship is assumed (a service instance can
   serv multiple flows).  This sub-section altered flow.  Modify is
   considered to move be an optional operation due to the
   service related sections. ]]

17.  Service-status

   Placeholder ...

18. possible controller
   plane limitations.

8.  Summary

   This document describes DetNet flow information model both and service
   information model for DetNet
   L3 flows IP networks and DetNet L2 flows based on the TSN data model specified by
   [IEEE8021Qcc].  This revision is extended with DetNet specific flow
   information model elements.

19. MPLS networks.

9.  IANA Considerations

   N/A.

20.

10.  Security Considerations

   N/A.

21.

11.  References
21.1.

11.1.  Normative References

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-11
              detnet-architecture-13 (work in progress), February May 2019.

   [I-D.ietf-detnet-dp-sol-mpls]
              Korhonen, J.

   [I-D.ietf-detnet-ip]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and B. J. Korhonen, "DetNet Data Plane: IP",
              draft-ietf-detnet-ip-01 (work in progress), July 2019.

   [I-D.ietf-detnet-mpls]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and J. Korhonen, "DetNet MPLS Data Plane
              Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 Plane: MPLS",
              draft-ietf-detnet-mpls-01 (work in progress), October 2018. July 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6003]  Papadimitriou, D., "Ethernet Traffic Parameters",
              RFC 6003, DOI 10.17487/RFC6003, October 2010,
              <https://www.rfc-editor.org/info/rfc6003>.

21.2.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2.  Informative References

   [GPP22885]
              3GPP, "Study on LTE support for Vehicle-to-Everything
              (V2X) services",
              <http://www.3gpp.org/DynaReport/22885.html>.

   [I-D.ietf-detnet-use-cases]
              Grossman, E., "Deterministic Networking Use Cases", draft-
              ietf-detnet-use-cases-20

   [I-D.ietf-detnet-data-plane-framework]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and J. Korhonen, "DetNet Data Plane
              Framework", draft-ietf-detnet-data-plane-framework-01
              (work in progress), December
              2018.

   [IEEE8021AS]
              IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local
              and metropolitan area networks - Timing and
              Synchronization for Time-Sensitive Applications in Bridged
              Local Area Networks", 2011,
              <http://standards.ieee.org/getieee802/
              download/802.1AS-2011.pdf>. July 2019.

   [IEEE8021CB]
              IEEE 802.1, Standards Association, "IEEE P802.1CB: Std 802.1CB-2017 IEEE Draft
              Standard for Local and metropolitan area networks - Frame
              Replication and Elimination for Reliability", 2017,
              <http://www.ieee802.org/1/pages/802.1cb.html>.
              <https://ieeexplore.ieee.org/document/8091139/>.

   [IEEE8021Q]
              IEEE 802.1, Standards Association, "IEEE 802.1Q-2014: Std 802.1Q-2018 IEEE
              Standard for Local and metropolitan area networks -
              Bridges and Bridged Networks", 2014, <http://standards.ieee.org/getieee802/
              download/802-1Q-2014.pdf>. 2018,
              <https://ieeexplore.ieee.org/document/8403927>.

   [IEEE8021Qbv]
              IEEE 802.1, Standards Association, "IEEE 802.1Qbv-2015: Std 802.1Qbv-2015 IEEE
              Standard for Local and metropolitan area networks -
              Bridges and Bridged Networks -- - Amendment 25: Enhancements
              for Scheduled Traffic", 2015, <https://standards.ieee.org/findstds/
              standard/802.1Qbv-2015.html>.
              <https://ieeexplore.ieee.org/document/7572858/>.

   [IEEE8021Qcc]
              IEEE 802.1, Standards Association, "IEEE P802.1Qcc-2015: Std 802.1Qcc-2018: IEEE Draft
              Standard for Local and metropolitan area networks -
              Bridges and Bridged Networks -- Amendment: Amendment 31: Stream
              Reservation Protocol (SRP) Enhancements and Performance
              Improvements", 2017,
              <http://www.ieee802.org/1/pages/802.1cc.html>. 2018,
              <https://ieeexplore.ieee.org/document/8514112/>.

   [IEEE8021TSN]
              IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN)
              Task Group", <http://www.ieee802.org/1/pages/tsn.html>.

   [IETFDetNet]
              IETF, "IETF Deterministic Networking (DetNet) Working
              Group", <https://datatracker.ietf.org/wg/detnet/charter/>.

Authors' Addresses

   Janos Farkas
   Ericsson
   Magyar tudosok korutja 11
   Budapest  1117
   Hungary

   Email: janos.farkas@ericsson.com

   Balazs Varga
   Ericsson
   Magyar tudosok korutja 11
   Budapest  1117
   Hungary

   Email: balazs.a.varga@ericsson.com
   Rodney Cummings
   National Instruments
   11500 N. Mopac Expwy
   Bldg. C
   Austin, TX  78759-3504
   USA

   Email: rodney.cummings@ni.com

   Yuanlong Jiang
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen  518129
   China

   Email: jiangyuanlong@huawei.com