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

Versions: 00 01 02

Network Working Group                                           Y. Zha
Internet Draft                                                Y. Jiang
Intended status: Informational                     Huawei Technologies
Expires: September 2017                                        L. Geng
                                                          China Mobile

                                                        March 13, 2017

            Deterministic Networking Flow Information Model


   Deterministic Networking (DetNet) provides end-to-end absolute
   delay and loss guarantee to serve real-time applications. DetNet
   is focused on a general approach that use techniques such as 1)
   data plane resources reservation for DetNet flows; 2) providing
   fixed path for DetNet flows; 3)sequentializng, replicating, and
   eliminating duplicate packets transmission [draft-ietf-detnet-
   architecture-00] to guarantee the worst case delay of DetNet flow
   while allow sharing among best effort traffic. Data flow
   information model is important to the DetNet work that it defines
   information be used by flow establishment and control protocols.
   This document describes and DetNet flow information model that
   represents the flow identifier, traffic description information so
   that can make resource reservation and provide differentiate

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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

   The list of current Internet-Drafts can be accessed at

Zha, et al.           Expires September 13 2017               [Page 1]

Internet-Draft         DetNet Flow Info Model               March 2017

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 13, 2017.

Copyright Notice

   Copyright (c) 2014 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
   (http://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. Introduction ................................................2
   2. Conventions used in this document ............................3
   3. DetNet Flow Information Model ................................4
      3.1. Flow Identifier .........................................4
         3.1.1. Layer 2 Flow Identification ........................5
         3.1.2. Layer 3 Flow Identification ........................6
      3.2. Transport Layer Information .............................6
      3.3. Flow Traffic Description ................................7
         3.3.1. Traffic Type .......................................9
         3.3.2. Traffic Shaping ....................................9
      3.4. Flow Statistics ........................................10
   4. Use of Flow Information Model ...............................11
      4.1. Mapping of Flow Information ............................11
      4.2. Data Plane Configuration ...............................12
   5. Security Considerations .....................................13
   6. IANA Considerations .........................................13
   7. Acknowledgments .............................................14
   8. References ..................................................14
      8.1. Normative References ...................................14
      8.2. Informative References .................................14

1. Introduction

   Deterministic service with both assured delay and data loss is
   promising to service providers. Due to lack of deterministic

Zha, et al.           Expires September 13 2017               [Page 2]

Internet-Draft         DetNet Flow Info Model               March 2017

   service provisioning mechanism there is no guarantee when
   deploying a time critical service [RFC3393]. Deterministic
   Networking (DetNet) tries to provide a solution to this issue with
   limited scope that the data flows are constrained with some
   maximum data rate properties. DetNet delivers assured end-to-end
   latency and packet loss by dedicating network resources to DetNet
   flows while unused reserved resource are still open to best effort

   In order to reserve proper amount of network resource to serve the
   DetNet flow, the DetNet flow first needs to be described with such
   parameters that can be understood by the network. Secondly,
   current flow description and resource reservation are mainly
   focused on bandwidth which is basically a statistical concept
   during a relative long observation interval. And also, there are
   different type of use cases those requires deterministic
   networking services. All these use cases may send different kind
   of traffics to the network with different deterministic service
   provisioning requirements [draft-ietf-detnet-use-cases-11].

   Data plane techniques such as queuing, shaping, scheduling and
   preemption are configured in a standard way to guarantee
   deterministic forwarding behavior in the network device. The
   controller or control plane takes the description of the DetNet
   flow and then translates into data plane level configuration to
   serve the flow. This is the key of DetNet as to define how to
   describe DetNet flow and how to reserve network resource for it.
   The flow description should be focused on traffic characteristics
   of real time service with parameters that could be converted to
   device level configurations.

   An information model defines concepts in a uniform way, enabling
   formal mapping processes to be developed to the information model
   to a set of data models. This simplifies the process of
   constructing software to automate the policy management process.
   It also simplifies the language generation process, though that is
   beyond the scope of this document.

   This document describes an information model for representing
   DetNet flow with comment concept and parameters of a DetNet
   service that can be mapped into device level configurations.

2. Conventions used in this document

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

Zha, et al.           Expires September 13 2017               [Page 3]

Internet-Draft         DetNet Flow Info Model               March 2017

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

3. DetNet Flow Information Model

   According to current charter, DetNet information model is to
   identify the information needed for flow establishment and control
   and be used by reservation protocols and data plane configuration.
   The work will be independent from the protocol(s) used to control
   the flows. The DetNet information model presented in this document
   defines some common concept of DetNet flows with information that
   can be used for flow identification, flow monitoring, performance
   management, reservation protocol, and data plane configuration.
   For example, deterministic properties of controlled latency, low
   packet loss, low packet delay variation, and high reliability.
   More information can be added in the future. And each part of the
   information model can be used individually by different network
   function or network entities. The DetNet information model only
   defines what kind of information is needed and how it could be
   used. Data repository, data definition language, query language,
   implementation language, and protocol should not be defined here.
   More specifically, the information model can be used by a data
   model for different scenarios. In [RFC3198], data model is "A
   mapping of the contents of an information model into a form that
   is specific to a particular type of data store or repository."

   In this document, DetNet information model contains three sets of
   information, flow identifier information, flow metering statistics,
   and traffic description.

3.1. Flow Identifier

   Flow identifier is the first step of flow description as DetNet
   requires differentiate service so flow needs to be identified by
   the data plane. The DetNet service is described at flow level so
   each flow could have unique flow identifier.

Zha, et al.           Expires September 13 2017               [Page 4]

Internet-Draft         DetNet Flow Info Model               March 2017

| DetNet |                             --------+   +---------+
| Sender |----\                    /---    |||||---|         |
+--------+     \    +-----------+ /    --------+   |Trans-   |
                \   |   DetNet  |/ DetNet Queue    |mission  |
                 ---| Classifier|\                 |Selection|---
+-----------+   /   +-----------+ \    --------+   |         |
|Best Effort|  /                   \--- ||||||||---|         |
| Sender    |-/                        --------+   +---------+
+-----------+                      Best Effort Queue
              Figure 1. DetNet Flow Being Classified

   As shown in figure 1, network reserves dedicate resource for
   DetNet flows which will be identified first to use the resource.
   So a DetNet flow model should first contain information for flow
   identification. As defined in [draft-ietf-detnet-architecture-00]
   draft, deterministic service can be applied to both layer 2 and
   layer 3 network, such as IP routing, MPLS labeling and Ethernet
   bridging, flow identifier information is needed for both layers.

3.1.1. Layer 2 Flow Identification

   Different flow indentifying technique may be used for different
   networks. DetNet provides layering flow identification models that
   can be used for both high layer and low layer. In [802.1qcc],
   flow identification in layer 2 is usually by mac address plus
   unique flow ID within the network domain. In access network which
   is usually layer 2 network, flow is identified by Vlan and MAC

| Name         | Elements     |
|              | Source       |
|              | MacAddress   |
|              +--------------+
|              | Destination  |
|Flow          | MacAddress   |
|Identifier    +--------------+
|              | VlanID       |
|              +--------------+
|              | UniqueID     |

Zha, et al.           Expires September 13 2017               [Page 5]

Internet-Draft         DetNet Flow Info Model               March 2017

3.1.2. Layer 3 Flow Identification

   In IP/MPLS network, flow identification in layer 3 is needed. For
   example, a LSP is setup to forward packets destined to particular
   IP address. If both DetNet flow and non-DetNet flow is sending to
   same destination, how to provide differentiate service becomes
   problem. First, the preliminary solution can be just provide
   DetNet service at user level, which means assuming traffic from
   particular source should be all performance guaranteed. Second,
   put additional label for per flow identification.

| Name         | Elements     |
|              | Protocol     |
|              +--------------+
|              | Source       |
|              | portID       |
|              +--------------+
|              | Destination  |
|Flow          | portID       |
|Identifier    +--------------+
|              | Source       |
|              | IpAddress    |
|              +--------------+
|              | Destination  |
|              | IpAddress    |
|              +--------------+
|              | UniqueID     |

3.2. Transport Layer Information

   Since flow model is used and being mapped between multiple layers,
   transport information is also mandatory. UDP flow and TCP flow
   apparently have absolute different traffic behavior and working
   mechanism which lead to different resource reservation scheme as
   well as forwarding features. So the source tells the network
   transport information of the flow it is going to send, e.g.,
   protocols related information. More details will be provided in
   next version.

Zha, et al.           Expires September 13 2017               [Page 6]

Internet-Draft         DetNet Flow Info Model               March 2017

| Name         | Elements             |
|              | udpSourcePort        |
|UDP           +----------------------+
|              | udpDestinationPort   |
|              | tcpSourcePort        |
|              +----------------------+
|              | tcpDestinationPort   |
|TCP           +----------------------+
|              | tcpWindowScale       |
|              +----------------------+
|              | tcpWindowSize        |

3.3. Flow Traffic Description

   The information model should contain traffic description
   information to define the traffic profile from the source. DetNet
   flow defines the source guarantee that is the promise of source
   that the maximum amount traffic it can send. It is a kind of
   contract between the source and network who serve the flow. If the
   source is sending overload or different type of traffic, the
   overload or traffic does not match the predefined traffic profile
   will be not guaranteed. So the DetNet is that the source tells the
   network "I will send the traffic like this", and the network will
   reserve the resource for the flow based on its traffic
   characteristics as defined in the model.

   Unlike previous flow model or traffic profile which is mainly
   based on bandwidth of service, DetNet flow should be more accurate
   and at lower level for deterministic forwarding. For DetNet
   service provisioning which is focused on absolute worst case delay,
   the network needs to know not only the number of packets the flow
   will be sending but also when or during what period of time the
   source will be sending what amount of packets. Based on the
   architecture draft, there are two kinds of flows, synchronous one
   and asynchronous one. The information model of the DetNet flow
   with traffic description information is shown as below.

Zha, et al.           Expires September 13 2017               [Page 7]

Internet-Draft         DetNet Flow Info Model               March 2017

| Name         | Elements     |
|              | Guaranteed   |
|              +--------------+
|              | RealTime     |
|ServiceType   +--------------+
|              | Mux          |
|QoS           |              |
|MTU           |              |
|Bandwidth     |              |
|Burst         |              |
|Periodic      |              |
|PeriodValue   |              |
|              |BurstID       |
|              +--------------+
|              |BurstLegnth   |
|              +--------------+
|Burst         |MaxFrames     |
|              +--------------+
|              |MaxFrameSize  |
|              +--------------+
|              |StartTime     |
|              +--------------+
|              |EndTime       |

   The basic idea is that the flow consists of a list of bursts. The
   Burst is a set of packets with burst duration. The burst is close
   related to service traffic pattern and also it is dependent on the
   data plane technique.

   There are two basic requirements for traffic information
   definition, first it can be used to describe service; second the
   parameter defined here can be mapped to data plane configuration.

Zha, et al.           Expires September 13 2017               [Page 8]

Internet-Draft         DetNet Flow Info Model               March 2017

3.3.1. Traffic Type

   Back to ATM era, when service wants to send traffic to a broadband
   network, it must inform network with information about what kind
   of traffic it is going to send as well as the performance
   requirements. DetNet provides absolute service guarantee for
   limited amount traffic, so the network also requires the
   information of traffic of the flow, such as constant rate flow,
   vibrate rate flow or unspecified. Then the network can make
   appropriate resource reservation for specific flow. E.g., for a
   VBR flow, peak rate can be 3-7 times over sustained rate which
   lead to sophisticated reservation scheme.

| Name          | Elements     |
|               | CBR          |
|               +--------------+
|TrafficType    | VBR          |
|               +--------------+
|               | UBR          |

3.3.2. Traffic Shaping

   As mentioned above, DetNet service only guarantee limited traffic
   with bounded delay. It is usually not easy to regulate source
   behavior when sending traffic, so shaping is necessary in DetNet
   working system. Meanwhile, only DetNet traffic that follows the
   predefined traffic behavior will be served properly, those
   overloaded will not be guaranteed.

   On the other hand, shaping procedure as one of the necessary
   working components needs to de standardized for deterministic
   delay provisioning. Network or control plane needs to know how the
   shaping, queuing and scheduling is performed to calculate delay.
   As shaping and queuing in DetNet is a per-flow based, the flow
   model contains information about shaping information.

   There are two commonly used shapers, leaky bucket and token bucket.
   Leaky bucket is defined to limit both bandwidth and burstiness of
   packet transmission and is recommended for ATM network with
   constant output rate. There are multiple implementations of leaky
   bucket, below is a set of parameters for one leaky bucket model.

Zha, et al.           Expires September 13 2017               [Page 9]

Internet-Draft         DetNet Flow Info Model               March 2017

   Token bucket, on the other hand is a shaping and policing model
   used for many protocols such as RSVP. Below is a Two-Parameter
   Token Bucket [RFC 3290].

| Name         | Elements     |
|              | BufferSize   |
|              +--------------+
|Leaky Bucket  | InputRate    |
|              +--------------+
|              | OutputRate   |
|              +--------------+
|              | InitialBuffer|
|              | Burst        |
|Token Bucket  +--------------+
|              | TokenRate    |

3.4. Flow Statistics

   As a matter of fact, there is no mechanism to provide flow delay
   and loss parameter, which is also important for DetNet service.
   Keeping the knowledge of flow-based delay and loss information is
   also crucial for OAM and fault management.

   The detail of flow metering statistic information in the
   information model will be proposed in next version.

| Name         | Elements     |
|MaxDelay      |              |
|MaxPacketLoss |              |
|              | FlowStart    |
|TimeStamp     +--------------+
|              | FlowEnd      |

Zha, et al.           Expires September 13 2017              [Page 10]

Internet-Draft         DetNet Flow Info Model               March 2017

4. Use of Flow Information Model

   As defined in current charter, DetNet flow information model is
   used for flow establishment and control and can also be used by
   reservation protocols and YANG data models.

4.1. Mapping of Flow Information

   This section proposes a way to map information model parameters
   into network configuration. [802.1qcc] defined stream reservation
   protocols in layer 2 network with deterministic characteristics.
   DetNet works on layer 3, which will not be covered by 802.1qcc.
   Figure 2 shows that, DetNet flow model is used to configure the
   DetNet network, e.g., TSN network. Some of the flow information
   defined in this model is mapped in to 802.1qcc parameters to
   configure TSN domain.

                        |        DetNet Flow Model        |
                             V                         V
                             V                         V
                  +---------------+                    V
                  | TSN Network   |                    V
                  | Configuration |                    V
                  +---------------+                    V
                   | 802.1qcc    |                     V
         ____      |             |                     V
        /    \     |             |                     V
       /      \____V___________  |                     V
  ____/                        \ |                     V    _
/                               \V________________    _V___/ \
|   +------+     +---+         +---+   +--------+ \  /        \_
|   |Talker|=====|NE |=========|NE |===|Listener| |  |          \
\   +------+     +---+         +---+   +--------+ |  \_        /
 \             ______                            /     \______/
  \           /      \                          /
   \_________/        \_______________Domain 1_/       Domain 2

         Figure 2. DetNet Flow Model to TSN Configuration

Zha, et al.           Expires September 13 2017              [Page 11]

Internet-Draft         DetNet Flow Info Model               March 2017

4.2. Data Plane Configuration

   As defined in current charter, the DetNet data plane should be TSN
   compatible. Take TSN TAS (Time Aware Shaper) for example, the
   information defined in the flow model can be mapped to data plane
   parameter to configure TSN time aware shaper that provides a
   deterministic forwarding behavior for the flow.

   As defined in previous section, information model contains traffic
   description of DetNet flow that can be used to configure data
   plane. In this section, take TSN time aware shaper as an example
   for data plane technique, mapping of data flow parameter to TAS
   configuration is presented.

   The basic idea is that, the controller or network control plane
   takes data flow traffic description as the request and compute the
   associated time interval and control list of the TAS gate control
   function. Data flow model contains timing information of the
   DetNet flow as it arrives at T1 and ends at T2, which can be
   mapped into control list of TAS to reserve an open gate for the
   DetNet flow for time period T1 to T2. As shown in figure 2, a
   DetNet flow with data traffic between T1 and T2 send the request
   to controller or control plane, and then the control plane uses
   the information to configure the TAS based on current status of
   TAS. Finally, the TAS function being configured with control list
   update for open gate transmission for this flow during T1 and T2.
   As a result, ideally, the flow will be transmitted immediately
   using the dedicated open gate time slot with absolute delay and
   loss guarantee.

Zha, et al.           Expires September 13 2017              [Page 12]

Internet-Draft         DetNet Flow Info Model               March 2017

                                  T1          T2  DetNet data flow
              +---------------+   /___________\   Traffic description
              |Data flow model|   \           /
              +---------------+   |||||||||||||
                     | |
                     | |
                     \ /
              | Control Plane |
                     / \
                     | |
                     \ /
       +-----------------------------+    Control List
       |    Time Aware Shaper        |    T0 CCCCCCCO
       |                             |    T1 OCCCCCCC
       | --------+ +----+ +---------+|    T2 CCCCCCCO
       |     |||||-|Gate|-|         ||        .
       | --------+ +----+ |         ||        .
       |DetNet Queue      |Trans-   ||        .
       |     .            |mission  ||    Tn CCCCCCCC
       |     .            |Selection||
       |     .            |         ||
       | --------+ +----+ |         ||
       |     |||||-|Gate|-|         ||
       | --------+ +----+ +---------+|
       |Best Effort                  |
       |Queue                        |
         Figure 3. Mapping of Flow Model into TAS Configuration

5. Security Considerations


6. IANA Considerations

   This document has no actions for IANA.

Zha, et al.           Expires September 13 2017              [Page 13]

Internet-Draft         DetNet Flow Info Model               March 2017

7. Acknowledgments

   This document has benefited from reviews, suggestions, comments
   and proposed text provided by the following members, listed in
   alphabetical order: Jinchun Xu and Hengjun Zhu.

8. References

8.1. Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP
             Performance Metrics (IPPM) ", RFC 3393, November 2002.

   [RFC3290] Y. Bernet, "An Informal Management Model for Diffserv
             Routers", RFC 3290, May 2002.

8.2. Informative References


   Grossman, E., et al. "Deterministic Networking Problem Statement",
   draft draft-ietf-detnet-use-cases-11 (work in progress), October


   Finn, N., Thubert, P., and M. Teener, "Deterministic Networking
   Architecture", draft-ietf-detnet-architecture-00 (work in
   progress), October 2016.


   IEEE 802.1Qcc, Draft 1.2, Mar 2017.

Zha, et al.           Expires September 13 2017              [Page 14]

Internet-Draft         DetNet Flow Info Model               March 2017

Authors' Addresses

   Yiyong Zha
   Huawei Technologies
   Email: zhayiyong@huawei.com

   Yuanlong Jiang
   Huawei Technologies
   Email: jiangyuanlong@huawei.com

   Liang Geng
   China Mobile
   Email: gengliang@chinamobile.com

Zha, et al.           Expires September 13 2017              [Page 15]

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