idnits 2.17.1 draft-li-apn-problem-statement-usecases-02.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 -- The document date (May 25, 2021) is 1066 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: 'RFC8754' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 567, 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 (-07) exists of draft-peng-apn-scope-gap-analysis-01 Summary: 2 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: November 26, 2021 D. Voyer 6 Bell Canada 7 C. Xie 8 China Telecom 9 P. Liu 10 China Mobile 11 Z. Qin 12 China Unicom 13 G. Mishra 14 Verizon Inc. 15 K. Ebisawa 16 Toyota Motor Corporation 17 S. Previdi 18 Huawei Technologies 19 J. Guichard 20 Futurewei Technologies Ltd. 21 May 25, 2021 23 Problem Statement and Use Cases of Application-aware Networking (APN) 24 draft-li-apn-problem-statement-usecases-02 26 Abstract 28 Network operators are facing the challenge of providing better 29 network services for users. As the ever-developing 5G and industrial 30 verticals evolve, more and more services that have diverse network 31 requirements such as ultra-low latency and high reliability are 32 emerging, and therefore differentiated service treatment is desired 33 by users. On the other hand, as network technologies such as 34 Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep 35 evolving, the network has the capability to provide more fine- 36 granularity differentiated services. However, network operators are 37 typically unware of the applications that are traversing their 38 network infrastructure, which means that not very effective 39 differentiated service treatment can be provided to the traffic 40 flows. As network technologies evolve including deployments of IPv6, 41 SRv6, Segment Routing over MPLS dataplane, the programmability 42 provided by IPv6 and Segment Routing can be augmented by conveying 43 application related information into the network satifying the fine- 44 granularity requirements. 46 This document analyzes the existing problems caused by lack of 47 service awareness, and outlines various use cases that could benefit 48 from an Application-aware Networking (APN) framework. 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 November 26, 2021. 73 Copyright Notice 75 Copyright (c) 2021 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. Challenges of lack of fine-granularity service 94 information . . . . . . . . . . . . . . . . . . . . . . . 4 95 3.2. Challenges of Traditional Differentiated Service 96 Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 97 3.3. Challenges of Supporting New 5G and Edge Computing 98 Technologies . . . . . . . . . . . . . . . . . . . . . . 6 99 4. Key Elements of Application-aware Networking (APN) . . . . . 7 100 5. Use cases for Application-aware Networking (APN) . . . . . . 8 101 5.1. Application-aware SLA Guarantee . . . . . . . . . . . . . 8 102 5.2. Application-aware network slicing . . . . . . . . . . . . 8 103 5.3. Application-aware Deterministic Networking . . . . . . . 9 104 5.4. Application-aware Service Function Chaining . . . . . . . 10 105 5.5. Application-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 . . . . . . . . . . . . . . . . . . . . . . . 13 115 1. Introduction 117 Due to the requirement for differentiated traffic treatment driven by 118 diverse new services, the ability to convey the application-aware 119 information and program the network infrastructure accordingly to 120 provide fine-grained services is becoming increasingly necessary for 121 network operators. The Application-aware Networking (APN) framework 122 is being defined to address the requirements and use cases are 123 described in this document. APN takes advantage of network 124 programmability by conveying application related information in the 125 data plane to facilitate network operators to provide fine-grained 126 services. 128 2. Terminology 130 ACL: Access Control List 132 APN: Application-aware Networking 134 APN6: Application-aware Networking for IPv6/SRv6 136 DPI: Deep Packet Inspection 138 PBR: Policy Based Routing 140 QoE: Quality of Experience 142 SDN: Software Defined Networking 144 SLA: Service Level Agreement 145 MPLS: Multiprotocol Label Switching 147 SR: Segment Routing 149 SRv6: Segment Routing over IPv6 dataplane 151 SR-MPLS: Segment Routing over MPLS dataplane 153 VPN: Virtual Private Network 155 TE: Traffic Engineering 157 FRR: Fast Reroute 159 CAPEX: Capital expenditures 161 OPEX: Operating expenditures 163 3. Problem Statement 165 This section summarizes the challenges currently faced by network 166 operators when attempting to provide fine-grained traffic operations 167 to satisfy the various requirements demanded by new applications that 168 require differentiated service treatment. 170 3.1. Challenges of lack of fine-granularity service information 172 In today's networks, the infrastructure through which the traffic is 173 forwarded is not able to obtain the fine-granularity service 174 information. It is therefore difficult for network operators to 175 provide fine-grained traffic operations for various performance- 176 demanding applications. In order to satisfy the SLA requirements 177 network operators continue to increase the network bandwidth but only 178 carrying very light traffic load (in general, around 30%-40% of its 179 capacity). 181 As network technologies keep evolving, the network capability has 182 been greatly enhanced and is able to provide fine-granularity service 183 provisioning. For example, 185 H-QoS: provides hierarchical fine-grained QoS services. 187 SR Policy: provides the ability to handle a large number of explicit 188 and flexible SR paths in order for services to select to satisfy 189 their SLA requirements. 191 Network Slicing: provides the ability to define a number of network 192 slices with guaranteed resources to satisfy highly demanding service 193 requirements. 195 IOAM: provides more accurate performance measurement of the traffic 196 flow. 198 In summary, driven by the ever-emerging diverse demanding services, 199 the lack of the fine-granularity information about the services in 200 the network will cause the following issues: 1) the service 201 information is not clearly described and known by the network, 2) the 202 fine-granularity service provisioning capability is not fully 203 utilised, 3) a fine-granularity service scheduling and measurement 204 cannot be achieved. 206 3.2. Challenges of Traditional Differentiated Service Provisioning 208 The traditional ways used to provide fine-grained service 209 provisioning face some challenges. The network devices mainly rely 210 on the 5-tuple of the packets or DPI. However, there are some 211 challenges for these traditional methods in differentiated service 212 provisioning: 214 1. Five Tuples used for ACL/PBR: five tuples are widely used for 215 ACL/PBR matching of traffic. However, these features cannot 216 provide enough information for the fine-grained service process, 217 and can only provide indirect application-level information which 218 needs to be translated. Generally, ACLs involve high overhead on 219 the forwarding process. Moreover, in some cases such as tunnel 220 encapsulation and IPv6 data plane with a list of extension 221 headers, it becomes impossible to resolve the 5 tuples due to the 222 transport layer information being pushed very deep in the packet. 224 2. Deep Packet Inspection (DPI): If more information is needed, it 225 must be extracted using DPI which can inspect deep into the 226 packets for application specific information. However, this will 227 introduce more CAPEX and OPEX for the network operator and impose 228 security and privacy challenges. 230 3. Orchestration and SDN-based Solution: In the era of SDN, 231 typically, an SDN controller is used to manage and operate the 232 network infrastructure and orchestrator elements introduce 233 application requirements so that the network is programmed 234 accordingly. The SDN controller can be aware of the service 235 requirements of the applications on the network through the 236 interface with the orchestrator, and the service requirement is 237 used by the controller for traffic management over the network. 238 However, this method raises the following problems: 240 A. The whole loop is long and time-consuming which is not 241 suitable for fast service provisioning for critical 242 applications; 244 B. Too many interfaces are involved in the loop, as shown in 245 Figure 1, which introduce challenges of standardization and 246 inter-operability. 248 +--------------+ 249 +-----| Orchestrator | -------------------+ 250 | +--------------+ Resource | 251 APP Req. | | Management | 252 +---------+ +---------+ & +---------+ 253 |SDN Ctrl1| |SDN Ctrl2| Service |SDN Ctrl3| 254 +---------+ +---------+ Provisioning +---------+ 255 App Req./ | | \ | \ 256 / | | \ | \ 257 / | | \ | \ 258 +---+ +-----+ +--------+ +-------+ +-------+ +-------+ 259 |APP| | DCN | |Network |..|Network| |Network|..|Network| 260 +---+ +-----+ | D1 | | D3 | | D4 | | D6 | 261 +--------+ +-------+ +-------+ +-------+ 263 Figure 1: Multiple interfaces involved in the long service- 264 provisioning loop 266 In [I-D.peng-apn-scope-gap-analysis], some mechanisms that have been 267 specified in IETF and using attribute/identifier to perform traffic 268 steering and service provisioning are analyzed. The existing 269 solutions are specific to a particular scenario or data plane, and a 270 generalized method used for fine-grained service provisioning is 271 still missing. 273 3.3. Challenges of Supporting New 5G and Edge Computing Technologies 275 New technologies such as 5G, IoT, and edge computing, are 276 continuously developing leading to more and more new types of 277 services accessing the network. Large volumes of network traffic 278 with diverse requirements such as low latency and high reliability 279 are therefore rapidly increasing. If traditional methods for 280 differentiation of traffic continue to be utilized, it will cause 281 much higher CAPEX and OPEX to satisfy the ever-developing 282 applications' diverse requirements. 284 4. Key Elements of Application-aware Networking (APN) 286 Application-aware Networking (APN) aims to address the problems 287 mentioned in Section 3, associated with fine-grained traffic 288 operations that are required in order to satisfy the various 289 application-awareness requirements demanded by new services that need 290 differentiated service treatment. 292 In APN, the application-aware information (APN Attribute) is derived 293 according to the existing information in the packet header and 294 encapsulated along with the encapsulation of the tunnel. With the 295 APN attribute, fine-granularity network services can be provisioned 296 within the APN domain accordingly. The APN attribute can include 297 application-aware ID (APN ID) and application-aware parameters (APN 298 Parameters). APN ID can be derived through the mapping from the 299 existing information of the packet header and the APN parameters can 300 be applied for the APN ID according to the local policy. The typical 301 APN parameters are the network performance requirements. 303 APN has the following key elements: 305 1. Application-aware information (APN attribute) is conveyed in the 306 data plane through augmentation of existing encapsulations such 307 as IPv6, SRv6 and MPLS. The conveyed APN attribute includes APN 308 ID and/or APN parameters. This information is acquired at the 309 edge of the APN domain according to the existing information in 310 the packet header. When a data packet uses APN and conveys the 311 application-aware information, it is referred in this document as 312 an APN packet. 314 2. Application-aware information and network service provisioning 315 matching providing fine-granularity network service provisioning 316 (traffic operations) and SLA guarantee based on the APN attribute 317 carried in APN packets. According to the APN attribute, 318 appropriate network services are selected, provisioned, and 319 provided to the demanding applications to satisfy their service 320 requirements. 322 3. Measurement of the network performance so to maintain the match 323 between the applications requirements and corresponding network 324 services for a better fine-granularity SLA compliance. The 325 network measurement methods include in-band and out-of-band, 326 passive, active, per-packet, per-flow, per node, end-to-end, etc. 327 These methods can also be integrated. 329 APN Network 331 Element 1: Conveying -------------------> 332 /|\ 333 APN attribute | Network capabilities 334 | (SLA guarantee) 335 | /|\ 336 Element 2: Matching | 337 | 338 Element 3: Network Measurement 340 Figure 2: Illustration of the key elements of APN 342 5. Use cases for Application-aware Networking (APN) 344 This section illustrates some of the use cases that can benefit from 345 APN. The corresponding requirements for APN are also outlined. 347 5.1. Application-aware SLA Guarantee 349 One of the key objectives of APN is for network operators to provide 350 fine-granularity SLA guarantees instead of coarse-grain traffic 351 operations. This will allow to provide differentiated services for 352 different applications and increase revenue accordingly. Among 353 various applications being carried and running in the network, some 354 revenue-producing applications such as online gaming, video 355 streaming, and enterprise video conferencing have much more demanding 356 performance requirements such as low network latency and high 357 bandwidth. In order to achieve better Quality of Experience (QoE) 358 for end users and engage customers, the network needs to be able to 359 provide fine-granularity and even application group-level SLA 360 guarantee. Differentiated service provisioning is also desired. 362 The APN architecture MUST address the following requirements: 364 o APN needs to perform the three key elements as described in 365 Section 4. 367 o Support application group-level fine-granularity traffic operation 368 that may include finer QoS scheduling. 370 5.2. Application-aware network slicing 372 More and more applications/services with diverse requirements are 373 being carried over and sharing a common operators' network 374 infrastructure. However, it is still desirable to have customized 375 network transport that can support some applications' specific 376 requirements, taking into consideration service and resource 377 isolation, which drives the concept of network slicing. 379 Network slicing provides ways to partition the network infrastructure 380 in either the control plane or data plane into multiple network 381 slices that are running in parallel. These network slices can serve 382 diverse services and fulfill their various requirements at the same 383 time. For example, the mission critical application that requires 384 ultra-low latency and high reliability can be provisioned over a 385 separate network slice. 387 The APN architecture MUST address the following requirements: 389 o APN needs to perform the three key elements as described in 390 Section 4 in the context of network slicing. 392 o For the element 2, the APN architecture MUST allow to assign a 393 given traffic flow to specific network slice according to the APN 394 attribute carried in the APN packet. 396 o For the element 3, the APN architecture MUST allow the network 397 measurement of 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 APN architecture MUST address the following requirements: 410 o APN needs to perform the three key elements as described in 411 Section 4 in the context of deterministic networking. 413 o For the element 2, the APN architecture MUST allow to assign a 414 given traffic flow to a specific deterministic path according to 415 the APN attribute carried in the APN packet. 417 o For the element 3, the APN architecture MUST allow the network 418 measurement of each application-aware deterministic path. 420 5.4. Application-aware Service Function Chaining 422 End-to-end service delivery often needs to go through various service 423 functions including traditional network service functions such as 424 firewalls, DPIs as well as new application-specific functions, both 425 physical and virtual. The definition and instantiation of an ordered 426 set of service functions and subsequent steering of the traffic 427 through them is called Service Function Chaining (SFC) [RFC7665]. 428 SFC is applicable to both fixed and mobile networks as well as data 429 center networks. 431 Generally, in order to manipulate a specific traffic flow along the 432 SFC, a DPI needs to be deployed as the first service function of the 433 chain to detect the application, which will impose high CAPEX and 434 consume long processing time. For encrypted traffic, it even becomes 435 impossible to inspect the traffic flow. 437 The APN architecture MUST address the following requirements: 439 o APN needs to perform the three key elements as described in 440 Section 4 in the context of service function chaining. 442 o For the element 1, class information can be conveyed. 444 o For the element 2, the APN architecture MUST allow to assign a 445 given traffic flow to a specific service function chain and MUST 446 allow the subsequent steering according to the APN attribute 447 carried in the APN packets. 449 o For the element 3, the APN architecture MUST allow the network 450 measurement of each application-aware service function chain. 452 5.5. Application-aware Network Measurement 454 Network measurement can be used for locating silent failure and 455 predicting QoE satisfaction, which enables real-time SLA awareness/ 456 proactive OAM. Operations, Administration, and Maintenance (OAM) 457 refers to a toolset for fault detection and isolation, and network 458 performance measurement. In-situ Operations, Administration, and 459 Maintenance (IOAM) records operational and telemetry information in 460 the packet while the packet traverses a path between two points in 461 the network. 463 The APN architecture MUST address the following requirements: 465 o APN needs to perform the two key elements as described in 466 Section 4 in the context of network measurement. The network 467 measurement in the element 3 does not need to be considered here. 469 6. IANA Considerations 471 This document does not include an IANA request. 473 7. Security Considerations 475 In the APN work, in order to reduce the privacy and security issues, 476 the APN attribute MUST be conveyed along with the tunnel information 477 in the APN domain. The APN attribute is encapsulated and removed at 478 the edge of the APN domain. The APN ID MUST be acquired from the 479 existing available information in the packet header without 480 interference into the payload. 482 According to the above specifications, the APN attribute is only 483 produced and used locally within the APN domain without the 484 involvement of the host/application side. 486 In order to prevent the malicious attack through the APN attribute, 487 the following policies can be configured at the network devices of 488 the APN domain. If the APN attribute is conveyed without the tunnel 489 information, the packet MUST be dropped. If the APN attributes are 490 not known to the APN domain, it should trigger the alarm information. 491 The packet can be forwarded without being processed or dropped 492 depending on the local policy. If the network service requirements 493 exceed the specification for the specific APN ID, it should trigger 494 the alarm information. The packet should be discarded to prevent 495 abusing of the resources. There should be rate-limiting policy at 496 the edge of the APN domain to prevent the traffic belonging to a 497 specific APN ID from exceeding the preset limit. 499 8. Acknowledgements 501 The authors would like to acknowledge Robert Raszuk (Bloomberg LP) 502 and Yukito Ueno (NTT Communications Corporation) for their valuable 503 review and comments. 505 9. Contributors 507 Daniel Bernier 508 Bell Canada 509 Canada 511 Email: daniel.bernier@bell.ca 513 Liang Geng 514 China Mobile 515 China 516 Email: gengliang@chinamobile.com 518 Chang Cao 519 China Unicom 520 China 522 Email: caoc15@chinaunicom.cn 524 Chang Liu 525 China Unicom 526 China 528 Email: liuc131@chinaunicom.cn 530 Cong Li 531 China Telecom 532 China 534 Email: licong@chinatelecom.cn 536 10. References 538 10.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 546 Chaining (SFC) Architecture", RFC 7665, 547 DOI 10.17487/RFC7665, October 2015, 548 . 550 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 551 RFC 8578, DOI 10.17487/RFC8578, May 2019, 552 . 554 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 555 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 556 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 557 . 559 10.2. Informative References 561 [I-D.ietf-6man-segment-routing-header] 562 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 563 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 564 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 565 progress), October 2019. 567 [I-D.ietf-spring-srv6-network-programming] 568 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 569 Matsushima, S., and Z. Li, "Segment Routing over IPv6 570 (SRv6) Network Programming", draft-ietf-spring-srv6- 571 network-programming-28 (work in progress), December 2020. 573 [I-D.peng-apn-scope-gap-analysis] 574 Peng, S. and Z. Li, "APN Scope and Gap Analysis", draft- 575 peng-apn-scope-gap-analysis-01 (work in progress), 576 February 2021. 578 Authors' Addresses 580 Zhenbin Li 581 Huawei Technologies 582 China 584 Email: lizhenbin@huawei.com 586 Shuping Peng 587 Huawei Technologies 588 China 590 Email: pengshuping@huawei.com 592 Daniel Voyer 593 Bell Canada 594 Canada 596 Email: daniel.voyer@bell.ca 598 Chongfeng Xie 599 China Telecom 600 China 602 Email: xiechf@chinatelecom.cn 603 Peng Liu 604 China Mobile 605 China 607 Email: liupengyjy@chinamobile.com 609 Zhuangzhuang Qin 610 China Unicom 611 China 613 Email: qinzhuangzhuang@chinaunicom.cn 615 Gyan Mishra 616 Verizon Inc. 617 USA 619 Email: gyan.s.mishra@verizon.com 621 Kentaro Ebisawa 622 Toyota Motor Corporation 623 Japan 625 Email: ebisawa@toyota-tokyo.tech 627 Stefano Previdi 628 Huawei Technologies 629 Italy 631 Email: stefano@previdi.net 633 James N Guichard 634 Futurewei Technologies Ltd. 635 USA 637 Email: jguichar@futurewei.com