idnits 2.17.1 draft-li-apn6-problem-statement-usecases-01.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1632 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8200' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 547, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8578 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 7, 2020 D. Voyer 6 Bell Canada 7 C. Xie 8 China Telecom 9 P. Liu 10 China Mobile 11 C. Liu 12 China Unicom 13 K. Ebisawa 14 Toyota Motor Corporation 15 S. Previdi 16 Individual 17 J. Guichard 18 Futurewei Technologies Ltd. 19 November 04, 2019 21 Problem Statement and Use Cases of Application-aware IPv6 Networking 22 (APN6) 23 draft-li-apn6-problem-statement-usecases-01 25 Abstract 27 Network operators are facing the challenge of providing better 28 network services for users. As the ever developing 5G and industrial 29 verticals evolve, more and more services that have diverse network 30 requirements such as ultra-low latency and high reliability are 31 emerging, and therefore differentiated service treatment is desired 32 by users. However, network operators are typically unaware of which 33 applications are traversing their network infrastructure, which means 34 that only coarse-grained services can be provided to users. As a 35 result, network operators are only evolving their infrastructure to 36 be large but dumb pipes without corresponding revenue increases that 37 might be enabled by differentiated service treatment. As network 38 technologies evolve including deployments of IPv6 and SRv6, the 39 programmability provided by IPv6 and SRv6 encapsulations can be 40 augmented by conveying application related information into the 41 network. Adding application knowledge to the network layer allows 42 applications to specify finer granularity requirements to the network 43 operator. 45 This document analyzes the existing problems caused by lack of 46 application awareness, and outlines various use cases that could 47 benefit from an Application-aware IPv6 Networking (APN6) 48 architecture. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at https://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on May 7, 2020. 73 Copyright Notice 75 Copyright (c) 2019 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (https://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 92 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 93 3.1. Large but Dumb Pipe . . . . . . . . . . . . . . . . . . . 4 94 3.2. Network on Its Own . . . . . . . . . . . . . . . . . . . 4 95 3.3. Decoupling of Network and Applications . . . . . . . . . 4 96 3.4. Challenges of Traditional Differentiated Service 97 Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 99 3.5. Challenges of Supporting New 5G and Edge Computing 100 Technologies . . . . . . . . . . . . . . . . . . . . . . 6 101 4. Key Elements of Application-aware IPv6 Networking (APN6) . . 6 102 5. Use cases for Application-aware IPv6 Networking (APN6) . . . 8 103 5.1. Application-aware SLA Guarantee . . . . . . . . . . . . . 8 104 5.2. Application-aware network slicing . . . . . . . . . . . . 9 105 5.3. Application-aware Deterministic Networking . . . . . . . 9 106 5.4. Application-aware Service Function Chaining . . . . . . . 10 107 5.5. Application-aware Network Measurement . . . . . . . . . . 10 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 111 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 113 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 114 10.2. Informative References . . . . . . . . . . . . . . . . . 12 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 117 1. Introduction 119 Due to the requirement for differentiated traffic treatment driven by 120 diverse new services, the ability to convey the characteristics of an 121 application's traffic flow and program the network infrastructure 122 accordingly to provide fine-grained service assurance is becoming 123 increasingly necessary for network operators. The Application-aware 124 IPv6 Networking (APN6) architecture is being defined to address the 125 requirements and use cases described in this document. APN6 takes 126 advantage of network programmability by conveying application related 127 information in the data plane allowing applications to specify finer 128 grained requirements to the network infrastructure. 130 2. Terminology 132 ACL: Access Control List 134 APN6: Application-aware IPv6 Networking 136 DPI: Deep Packet Inspection 138 PBR: Policy Based Routing 140 QoE: Quality of Experience 142 SDN: Software Defined Networking 144 3. Problem Statement 146 This section summarizes the challenges currently faced by network 147 operators when attempting to provide fine-grained traffic operations 148 to satisfy the various application-awareness requirements demanded by 149 new services that require differentiated service treatment. 151 3.1. Large but Dumb Pipe 153 In today's networks, the infrastructure through which user traffic is 154 forwarded is not able to determine information about the packet, 155 including which application the traffic belongs to, without the 156 introduction of middleware such as DPI, that is, the network and 157 applications are decoupled. It is therefore difficult for network 158 operators to provide fine-grained traffic operations for performance- 159 demanding applications. In order to satisfy the SLA requirements 160 network operators continue to increase the network bandwidth but only 161 carrying very light traffic load (around 30%-40% of its capacity). 162 This situation greatly increases the CAPEX and OPEX but only brings 163 very little revenue from the carried services. 165 3.2. Network on Its Own 167 As the network evolves, technologies such as VPN/TE/FRR play 168 important roles in satisfying service isolation, SLA guarantee, and 169 high reliability, etc. These network technologies have themselves 170 been evolving, introducing new features that forces the network 171 operator to be continuously upgrading their network infrastructure. 172 However, none of these network technologies make the network aware of 173 which application traffic belongs to and the fine granularity 174 requirements of the application. Therefore, such continuous network 175 infrastructure upgrade doesn't always enable true fine-grained 176 traffic operation, therefore reducing the ability to bring 177 corresponding revenue increase. 179 3.3. Decoupling of Network and Applications 181 MPLS played a very important role in helping the network enter the 182 generation of All-IP successfully. However, MPLS doesn't allow a 183 close interworking with the application layer since MPLS 184 encapsulation is, typically, not used by the packet source. 186 As new services continuously evolve, more encapsulations are 187 required, and this isolation and decoupling has further become the 188 blockage towards the seamless convergence of the network and 189 applications. 191 3.4. Challenges of Traditional Differentiated Service Provisioning 193 Several IETF activities have been reviewed which are primarily 194 intended to evolve the IP architecture to support new service 195 definitions which allow preferential or differentiated treatment to 196 be accorded to certain types of traffic. The challenge when using 197 traditional ways to guarantee an SLA is that the packets are not able 198 to carry enough information for indicating applications and 199 expressing their service/SLA requirements. The network devices 200 mainly rely on the 5-tuple of the packets or DPI. However, there are 201 some challenges for these traditional methods in differentiated 202 service provisioning: 204 1. Five Tuples used for ACL/PBR 206 Five tuples are widely used for ACL/PBR matching of traffic. 207 However, these features cannot provide enough information for the 208 fine-grained service process, and can only provide indirect 209 application information which needs to be translated in order to 210 indicate a specific application. 212 2. Deep Packet Inspection (DPI) 214 If more information is needed, it must be extracted using DPI which 215 can inspect deep into the packets for application specific 216 information. However, this will introduce more CAPEX and OPEX for 217 the network operator and imposes security challenges. 219 3. Orchestration and SDN-based Solution 221 In the era of SDN, typically, an SDN controller is used to manage and 222 operate the network infrastructure and orchestrator elements 223 introduce application requirements so that the network is programmed 224 accordingly. The SDN controller can be aware of the service 225 requirements of the applications on the network through the interface 226 with the orchestrator, and the service requirement is used by the 227 controller for traffic management over the network. However, this 228 method raises the following problems: 230 1) The whole loop is long and time-consuming which is not suitable 231 for fast service provisioning for critical applications; 233 2) Too many interfaces are involved in the loop, as shown in 234 Figure 1, which introduce challenges of standardization and inter- 235 operability. 237 +--------------+ 238 /-----| Orchestrator | -------------------\ 239 / +--------------+ Resource \ 240 APP Req. / \ Management \ 241 +---------+ +---------+ & +---------+ 242 |SDN Ctrl1| |SDN Ctrl2| Service |SDN Ctrl3| 243 +---------+ +---------+ Provisioning +---------+ 244 APP Req. / \ / \ / \ 245 +-/-+ +--\--+ +----------+ +----------+ +----------+ +----------+ 246 |APP| | DCN | |Network D1|..|Network D3| |Network D4|..|Network D6| 247 +---+ +-----+ +----------+ +----------+ +----------+ +----------+ 249 Figure 1. Many interfaces involved in the long service-provisioning loop 251 3.5. Challenges of Supporting New 5G and Edge Computing Technologies 253 New technologies such as 5G, IoT, and edge computing, are 254 continuously developing leading to more and more new types of 255 services accessing the network. Large volumes of network traffic 256 with diverse requirements such as low latency and high reliability 257 are therefore rapidly increasing. If traditional methods for 258 differentiation of traffic continue to be utilized, it will cause 259 much higher CAPEX and OPEX to satisfy the ever-developing 260 applications' diverse requirements. 262 4. Key Elements of Application-aware IPv6 Networking (APN6) 264 Application-aware IPv6 Networking (APN6) aims to address the 265 aforementioned problems associated with fine-grained traffic 266 operations that are required in order to satisfy the various 267 application-awareness requirements demanded by new services that need 268 differentiated service treatment. APN6 conveys information into the 269 network infrastructure about the characteristics of the application 270 associated with a traffic flow (including application identification 271 and network performance requirements), allowing the network to 272 quickly adapt and perform the necessary network resource adjustments 273 to maintain SLA performance guarantees, and hence better serve 274 application fine-grained service requirements. 276 The advantages of using IPv6 to support APN6 include, 278 1. Simplicity: Conveying application information with IPv6 279 encapsulation can just be based on IP reachability. 281 2. Seamless convergence: Much easier to achieve seamless convergence 282 between applications and network since both are based on IPv6. 284 3. Great extensibility: IPv6 encapsulation including its extension 285 headers can be used to carry very rich information relevant to 286 applications. 288 4. Good compatibility: On-demand network upgrade and service 289 provisioning. If the application information is not recognized 290 by the node, the packet will be forwarded based on pure IPv6, 291 which ensure backward compatibility. 293 5. Little dependency: Information conveying and service provisioning 294 are only based on the forwarding plane of devices, which is 295 different from the Orchestration and SDN-based solution which 296 involves multiple elements and diverse interfaces. 298 6. Quick response: Flow-driven and direct response from devices 299 since it is based on the forwarding plane. 301 APN6 has the following key elements: 303 1. Application information should be conveyed in the data plane 304 through augmentation of existing encapsulations such as IPv6 and/ 305 or SRv6. The conveyed application characteristic information 306 (application-aware information) includes application 307 identification and/or its network performance requirements. This 308 element should not be enforced but provide an open option for 309 applications to decide whether to input this application-aware 310 information into their data stream. 312 2. Application information and network service provisioning matching 313 providing fine-granularity network service provisioning (traffic 314 operations) and SLA guarantee based on the application-aware 315 information carried in APN6 packets. This element provides the 316 network capabilities to applications. According to the 317 application-aware information, appropriate network services are 318 selected, provisioned, and provided to the demanding applications 319 to satisfy their performance requirements. 321 3. Network measurement of network performance and update the match 322 between the applications and corresponding network services for 323 better fine-granularity SLA compliance. The network measurement 324 methods include in-band and out-of-band, passive, active, per- 325 packet, per-flow, per node, end-to-end, etc. These methods can 326 also be integrated. 328 Applications | Network 330 Element 1: Conveying -------------------> 331 /|\ 332 Application Info | Network capabilities 333 | (SLA guarantee) 334 | /|\ 335 Element 2: Matching | 336 | 337 Element 3: Network Measurement 339 Figure 2. Illustration of the key elements of APN6 341 5. Use cases for Application-aware IPv6 Networking (APN6) 343 This section provides the use cases that can benefit from the 344 application awareness introduced by APN6. The corresponding 345 requirements for APN6 are also outlined. 347 5.1. Application-aware SLA Guarantee 349 One of the key objectives of APN6 is for network operators to provide 350 fine-granularity SLA guarantees instead of coarse-grain traffic 351 operations. Among various applications being carried and running in 352 the network, some revenue-producing applications such as online 353 gaming, video streaming, and enterprise video conferencing have much 354 more demanding performance requirements such as low network latency 355 and high bandwidth. In order to achieve better Quality of Experience 356 (QoE) for end users and engage customers, the network needs to be 357 able to provide fine-granularity and even application-level SLA 358 guarantee. Differentiated service provisioning is also desired. 360 One of the key objective of APN6 is for network operators to provide 361 fine-granularity SLA guarantees instead of coarse-grain traffic 362 operations. This will enable them to provide differentiated services 363 for different applications and increase revenue accordingly. 365 The APN6 architecture design MUST address the following requirements: 367 o APN6 needs to perform the three key elements as described in 368 Section 4. 370 o Support application-level fine-granularity traffic operation that 371 may include finer QoS scheduling. 373 5.2. Application-aware network slicing 375 More and more applications/services with diverse requirements are 376 being carried over and sharing the network operators' network 377 infrastructure. However, it is still desirable to have customized 378 network transport that can support some application's specific 379 requirements, taking into consideration service and resource 380 isolation, which drives the concept of network slicing. 382 Network slicing provides ways to partition the network infrastructure 383 in either the control plane or data plane into multiple network 384 slices that are running in parallel. These network slices can serve 385 diverse services and fulfill their various requirements at the same 386 time. For example, the mission critical application that requires 387 ultra-low latency and high reliability can be provisioned over a 388 separate network slice. 390 The APN6 architecture design MUST address the following requirements: 392 o APN6 needs to perform the three key elements as described in 393 Section 4 in the context of network slicing. To be more specific, 394 for element 2, it needs to match to a specific network slice 395 according to the application information carried in the APN6 396 packets. The network measurement in element 3 also needs to 397 happen within each network slice. 399 5.3. Application-aware Deterministic Networking 401 [RFC8578] documents use cases for diverse industry applications that 402 require deterministic flows over multi-hop paths. Deterministic 403 flows provide guaranteed bandwidth, bounded latency, and other 404 properties relevant to the transport of time-sensitive data, and can 405 coexist on an IP network with best-effort traffic. It also provides 406 for highly reliable flows through provision for redundant paths. 408 The APN6 architecture design MUST address the following requirements: 410 o APN6 needs to perform the three key elements as described in 411 Section 4 in the context of deterministic networking. To be more 412 specific, for the element 2, it needs to match to a specific 413 deterministic path according to the application information 414 carried in the APN6 packets. The network measurement in element 3 415 also needs to be performed on each application-aware deterministic 416 path. 418 5.4. Application-aware Service Function Chaining 420 End-to-end service delivery often needs to go through various service 421 functions, including traditional network service functions such as 422 firewalls, DPIs as well as new application-specific functions, both 423 physical and virtual. The definition and instantiation of an ordered 424 set of service functions and subsequent steering of the traffic 425 through them is called Service Function Chaining (SFC) [RFC7665]. 426 SFC is applicable to both fixed and mobile networks as well as data 427 center networks. 429 Generally, in order to manipulate a specific application traffic 430 along the SFC, a DPI needs to be deployed as the first service 431 function of the chain to detect the application, which will impose 432 high CAPEX and consume long processing times. For encrypted traffic, 433 it even becomes impossible to inspect the application. 435 The APN6 architecture design MUST address the following requirements: 437 o APN6 needs to perform the three key elements as described in 438 Section 4 in the context of service function chaining. To be more 439 specific, for element 1 class information can be conveyed. For 440 element 2, it needs to match to a specific service function chain 441 and subsequent steering according to the application information 442 carried in the APN6 packets. The network measurement in element 3 443 also needs to happen within each app-aware service function chain. 445 5.5. Application-aware Network Measurement 447 Network measurement can be used for locating silent failure and 448 predicting QoE satisfaction, which enables real-time SLA awareness/ 449 proactive OAM. Operations, Administration, and Maintenance (OAM) 450 refers to a toolset for fault detection and isolation, and network 451 performance measurement. In-situ Operations, Administration, and 452 Maintenance (IOAM) records operational and telemetry information in 453 the packet while the packet traverses a path between two points in 454 the network. 456 The APN6 architecture MUST address the following requirements: 458 o APN6 needs to perform the two key elements as described in 459 Section 4 in the context of network measurement. The network 460 measurement in element 3 does not need to be considered here. 462 6. IANA Considerations 464 This document does not include an IANA request. 466 7. Security Considerations 468 Since the application information is conveyed into the network, it 469 does involve some security and privacy issues. 471 First, APN6 only provides the capability to the applications to 472 provide their profiles and requirements to the network, but it leaves 473 the applications to decide whether to input this information. If the 474 applications decide not to provide any information, they will be 475 treated in the same way as today's network and cannot get the 476 benefits from APN6. 478 Once the application information has been carried in the IPv6 packets 479 and conveyed into the network, the IPv6 extension headers, AH and 480 ESP, can be used to guarantee the authenticity of the added 481 application information. 483 Any scheme involving an information exchange between layers 484 (application and network layers in this case) will obviously require 485 an accurate valuation of security mechanism in order to prevent any 486 leak of critical information. Some additional considerations may be 487 required for multi-domain use cases. For example, how to agree upon 488 which application information/ID to use and guarantee authenticity 489 for packets traveling through multiple domains (network operators). 491 8. Acknowledgements 493 The authors would like to acknowledge Robert Raszuk (Bloomberg LP) 494 and Yukito Ueno (NTT Communications Corporation) for their valuable 495 review and comments. 497 9. Contributors 499 Liang Geng 500 China Mobile 501 China 503 Email: gengliang@chinamobile.com 505 Chang Cao 506 China Unicom 507 China 509 Email: caoc15@chinaunicom.cn 510 Cong Li 511 China Telecom 512 China 514 Email: licong.bri@chinatelecom.cn 516 10. References 518 10.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, 522 DOI 10.17487/RFC2119, March 1997, 523 . 525 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 526 Chaining (SFC) Architecture", RFC 7665, 527 DOI 10.17487/RFC7665, October 2015, 528 . 530 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 531 (IPv6) Specification", STD 86, RFC 8200, 532 DOI 10.17487/RFC8200, July 2017, 533 . 535 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 536 RFC 8578, DOI 10.17487/RFC8578, May 2019, 537 . 539 10.2. Informative References 541 [I-D.ietf-6man-segment-routing-header] 542 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 543 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 544 Routing Header (SRH)", draft-ietf-6man-segment-routing- 545 header-26 (work in progress), October 2019. 547 [I-D.ietf-spring-srv6-network-programming] 548 Filsfils, C., Camarillo, P., Leddy, J., 549 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 550 Network Programming", draft-ietf-spring-srv6-network- 551 programming-05 (work in progress), October 2019. 553 Authors' Addresses 554 Zhenbin Li 555 Huawei Technologies 556 China 558 Email: lizhenbin@huawei.com 560 Shuping Peng 561 Huawei Technologies 562 China 564 Email: pengshuping@huawei.com 566 Daniel Voyer 567 Bell Canada 568 Canada 570 Email: daniel.voyer@bell.ca 572 Chongfeng Xie 573 China Telecom 574 China 576 Email: xiechf.bri@chinatelecom.cn 578 Peng Liu 579 China Mobile 580 China 582 Email: liupengyjy@chinamobile.com 584 Chang Liu 585 China Unicom 586 China 588 Email: liuc131@chinaunicom.cn 590 Kentaro Ebisawa 591 Toyota Motor Corporation 592 Japan 594 Email: ebisawa@toyota-tokyo.tech 595 Stefano Previdi 596 Individual 597 Italy 599 Email: stefano@previdi.net 601 James N Guichard 602 Futurewei Technologies Ltd. 603 USA 605 Email: jguichar@futurewei.com