idnits 2.17.1 draft-zha-detnet-requirments-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 111 has weird spacing: '...oreover not o...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 16, 2016) is 2962 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.finn-detnet-problem-statement' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'CoMP' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'EA12' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'UHD-video' is defined on line 514, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Zha 2 Internet Draft Huawei Technologies 3 Intended status: Informational L. Geng 4 Expires: September 2016 China Mobile 6 March 16, 2016 8 Deterministic Networking Requirements on Data and Control Plane 9 draft-zha-detnet-requirments-00 11 Abstract 13 Deterministic Networking (DetNet) is focused on how to serve time 14 critical flow with low data loss and bounded delay. Unlike 15 contemporary solution which improves QoS such as TE, redundant 16 bandwidth provisioning and dedicated channel reservation, DetNet 17 provides more general approaches that use IP-based techniques and 18 guarantee the worst-case latency of DetNet flows while allowing 19 sharing among best-effort flows. For this purpose, DetNet may 20 require upgraded or redefined data plane as well as control plane, 21 since current networking cannot assure maximum end-to-end latency. 22 This document describes some technical requirements on possible 23 data plane, control plane and DetNet flow modeling that can help 24 to clarify those capabilities DetNet should have. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet-Drafts 39 as reference material or to cite them other than as "work in 40 progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on September 16, 2016. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction .................................................2 67 2. Conventions used in this document ............................3 68 3. Overall Architecture .........................................4 69 4. Data Plane Requirements ......................................4 70 4.1. MPLS to Support DetNet Flow Forwarding ..................4 71 4.2. DetNet Flow Identification ..............................5 72 4.3. Deterministic Forwarding Capability .....................6 73 5. Control Plane Requirements ...................................7 74 5.1. Distributed or Centralized Control ......................7 75 5.2. Southbound/Northbound Interfaces ........................8 76 5.3. Peer-to-Peer Reservation Protocol .......................9 77 6. Requirements on DetNet Flow Modeling .........................9 78 7. Requirements on Synchronization and OAM .....................10 79 8. Security Considerations .....................................10 80 9. IANA Considerations .........................................10 81 10. Acknowledgments ............................................10 82 11. References .................................................10 83 11.1. Normative References ..................................10 84 11.2. Informative References ................................11 86 1. Introduction 88 The rapid growth of the existing communication system and its 89 access into almost all aspects of daily life has led to great 90 dependency on services it provides. The communication network, as 91 it is today, has applications such as multimedia and peer-to-peer 92 file sharing distribution that require Quality of Service (QoS) 93 which guarantees delay and jitter to maintain a certain level of 94 performance. Meanwhile, cellular network has become key element in 95 modern social network with increasing popularity over the past 96 years. A communication system with extreme real-time and high 97 reliability is essential for the next concurrent and next 98 generation cellular networks as well as its bearer network for E- 99 2-E performance requirements. 101 Conventional transport network is IP-based for the benefits of 102 high bandwidth and low cost. However, the delay and jitter 103 guarantee becomes a challenge in case of contention since the 104 service is not deterministic but best effort. With more and more 105 rigid demand in latency control in the future network [METIS], 106 deterministic networking [I-D.finn-detnet-architecture] becomes a 107 promising solution to meet the requirement of ultra low-latency of 108 certain applications and use cases. There are already typical 109 issues for latency sensitive networking requirements in midhaul 110 and backhaul network to support LTE and future 5G network [5G]. 111 Moreover not only the telecom industry but also other vertical 112 industries have increasing demand on delay-sensitive 113 communications as automation becomes increasingly popular recently. 115 More specifically, CoMP techniques, D-2-D, industrial automation 116 and gaming/media service all have great dependency on low delay 117 communications as well as high reliability to guarantee the 118 service performance. Note that the deterministic networking is not 119 equal to low latency as it is more focused on the worst case delay 120 bound of the duration of certain application or service. It can be 121 argued that without high certainty and absolute delay guarantee, 122 low delay provisioning is just relative [RFC3393], which is not 123 sufficient to some delay-critical service since delay violation in 124 an instance cannot be tolerated. Overall, the requirements from 125 vertical industries seem to be well aligned with the expected low 126 latency and high determinist performance of future networks 128 This document only describes technical requirements and design 129 principles on data plane, control plane and modeling to minimize 130 the scope of this document since a full coverage of DetNet can be 131 found in [I-D.finn-detnet-architecture] 133 2. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 136 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 137 in this document are to be interpreted as described in [RFC2119]. 138 In this document, these words will appear with that interpretation 139 only when in ALL CAPS. Lower case uses of these words are not to 140 be interpreted as carrying [RFC2119] significance. 142 3. Overall Architecture 144 Draft [I-D.finn-detnet-architecture] provides an overall picture 145 of the DetNet operation. The draft covers almost every aspects of 146 deterministic service provisioning which will be indeed asking for 147 an architectural upgrade. An entire working system is needed for 148 end-to-end delay-guaranteed service provisioning, but the WG may 149 only works on several topics as the final deliverables. Meanwhile, 150 there are still some open issues on both design and implementation 151 of data plane and control plane. 153 Based on the current architecture, three key aspects are 154 identified: how to specify the data plane (including the 155 forwarding in [I-D.finn-detnet-architecture]) and what is the 156 essential characteristic of the data plane enabling deterministic 157 forwarding; how to design appropriate control protocols and 158 mechanisms to serve end-to-end DetNet flows; what and how modeling 159 should be defined to describe basic principles of both data plane 160 and control plane. 162 4. Data Plane Requirements 164 As mentioned in the current charter, DetNet focus on Layer 3 165 techniques to support deterministic latency applications. Without 166 redefining the hardware and physical layers, potential data plane 167 must be compatible with Layer 2 operations (i.e. TSN) In the 168 architectural draft[I-D.finn-detnet-architecture], the data plane 169 is described as the most fundamental element of the network, 170 comprising the device and forwarding plane, which decides the 171 queuing, scheduling and shaping of traffic. In order to provide 172 converged networking in which DetNet flows get bounded delay 173 guarantee while non-DetNet flows are best-effort, the DetNet data 174 plane should specify to answer the following questions: how to use 175 existing technologies for Layer 3 operation, MPLS may be a good 176 candidate to setup end-to-end deterministic flow path; how to 177 identify the DetNet data flow; a standardized mechanism of DetNet 178 flow forwarding including queuing, transmission, shaping and etc. 180 4.1. MPLS to Support DetNet Flow Forwarding 182 IEEE works on Layer 1-2 technologies where TSN has successfully 183 provided a potential solution to the problem of serving timing 184 critical data flow in Ethernet. In order to expand the guaranteed 185 delay provisioning to the scale of the entire network, it is 186 critical for DetNet WG to define the Layer forwarding. As 187 mentioned in current charter, the goal is to use existing 188 technology that can be compatible with TSN work. Given that, MPLS 189 technology is a good candidate for it maturity and robustness. 191 MPLS lies between Layer 3 and 2 with an encapsulation of different 192 protocols. Supposing that deterministic forwarding is ready at 193 each hop under TSN, MPLS can carry Ethernet frames to utilize TSN 194 techniques to provide an end-to-end label switched DetNet path. In 195 this way, the WG may needs to further define how to use MPLS in 196 the following aspects: 198 -Setup Label Switched Path (LSP) for DetNet flow with label 199 definition and QoS mapping. 201 -Latency-aware LSP installment and removing. RSVP-TE may not be 202 suitable for DetNet flows as it only describes macro-parameters 203 such as bandwidth. An extension may be desirable with latency 204 parameter. 206 -Supporting Layer-2 techniques such as pseudowire. 208 4.2. DetNet Flow Identification 210 Identification is the first step among all corresponding 211 operations related to DetNet flows. Because of the unified 212 transmission of both deterministic traffic flow and conventional 213 best effort flows, DetNet flow needs to be identified for certain 214 processes. Basically, there are two questions need to be taken are 215 of based on the authors' opinions: first, how to identify the flow 216 entity; second, how to identify its delay bound requirement. 218 Flow identification can be done via some tuple matching approach, 219 such as {VLAN identifier, destination MAC address} pair, 220 source/destination address, port, MAC address and so on. All these 221 approach can mark a unique flow in the network. However, they are 222 all dependent to the source. In other words, if the source is 223 sending both DetNet flow and best effort flow, this approach does 224 not work. To tackle with this challenge, a different destination 225 MAC address or a VLAN ID could be used. And so does the MPLS 226 labels. 228 A transformation in Layer 2 or a proxy function could be a 229 solution. More fundamental solution can be redefining new flag or 230 defining new flow model without doing the tuple matching. 231 Meanwhile, the flow identification should be application-aware and 232 impendent of sending source. An alternative approach can be 233 similar to those in Service Function Chain (SFC) to define 234 encapsulation format be agnostic to the layer at which it is 235 applied and the service that is being constructed. However, this 236 provision certainly need more work depending on the acceptance of 237 WG. 239 The second issue is how to identify the delay bound of the target 240 flow being required. This is a new question which has not been 241 well discussed. For DetNet, we want to do absolute delay bound 242 provisioning while allowing best effort traffic to share 243 unscheduled traffic. In this way, how to provision just enough 244 resource to the DetNet flow is the major problem. So first needs 245 is to know the delay bound of the application flow. Treat all 246 DetNet flow as the same does not make sense since one flow 247 requires 1ms delay but the other requires 10ms which are all 248 deterministic but definitely needs different amount of network 249 resources. 251 Currently, the flow can be marked with QoS level, e.g. 0-7, 252 denotes the level of priority of the flow. There is no absolute 253 delay information of the flow as QoS level only specifies the 254 general characteristic of the data flow. A new mechanism to label 255 the absolute delay bound is necessary and it can be done via a 256 mapping algorithm between delay bound and current QoS labeling. 258 4.3. Deterministic Forwarding Capability 260 Although, DetNet will not define new hardware or physical layer, 261 different flow forwarding mechanism including queuing, 262 transmission selection, and shaping equipped by different network 263 devices or network elements can lead to the uncertainty of the 264 timing. To achieve predictable delay introduced in every hop, a 265 standard of queuing, transmission selection, shaping, and 266 preemption is needed to unify all the NEs in forwarding plane. TSN 267 can be expected to support this but sufficiently well-defined 268 characteristics should be defined in the WG. In the authors' 269 opinion, at least two features should be defined: 271 -Frame preemption. As transmitted via the same medium, 272 deterministic flow should always have absolute priority against 273 best effort flow, which means the DetNet flow should be first 274 scheduled if there is any. The problem is if the port is 275 transmitting a best effort flow, the incoming DetNet flow has to 276 wait a MTU transmission time thus introduce 12us delay in a 1GE 277 line. So the best effort flow should be permeable to the DetNet 278 flow. TSN 802.1qbu is working preemption solution for Ethernet, 279 DetNet should be expected to have this capability either in Layer 280 2 or Layer 3. In addition to current TSN solution which is mainly 281 focused on cut best effort packet into smaller packet with 282 encapsulation, preemption on demand or real time preemption should 283 also be considered to avoid overhead and save latency. 285 -Time aware scheduling: preemption can solve the conflict between 286 DetNet flow and best effort flow by giving DetNet flow absolute 287 priority to preempt normal traffic. Conflict between DetNet flows 288 can still introduce uncertain delay. So scheduling of DetNet 289 traffic in advance with time aware capability is desirable to 290 solve this conflict. 292 5. Control Plane Requirements 294 In the use case draft [I-D.draft-ietf-detnet-use-cases], several 295 use cases summarize the needs of unified control and management 296 protocols and control plane. Control plane is the key component of 297 DetNet that can unify the existing Layer 2 technology and Layer 3 298 to deliver a fully functional solution for delay guarantee service. 299 Note that here "control plane" is used just for simplicity to 300 represent all control and management mechanism and protocols which 301 does not mean the separation of control and forwarding plane in 302 SDN. 304 The DetNet control plane design should include: architectural 305 choice as distributed or centralized control; 306 southbound/northbound interface; peer-to-peer reservation 307 protocols. 309 5.1. Distributed or Centralized Control 311 Assuming the data plane upgrade can provide deterministic 312 forwarding behavior at each hop, a unified control mechanism is 313 demanded to provide end-to-end delay guarantee. Although the 314 architecture draft propose a controller based centralized control 315 plane mechanism, it has not been decided yet to solely focus on 316 centralized only. The WG should also consider some distributed 317 solution with reservation protocols since centralized resource 318 reservation may introduce addition latency. 320 Introducing centralized controller seems to be the simple and 321 stringent forward solution. SDN is the new fashion right now with 322 separation of control plane from device to a remote controller. 323 For DetNet, if there is a central controller can do the path 324 computing, resource reservation and transmission selection based 325 on the information and delay requirement of the target flow on 326 every hop, it definitely can help to minimize the delay. First of 327 all, path computing has to be relied on central controller to 328 select the best forwarding path based on the DetNet flow request 329 and global information of the network. Secondly, reserve enough 330 resource at every hop is challenging for end-to-end delay 331 guarantee which can be benefited from a control resource manager 332 to make the DetNet flow get just enough resource at every hop. 333 Thirdly, transmission selection or scheduling at each hop is also 334 crucial to serve the flow in time. A central arbiter can be 335 equipped to make the DetNet flow travel pass the multi-hop with 336 green light all the way 338 On the other hand, centralized controller is offsite and has to 339 communicate with all the NEs of entire network which can bring in 340 addition latency. For DetNet flows that require ms delay, the time 341 cost of communication to the controller and communication between 342 control and NEs is not affordable. So a distributed control 343 mechanism is also considered to be promising in some scenarios. 344 With distributed control, the DetNet flows do not have to wait the 345 controller to acknowledge and configure the downstream NEs. An 346 efficient reserve protocol is needed to reserve bandwidth, buffer 347 and other resource at each hop along the forwarding path. Also, a 348 hybrid approach can also be helpful as the controller can setup 349 the path and distributed protocol to reserve the resource at each 350 hop. 352 5.2. Southbound/Northbound Interfaces 354 Within SDN architecture, southbound and northbound are the key 355 interfaces which are close related the NEs and flow model. If 356 there is a central controller for DetNet, it needs to know the 357 forwarding capabilities of the NEs and then send the configuration 358 to the NEs to serve the DetNet flow. All of this information is 359 transmitted via southbound interface. Also the controller should 360 get the service level requirements via northbound interface which 361 is based on the service model of DetNet flows. 363 Southbound interface should enables communication between control 364 plane and network elements with following information: 366 -The resource inventory of the network elements, such as left over 367 bandwidth, unscheduled time slot on link or the size of the unused 368 buffer. 370 -Topology information of the network, it can be the similar work 371 that is being done in I2RS or TEAS. 373 -The data plane information of NEs, which include the queuing, 374 transmission selection, shaping and preemption related information. 376 -The scheduling or QoS setting on the data plane and the 377 configuration information that makes the change. 379 Northbound interface enables communication between applications 380 and control and it should contain information related to: 382 -Service level delay requirement which can be transformed into 383 device configuration change in the controller. 385 -Flow and service description which can be relied on flow model 386 and configuration model. 388 5.3. Peer-to-Peer Reservation Protocol 390 As mentioned in section 5.1, distributed reservation protocols are 391 also desired even in a centralized architecture to reduce the 392 setup time caused by communication with controller. And ideal case 393 is that, a peer-to-peer protocol for a S-D pair to reserve 394 resource for DetNet flow without a central controller. Of cause 395 this will be an efficient and sophisticated approach if WG can 396 make it possible to deploy. In the authors' opinion, this peer-to- 397 peer reservation protocol should have characteristics such as: 399 -A hop by hop reservation protocol that reserve resource for the 400 coming DetNet flow before arriving to the next hop. The DetNet 401 flow will just pass through the hop using pre-setup resource. 403 -Only control packet or reservation signal is processed at each 404 hop, DetNet flow will be transmitted transparently all the way to 405 destination. 407 -This multi-hop signaling should start transmission of DetNet flow 408 immediately after setting up the path to next hop without 409 configure end-to-end path. 411 6. Requirements on DetNet Flow Modeling 413 DetNet flow modeling is one the most important deliverables of 414 this WG. How to model the DetNet flow will decide how to serve the 415 flow and how to reserve the resource, which are all the main focus 416 of the WG. Model is about description of characteristic of flow 417 transmission, technical requirements and network resource demands. 418 Traditional flow model is based on RSVP model which includes peak 419 rate, sustain rate, burst and etc. this is not feasible for 420 deterministic service provisioning as the bandwidth itself is not 421 a accurate description of latency. The DetNet flow modeling should 422 include: 424 -Application-aware description of the flow. 426 -Timing information of the flow so that the network can provide 427 accurate service to guarantee the delay requirement. 429 -Data transmission information of the flow including packet size, 430 interval, traffic pattern and so on. 432 -Network-aware constraints on networking environment. 434 7. Requirements on Synchronization and OAM 436 Since operations and scheduling can be time-aware in DetNet and 437 absolute delay bound is a must in a multi-hop network, time 438 synchronization is necessary. Besides, in both centralized and 439 distributed architecture, delay measuring among multi-hops and 440 synchronization is a must for DetNet. 442 There is also a need for OAM system and protocols which can help 443 to provide E2E delay sensitive service provisioning. 445 More details of synchronization and OAM will be provided in next 446 version. 448 8. Security Considerations 450 TBD 452 9. IANA Considerations 454 This document has no actions for IANA. 456 10. Acknowledgments 458 This document has benefited from reviews, suggestions, comments 459 and proposed text provided by the following members, listed in 460 alphabetical order: Yuanlong Jiang and Oilver Huang. 462 11. References 464 11.1. Normative References 466 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP 470 Performance Metrics (IPPM) ", RFC 3393, November 2002. 472 11.2. Informative References 474 [I-D.finn-detnet-problem-statement] 476 Finn, N. and P. Thubert, "Deterministic Networking Problem 477 Statement", draft-finn-detnet-problem-statement-02 (work in 478 progress), October 2015. 480 [I-D.finn-detnet-architecture] 482 Finn, N., Thubert, P., and M. Teener, "Deterministic Networking 483 Architecture", draft-finn-detnet-architecture-03 (work in 484 progress), March 2016. 486 [I-D.draft-ietf-detnet-use-cases] 488 Ethan Grossman, et al, "Deterministic Networking Use Cases", 489 draft-ietf-detnet-use-cases-08, March 2016. 491 [METIS] METIS Document Number: ICT-317669-METIS/D1.1, Scenarios, 492 requirements and KPIs for 5G mobile and wireless system, April 29, 493 2013. Available on line at: 496 [5G] Ericsson white paper, "5G Radio Access, Challenges for 2020 497 and Beyond." June 2013. Available at: 498 500 [CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND 501 ENHANCEMENT ", MARCH 2015, 502 505 [LTE-Latency]Samuel Johnston, "LTE Latency: How does it compare to 506 other technologies?" report of OpenSignal March 10, 2014. 507 510 [EA12] P. C. Evans, M. Annunziata, "Industrial Internet: Pushing the 511 Boundaries of Minds and Machines", General Electric White paper, 512 November 2012. 514 [UHD-video] Petr Holub, "Ultra-High Definition Videos and Their 515 Applications over the Network", The 7th International Symposium on 516 VICTORIES Project, OCTOBER 8, 2014. 519 Authors' Addresses 521 Yiyong Zha 522 Huawei Technologies 523 Email: zhayiyong@huawei.com 525 Liang Geng 526 China Mobile 527 Email: liang.geng@hotmail.com