Internet DRAFT - draft-zha-detnet-requirments

draft-zha-detnet-requirments



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 
                    draft-zha-detnet-requirments-00 


Abstract 

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

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

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
 
 
 
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 
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
   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 
   parameter.  

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

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

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

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

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

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

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

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

   -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 
   include: 
 
 
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 
   version.  

8. Security Considerations 

   TBD 

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 

   [I-D.finn-detnet-problem-statement] 

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

   [I-D.finn-detnet-architecture]  

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

   [I-D.draft-ietf-detnet-use-cases] 

   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-
   content/uploads/deliverables/METIS_D1.1_v1.pdf>  

   [5G] Ericsson white paper, "5G Radio Access, Challenges for 2020 
   and Beyond." June 2013. Available at: 
   <http://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf> 

   [CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND 
   ENHANCEMENT ", MARCH 2015, 
   <https://www.ngmn.org/uploads/media/NGMN_RANEV_D3_CoMP_Evaluation_
   and_Enhancement_v2.0.pdf>  

   [LTE-Latency]Samuel Johnston, "LTE Latency: How does it compare to 
   other technologies?" report of OpenSignal March 10, 2014. 
   <http://opensignal.com/blog/2014/03/10/lte-latency-how-does-it-
   compare-to-other-technologies/> 

   [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-
   victories.org/jp/7th_sympo_ws/PetrHolub_presentation.pdf>  

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]