[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

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

                                                        March 16, 2016

     Deterministic Networking Requirements on Data and Control Plane


   Deterministic Networking (DetNet) is focused on how to serve time
   critical flow with low data loss and bounded delay. Unlike
   contemporary solution which improves QoS such as TE, redundant
   bandwidth provisioning and dedicated channel reservation, DetNet
   provides more general approaches that use IP-based techniques and
   guarantee the worst-case latency of DetNet flows while allowing
   sharing among best-effort flows. For this purpose, DetNet may
   require upgraded or redefined data plane as well as control plane,
   since current networking cannot assure maximum end-to-end latency.
   This document describes some technical requirements on possible
   data plane, control plane and DetNet flow modeling that can help
   to clarify those capabilities DetNet should have.

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

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

Zha and Geng          Expires September 16 2016               [Page 1]

Internet-Draft           DetNet Requirements                March 2016

   This Internet-Draft will expire on September 16, 2016.

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. Overall Architecture .........................................4
   4. Data Plane Requirements ......................................4
      4.1. MPLS to Support DetNet Flow Forwarding ..................4
      4.2. DetNet Flow Identification ..............................5
      4.3. Deterministic Forwarding Capability .....................6
   5. Control Plane Requirements ...................................7
      5.1. Distributed or Centralized Control ......................7
      5.2. Southbound/Northbound Interfaces ........................8
      5.3. Peer-to-Peer Reservation Protocol .......................9
   6. Requirements on DetNet Flow Modeling .........................9
   7. Requirements on Synchronization and OAM .....................10
   8. Security Considerations .....................................10
   9. IANA Considerations .........................................10
   10. Acknowledgments ............................................10
   11. References .................................................10
      11.1. Normative References ..................................10
      11.2. Informative References ................................11

1. Introduction

   The rapid growth of the existing communication system and its
   access into almost all aspects of daily life has led to great
   dependency on services it provides. The communication network, as
   it is today, has applications such as multimedia and peer-to-peer
   file sharing distribution that require Quality of Service (QoS)
   which guarantees delay and jitter to maintain a certain level of

Zha and Geng         Expires September 16, 2016               [Page 2]

Internet-Draft           DetNet Requirements                March 2016

   performance. Meanwhile, cellular network has become key element in
   modern social network with increasing popularity over the past
   years. A communication system with extreme real-time and high
   reliability is essential for the next concurrent and next
   generation cellular networks as well as its bearer network for E-
   2-E performance requirements.

   Conventional transport network is IP-based for the benefits of
   high bandwidth and low cost. However, the delay and jitter
   guarantee becomes a challenge in case of contention since the
   service is not deterministic but best effort. With more and more
   rigid demand in latency control in the future network [METIS],
   deterministic networking [I-D.finn-detnet-architecture] becomes a
   promising solution to meet the requirement of ultra low-latency of
   certain applications and use cases. There are already typical
   issues for latency sensitive networking requirements in midhaul
   and backhaul network to support LTE and future 5G network [5G].
   Moreover  not only the telecom industry but also other vertical
   industries have increasing demand on delay-sensitive
   communications as automation becomes increasingly popular recently.

   More specifically, CoMP techniques, D-2-D, industrial automation
   and gaming/media service all have great dependency on low delay
   communications as well as high reliability to guarantee the
   service performance. Note that the deterministic networking is not
   equal to low latency as it is more focused on the worst case delay
   bound of the duration of certain application or service. It can be
   argued that without high certainty and absolute delay guarantee,
   low delay provisioning is just relative [RFC3393], which is not
   sufficient to some delay-critical service since delay violation in
   an instance cannot be tolerated. Overall, the requirements from
   vertical industries seem to be well aligned with the expected low
   latency and high determinist performance of future networks

   This document only describes technical requirements and design
   principles on data plane, control plane and modeling to minimize
   the scope of this document since a full coverage of DetNet can be
   found in [I-D.finn-detnet-architecture]

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

Zha and Geng         Expires September 16, 2016               [Page 3]

Internet-Draft           DetNet Requirements                March 2016

3. Overall Architecture

   Draft [I-D.finn-detnet-architecture] provides an overall picture
   of the DetNet operation. The draft covers almost every aspects of
   deterministic service provisioning which will be indeed asking for
   an architectural upgrade. An entire working system is needed for
   end-to-end delay-guaranteed service provisioning, but the WG may
   only works on several topics as the final deliverables. Meanwhile,
   there are still some open issues on both design and implementation
   of data plane and control plane.

   Based on the current architecture, three key aspects are
   identified: how to specify the data plane (including the
   forwarding in [I-D.finn-detnet-architecture]) and what is the
   essential characteristic of the data plane enabling deterministic
   forwarding; how to design appropriate control protocols and
   mechanisms to serve end-to-end DetNet flows; what and how modeling
   should be defined to describe basic principles of both data plane
   and control plane.

4. Data Plane Requirements

   As mentioned in the current charter, DetNet focus on Layer 3
   techniques to support deterministic latency applications. Without
   redefining the hardware and physical layers, potential data plane
   must be compatible with Layer 2 operations (i.e. TSN) In the
   architectural draft[I-D.finn-detnet-architecture], the data plane
   is described as the most fundamental element of the network,
   comprising the device and forwarding plane, which decides the
   queuing, scheduling and shaping of traffic. In order to provide
   converged networking in which DetNet flows get bounded delay
   guarantee while non-DetNet flows are best-effort, the DetNet data
   plane should specify to answer the following questions: how to use
   existing technologies for Layer 3 operation, MPLS may be a good
   candidate to setup end-to-end deterministic flow path; how to
   identify the DetNet data flow; a standardized mechanism of DetNet
   flow forwarding including queuing, transmission, shaping and etc.

4.1. MPLS to Support DetNet Flow Forwarding

   IEEE works on Layer 1-2 technologies where TSN has successfully
   provided a potential solution to the problem of serving timing
   critical data flow in Ethernet. In order to expand the guaranteed
   delay provisioning to the scale of the entire network, it is
   critical for DetNet WG to define the Layer forwarding. As
   mentioned in current charter, the goal is to use existing

Zha and Geng         Expires September 16, 2016               [Page 4]

Internet-Draft           DetNet Requirements                March 2016

   technology that can be compatible with TSN work. Given that, MPLS
   technology is a good candidate for it maturity and robustness.

   MPLS lies between Layer 3 and 2 with an encapsulation of different
   protocols. Supposing that deterministic forwarding is ready at
   each hop under TSN, MPLS can carry Ethernet frames to utilize TSN
   techniques to provide an end-to-end label switched DetNet path. In
   this way, the WG may needs to further define how to use MPLS in
   the following aspects:

   -Setup Label Switched Path (LSP) for DetNet flow with label
   definition and QoS mapping.

   -Latency-aware LSP installment and removing. RSVP-TE may not be
   suitable for DetNet flows as it only describes macro-parameters
   such as bandwidth. An extension may be desirable with latency

   -Supporting Layer-2 techniques such as pseudowire.

4.2. DetNet Flow Identification

   Identification is the first step among all corresponding
   operations related to DetNet flows. Because of the unified
   transmission of both deterministic traffic flow and conventional
   best effort flows, DetNet flow needs to be identified for certain
   processes. Basically, there are two questions need to be taken are
   of based on the authors' opinions: first, how to identify the flow
   entity; second, how to identify its delay bound requirement.

   Flow identification can be done via some tuple matching approach,
   such as {VLAN identifier, destination MAC address} pair,
   source/destination address, port, MAC address and so on. All these
   approach can mark a unique flow in the network. However, they are
   all dependent to the source. In other words, if the source is
   sending both DetNet flow and best effort flow, this approach does
   not work. To tackle with this challenge, a different destination
   MAC address or a VLAN ID could be used. And so does the MPLS

   A transformation in Layer 2 or a proxy function could be a
   solution. More fundamental solution can be redefining new flag or
   defining new flow model without doing the tuple matching.
   Meanwhile, the flow identification should be application-aware and
   impendent of sending source. An alternative approach can be
   similar to those in Service Function Chain (SFC) to define
   encapsulation format be agnostic to the layer at which it is

Zha and Geng         Expires September 16, 2016               [Page 5]

Internet-Draft           DetNet Requirements                March 2016

   applied and the service that is being constructed. However, this
   provision certainly need more work depending on the acceptance of

   The second issue is how to identify the delay bound of the target
   flow being required. This is a new question which has not been
   well discussed. For DetNet, we want to do absolute delay bound
   provisioning while allowing best effort traffic to share
   unscheduled traffic. In this way, how to provision just enough
   resource to the DetNet flow is the major problem. So first needs
   is to know the delay bound of the application flow. Treat all
   DetNet flow as the same does not make sense since one flow
   requires 1ms delay but the other requires 10ms which are all
   deterministic but definitely needs different amount of network

   Currently, the flow can be marked with QoS level, e.g. 0-7,
   denotes the level of priority of the flow. There is no absolute
   delay information of the flow as QoS level only specifies the
   general characteristic of the data flow. A new mechanism to label
   the absolute delay bound is necessary and it can be done via a
   mapping algorithm between delay bound and current QoS labeling.

4.3. Deterministic Forwarding Capability

   Although, DetNet will not define new hardware or physical layer,
   different flow forwarding mechanism including queuing,
   transmission selection, and shaping equipped by different network
   devices or network elements can lead to the uncertainty of the
   timing. To achieve predictable delay introduced in every hop, a
   standard of queuing, transmission selection, shaping, and
   preemption is needed to unify all the NEs in forwarding plane. TSN
   can be expected to support this but sufficiently well-defined
   characteristics should be defined in the WG. In the authors'
   opinion, at least two features should be defined:

   -Frame preemption. As transmitted via the same medium,
   deterministic flow should always have absolute priority against
   best effort flow, which means the DetNet flow should be first
   scheduled if there is any. The problem is if the port is
   transmitting a best effort flow, the incoming DetNet flow has to
   wait a MTU transmission time thus introduce 12us delay in a 1GE
   line. So the best effort flow should be permeable to the DetNet
   flow. TSN 802.1qbu is working preemption solution for Ethernet,
   DetNet should be expected to have this capability either in Layer
   2 or Layer 3. In addition to current TSN solution which is mainly
   focused on cut best effort packet into smaller packet with

Zha and Geng         Expires September 16, 2016               [Page 6]

Internet-Draft           DetNet Requirements                March 2016

   encapsulation, preemption on demand or real time preemption should
   also be considered to avoid overhead and save latency.

   -Time aware scheduling: preemption can solve the conflict between
   DetNet flow and best effort flow by giving DetNet flow absolute
   priority to preempt normal traffic. Conflict between DetNet flows
   can still introduce uncertain delay. So scheduling of DetNet
   traffic in advance with time aware capability is desirable to
   solve this conflict.

5. Control Plane Requirements

   In the use case draft [I-D.draft-ietf-detnet-use-cases], several
   use cases summarize the needs of unified control and management
   protocols and control plane. Control plane is the key component of
   DetNet that can unify the existing Layer 2 technology and Layer 3
   to deliver a fully functional solution for delay guarantee service.
   Note that here "control plane" is used just for simplicity to
   represent all control and management mechanism and protocols which
   does not mean the separation of control and forwarding plane in

   The DetNet control plane design should include: architectural
   choice as distributed or centralized control;
   southbound/northbound interface; peer-to-peer reservation

5.1. Distributed or Centralized Control

   Assuming the data plane upgrade can provide deterministic
   forwarding behavior at each hop, a unified control mechanism is
   demanded to provide end-to-end delay guarantee. Although the
   architecture draft propose a controller based centralized control
   plane mechanism, it has not been decided yet to solely focus on
   centralized only. The WG should also consider some distributed
   solution with reservation protocols since centralized resource
   reservation may introduce addition latency.

   Introducing centralized controller seems to be the simple and
   stringent forward solution. SDN is the new fashion right now with
   separation of control plane from device to a remote controller.
   For DetNet, if there is a central controller can do the path
   computing, resource reservation and transmission selection based
   on the information and delay requirement of the target flow on
   every hop, it definitely can help to minimize the delay. First of
   all, path computing has to be relied on central controller to
   select the best forwarding path based on the DetNet flow request

Zha and Geng         Expires September 16, 2016               [Page 7]

Internet-Draft           DetNet Requirements                March 2016

   and global information of the network. Secondly, reserve enough
   resource at every hop is challenging for end-to-end delay
   guarantee which can be benefited from a control resource manager
   to make the DetNet flow get just enough resource at every hop.
   Thirdly, transmission selection or scheduling at each hop is also
   crucial to serve the flow in time. A central arbiter can be
   equipped to make the DetNet flow travel pass the multi-hop with
   green light all the way

   On the other hand, centralized controller is offsite and has to
   communicate with all the NEs of entire network which can bring in
   addition latency. For DetNet flows that require ms delay, the time
   cost of communication to the controller and communication between
   control and NEs is not affordable. So a distributed control
   mechanism is also considered to be promising in some scenarios.
   With distributed control, the DetNet flows do not have to wait the
   controller to acknowledge and configure the downstream NEs. An
   efficient reserve protocol is needed to reserve bandwidth, buffer
   and other resource at each hop along the forwarding path. Also, a
   hybrid approach can also be helpful as the controller can setup
   the path and distributed protocol to reserve the resource at each

5.2. Southbound/Northbound Interfaces

   Within SDN architecture, southbound and northbound are the key
   interfaces which are close related the NEs and flow model. If
   there is a central controller for DetNet, it needs to know the
   forwarding capabilities of the NEs and then send the configuration
   to the NEs to serve the DetNet flow. All of this information is
   transmitted via southbound interface. Also the controller should
   get the service level requirements via northbound interface which
   is based on the service model of DetNet flows.

   Southbound interface should enables communication between control
   plane and network elements with following information:

   -The resource inventory of the network elements, such as left over
   bandwidth, unscheduled time slot on link or the size of the unused

   -Topology information of the network, it can be the similar work
   that is being done in I2RS or TEAS.

   -The data plane information of NEs, which include the queuing,
   transmission selection, shaping and preemption related information.

Zha and Geng         Expires September 16, 2016               [Page 8]

Internet-Draft           DetNet Requirements                March 2016

   -The scheduling or QoS setting on the data plane and the
   configuration information that makes the change.

   Northbound interface enables communication between applications
   and control and it should contain information related to:

   -Service level delay requirement which can be transformed into
   device configuration change in the controller.

   -Flow and service description which can be relied on flow model
   and configuration model.

5.3. Peer-to-Peer Reservation Protocol

   As mentioned in section 5.1, distributed reservation protocols are
   also desired even in a centralized architecture to reduce the
   setup time caused by communication with controller. And ideal case
   is that, a peer-to-peer protocol for a S-D pair to reserve
   resource for DetNet flow without a central controller. Of cause
   this will be an efficient and sophisticated approach if WG can
   make it possible to deploy. In the authors' opinion, this peer-to-
   peer reservation protocol should have characteristics such as:

   -A hop by hop reservation protocol that reserve resource for the
   coming DetNet flow before arriving to the next hop. The DetNet
   flow will just pass through the hop using pre-setup resource.

   -Only control packet or reservation signal is processed at each
   hop, DetNet flow will be transmitted transparently all the way to

   -This multi-hop signaling should start transmission of DetNet flow
   immediately after setting up the path to next hop without
   configure end-to-end path.

6. Requirements on DetNet Flow Modeling

   DetNet flow modeling is one the most important deliverables of
   this WG. How to model the DetNet flow will decide how to serve the
   flow and how to reserve the resource, which are all the main focus
   of the WG. Model is about description of characteristic of flow
   transmission, technical requirements and network resource demands.
   Traditional flow model is based on RSVP model which includes peak
   rate, sustain rate, burst and etc. this is not feasible for
   deterministic service provisioning as the bandwidth itself is not
   a accurate description of latency. The DetNet flow modeling should

Zha and Geng         Expires September 16, 2016               [Page 9]

Internet-Draft           DetNet Requirements                March 2016

   -Application-aware description of the flow.

   -Timing information of the flow so that the network can provide
   accurate service to guarantee the delay requirement.

   -Data transmission information of the flow including packet size,
   interval, traffic pattern and so on.

   -Network-aware constraints on networking environment.

7. Requirements on Synchronization and OAM

   Since operations and scheduling can be time-aware in DetNet and
   absolute delay bound is a must in a multi-hop network, time
   synchronization is necessary. Besides, in both centralized and
   distributed architecture, delay measuring among multi-hops and
   synchronization is a must for DetNet.

   There is also a need for OAM system and protocols which can help
   to provide E2E delay sensitive service provisioning.

   More details of synchronization and OAM will be provided in next

8. Security Considerations


9. IANA Considerations

   This document has no actions for IANA.

10. Acknowledgments

   This document has benefited from reviews, suggestions, comments
   and proposed text provided by the following members, listed in
   alphabetical order: Yuanlong Jiang and Oilver Huang.

11. References

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

Zha and Geng         Expires September 16, 2016              [Page 10]

Internet-Draft           DetNet Requirements                March 2016

11.2. Informative References


   Finn, N. and P. Thubert, "Deterministic Networking Problem
   Statement", draft-finn-detnet-problem-statement-02 (work in
   progress), October 2015.


   Finn, N., Thubert, P., and M. Teener, "Deterministic Networking
   Architecture", draft-finn-detnet-architecture-03 (work in
   progress), March 2016.


   Ethan Grossman, et al, "Deterministic Networking Use Cases",
   draft-ietf-detnet-use-cases-08, March 2016.

   [METIS] METIS Document Number: ICT-317669-METIS/D1.1, Scenarios,
   requirements and KPIs for 5G mobile and wireless system, April 29,
   2013. Available on line at: <https://www.metis2020.com/wp-

   [5G] Ericsson white paper, "5G Radio Access, Challenges for 2020
   and Beyond." June 2013. Available at:


   [LTE-Latency]Samuel Johnston, "LTE Latency: How does it compare to
   other technologies?" report of OpenSignal March 10, 2014.

   [EA12] P. C. Evans, M. Annunziata, "Industrial Internet: Pushing the
   Boundaries of Minds and Machines", General Electric White paper,
   November 2012.

Zha and Geng         Expires September 16, 2016              [Page 11]

Internet-Draft           DetNet Requirements                March 2016

   [UHD-video] Petr Holub, "Ultra-High Definition Videos and Their
   Applications over the Network", The 7th International Symposium on
   VICTORIES Project, OCTOBER 8, 2014. <http://www.aist-

Authors' Addresses

   Yiyong Zha
   Huawei Technologies
   Email: zhayiyong@huawei.com

   Liang Geng
   China Mobile
   Email: liang.geng@hotmail.com

Zha and Geng         Expires September 16, 2016              [Page 12]