idnits 2.17.1 draft-li-apn-framework-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 (February 22, 2021) is 1151 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: 'RFC7665' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC8578' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 550, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-01 == Outdated reference: A later version (-02) exists of draft-peng-apn-security-privacy-consideration-00 ** Downref: Normative reference to an Informational draft: draft-peng-apn-security-privacy-consideration (ref. 'I-D.peng-apn-security-privacy-consideration') ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8578 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: August 26, 2021 D. Voyer 6 Bell Canada 7 C. Li 8 China Telecom 9 P. Liu 10 China Mobile 11 C. Cao 12 China Unicom 13 K. Ebisawa 14 Toyota Motor Corporation 15 S. Previdi 16 Huawei Technologies 17 J. Guichard 18 Futurewei Technologies Ltd. 19 February 22, 2021 21 Application-aware Networking (APN) Framework 22 draft-li-apn-framework-02 24 Abstract 26 A multitude of applications are carried over the network, which have 27 varying needs for network bandwidth, latency, jitter, and packet 28 loss, etc. Some new emerging applications (e.g. 5G) have very 29 demanding performance requirements. However, in current networks, 30 the network and applications are decoupled, that is, the network is 31 not aware of the applications' requirements in a fine granularity. 32 Therefore, it is difficult to provide truly fine-granularity traffic 33 operations for the applications and guarantee their SLA requirements. 35 This document proposes a new framework, named Application-aware 36 Networking (APN), where application characteristic information such 37 as application-aware identification and network performance 38 requirements is carried in the packet encapsulation in order to 39 facilitate service provisioning, perform fine-granularity traffic 40 steering and network resource adjustment. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 26, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 78 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 4. APN Framework and Key Components . . . . . . . . . . . . . . 4 80 5. APN Requirements . . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. Application-aware Information Conveying Requirements . . 6 82 5.2. Application-aware Information Handling Requirements . . . 8 83 5.2.1. App-aware SLA Guarantee . . . . . . . . . . . . . . . 8 84 5.2.2. App-aware network slicing . . . . . . . . . . . . . . 8 85 5.2.3. App-aware deterministic networking . . . . . . . . . 9 86 5.2.4. App-aware service function chaining . . . . . . . . . 9 87 5.2.5. App-aware network measurement . . . . . . . . . . . . 10 88 5.3. Security requirements . . . . . . . . . . . . . . . . . . 10 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 92 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 10.2. Informative References . . . . . . . . . . . . . . . . . 12 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 A multitude of applications are carried over the network, which have 101 varying needs for network bandwidth, latency, jitter, and packet 102 loss, etc. Some applications such as online gaming and live video 103 streaming has very demanding network requirements and therefore 104 require special treatment in the network. However, in current 105 networks, the network and applications are decoupled, that is, the 106 network is not aware of the applications' requirements in a fine 107 granularity. Therefore, it is difficult to provide truly fine- 108 granularity traffic operations for the applications and guarantee 109 their SLA requirements accordingly. 110 [I-D.li-apn-problem-statement-usecases] describes the challenges of 111 traditional differentiated service provisioning methods, such as five 112 tuples used for ACL/PBR causing coarse granularity, DPI imposing high 113 CAPEX & OPEX and security issues, as well as orchestration and SDN- 114 based solution causing long control loops. 116 This document proposes a new framework, named Application-aware 117 Networking (APN), aiming to guarantee fine-granularity SLA 118 requirements of applications, where application characteristic 119 information such as application-aware identification and network 120 performance requirements is carried in the packet encapsulation in 121 order to facilitate service provisioning, perform traffic steering, 122 and network resource adjustment. 124 2. Specification of Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 This document is not a protocol specification and the key words in 131 this document are used for clarity and emphasis of requirements 132 language. 134 3. Terminology 136 ACL: Access Control List 138 APN: Application-aware Networking 140 APN6: Application-aware Networking for IPv6/SRv6 142 DPI: Deep Packet Inspection 144 MPLS: Multiprotocol Label Switching 145 PBR: Policy Based Routing 147 QoE: Quality of Experience 149 SDN: Software Defined Networking 151 SLA: Service Level Agreement 153 SR: Segment Routing 155 SR-MPLS: Segment Routing over MPLS dataplane 157 SRv6: Segment Routing over IPv6 dataplane 159 4. APN Framework and Key Components 161 The APN framework is shown in Figure 1. The key components include 162 Service-aware App, App-aware Edge Device, App-aware-process Head-End, 163 App-aware-process Mid-Point, and App-aware-process End-Point. 165 Packets carry application characteristic information (i.e. 166 application-aware information) which includes the following 167 information: 169 o Application-aware identification information: identifies the 170 application (group), the user (group), and their SLA requirements, 171 indicating that all packets belonging to the same flow will be 172 given the same treatment by the network. ; 174 o Network performance requirements information that specify at least 175 one of the following parameters: bandwidth, delay, delay 176 variation, packet loss ratio, security, etc. 178 Client Server 179 +-----+ +-----+ 180 |App x|-\ /->|App x| 181 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 182 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 183 User side |aware|-|process |-B-|process |-B-|process | 184 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 185 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 186 |App y|-/ \->|App y| 187 +-----+ --------- Uplink ----------> +-----+ 189 Figure 1: Framework and Key Components 191 The key components are introduced as follows. 193 1. Service-aware App: the host obtains the application 194 characteristic information of the Service-aware App and generates 195 the packets which carry the application characteristic 196 information in the encapsulation. If carried in the packets, 197 this information is used by the App-aware-process Head-End to 198 determine the path between the App-aware-process Head-End and the 199 App-aware-process End-Point for forwarding the packets to their 200 destination, that is, to steer the packet into a given policy 201 which satisfies the application requirements. With the Service- 202 aware App, the network is aware of the service requirements 203 expressed by the applications explicitly. In the APN framework, 204 the application is not mandatory to be service-aware. 206 2. App-aware Edge Device: this network device receives packets from 207 applications and obtains the application characteristic 208 information. If the application is not Service-aware App, the 209 application characteristic information can be retrieved by packet 210 inspection, derived from services information such as double VLAN 211 tagging (C-VLAN and S-VLAN), or added according to the local 212 policies which is out of the scope of this document. The App- 213 aware Edge Device adds the application characteristic information 214 in the encapsulation on behalf of the application. The packets 215 carrying the application characteristic information will be sent 216 to the App-aware-process Head-End, and the application 217 characteristic information will be used to determine the path 218 between the App-aware-process Head-End and the App-aware-process 219 End-Point for forwarding the packets. 221 3. App-aware-process Head-End: This network device receives packets 222 and obtains the application characteristic information. A set of 223 paths, tunnels or SR policy, exist between the App-aware-process 224 Head-End and the App-aware-process End-Point. The App-aware- 225 process Head-End maintains the matching relationship between the 226 application characteristic information and the paths between the 227 App-aware-process Head-End and the App-aware-process End-Point. 228 The App-aware-process Head-End determines the path between the 229 App-aware-process Head-End and the App-aware-process End-Point 230 according to the application characteristic information carried 231 in the packets and the matching relationship with it, which 232 satisfies the service requirements of the application. If there 233 is no such matching path found, the App-aware-process Head-End 234 can set up a path towards the App-aware-process End-Point, and 235 the matching relationship will be stored. The App-aware-process 236 Head-End forwards the packets along the path. The application 237 information conveyed by the packet received from the App-aware 238 Edge Device can also be copied or be mapped to the outgoing 239 packet header, e.g, IPv6 header followed by an extension header 240 for further application-aware process. 242 4. App-aware-process Mid-Point: the Mid-Point provides the path 243 service according to the path set up by the App-aware-process 244 Head-End which satisfies the service requirements conveyed by the 245 packets. The Mid-Point may also adjust the resource locally to 246 guarantee the service requirements depending on a specific policy 247 and the application-aware information conveyed by the packet. 248 Policy definitions and mechanisms are out of the scope of this 249 document. 251 5. App-aware-process End-Point: the process of the specific service 252 path will end at the End-Point. The service requirements 253 information can be removed at the End-Point together with the 254 outer encapsulation or go on to be conveyed with the packets. 256 According to the application characteristic information carried in 257 the packets the network is able to adjust its resources fast in order 258 to satisfy the service requirement of applications. The flow-driven 259 method also reduces the challenges of interoperability and long 260 control loop. 262 5. APN Requirements 264 APN doesn't mandate a specific encapsulation however it is reasonable 265 to assume that most of the APN benefits are achieved when utilizing 266 IPv6 encapsulation (e.g. IPv6 header as well as, possibly, extension 267 headers). APN6 (the APN architecture applied to the IPv6/SRv6 data 268 plane) consists of the application-aware information conveyed into 269 the network through the use of IPv6 header and Extension Headers and 270 where the network performs service provisioning, traffic steering, 271 and SLA guarantee according to such information. This section 272 specifies the requirements for supporting the APN framework, 273 including the requirements for conveying and handling the 274 application-aware information and related security requirements. 275 Other encapsulation may be used with some obvious constraint such as, 276 as in the case of MPLS, the limited space available in the header 277 (i.e., 20-bit label size). 279 5.1. Application-aware Information Conveying Requirements 281 The application-aware information includes application-aware 282 identification information and network performance requirements 283 information. 285 1. Application-aware identification information includes the 286 following identifiers (IDs), 287 * SLA level: indicates the level of SLA requirement such as 288 Gold, Silver, Bronze. In some cases, color (e.g. red, green) 289 can be used to indicate the SLA level. 291 * Application ID: identifies an application (group) of the 292 traffic. 294 * User ID: identifies the user (group) of the traffic. 296 * Flow ID: identifies the key session of the application 297 traffic. 299 The different combinations of the IDs can be used to provide 300 different granularity of the service provisioning and SLA 301 guarantee for the traffic. 303 2. Network performance requirements information includes the 304 following parameters: 306 * Bandwidth: the bandwidth requirement 308 * Latency: the latency requirement 310 * Packet loss ratio: the packet loss ratio requirement 312 * Jitter: the jitter requirement 314 The different combinations of the parameters are for further 315 expressing the more detailed service requirements, conveyed 316 together with the Application-aware identification information, 317 which can be used to match to appropriate tunnels/SR Policies, 318 queues that can satisfy these service requirements. If not 319 available, new tunnels/SR Policies can also be triggered to be 320 set up. 322 [REQ 1a]. Application-aware identification information MUST include 323 Application ID to indicate the application (group) that generates the 324 packet. 326 [REQ 1b]. SLA level is RECOMMENDED to be included in the 327 Application-aware identification information. 329 [REQ 1c]. User ID and Flow ID are OPTIONAL to be included in the 330 Application-aware identification information. 332 [REQ 1d]. Network performance requirements information is OPTIONAL. 334 [REQ 1e]. All the nodes along the path SHOULD be able to process the 335 application-aware information if needed. 337 [REQ 1f]. The application-aware information can be generated 338 directly by application, or by the application-aware edge devices 339 though packet inspection or local policy. 341 [REQ 1g]. The application-aware information SHOULD be kept intact 342 when directly copied from the application-aware edge devices and 343 carried in the packet. 345 5.2. Application-aware Information Handling Requirements 347 The app-aware-process Head-End and app-aware-process Mid-Point 348 perform matching operation against the application-aware information, 349 that is, to match IDs and/or service requirements to the 350 corresponding network resources (tunnels/SR policies, queues). 352 5.2.1. App-aware SLA Guarantee 354 In order to achieve better Quality of Experience (QoE) of end users 355 and engage customers, the network needs to be able to provide fine- 356 granularity and even application-level SLA guarantee 357 [I-D.li-apn-problem-statement-usecases]. 359 [REQ 2-1a]. With the application-aware information, the App-aware- 360 process Head-End SHOULD be able to steer the traffic to the tunnel/SR 361 policy that satisfies the matching operation. 363 [REQ 2-1b]. With the application-aware information, the App-aware- 364 process Head-End SHOULD be able to trigger the setup of the tunnel/SR 365 policy that satisfies the matching operation. 367 [REQ 2-1c]. With the application-aware information, the App-aware- 368 process Head-End and Mid-Point SHOULD be able to steer the traffic to 369 the queue that satisfies the matching operation. 371 [REQ 2-1d]. With the application-aware information, the App-aware- 372 process Head-End and Mid-Point SHOULD be able to trigger the 373 configuration of the queue that satisfies the matching operation. 375 5.2.2. App-aware network slicing 377 Network slicing provides ways to partition the network infrastructure 378 in either control plane or data plane into multiple network slices 379 that are running in parallel. The resources on each node need to be 380 associated to corresponding slices. 382 [REQ 2-2a]. With the application-aware information, the App-aware- 383 process Head-End SHOULD be able to steer the traffic to the slice 384 that satisfies the matching operation. 386 [REQ 2-2a]. With the application-aware information, the App-aware- 387 process Mid-Point SHOULD be able to associate the traffic to the 388 resources in the slice that satisfies the matching operation. 390 5.2.3. App-aware deterministic networking 392 Along the path each node needs to provide guaranteed bandwidth, 393 bounded latency, and other properties relevant to the transport of 394 time-sensitive data for the Detnet flows that coexist with the best- 395 effort traffic. 397 [REQ 2-3a]. With the application-aware information, the App-aware- 398 process Head-End SHOULD be able to steer the traffic to the 399 appropriate path that satisfies the matching operation. 401 [REQ 2-3b]. With the application-aware information, the App-aware- 402 process Head-End SHOULD be able to trigger the setup of the 403 appropriate path that satisfies the matching operation for the Detnet 404 flows. 406 [REQ 2-3c]. With the application-aware information, the App-aware- 407 process Mid-Point SHOULD be able to associate the traffic to the 408 resources along the path that satisfies the performance guarantee. 410 [REQ 2-3d]. With the application-aware information, the App-aware- 411 process Mid-Point SHOULD be able to reserve the resources for the 412 Detnet flows along the path that satisfies the performance guarantee. 414 5.2.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. SFC is applicable to both fixed and 420 mobile networks as well as data center networks. 422 [REQ 2-4a]. With the application-aware information, the App-aware- 423 process devices SHOULD be able to steer the traffic to the 424 appropriate service function. 426 [REQ 2-4b]. The App-aware-process devices SHOULD be able to process 427 the application-aware information carried in the packets. 429 5.2.5. App-aware network measurement 431 Network measurement can be used for locating silent failure and 432 predicting QoE satisfaction, which enables real-time SLA awareness/ 433 proactive OAM. 435 [REQ 2-5a]. The App-aware-process devices SHOULD be able to perform 436 IOAM based on the Application-aware identification information. 438 [REQ 2-5b]. The network measurement results can be reported based on 439 the Application-aware identification information and verify whether 440 the performance requirements are satisfied. 442 5.3. Security requirements 444 [REQ 3a]. The security mechanism defined for APN MUST allow an 445 operator to prevent applications sending arbitrary application-aware 446 information without agreement with the operator. 448 [REQ 3b]. The security mechanism defined for APN MUST prevent an 449 application requesting a service which it is not entitled to get. 451 [REQ 3c]. The APN mechanisms MUST preserve user privacy. More 452 details related to this requirement can be found in 453 [I-D.peng-apn-security-privacy-consideration]. 455 6. IANA Considerations 457 This document does not include an IANA request. 459 7. Security Considerations 461 [I-D.li-apn-problem-statement-usecases] and 462 [I-D.peng-apn-security-privacy-consideration] describe the security 463 considerations and requirements for APN. 465 8. Acknowledgements 467 The authors would like to acknowledge Robert Raszuk (Bloomberg LP), 468 and Yukito Ueno (NTT Communications Corporation) for their valuable 469 reviews and comments. 471 9. Contributors 473 Daniel Bernier 474 Bell Canada 476 Email: daniel.bernier@bell.ca 477 Chongfeng Xie 478 China Telecom 480 Email: xiechf@chinatelecom.cn 482 Feng Yang 483 China Mobile 485 Email: yangfeng@chinamobile.com 487 Zhuangzhuang Qin 488 China Unicom 490 Email: qinzhuangzhuang@chinaunicom.cn 492 Chang Liu 493 China Unicom 495 Email: liuc131@chinaunicom.cn 497 Gyan Mishra 498 Verizon 500 Email: hayabusagsm@gmail.com 502 Luis M. Contreras 503 Telefonica 505 Email: contreras.ietf@gmail.com 507 Luc-Fabrice Ndifor Ngwa 508 MTN 510 Email: Luc-Fabrice.Ndifor@mtn.com 512 10. References 514 10.1. Normative References 516 [I-D.li-apn-problem-statement-usecases] 517 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 518 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 519 Statement and Use Cases of Application-aware Networking 520 (APN)", draft-li-apn-problem-statement-usecases-01 (work 521 in progress), September 2020. 523 [I-D.peng-apn-security-privacy-consideration] 524 Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, 525 "APN Security and Privacy Considerations", draft-peng-apn- 526 security-privacy-consideration-00 (work in progress), 527 September 2020. 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, 531 DOI 10.17487/RFC2119, March 1997, 532 . 534 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 535 Chaining (SFC) Architecture", RFC 7665, 536 DOI 10.17487/RFC7665, October 2015, 537 . 539 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 540 (IPv6) Specification", STD 86, RFC 8200, 541 DOI 10.17487/RFC8200, July 2017, 542 . 544 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 545 RFC 8578, DOI 10.17487/RFC8578, May 2019, 546 . 548 10.2. Informative References 550 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 551 Xiao, "Overview and Principles of Internet Traffic 552 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 553 . 555 Authors' Addresses 557 Zhenbin Li 558 Huawei Technologies 559 China 561 Email: lizhenbin@huawei.com 563 Shuping Peng 564 Huawei Technologies 565 China 567 Email: pengshuping@huawei.com 568 Daniel Voyer 569 Bell Canada 570 Canada 572 Email: daniel.voyer@bell.ca 574 Cong Li 575 China Telecom 576 China 578 Email: licong@chinatelecom.cn 580 Peng Liu 581 China Mobile 582 China 584 Email: liupengyjy@chinamobile.com 586 Chang Cao 587 China Unicom 588 China 590 Email: caoc15@chinaunicom.cn 592 Kentaro Ebisawa 593 Toyota Motor Corporation 594 Japan 596 Email: ebisawa@toyota-tokyo.tech 598 Stefano Previdi 599 Huawei Technologies 600 Italy 602 Email: stefano@previdi.net 604 James N Guichard 605 Futurewei Technologies Ltd. 606 USA 608 Email: jguichar@futurewei.com