idnits 2.17.1 draft-li-apn6-problem-statement-usecases-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 : ---------------------------------------------------------------------------- ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 25, 2019) is 1675 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: 'I-D.ietf-6man-segment-routing-header' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 544, 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 (-26) exists of draft-ietf-6man-segment-routing-header-23 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-02 Summary: 3 errors (**), 0 flaws (~~), 6 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: March 28, 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 Y. Ueno 16 NTT Communications Corporation 17 S. Previdi 18 Individual 19 J. Guichard 20 Futurewei Technologies Ltd. 21 September 25, 2019 23 Problem statement and use cases of Application-aware IPv6 Networking 24 (APN6) 25 draft-li-apn6-problem-statement-usecases-00 27 Abstract 29 Operators are facing the challenges of providing better network 30 services for users. As the ever-developing 5G and industrial 31 verticals evolve, more and more services that have diverse network 32 requirements such as ultra-low latency and high reliability are 33 emerging and accessing the network, differentiated service treatments 34 are desired by users. However, operators are still not aware of 35 applications, which cause that only coarse-grained services can be 36 provided to users. As a result, operators are only evolving to be 37 large but dumb pipes without corresponding revenue increase. As the 38 network technologies evolve including deployments of IPv6 and SRv6, 39 the programmability provided by IPv6 and SRv6 encapsulations can be 40 augmented by conveying the application related information into the 41 network. Adding application knowledge to the network layer, allow 42 applications to specify finer granularity requirements, which 43 eventually bridges network and applications. 45 This document analyzes the existing problems of the current operators 46 in the application awareness, and outlines various use cases that 47 could benefit from the Application-aware IPv6 Networking (APN6). 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on March 28, 2020. 72 Copyright Notice 74 Copyright (c) 2019 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (https://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 91 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 92 3.1. Large but dumb pipe . . . . . . . . . . . . . . . . . . . 4 93 3.2. Network on its own . . . . . . . . . . . . . . . . . . . 4 94 3.3. Decoupling of network and applications . . . . . . . . . 4 95 3.4. Challenges of traditional differentiated service 96 provisioning . . . . . . . . . . . . . . . . . . . . . . 4 98 3.5. Challenges of supporting new 5G and edge computing . . . 6 99 4. Application-aware IPv6 Networking (APN6) . . . . . . . . . . 6 100 5. Use cases of APN6 . . . . . . . . . . . . . . . . . . . . . . 8 101 5.1. App-aware SLA Guarantee . . . . . . . . . . . . . . . . . 8 102 5.2. App-aware network slicing . . . . . . . . . . . . . . . . 9 103 5.3. App-aware deterministic networking . . . . . . . . . . . 9 104 5.4. App-aware service function chaining . . . . . . . . . . . 10 105 5.5. App-aware network measurement . . . . . . . . . . . . . . 10 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 108 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 109 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 112 10.2. Informative References . . . . . . . . . . . . . . . . . 12 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 115 1. Introduction 117 Operators are facing the challenges of providing better network 118 services for users. As the ever-developing 5G and industrial 119 verticals evolve, more and more services that have diverse network 120 requirements such as ultra-low latency and high reliability are 121 emerging and accessing the network, differentiated service treatments 122 are desired by users. However, operators are still not aware of 123 applications, which cause that only coarse-grained services can be 124 provided to users. As a result, operators are only evolving to be 125 large but dumb pipes without corresponding revenue increase. As the 126 network technologies evolve including deployments of IPv6 and SRv6, 127 the programmability provided by IPv6 and SRv6 encapsulations can be 128 augmented by conveying the application related information into the 129 network. Adding application knowledge to the network layer, allow 130 applications to specify finer granularity requirements, which 131 eventually bridges network and applications. 133 This document analyzes the existing problems of the current operators 134 in the application awareness, and outlines various use cases that 135 could benefit from the Application-aware IPv6 Networking (APN6). 137 2. Terminology 139 ACL: Access Control List 141 APN6: Application-aware IPv6 Networking 143 DPI: Deep Packet Inspection 145 PBR: Policy Based Routing 146 QoE: Quality of Experience 148 3. Problem Statement 150 This section summarizes the challenges faced by the operators to 151 satisfy the various requirements of applications and provide fine- 152 granular traffic operations. 154 3.1. Large but dumb pipe 156 Currently, the network is still not aware of applications, that is, 157 the network and applications are actually decoupled. It is difficult 158 for network operators to provide fine-granular traffic operations for 159 performance-demanding applications. In order to satisfy the SLA 160 requirements operators continue to increase the network bandwidth but 161 only carrying very light traffic load (around 30%-40% of its 162 capacity). This situation greatly increases the CAPEX and OPEX but 163 only brings very little revenue from the carried services, which 164 makes operators' network infrastructure large but dumb pipes. 166 3.2. Network on its own 168 As the network evolves, VPN/TE/FRR play important roles in satisfying 169 the service isolation, SLA guarantee, and high reliability, etc. 170 Those network technologies have been evolving themselves, which make 171 the network features continuously upgrading. However, such 172 continuous upgrading doesn't bring corresponding revenue increase. 173 Marginal Utility has been reduced, which has become the bottleneck of 174 operators to increase their revenue. 176 3.3. Decoupling of network and applications 178 MPLS played a very important role in helping the network enter the 179 generation of All-IP successfully. However, MPLS actually doesn't 180 allow a close interworking with the application layer since MPLS 181 encapsulation is, typically, not used by the packet source. 183 As new services continuously evolve, more encapsulations are 184 required, and this isolation and decoupling has further become the 185 blockage towards the seamless convergence of the network and 186 applications. 188 3.4. Challenges of traditional differentiated service provisioning 190 A number of IETF activities have been reviewed which are primarily 191 intended to evolve the IP architecture to support new service 192 definitions which allow preferential or differentiated treatment to 193 be accorded to certain types of traffic. The challenge when using 194 traditional ways to guarantee SLA is that the packets are not able to 195 carry enough information for indicating applications and expressing 196 their service/SLA requirements. The network devices mainly rely on 197 the 5-tuple of the packets or DPI. However, there are some 198 challenges of those traditional methods in differentiated service 199 provisioning. 201 1. Five tuples used for ACL/PBR 203 Five tuples are widely used for ACL/PBR. However, they cannot 204 provide enough information for the fine-grained service process, and 205 can only be seen as indirect application information which needs to 206 be translated in order to indicate a specific application. It will 207 further impact on the forwarding performance. 209 2. Deep Packet Inspection (DPI) 211 If more information is needed, it has to be done through the use of 212 DPI in order to deeply inspect the packets. However, this will 213 introduce more CAPEX and OPEX in the network and also it imposes 214 security challenges. 216 3. Orchestration and SDN-based solution 218 In the era of SDN, typically, a SDN controller is used to manage and 219 operate the network infrastructure and orchestrator elements allow to 220 introduce application requirements so that the network is programmed 221 accordingly. The SDN controller can be aware of the service 222 requirements of the applications on the network through the interface 223 with the orchestrator, and the service requirement is used by the 224 controller for traffic management over the network. However, this 225 method raises the following problems: 227 1) The whole loop is long and time-consuming which is not suitable 228 for the fast service provisioning for critical applications; 230 2) Too many interfaces are involved in the loop, as shown in 231 Figure 1, which introduce challenges of standardization and inter- 232 operability. 234 +--------------+ 235 /-----| Orchestrator | -------------------\ 236 / +--------------+ Resource \ 237 APP Req. / \ Management \ 238 +---------+ +---------+ & +---------+ 239 |SDN Ctrl1| |SDN Ctrl2| Service |SDN Ctrl3| 240 +---------+ +---------+ Provisioning +---------+ 241 APP Req. / \ / \ / \ 242 +-/-+ +--\--+ +----------+ +----------+ +----------+ +----------+ 243 |APP| | DCN | |Network D1|..|Network D3| |Network D4|..|Network D6| 244 +---+ +-----+ +----------+ +----------+ +----------+ +----------+ 246 Figure 1. Many interfaces involved in the long service-provisioning loop 248 3.5. Challenges of supporting new 5G and edge computing 250 As the continuous development of 5G, IoT, and edge computing, more 251 and more new type of services are (and will be) accessing network. 252 Vast volume of network traffic with diverse requirements such as low 253 latency and high reliability rapidly increases. If we continue to 254 use traditional methods, it will cause much higher CAPEX and OPEX to 255 satisfy the ever-developing applications' diverse requirements. 257 4. Application-aware IPv6 Networking (APN6) 259 To resolve the above-mentioned issues, one possible way is to convey 260 the application characteristic information (including application 261 identification and network performance requirements) into the 262 network, and make the network aware of application characteristic 263 information more quickly in order to perform the fine-granularity 264 network resource adjustment and SLA performance guarantee, hence to 265 better serve demanding applications. 267 The IPv6 encapsulation including its extension headers (EH) [RFC8200] 268 are well suited for a good programmability and can be utilized to 269 encapsulate application information as well as other necessary 270 information. EH provides very good foundations for the application- 271 aware fine-granularity service provisioning. We name this technology 272 as APN6. 274 The advantages of using IPv6 to support APN6 include, 276 1. Simplicity: Conveying application information with IPv6 277 encapsulation can just be based on IP reachability. 279 2. Seamless convergence: Much easier to achieve seamless convergence 280 between applications and network since both are based on IPv6. 282 3. Great extensibility: IPv6 encapsulation including its extension 283 headers can be used to carry very rich information relevant to 284 applications. 286 4. Good compatibility: On-demand network upgrade and service 287 provisioning. If the application information is not recognized 288 by the node, the packet will be forwarded based on pure IPv6, 289 which ensure backward compatibility. 291 5. Little dependency: Information conveying and service provisioning 292 are only based on the forwarding plane of devices, which is 293 different from the Orchestration and SDN-based solution which 294 involves multiple elements and diverse interfaces. 296 6. Quick response: Flow-driven and direct response from devices 297 since it is based on the forwarding plane. 299 APN6 has the following key elements, 301 1. Application information is conveyed by the IPv6 encapsulation: 302 The conveyed application characteristic information (application- 303 aware information) includes application identification and/or its 304 network performance requirements. This element is not enforced 305 but actually provides an open option for applications to decide 306 whether to input this application-aware information. 308 2. Application information and network service provisioning 309 matching: provide fine-granularity network service provisioning 310 (traffic operations) and SLA guarantee based on the application- 311 aware information carried in IPv6 packets. This element provides 312 the network capabilities to applications. According to the 313 application-aware information, appropriate network services are 314 selected and provisioned to the demanding applications and 315 satisfy their performance requirements. 317 3. Network measurement based on IPv6: measure the network 318 performance and update the matching between the applications and 319 corresponding network services in order for better fine- 320 granularity SLA compliance. The network measurement methods 321 include in-band and out-of-band, passive, active, per-packet, 322 per-flow, per node, end-to-end, etc. These methods can also be 323 integrated. 325 Applications | Network 327 Element 1: Conveying -------------------> 328 /|\ 329 Application Info | Network capabilities 330 | (SLA guarantee) 331 | /|\ 332 Element 2: Matching | 333 | 334 Element 3: Network Measurement 336 Figure 2. Illustration of the key elements of APN6 338 5. Use cases of APN6 340 This session provides the use cases that can benefit from the 341 application awareness. The corresponding requirements for APN6 are 342 also outlined. 344 5.1. App-aware SLA Guarantee 346 Among various applications being carried and running in the network, 347 some revenue-producing applications such as online gaming, video 348 streaming, and enterprise video conferencing have much more demanding 349 performance requirements such as low network latency and high 350 bandwidth. In order to achieve better Quality of Experience (QoE) of 351 the end users and engage customers, the network needs to be able to 352 provide fine-granularity and even application-level SLA guarantee. 353 Differentiated service provisioning is desired. 355 One of the key objective of APN6 is for operators to provide fine- 356 granularity SLA guarantee instead of coarse-grain traffic operations. 357 This will enable operators to provide differentiated services for 358 different applications of their customers and make increase revenue 359 accordingly. 361 Requirements for APN6: 363 For achieving App-aware SLA Guarantee, APN6 needs to perform the 364 three key elements as described in Section 4. Application-level 365 fine-granularity traffic operation that may include finer QoS 366 scheduling is the key to guarantee the SLA of each specific demanding 367 application. 369 5.2. App-aware network slicing 371 More and more applications/services with diverse requirements are 372 being carried over and sharing operators' network infrastructure, the 373 same to the enterprise case. However, it is still desired to have 374 customized network transport that is able to support some 375 application's specific requirements, considering also the service and 376 resource isolation, which drives the concept of network slicing. 378 Network slicing provides ways to partition the network infrastructure 379 in either control plane or data plane into multiple network slices 380 that are running in parallel. These network slices can serve diverse 381 services and fulfill their various requirements at the same time. 382 For example, the mission critical application that requires ultra-low 383 latency and high reliability can be provisioned over a separated 384 network slice. 386 Requirements for APN6: 388 For achieving App-aware network slicing, APN6 needs to perform the 389 three key elements as described in Section 4 in the context of 390 network slicing. To be more specific, for the element 2, it needs to 391 match to a specific network slice according to the application 392 information carried in the IPv6 packets. The network measurement in 393 element 3 also needs to happen within each network slice. 395 5.3. App-aware deterministic networking 397 [RFC8578] documents use cases for diverse industry applications that 398 require deterministic flows over multi-hop paths. Deterministic 399 flows provide guaranteed bandwidth, bounded latency, and other 400 properties relevant to the transport of time-sensitive data, and can 401 coexist on an IP network with best-effort traffic. It also provides 402 for highly reliable flows through provision for redundant paths. 404 Requirements for APN6: 406 For achieving App-aware deterministic networking, APN6 needs to 407 perform the three key elements as described in Section 4 in the 408 context of deterministic networking. To be more specific, for the 409 element 2, it needs to match to a specific deterministic path 410 according to the application information carried in the IPv6 packets. 411 The network measurement in element 3 also needs to be performed on 412 each app-aware deterministic path. 414 5.4. App-aware service function chaining 416 The end-to-end service delivery often needs to go through various 417 service functions, including traditional network service functions 418 such as firewalls, DPI as well as new application-specific functions, 419 both physical and virtual. The definition and instantiation of an 420 ordered set of service functions and subsequent steering of the 421 traffic through them is called Service Function Chaining (SFC) 422 [RFC7665]. SFC is applicable to both fixed and mobile networks as 423 well as data center networks. 425 Generally, in order to manipulate a specific application traffic 426 along the SFC, a DPI needs to be deployed as the first service 427 function of the chain to detect the application, which will impose 428 high CAPEX and consume long processing time. For the encrypted 429 traffic, it even becomes impossible to inspect the application. 431 Requirements for APN6: 433 For achieving App-aware service function chaining, APN6 needs to 434 perform the three key elements as described in Section 4 in the 435 context of service function chaining. To be more specific, for 436 element 1 class information can be conveyed. For element 2, it needs 437 to match to a specific service function chain and subsequent steering 438 according to the application information carried in the IPv6 packets. 439 The network measurement in element 3 also needs to happen within each 440 app-aware service function chain. 442 5.5. App-aware network measurement 444 Network measurement can be used for locating silent failure and 445 predicting QoE satisfaction, which enables real-time SLA awareness/ 446 proactive OAM. Operations, Administration, and Maintenance (OAM) 447 refers to a toolset for fault detection and isolation, and network 448 performance measurement. In-situ Operations, Administration, and 449 Maintenance (IOAM) records operational and telemetry information in 450 the packet while the packet traverses a path between two points in 451 the network. 453 Requirements for APN6: 455 For achieving App-aware network measurement, APN6 needs to perform 456 the two key elements as described in Section 4 in the context of 457 network measurement. The network measurement in element 3 does not 458 need to be considered here. 460 6. IANA Considerations 462 This document does not include an IANA request. 464 7. Security Considerations 466 Since the application information is conveyed into the network, it 467 does involve some security and privacy issues. 469 First of all, APN6 only provides the capability to the applications 470 to provide their profiles and requirements to the network, but it 471 leaves the applications to decide whether to input this information. 472 If the applications decide not to provide any information, they will 473 be treated in the same way as today's network and cannot get the 474 benefits from APN6. 476 Once the application information has been carried in the IPv6 packets 477 and conveyed into the network, the IPv6 extension headers, AH and 478 ESP, can be used to guarantee the authenticity of the added 479 application information. 481 Any scheme involving an information exchange between layers 482 (application and network layers in this case) will obviously require 483 an accurate valuation of security mechanism in order to prevent any 484 leak of critical information. Some additional considerations may be 485 required for multi-domain use cases. For example, how to agree upon 486 which application information/ID to use and guarantee authenticity 487 for packets traveling through multiple domains (network operators). 489 8. Acknowledgements 491 The authors would like to acknowledge Robert Raszuk for his valuable 492 review and comments. 494 9. Contributors 496 Liang Geng 497 China Mobile 498 China 500 Email: gengliang@chinamobile.com 502 Chang Cao 503 China Unicom 504 China 506 Email: caoc15@chinaunicom.cn 507 Cong Li 508 China Telecom 509 China 511 Email: licong.bri@chinatelecom.cn 513 10. References 515 10.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 523 Chaining (SFC) Architecture", RFC 7665, 524 DOI 10.17487/RFC7665, October 2015, 525 . 527 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 528 (IPv6) Specification", STD 86, RFC 8200, 529 DOI 10.17487/RFC8200, July 2017, 530 . 532 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 533 RFC 8578, DOI 10.17487/RFC8578, May 2019, 534 . 536 10.2. Informative References 538 [I-D.ietf-6man-segment-routing-header] 539 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 540 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 541 Routing Header (SRH)", draft-ietf-6man-segment-routing- 542 header-23 (work in progress), September 2019. 544 [I-D.ietf-spring-srv6-network-programming] 545 Filsfils, C., Camarillo, P., Leddy, J., 546 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 547 Network Programming", draft-ietf-spring-srv6-network- 548 programming-02 (work in progress), September 2019. 550 Authors' Addresses 551 Zhenbin Li 552 Huawei Technologies 553 China 555 Email: lizhenbin@huawei.com 557 Shuping Peng 558 Huawei Technologies 559 China 561 Email: pengshuping@huawei.com 563 Daniel Voyer 564 Bell Canada 565 Canada 567 Email: daniel.voyer@bell.ca 569 Chongfeng Xie 570 China Telecom 571 China 573 Email: xiechf.bri@chinatelecom.cn 575 Peng Liu 576 China Mobile 577 China 579 Email: liupengyjy@chinamobile.com 581 Chang Liu 582 China Unicom 583 China 585 Email: liuc131@chinaunicom.cn 587 Kentaro Ebisawa 588 Toyota Motor Corporation 589 Japan 591 Email: ebisawa@toyota-tokyo.tech 592 Yukito Ueno 593 NTT Communications Corporation 594 Japan 596 Email: yukito.ueno@ntt.com 598 Stefano Previdi 599 Individual 600 Italy 602 Email: stefano@previdi.net 604 James N Guichard 605 Futurewei Technologies Ltd. 606 USA 608 Email: jguichar@futurewei.com