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: [5G] Ericsson white paper, "5G Radio Access, Challenges for 2020 and Beyond." June 2013. Available at: [CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND ENHANCEMENT ", MARCH 2015, [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. 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]