[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-detnet-flow-information-model

DetNet                                                         J. Farkas
Internet-Draft                                                  B. Varga
Intended status: Standards Track                                Ericsson
Expires: May 3, 2018                                         R. Cummings
                                                    National Instruments
                                                             J. Yuanlong
                                                               Z. Yiyong
                                                                  Huawei
                                                        October 30, 2017


                     DetNet Flow Information Model
             draft-farkas-detnet-flow-information-model-02

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 for Layer 3 and Layer
   2 flows in an integrated fashion.

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 May 3, 2018.

Copyright Notice

   Copyright (c) 2017 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



Farkas, et al.             Expires May 3, 2018                  [Page 1]


Internet-Draft        DetNet Flow Information Model         October 2017


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Non Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   5
   3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   5
   4.  Naming Conventions  . . . . . . . . . . . . . . . . . . . . .   5
   5.  End System and DetNet domain  . . . . . . . . . . . . . . . .   6
   6.  Flow  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Identification and Specification of Flows . . . . . . . .   8
       6.1.1.  DetNet L3 Flow Identification and Specification at
               UNI . . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.2.  DetNet L2 Flow Identification and Specification at
               UNI . . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.3.  DetNetwork Flow Identification and Specification  . .  10
     6.2.  Traffic Specification . . . . . . . . . . . . . . . . . .  10
     6.3.  Flow Rank . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.4.  Service Rank  . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Source  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Destination . . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Common Attributes of Source and Destination . . . . . . . . .  13
     9.1.  End System Interfaces . . . . . . . . . . . . . . . . . .  13
     9.2.  Interface Capabilities  . . . . . . . . . . . . . . . . .  13
     9.3.  User to Network Requirements  . . . . . . . . . . . . . .  14
   10. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   11. Egress  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   12. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  DetNet Domain Capabilities . . . . . . . . . . . . . . .  16
   13. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . .  16
     13.1.  Status Info  . . . . . . . . . . . . . . . . . . . . . .  17
     13.2.  Interface Configuration  . . . . . . . . . . . . . . . .  18
     13.3.  Failed Interfaces  . . . . . . . . . . . . . . . . . . .  19
   14. Service-status  . . . . . . . . . . . . . . . . . . . . . . .  19
   15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   17. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     18.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21




Farkas, et al.             Expires May 3, 2018                  [Page 2]


Internet-Draft        DetNet Flow Information Model         October 2017


1.  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-alt].  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].  DetNet service can
   be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and
   DetNet L2 flows.  Therefore, the DetNet flow and service information
   model provided by this document covers both DetNet L3 flows and
   DetNet L2 flows 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.
















Farkas, et al.             Expires May 3, 2018                  [Page 3]


Internet-Draft        DetNet Flow Information Model         October 2017


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

         Figure 1: 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 data model specified by
   [IEEE8021Qcc].  Furthermore, the DetNet flow information model relies
   on 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 the
   Centralized Network / Distributed User Model out of the models
   specified by [IEEE8021Qcc].  That is, there is 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.

1.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 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 along those
   lines.  As the TSN flow information/data model specified by



Farkas, et al.             Expires May 3, 2018                  [Page 4]


Internet-Draft        DetNet Flow Information Model         October 2017


   [IEEE8021Qcc] is mature, 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.

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.

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

3.  Terminology and Definitions

   This document uses the terminology established in Section 2 of the
   DetNet architecture document [I-D.ietf-detnet-architecture].  The
   DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used
   to perform translation from [IEEE8021Qcc] to this document.
   Additional terms used in this document:

   DetNet L3 Flow:  Layer 3 (L3) flow leveraging DetNet service.

   DetNet L2 Flow:  Layer 2 (L2) flow leveraging DetNet service.

   DetNetwork Flow:  DetNet data plane specific encapsulated format of a
      DetNet L2 or L3 flow leveraging DetNet service.

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



Farkas, et al.             Expires May 3, 2018                  [Page 5]


Internet-Draft        DetNet Flow Information Model         October 2017


   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.

5.  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 and Egress.  In addition the technology of the
   DetNet domain 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 a DetNet flow from a Source.
      The 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.



Farkas, et al.             Expires May 3, 2018                  [Page 6]


Internet-Draft        DetNet Flow Information Model         October 2017


   o  Egress: an edge system sending traffic towards a Destination of a
      DetNet flow.  The Egress information group includes elements that
      specify the egress point for 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 and methods for a single
      flow.  This information group is applied within the network.

   o  Service-Status: the status of a DetNet service.  The status
      information group includes elements that specify the status of the
      service specific state of the network.  This information group is
      applied from the network to the user.  This information group
      informs the user whether or not the service is ready for use.

   There are two operations for each flow with respect to a Source or a
   Destination (and an Ingress or an Egress):

   o  Join: Source/Destination request to join the flow.

   o  Leave: Source/Destination request to leave the flow.

   o  Modify: Source/Destination request to change the flow.

   Modify operation can be considered to address cases when a flow is
   slightly changed, e.g., only MaxPayloadSize (Section 6.2) has been
   changed.  The advantage of having a Modify is that it allows to
   initiate 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 in figuring out whether the new
   flow spec can be supported, the central entity has to assume that the
   resources committed to the current flow are in use.  Via Modify the
   central 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 control-plane
   limitations.

   As the DetNet UNI can provide service for both L3 and L2 flows, end
   systems may not need to implement the L3 <=> L2 Transfer Function
   specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also
   subclause 46.1 in [IEEE8021Qcc]).  An edge node may implement a
   function similar to the Transfer Function, see, e.g., the Svc Proxy
   in Figure 1 in [I-D.ietf-detnet-dp-alt].







Farkas, et al.             Expires May 3, 2018                  [Page 7]


Internet-Draft        DetNet Flow Information Model         October 2017


6.  Flow

   The flows leveraging DetNet service can be unicast or multicast data
   flows for an application with constrained requirements on network
   performance, e.g., low packet loss rate and/or latency.  Therefore,
   they can require different connectivity types: point-to-point (p2p)
   or point-to-multipoint (p2mp).  The p2mp connectivity is created by a
   transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt].
   (Note that mp2mp connectivity is a superposition of p2mp
   connections.)

   Many flows using DetNet service are periodic with fix packet size
   (i.e., Constant Bit Rate (CBR) flows), or periodic with variable
   packet size.

   Delay 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 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 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 have the following attributes:

   a.  DataFlowSpecification (Section 6.1)

   b.  TrafficSpecification (Section 6.2)

   c.  FlowRank (Section 6.3)

   Flow attributes are described in the following sections.

6.1.  Identification and Specification of Flows

   Identification options for DetNet flows at the UNI and within the
   DetNet domain are specified as follows; see Section 6.1.1 for DetNet
   L3 flows (at UNI), Section 6.1.2 for DetNet L2 flows (at UNI) and
   Section 6.1.3 for DetNetwork flows (within the network).







Farkas, et al.             Expires May 3, 2018                  [Page 8]


Internet-Draft        DetNet Flow Information Model         October 2017


6.1.1.  DetNet L3 Flow Identification and Specification at UNI

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

   a.  SourceIpAddress

   b.  DestinationIpAddress

   c.  IPv6FlowLabel

   d.  Dscp

   e.  Protocol

   f.  SourcePort

   g.  DestinationPort

6.1.2.  DetNet L2 Flow Identification and Specification at UNI

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







Farkas, et al.             Expires May 3, 2018                  [Page 9]


Internet-Draft        DetNet Flow Information Model         October 2017


6.1.3.  DetNetwork Flow Identification and Specification

   Identification of DetNet flows within the DetNet domain are used in
   the service information model.  The attributes are specific to the
   forwarding paradigm within the DetNet domain.  DetNetwork flows can
   be identified and specified by the following attributes:

   a.  SourceIpAddress

   b.  DestinationIpAddress

   c.  IPv6FlowLabel

   d.  MplsLabel

6.2.  Traffic Specification

   TrafficSpecification specifies how the Source transmits packets for
   the flow.  This is effectively the promise/request of the Source 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 will transmit in one Interval.

   c.  MaxPayloadSize: the maximum payload size that the Source 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.  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 TrafficSpecification
   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:





Farkas, et al.             Expires May 3, 2018                 [Page 10]


Internet-Draft        DetNet Flow Information Model         October 2017


   o  AveragePacketsPerInterval: the average number of packets that the
      Source will transmit in one Interval.

   o  AveragePayloadSize: the average payload size that the Source will
      transmit.

   ]]

   [[NOTE2: another alternative to deal better with various traffic
   types can rely on [RFC6003], which describes the support of Metro
   Ethernet Forum (MEF) Ethernet traffic parameters for using for
   resource reservation purposes.  Such a Bandwidth Profile can be also
   adapted to describe the set of traffic parameters 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
   the committed rate.  The Excess Rate 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, and 5G PPP work defines traffic model for MTC (Machine Type
   Communication) use cases.  Periodic traffic type is usually for
   status update between devices or devices transmit status report to 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 an alert is sent, it waits until the issue being solved to
   be able to send another alert.  MaxPacketPerEvent, defines the max
   number of packets within one message. ]]

6.3.  Flow Rank

   FlowRank provides the rank of this flow relative to other flows in
   the network.  This rank is used to determine success/failure of flow
   establishment.  Rank (boolean) is used by the network 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 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).



Farkas, et al.             Expires May 3, 2018                 [Page 11]


Internet-Draft        DetNet Flow Information Model         October 2017


6.4.  Service Rank

   ServiceRank provides the rank of this service instance relative to
   other services in the network.  This rank is used to determine
   success/failure of service instance establishment.  Rank (boolean) is
   used by 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 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
   the false value (i.e., services with false are dropped first).

7.  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) of the Source.

   The Source object includes the following attributes:

   a.  DataFlowSpecification (Section 6.1)

   b.  TrafficSpecification (Section 6.2)

   c.  FlowRank (Section 6.3)

   d.  EndSystemInterfaces (Section 9.1)

   e.  InterfaceCapabilities (Section 9.2)

   f.  UserToNetworkRequirements (Section 9.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.



Farkas, et al.             Expires May 3, 2018                 [Page 12]


Internet-Draft        DetNet Flow Information Model         October 2017


8.  Destination

   The Destination object includes the following attributes:

   a.  DataFlowSpecification (Section 6.1)

   b.  EndSystemInterfaces (Section 9.1)

   c.  InterfaceCapabilities (Section 9.2)

   d.  UserToNetworkRequirements (Section 9.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): Should we add
   DestinationRank?  It could distinguish the importance of Destinations
   if the flow cannot be provided for all Destinations.]]

9.  Common Attributes of Source and Destination

   Source and Destination end systems have the following common
   attributes in addition to DataFlowSpecification (Section 6.1).

9.1.  End System Interfaces

   EndSystemInterfaces is a list 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 by the end system, e.g., based on IfIndex parameter.

9.2.  Interface Capabilities

   InterfaceCapabilities specifies the network capabilities of all
   interfaces (ports) contained in the EndSystemInterfaces object
   (Section 9.1).  These capabilities may be configured via the
   InterfaceConfiguration object (Section 13.2) of the Status object
   (Section 13).



Farkas, et al.             Expires May 3, 2018                 [Page 13]


Internet-Draft        DetNet Flow Information Model         October 2017


   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 or Destination object (i.e.,
   one entry in EndSystemInterfaces (Section 9.1)).  Use of multiple
   entries in EndSystemInterfaces is intended for network capabilities
   that span multiple interfaces (e.g., packet replication and
   elimination).";.

   InterfaceCapabilities attributes:

   a.  SubInterfaceCapable (sub-interface capable)

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

   [[NOTE (to be removed from a future revision): InterfaceCapabilities
   attributes are 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 of the optional Stream
      Identification types supported by the interface as specified in
      [IEEE8021CB].)

   o  CB-SequenceTypeList (a list of the optional Sequence Encode/Decode
      types supported by the interface as specified in [IEEE8021CB].)

   ]]

9.3.  User to Network Requirements

   UserToNetworkRequirements specifies user requirements for the flow,
   such as latency and reliability.

   The UserToNetworkRequirements object includes the following
   attributes:

   a.  NumReplicationTrees

   b.  MaxLatency

   NumReplicationTrees specifies the number of maximally disjoint trees
   that the network should configure to provide packet replication and
   elimination for the flow.  NumReplicationTrees is provided by the
   Source only.  Destinations SHALL set this element to one.  Value zero
   and one indicate no packet replication and elimination for the flow.



Farkas, et al.             Expires May 3, 2018                 [Page 14]


Internet-Draft        DetNet Flow Information Model         October 2017


   When NumReplicationTrees is greater than one, packet replication and
   elimination is to be used for the flow.  If the Source sets this
   element to greater than one, and packet replication and elimination
   is not possible in the network (e.g., no disjoint paths, or the nodes
   do not support packet replication and elimination), then the
   FailureCode of the Status object is non-zero (Section 13.1).

   MaxLatency is the maximum latency from Source to Destination(s) for a
   single packet of the flow.  MaxLatency is specified as an integer
   number of nanoseconds.  When this requirement is specified by the
   Source, it must be satisfied for all Destinations.  When this
   requirement is specified by a Destination, it must be satisfied for
   that particular Destination only.  If the UserToNetworkRequirements
   group is not provided within the Source or Destination object, then
   value zero SHALL be used for this element.  Value zero represents a
   special use for the maximum latency requirement.  Value zero locks-
   down the initial latency that the network provides in the
   AccumulatedLatency parameter of the Status object (Section 13) after
   the successful configuration of the flow, such that any subsequent
   increase in the latency beyond that initial value causes the flow to
   fail.

   [[NOTE-1 (to be removed from a future revision): Should we add a
   parameter to specify the maximum packet loss rate that can be
   tolerated for the flow?]]

   [[NOTE-2 (to be removed from a future revision): TrafficSpecification
   (Section 6.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 be guaranteed for the flow by the network?]]

10.  Ingress

   Placeholder ...

11.  Egress

   Placeholder ...

12.  DetNet Domain

   The DetNet Domain may change the encapsulation of a DetNet L2 or L3
   flow at the UNI.  That impacts not only how a flow can be recognised
   inside the DetNet domain but also the resource reservation
   calculations.

   The DetNet Domain object specifies:



Farkas, et al.             Expires May 3, 2018                 [Page 15]


Internet-Draft        DetNet Flow Information Model         October 2017


   o  The behavior of the flow (how/when it is transmited).

   o  The requirements of the flow from the network.

   o  The capabilities of the DetNet domain.

   The DetNet domain object includes the following attributes:

   a.  DataFlowSpecification (Section 6.1)

   b.  TrafficSpecification (Section 6.2)

   c.  ServiceRank (Section 6.4)

   d.  DetnetDomainCapabilities (Section 12.1)

   e.  UserToNetworkRequirements (Section 9.3)

12.1.  DetNet Domain Capabilities

   DetnetDomainCapabilities specifies the network capabilities, which
   can be used to provide DetNet service.  DetNet Edge nodes may change
   the encapsulation of a flow according to the data plane used inside
   the DetNet domain.

   DetnetDomainCapabilities object includes the following attributes:

   a.  EncapsulationFormat (data plane specific encapsulation)

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

13.  Flow-status

   The FlowStatus object is provided by the network each Source and
   Destination of the flow.  The Status object provides the status of
   the flow with respect to the establishment of the flow by the
   network.  The Status object is delivered via the corresponding UNI to
   each Source and Destination end system of the 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 the attributes a), b), c); and MAY
   include attributes d), e):

   a.  DataFlowSpecification (Section 6.1)

   b.  StatusInfo (Section 13.1)



Farkas, et al.             Expires May 3, 2018                 [Page 16]


Internet-Draft        DetNet Flow Information Model         October 2017


   c.  AccumulatedLatency (this section below)

   d.  InterfaceConfiguration (Section 13.2)

   e.  FailedInterfaces (Section 13.3)

   DataFlowSpecification identifies the flow for which status is
   provided.  DataFlowSpecification is described in (Section 6.1) If the
   Status object is provided without a Source or Destination object in a
   protocol message via a UNI, then the DataFlowSpecification object
   SHALL be included within the Status object 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 the Source/Destination
   object, and therefore DataFlowSpecification is not required within
   the Status object.

   AccumulatedLatency provides the worst-case latency that 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
   is specified as an integer number of nanoseconds.  Latency is
   measured using the time at which the data frame's message timestamp
   point passes the reference plane marking the boundary between the
   network media and PHY.  The message timestamp point is specified by
   IEEE Std 802.1AS [IEEE8021AS] for various media.  For a successful
   Status, the network returns a value less than or equal to the
   MaxLatency of the UserToNetworkRequirements (Section 9.3).  If the
   NumReplicationTrees of the UserToNetworkRequirements (Section 9.3) is
   one, then the AccumlatedLatency SHALL provide the worst latency for
   the current path from the Source to each Destination.  If the path is
   changed (e.g., due to rerouting), then the AccumulatedLatency changes
   accordingly.  If the NumReplicationTrees of the
   UserToNetworkRequirements (Section 9.3) is greater than one,
   AccumlatedLatency SHALL provide the worst latency for all paths in
   use from the Source to each Destination.

13.1.  Status Info

   StatusInfo provides information regarding the status of a flow's
   configuration in the network.

   The StatusInfo object MAY include the following attributes:

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

       *  None: no Source



Farkas, et al.             Expires May 3, 2018                 [Page 17]


Internet-Draft        DetNet Flow Information Model         October 2017


       *  Ready: Source is ready

       *  Failed: Source failed

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

       *  None: no Destination

       *  Ready: all Destinations are ready

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

       *  Failed: All Destinations failed.

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

   [[NOTE (to be removed from a future revision): FailureCodes to be
   defined for DetNet.  Table 46-1 of [IEEE8021Qcc] describes TSN
   failure codes.]]

13.2.  Interface Configuration

   InterfaceConfiguration provides information about of interfaces in
   the Source/Destination.  This configuration related information
   assists the network in meeting the requirements of the flow.  The
   InterfaceConfiguration object is according to the capabilities of the
   interface.  InterfaceConfiguration can be distinct for each Source or
   Destination of each flow.  If the InterfaceConfiguration object is
   not provided within the Status object, then the network SHALL assume
   zero elements as the default (no interface configuration).

   The InterfaceConfiguration object MAY include one or more the
   following attributes:

   a.  MAC or IP Address to identify the interface

   b.  DataFlowSpecification (Section 6.1)







Farkas, et al.             Expires May 3, 2018                 [Page 18]


Internet-Draft        DetNet Flow Information Model         October 2017


13.3.  Failed Interfaces

   FailedInterfaces provides a list of one or more physical interfaces
   (ports) in the failed node when a failure occurs in the network.

   The FailedInterface object includes the following attributes:

   a.  MAC or IP Address to identify the interface

   b.  InterfaceName

   InterfaceName is the name of the interface (port) within the node.
   This interface name SHALL be persistent, and unique within the node.

14.  Service-status

   Placeholder ...

15.  Summary

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

16.  IANA Considerations

   N/A.

17.  Security Considerations

   N/A.

18.  References

18.1.  Normative References

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-03 (work in progress), August 2017.

   [I-D.ietf-detnet-dp-alt]
              Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
              Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
              and Solution Alternatives", draft-ietf-detnet-dp-alt-00
              (work in progress), October 2016.




Farkas, et al.             Expires May 3, 2018                 [Page 19]


Internet-Draft        DetNet Flow Information Model         October 2017


   [I-D.ietf-detnet-use-cases]
              Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
              Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y.,
              Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,
              X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D.,
              Geng, X., Dujovne, D., and M. Seewald, "Deterministic
              Networking Use Cases", draft-ietf-detnet-use-cases-13
              (work in progress), September 2017.

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

18.2.  Informative References

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

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

   [IEEE8021CB]
              IEEE 802.1, "IEEE P802.1CB: 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>.

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







Farkas, et al.             Expires May 3, 2018                 [Page 20]


Internet-Draft        DetNet Flow Information Model         October 2017


   [IEEE8021Qbv]
              IEEE 802.1, "IEEE 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>.

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

   [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
   Konyves Kalman krt. 11/B
   Budapest  1097
   Hungary

   Email: janos.farkas@ericsson.com


   Balazs Varga
   Ericsson
   Konyves Kalman krt. 11/B
   Budapest  1097
   Hungary

   Email: balazs.a.varga@ericsson.com











Farkas, et al.             Expires May 3, 2018                 [Page 21]


Internet-Draft        DetNet Flow Information Model         October 2017


   Rodney Cummings
   National Instruments
   11500 N. Mopac Expwy
   Bldg. C
   Austin, TX  78759-3504
   USA

   Email: rodney.cummings@ni.com


   Jiang Yuanlong
   Huawei

   Email: jiangyuanlong@huawei.com


   Zha Yiyong
   Huawei

   Email: zhayiyong@huawei.com































Farkas, et al.             Expires May 3, 2018                 [Page 22]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/