DetNet                                                         J. Farkas
Internet-Draft                                                  B. Varga
Intended status: Standards Track                                Ericsson
Expires: April 29, 2020                                      R. Cummings
                                                    National Instruments
                                                                Y. Jiang
                                           Huawei Technologies Co., Ltd.
                                                                D. Fedyk
                                                 LabN Consulting, L.L.C.
                                                        October 27, 2019


                     DetNet Flow Information Model
              draft-ietf-detnet-flow-information-model-06

Abstract

   This document describes flow and service information model for
   Deterministic Networking (DetNet).  These models are defined for IP
   and 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 April 29, 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



Farkas, et al.           Expires April 29, 2020                 [Page 1]


Internet-Draft        DetNet Flow Information Model         October 2019


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.2.  Non Goals . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   6
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Naming Conventions  . . . . . . . . . . . . . . . . . . .   7
     2.4.  Requirements Language . . . . . . . . . . . . . . . . . .   7
   3.  DetNet Domain and its Modeling  . . . . . . . . . . . . . . .   7
     3.1.  DetNet Service Overview . . . . . . . . . . . . . . . . .   7
     3.2.  Reference Points Used in Modeling . . . . . . . . . . . .   8
     3.3.  Information Elements  . . . . . . . . . . . . . . . . . .   8
   4.  App-flow Related Parameters . . . . . . . . . . . . . . . . .   9
     4.1.  App-flow Characteristics  . . . . . . . . . . . . . . . .   9
     4.2.  App-flow Requirements . . . . . . . . . . . . . . . . . .   9
   5.  DetNet Flow Related Parameters  . . . . . . . . . . . . . . .  10
     5.1.  Management ID of the DetNet Flow  . . . . . . . . . . . .  10
     5.2.  Payload type of the DetNet Flow . . . . . . . . . . . . .  11
     5.3.  Format of the DetNet Flow . . . . . . . . . . . . . . . .  11
     5.4.  Identification and Specification of DetNet Flows  . . . .  11
       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  . . . . . . . .  11
     5.6.  Endpoints of the DetNet Flow  . . . . . . . . . . . . . .  12
     5.7.  Rank of the DetNet Flow . . . . . . . . . . . . . . . . .  12
     5.8.  Status of the DetNet Flow . . . . . . . . . . . . . . . .  13
     5.9.  Requirements of the DetNet Flow . . . . . . . . . . . . .  13
       5.9.1.  Minimum Bandwidth of the DetNet Flow  . . . . . . . .  14
       5.9.2.  Maximum Latency of the DetNet Flow  . . . . . . . . .  14
       5.9.3.  Maximum Latency Variation of the DetNet Flow  . . . .  14
       5.9.4.  Maximum Loss of the DetNet Flow . . . . . . . . . . .  14
       5.9.5.  Maximum Consecutive 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 . . . . . . . . . . . . . .  15
     6.1.  Management ID of the DetNet service . . . . . . . . . . .  15
     6.2.  Delivery Type of the DetNet service . . . . . . . . . . .  15
     6.3.  Delivery Profile of the DetNet Service  . . . . . . . . .  15
       6.3.1.  Minimum Bandwidth of the DetNet Service . . . . . . .  15
       6.3.2.  Maximum Latency of the DetNet Service . . . . . . . .  16
       6.3.3.  Maximum Latency Variation of the DetNet Service . . .  16



Farkas, et al.           Expires April 29, 2020                 [Page 2]


Internet-Draft        DetNet Flow Information Model         October 2019


       6.3.4.  Maximum Loss of the DetNet Service  . . . . . . . . .  16
       6.3.5.  Maximum Consecutive Loss of the DetNet Service  . . .  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 . . . . . . . . .  16
     6.6.  Rank of the DetNet Service  . . . . . . . . . . . . . . .  17
     6.7.  Status of the DetNet Service  . . . . . . . . . . . . . .  17
   7.  Flow Specific Operations  . . . . . . . . . . . . . . . . . .  18
     7.1.  Join Operation  . . . . . . . . . . . . . . . . . . . . .  18
     7.2.  Leave Operation . . . . . . . . . . . . . . . . . . . . .  18
     7.3.  Modify Operation  . . . . . . . . . . . . . . . . . . . .  18
   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   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 [I-D.ietf-detnet-architecture].

   This document describes the Detnet Flow Service Information Model.
   For reference [RFC3444] describes the rational behind Information
   Models in general.  This document describes the Flow and Service
   information models for operators and users to understand Detnet
   services, and for implementors as a guide to the functionality
   required by Detnet services.

   The DetNet Architecture treats the 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
   mechanisms.

   In the IETF DetNet service utilizes 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].
   IEEE 802.1 Time Sensitive Networking (TSN) utilizes Ethernet and is
   defined over Ethernet networks.  A DetNet flow includes one or more
   App-flow(s) as payload.  App-flows can be Ethernet, MPLS, or IP



Farkas, et al.           Expires April 29, 2020                 [Page 3]


Internet-Draft        DetNet Flow Information Model         October 2019


   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 etc.).  In some scenarios
   App-flow and DetNet 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 contains both DetNet flow and App-flow specific information
   in an integrated fashion.

   In a given network scenario three information models can
   distinguished:

   o  Flow models that 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 that 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 that describe in detail the settings required
      on network nodes to provide a data flow proper service.

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





Farkas, et al.           Expires April 29, 2020                 [Page 4]


Internet-Draft        DetNet Flow Information Model         October 2019


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

         Figure 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 origination of the
   DetNet flow information model was the flow identification
   possibilities described in [IEEE8021CB], which is used by
   [IEEE8021Qcc] as well.  In addition to the TSN data model,
   [IEEE8021Qcc] also specifies configuration of TSN features (e.g.,
   traffic scheduling specified by [IEEE8021Qbv]).  The common
   architecture and flow 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.

1.1.  Goals

   As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates
   with IEEE 802.1 TSN in order to define a common architecture for both
   Layer 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
   [IEEE8021Qcc], which is an amendment to [IEEE8021Q].

   This document specifies flow and service information models only.








Farkas, et al.           Expires April 29, 2020                 [Page 5]


Internet-Draft        DetNet Flow Information Model         October 2019


1.2.  Non Goals

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

2.  Terminology

2.1.  Terms Used in This Document

   This document uses the terminology established in the DetNet
   architecture [I-D.ietf-detnet-architecture] and 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.

   The following terminology is used in accordance with
   [I-D.ietf-detnet-architecture]:

   App-flow      The payload (data) carried over a DetNet service.

   DetNet flow   A DetNet flow is a sequence of packets which conform
                 uniquely to a flow 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.

   The following 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 the start of a DetNet flow.
                 Networking technology specific encapsulation may be
                 added here to the served App-flow(s).

   DN Egress     Reference point for the termination of a DetNet flow.
                 Networking technology specific encapsulation may be
                 removed here from the served App-flow(s).







Farkas, et al.           Expires April 29, 2020                 [Page 6]


Internet-Draft        DetNet Flow Information Model         October 2019


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.  Example composed
      names are SourceMacAddress and DestinationIPv6Address.

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

   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.





Farkas, et al.           Expires April 29, 2020                 [Page 7]


Internet-Draft        DetNet Flow Information Model         October 2019


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

3.2.  Reference Points Used in Modeling

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

   App-flow specific reference points are the Source (where it starts)
   and the Destination (where it terminates).  Similarly a DetNet flow
   has reference points termed DN Ingress (where a DetNet flow starts)
   and 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.

   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 encapsulation to/from the served App-
   flow(s) (e.g., MPLS label(s), UDP and IP headers).

3.3.  Information Elements

   The DetNet flow information model and the service model relies on
   three groups of information elements:

   o  App-flow related parameters: 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.).

   o  DetNet flow related parameters: these describe the DetNet flow
      characteristics (e.g., identification, format, traffic
      specification, endpoints, rank, etc.).

   o  DetNet service related parameters: these describe the expected
      service characteristics (e.g., delivery type, connectivity delay/
      loss, status, rank, etc.).

   In the information model a DetNet flow contains one or more
   (aggregated) App-flows (N:1 mapping).  During DetNet 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 relationship for the DetNet
   flow(s) to the DetNet Service.





Farkas, et al.           Expires April 29, 2020                 [Page 8]


Internet-Draft        DetNet Flow Information Model         October 2019


4.  App-flow Related Parameters

   When Deterministic service is required by 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.

4.1.  App-flow Characteristics

   App-flow characteristics are described by the following parameters:

   o  FlowID: a unique (management) identifier of the App-flow.  It can
      be used to define the N:1 mapping of App-flows to a DetNet flow.

   o  FlowType: set by the encapsulation format of the flow.  It can be
      Ethernet (TSN), MPLS, or IP.

   o  DataFlowSpecification: a flow descriptor, defining which packets
      belongs to a flow using, specific packet header fields such as
      src-addr, dst-addr, label, VLAN-ID, etc.

   o  TrafficSpecification: a flow descriptor, defining traffic
      parameters such as packet size, transmission time interval, and
      maximum packets per time interval.

   o  FlowEndpoints: delineate the start and termination reference
      points of the App-flow by pointing to the source interface/node
      and destination interface(s)/node(s).

   o  FlowStatus: indicates the status of the App-flow with respect to
      the establishment of the flow by the connected network, e.g.,
      ready, failed, etc.

   o  FlowRank: indicates the rank of this flow relative to other flows
      in the connected network.

4.2.  App-flow Requirements

   App-flow requirements are described by the following parameters:

   o  FlowRequirements: defines the attributes of the App-flow regarding
      bandwidth, latency, latency variation, loss, and misordering
      tolerance.

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



Farkas, et al.           Expires April 29, 2020                 [Page 9]


Internet-Draft        DetNet Flow Information Model         October 2019


5.  DetNet Flow Related Parameters

   The Data model specified by [IEEE8021Qcc] describes data flows using
   TSN service as periodic flows with fix packet size (i.e., Constant
   Bit Rate (CBR) flows) or with variable packet size.  The same concept
   is applied 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 latency and loss.  For
   example, some real-time applications allow graceful degradation if
   loss happens (e.g., sample-based data processing, media
   distribution).  Some other applications may require high-bandwidth
   connections that make use of packet replication techniques which are
   economically challenging or even impossible.  Some applications may
   not tolerate loss, but are not delay sensitive (e.g., bufferless
   sensors).  Time or loss sensitive applications may have somewhat
   special requirements especially for loss (e.g., no loss over two
   consecutive communication cycles; very low outage time, etc.).

   DetNet flows have the following attributes:

   a.  DnFlowID (Section 5.1)
   b.  DnPayloadType (Section 5.2)
   c.  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 5.9)
   o  DnFlowBiDir (Section 5.10)

   Flow attributes are described in the following sections.

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 by DnFlowID.  It can be
   used to define the many to one mapping of DetNet flows to a DetNet
   service.







Farkas, et al.           Expires April 29, 2020                [Page 10]


Internet-Draft        DetNet Flow Information Model         October 2019


5.2.  Payload type of the DetNet Flow

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

5.3.  Format of the DetNet Flow

   The DnFlowFormat attribute is set according to the 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 Ingress/Egress and
   within the DetNet domain are specified as follows; see Section 5.4.1
   for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows.

5.4.1.  DetNet MPLS Flow Identification and Specification

   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 [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 (6-tuple) [I-D.ietf-detnet-ip]:

   a.  SourceIpAddress
   b.  DestinationIpAddress
   c.  IPv6FlowLabel
   d.  Dscp (attribute)
   e.  Protocol
   f.  SourcePort
   g.  DestinationPort
   h.  IPSecSpi

5.5.  Traffic Specification of the DetNet Flow

   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.



Farkas, et al.           Expires April 29, 2020                [Page 11]


Internet-Draft        DetNet Flow Information Model         October 2019


   TrafficSpecification has the following attributes:

   a.  Interval: the period of time in which the traffic specification
       is specified.

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

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

   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 sensitive).
   Possible options how to extend DnTrafficSpecification attributes is
   for further discussion. ]]

5.6.  Endpoints of the DetNet Flow

   The DnFlowEndpoints attribute defines the starting and termination
   reference points of the DetNet flow by pointing to the ingress
   interface/node and egress interface(s)/node(s).  Depending on the
   network scenario it defines an interface or a node.  Interface can be
   defined for example if the App-flow is a TSN Stream and it is
   received over a well defined UNI interface.  For example, for App-
   flows with MPLS encapsulation defining an ingress node is more common
   when per platform label space is used.

5.7.  Rank of the DetNet Flow

   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 for example a port of a node becomes
   oversubscribed (e.g., due to network re-configuration).








Farkas, et al.           Expires April 29, 2020                [Page 12]


Internet-Draft        DetNet Flow Information Model         October 2019


5.8.  Status of the DetNet Flow

   DnFlowStatus provides the status of the DetNet flow with respect to
   the establishment of the flow by the DetNet domain.

   The DnFlowStatus SHALL include the following attributes:

   a.  DnIngressStatus is an enumeration for the status of the 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 status of the flow's
       Egress reference points:

       *  None: no Egress.
       *  Ready: all Egresses are ready.
       *  PartialFailed: One or more Egress ready, and one or more
          Egress failed.  The DetNet flow can be used if the Ingress is
          Ready.
       *  Failed: All Egresses failed.
       *  OutOfService: Administratively blocked.

   c.  FailureCode: A non-zero code that specifies the error if the
       DetNet flow encounters a failure (e.g., packet replication and
       elimination 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): FailureCodes
   to be defined for DetNet.  Table 46-1 of [IEEE8021Qcc] describes TSN
   failure codes.]]

5.9.  Requirements of the DetNet Flow

   DnFlowRequirements specifies requirements to ensure the service level
   desired for the DetNet flow.

   The DnFlowRequirements includes the following attributes:

   a.  MinBandwidth(Section 5.9.1)
   b.  MaxLatency(Section 5.9.2)
   c.  MaxLatencyVariation(Section 5.9.3)
   d.  MaxLoss(Section 5.9.4)
   e.  MaxConsecutiveLossTolerance(Section 5.9.5)



Farkas, et al.           Expires April 29, 2020                [Page 13]


Internet-Draft        DetNet Flow Information Model         October 2019


   f.  MaxMisordering(Section 5.9.6)

5.9.1.  Minimum Bandwidth of the DetNet Flow

   MinBandwidth is the minimum bandwidth that has to be guaranteed for
   the DetNet flow.  MinBandwidth is specified in octets per second.

5.9.2.  Maximum Latency of the DetNet Flow

   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.

5.9.3.  Maximum Latency Variation of the DetNet Flow

   MaxLatencyVariation is the difference between the minimum and the
   maximum end-to-end one-way latency.  MaxLatencyVariation is specified
   as an integer number of nanoseconds.

5.9.4.  Maximum Loss of the DetNet Flow

   MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
   the DetNet flow between the Ingress and Egress(es).

5.9.5.  Maximum Consecutive Loss of the DetNet Flow

   Some applications have 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 for example based on sequence number.

5.9.6.  Maximum Misordering Tolerance of the DetNet Flow

   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.

5.10.  BiDir requirement of the DetNet Flow

   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.




Farkas, et al.           Expires April 29, 2020                [Page 14]


Internet-Draft        DetNet Flow Information Model         October 2019


6.  DetNet Service Related Parameters

   DetNet service have the following attributes:

   a.  DnServiceID (Section 6.1)
   b.  DnServiceDeliveryType (Section 6.2)
   c.  DnServiceDeliveryProfile (Section 6.3)
   d.  DNServiceConnectivity (Section 6.4)
   e.  DnServiceBiDir (Section 6.5)
   f.  DnServiceRank (Section 6.6)
   g.  DnServiceStatus (Section 6.7)

   Service attributes are described in the following sections.

6.1.  Management ID of the DetNet service

   A unique (management) identifier for each DetNet service within the
   DetNet domain.  It can be used to define the many to one mapping of
   DetNet flows to a DetNet service.

6.2.  Delivery Type of the DetNet service

   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.

6.3.  Delivery Profile of the DetNet Service

   DnServiceDeliveryProfile specifies delivery profile to ensure proper
   serving of the DetNet flow.

   The DnServiceDeliveryProfile includes the following attributes:

   a.  MinBandwidth(Section 6.3.1)
   b.  MaxLatency(Section 6.3.2)
   c.  MaxLatencyVariation(Section 6.3.3)
   d.  MaxLoss(Section 6.3.4)
   e.  MaxConsecutiveLossTolerance(Section 6.3.5)
   f.  MaxMisordering(Section 6.3.6)

6.3.1.  Minimum Bandwidth of the DetNet Service

   MinBandwidth is the minimum bandwidth that has to be guaranteed for
   the DetNet service.  MinBandwidth is specified in octets per second.







Farkas, et al.           Expires April 29, 2020                [Page 15]


Internet-Draft        DetNet Flow Information Model         October 2019


6.3.2.  Maximum Latency of the DetNet Service

   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.

6.3.3.  Maximum Latency Variation of the DetNet Service

   MaxLatencyVariation is the difference between the minimum and the
   maximum end-to-end one-way latency.  MaxLatencyVariation is specified
   as an integer number of nanoseconds.

6.3.4.  Maximum Loss of the DetNet Service

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

6.3.5.  Maximum Consecutive Loss of the DetNet Service

   Some applications have 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 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
   transport layer function (e.g., p2mp LSP).  (Note: mp2mp connectivity
   is a superposition of p2mp connections.)

6.5.  BiDir requirement of the DetNet Service

   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.



Farkas, et al.           Expires April 29, 2020                [Page 16]


Internet-Draft        DetNet Flow Information Model         October 2019


6.6.  Rank of the DetNet Service

   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.

6.7.  Status of the DetNet Service

   DnServiceStatus information group includes elements that specify the
   status of the service specific state of the DetNet domain.  This
   information group informs the user whether or not the service is
   ready for use.

   The DnServiceStatus SHALL include the following attributes:

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

       *  None: no Ingress.
       *  Ready: Ingress is ready.
       *  Failed: Ingress failed.
       *  OutOfService: Administratively blocked.

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

       *  None: no Egress.
       *  Ready: all Egresses are ready.
       *  PartialFailed: One or more Egress ready, and one or more
          Egress failed.  The DetNet flow can be used if the Ingress is
          Ready.
       *  Failed: All Egresses failed.
       *  OutOfService: Administratively blocked.

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

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







Farkas, et al.           Expires April 29, 2020                [Page 17]


Internet-Draft        DetNet Flow Information Model         October 2019


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 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.

   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 a Destination):

   o  Join: DN Ingress/DN Egress intends to join the flow.
   o  Leave: DN Ingress/DN Egress intends to leave the flow.
   o  Modify: DN Ingress/DN Egress intends to change the flow.

7.1.  Join Operation

   For the join operation, the DnFlowSpecification, DnFlowRank,
   DnFlowEndpoint, and DnTrafficSpecification SHALL be included within
   the DnIngress or DnEgress information group.  For the 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 DnEgress information group.

7.3.  Modify Operation

   For the modify operation, the DnFlowSpecification, DnFlowRank,
   DnFlowEndpoint, and DnTrafficSpecification SHALL be included within
   the DnIngress or DnEgress information group.  For the join operation,
   the DnServiceRequirements groups MAY be included.




Farkas, et al.           Expires April 29, 2020                [Page 18]


Internet-Draft        DetNet Flow Information Model         October 2019


   The Modify operation can be considered to address cases when a flow
   is slightly changed, e.g., only MaxPayloadSize (Section 5.5) 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 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.

8.  Summary

   This document describes DetNet flow information model and service
   information model for DetNet IP networks and DetNet MPLS networks.

9.  IANA Considerations

   N/A.

10.  Security Considerations

   Security considerations for DetNet are described in detail in
   [I-D.ietf-detnet-security].  General security considerations are
   described in [I-D.ietf-detnet-architecture].  This section covers
   security for the Flow Information Model and there are no additional
   security considerations introduced by this document.

11.  References

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-13 (work in progress), May 2019.

   [I-D.ietf-detnet-ip]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and 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 Data Plane: MPLS",
              draft-ietf-detnet-mpls-01 (work in progress), July 2019.



Farkas, et al.           Expires April 29, 2020                [Page 19]


Internet-Draft        DetNet Flow Information Model         October 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>.

   [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

   [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-02
              (work in progress), September 2019.

   [I-D.ietf-detnet-security]
              Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
              J., Austad, H., Stanton, K., and N. Finn, "Deterministic
              Networking (DetNet) Security Considerations", draft-ietf-
              detnet-security-05 (work in progress), August 2019.

   [IEEE8021CB]
              IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE
              Standard for Local and metropolitan area networks - Frame
              Replication and Elimination for Reliability", 2017,
              <https://ieeexplore.ieee.org/document/8091139/>.

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

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










Farkas, et al.           Expires April 29, 2020                [Page 20]


Internet-Draft        DetNet Flow Information Model         October 2019


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

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

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              DOI 10.17487/RFC3444, January 2003,
              <https://www.rfc-editor.org/info/rfc3444>.

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






Farkas, et al.           Expires April 29, 2020                [Page 21]


Internet-Draft        DetNet Flow Information Model         October 2019


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

   Email: jiangyuanlong@huawei.com


   Don Fedyk
   LabN Consulting, L.L.C.

   Email: dfedyk@labn.net






































Farkas, et al.           Expires April 29, 2020                [Page 22]