idnits 2.17.1 draft-li-apn-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2020) is 1505 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 513, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC8578' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 529, 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 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 2 errors (**), 0 flaws (~~), 5 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: September 7, 2020 D. Voyer 6 Bell Canada 7 C. Li 8 China Telecom 9 L. Geng 10 China Mobile 11 C. Cao 12 China Unicom 13 K. Ebisawa 14 Toyota Motor Corporation 15 S. Previdi 16 Individual 17 J. Guichard 18 Futurewei Technologies Ltd. 19 March 6, 2020 21 Application-aware Networking (APN) Framework 22 draft-li-apn-framework-00 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 identification and its network performance 38 requirements is carried in the packet encapsulation in order to 39 facilitate service provisioning, perform application-level 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 September 7, 2020. 59 Copyright Notice 61 Copyright (c) 2020 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-apn6-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 identification and its network 120 performance requirements is carried in the packet encapsulation in 121 order to determine the path, steer traffic, and perform network 122 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, the user of the application, i.e, the packets of the 171 traffic flow belonging to a specific SLA level/Application/User; 173 o Network performance requirements information that specify at least 174 one of the following parameters: bandwidth, delay, delay 175 variation, packet loss ratio, security, etc. 177 Client Server 178 +-----+ +-----+ 179 |App x|-\ /->|App x| 180 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 181 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 182 User side |aware|-|process |-B-|process |-B-|process | 183 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 184 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 185 |App y|-/ \->|App y| 186 +-----+ --------- Uplink ----------> +-----+ 188 Figure 1: Framework and Key Components 190 The key components are introduced as follows. 192 1. Service-aware App: the host obtains the application 193 characteristic information of the Service-aware App and generates 194 the packets which carry the application characteristic 195 information in the encapsulation. If carried in the packets, 196 this information is used by the App-aware-process Head-End to 197 determine the path between the App-aware-process Head-End and the 198 App-aware-process End-Point for forwarding the packets to their 199 destination, that is, to steer the packet into a given policy 200 which satisfies the application requirements. In the APN 201 framework, the application is not mandatory to be service-aware. 203 2. App-aware Edge Device: this network device receives packets from 204 applications and obtains the application characteristic 205 information. If the application is not Service-aware App, the 206 application characteristic information can be retrieved by packet 207 inspection, derived from services information such as double VLAN 208 tagging (C-VLAN and S-VLAN), or added according to the local 209 policies which is out of the scope of this document. The App- 210 aware Edge Device adds the application characteristic information 211 in the encapsulation on behalf of the application. The packets 212 carrying the application characteristic information will be sent 213 to the App-aware-process Head-End, and the application 214 characteristic information will be used to determine the path 215 between the App-aware-process Head-End and the App-aware-process 216 End-Point for forwarding the packets. 218 3. App-aware-process Head-End: This network device receives packets 219 and obtains the application characteristic information. A set of 220 paths, tunnels or SR policy, exist between the App-aware-process 221 Head-End and the App-aware-process End-Point. The App-aware- 222 process Head-End maintains the matching relationship between the 223 application characteristic information and the paths between the 224 App-aware-process Head-End and the App-aware-process End-Point. 225 The App-aware-process Head-End determines the path between the 226 App-aware-process Head-End and the App-aware-process End-Point 227 according to the application characteristic information carried 228 in the packets and the matching relationship with it, which 229 satisfies the service requirements of the application. If there 230 is no such matching path found, the App-aware-process Head-End 231 can set up a path towards the App-aware-process End-Point, and 232 the matching relationship will be stored. The App-aware-process 233 Head-End forwards the packets along the path. The application 234 information conveyed by the packet received from the App-aware 235 Edge Device can also be copied or be mapped to the outgoing 236 packet header, e.g, IPv6 header followed by an extension header 237 for further application-aware process. 239 4. App-aware-process Mid-Point: the Mid-Point provides the path 240 service according to the path set up by the App-aware-process 241 Head-End which satisfies the service requirements conveyed by the 242 packets. The Mid-Point may also adjust the resource locally to 243 guarantee the service requirements depending on a specific policy 244 and the application-aware information conveyed by the packet. 245 Policy definitions and mechanisms are out of the scope of this 246 document. 248 5. App-aware-process End-Point: the process of the specific service 249 path will end at the End-Point. The service requirements 250 information can be removed at the End-Point together with the 251 outer encapsulation or go on to be conveyed with the packets. 253 In this way the network is aware of the service requirements 254 expressed by the applications explicitly. According to the service 255 requirement information carried in the packets the network is able to 256 adjust its resources fast in order to satisfy the service requirement 257 of applications. The flow-driven method also reduces the challenges 258 of interoperability and long control loop. 260 5. APN Requirements 262 APN doesn't mandate a specific encapsulation however it is reasonable 263 to assume that most of the APN benefits are achieved when utilizing 264 IPv6 encapsulation (e.g. IPv6 header as well as, possibly, extension 265 headers). APN6 (the APN architecture applied to the IPv6/SRv6 data 266 plane) consists of the application-aware information conveyed into 267 the network through the use of IPv6 header and Extension Headers and 268 where the network performs service provisioning, traffic steering, 269 and SLA guarantee according to such information. This section 270 specifies the requirements for supporting the APN framework, 271 including the requirements for conveying and handling the 272 application-aware information and related security requirements. 273 Other encapsulation may be used with some obvious constraint such as, 274 as in the case of MPLS, the limited space available in the header 275 (i.e., 20-bit label size). 277 5.1. Application-aware Information Conveying Requirements 279 The application-aware information includes application-aware 280 identification information and network performance requirements 281 information. 283 1. Application-aware identification information includes the 284 following identifiers (IDs), 285 * SLA level: indicates the level of SLA requirement of the 286 application such as Gold, Silver, Bronze. In some cases, 287 color (e.g. red, green) can be used to indicate the SLA level. 289 * Application ID: identifies an application. 291 * User ID: identifies the user of the application. 293 * Flow ID: identifies the flow which the application traffic 294 belongs to. 296 The different combinations of the IDs can be used to provide 297 different granularity of the service provisioning and SLA 298 guarantee for the traffic. 300 2. Network performance requirements information includes the 301 following parameters: 303 * Bandwidth: the bandwidth requirement of the application 304 traffic 306 * Latency: the latency requirement of the application 308 * Packet loss ratio: the packet loss ratio requirement of the 309 application 311 * Jitter: the jitter requirement of the application 313 The different combinations of the parameters are for further 314 expressing the more detailed service requirements of an 315 application, conveyed together with the Application-aware 316 identifiers, which can be used to match to appropriate tunnels/SR 317 Policies, queues that can satisfy these service requirements. If 318 not available, new tunnels/SR Policies can also be triggered to 319 be set up. 321 [REQ 1a]. Application-aware identification information MUST include 322 Application ID to indicate the application that generates the packet. 324 [REQ 1b]. SLA level is RECOMMENDED to be included in the 325 Application-aware identification information. 327 [REQ 1c]. User ID and Flow ID are OPTIONAL to be included in the 328 Application-aware identification information. 330 [REQ 1d]. Network performance requirements information is OPTIONAL. 332 [REQ 1e]. All the nodes along the path SHOULD be able to process the 333 application-aware information if needed. 335 [REQ 1f]. The application-aware information can be generated 336 directly by application, or by the application-aware edge devices 337 though packet inspection or local policy. 339 [REQ 1g]. The application-aware information SHOULD be kept intact 340 when directly copied from the application-aware edge devices and 341 carried in the packet. 343 5.2. Application-aware Information Handling Requirements 345 The app-aware-process Head-End and app-aware-process Mid-Point 346 perform matching operation against the application-aware information, 347 that is, to match IDs and/or service requirements to the 348 corresponding network resources (tunnels/SR policies, queues). 350 5.2.1. App-aware SLA Guarantee 352 In order to achieve better Quality of Experience (QoE) of end users 353 and engage customers, the network needs to be able to provide fine- 354 granularity and even application-level SLA guarantee 355 [I-D.li-apn6-problem-statement-usecases]. 357 [REQ 2-1a]. With the application-aware information, the App-aware- 358 process Head-End SHOULD be able to steer the traffic to the tunnel/SR 359 policy that satisfies the matching operation. 361 [REQ 2-1b]. With the application-aware information, the App-aware- 362 process Head-End SHOULD be able to trigger the setup of the tunnel/SR 363 policy that satisfies the matching operation. 365 [REQ 2-1c]. With the application-aware information, the App-aware- 366 process Head-End and Mid-Point SHOULD be able to steer the traffic to 367 the queue that satisfies the matching operation. 369 [REQ 2-1d]. With the application-aware information, the App-aware- 370 process Head-End and Mid-Point SHOULD be able to trigger the 371 configuration of the queue that satisfies the matching operation. 373 5.2.2. App-aware network slicing 375 Network slicing provides ways to partition the network infrastructure 376 in either control plane or data plane into multiple network slices 377 that are running in parallel. The resources on each node need to be 378 associated to corresponding slices. 380 [REQ 2-2a]. With the application-aware information, the App-aware- 381 process Head-End SHOULD be able to steer the traffic to the slice 382 that satisfies the matching operation. 384 [REQ 2-2a]. With the application-aware information, the App-aware- 385 process Mid-Point SHOULD be able to associate the traffic to the 386 resources in the slice that satisfies the matching operation. 388 5.2.3. App-aware deterministic networking 390 Along the path each node needs to provide guaranteed bandwidth, 391 bounded latency, and other properties relevant to the transport of 392 time-sensitive data for the Detnet flows that coexist with the best- 393 effort traffic. 395 [REQ 2-3a]. With the application-aware information, the App-aware- 396 process Head-End SHOULD be able to steer the traffic to the 397 appropriate path that satisfies the matching operation. 399 [REQ 2-3b]. With the application-aware information, the App-aware- 400 process Head-End SHOULD be able to trigger the setup of the 401 appropriate path that satisfies the matching operation for the Detnet 402 flows. 404 [REQ 2-3c]. With the application-aware information, the App-aware- 405 process Mid-Point SHOULD be able to associate the traffic to the 406 resources along the path that satisfies the performance guarantee. 408 [REQ 2-3d]. With the application-aware information, the App-aware- 409 process Mid-Point SHOULD be able to reserve the resources for the 410 Detnet flows along the path that satisfies the performance guarantee. 412 5.2.4. App-aware service function chaining 414 The end-to-end service delivery often needs to go through various 415 service functions, including traditional network service functions 416 such as firewalls, DPI as well as new application-specific functions, 417 both physical and virtual. SFC is applicable to both fixed and 418 mobile networks as well as data center networks. 420 [REQ 2-4a]. With the application-aware information, the App-aware- 421 process devices SHOULD be able to steer the traffic to the 422 appropriate service function. 424 [REQ 2-4b]. The App-aware-process devices SHOULD be able to process 425 the application-aware information carried in the packets. 427 5.2.5. App-aware network measurement 429 Network measurement can be used for locating silent failure and 430 predicting QoE satisfaction, which enables real-time SLA awareness/ 431 proactive OAM. 433 [REQ 2-5a]. With the application-aware identification information, 434 the App-aware-process devices SHOULD be able to perform IOAM based on 435 the Application ID. 437 [REQ 2-5a]. With the application-aware information, the network 438 measurement results can be reported based on the Application ID and 439 verify whether the performance requirements of the application are 440 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 6. IANA Considerations 453 This document does not include an IANA request. 455 7. Security Considerations 457 [I-D.li-apn6-problem-statement-usecases] and describe the security 458 considerations and requirements for APN. 460 8. Acknowledgements 462 The authors would like to acknowledge Robert Raszuk (Bloomberg LP) 463 and Yukito Ueno (NTT Communications Corporation) for their valuable 464 reviews and comments. 466 9. Contributors 468 Daniel Bernier 469 Bell Canada 470 Canada 472 Email: daniel.bernier@bell.ca 473 Chongfeng Xie 474 China Telecom 475 China 477 Email: xiechf@chinatelecom.cn 479 Peng Liu 480 China Mobile 481 China 483 Email: liupengyjy@chinamobile.com 485 Zhuangzhuang Qin 486 China Unicom 487 China 489 Email: qinzhuangzhuang@chinaunicom.cn 491 Chang Liu 492 China Unicom 493 China 495 Email: liuc131@chinaunicom.cn 497 10. References 499 10.1. Normative References 501 [I-D.li-apn6-problem-statement-usecases] 502 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 503 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 504 Statement and Use Cases of Application-aware IPv6 505 Networking (APN6)", draft-li-apn6-problem-statement- 506 usecases-01 (work in progress), November 2019. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 514 Chaining (SFC) Architecture", RFC 7665, 515 DOI 10.17487/RFC7665, October 2015, 516 . 518 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 519 (IPv6) Specification", STD 86, RFC 8200, 520 DOI 10.17487/RFC8200, July 2017, 521 . 523 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 524 RFC 8578, DOI 10.17487/RFC8578, May 2019, 525 . 527 10.2. Informative References 529 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 530 Xiao, "Overview and Principles of Internet Traffic 531 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 532 . 534 Authors' Addresses 536 Zhenbin Li 537 Huawei Technologies 538 China 540 Email: lizhenbin@huawei.com 542 Shuping Peng 543 Huawei Technologies 544 China 546 Email: pengshuping@huawei.com 548 Daniel Voyer 549 Bell Canada 550 Canada 552 Email: daniel.voyer@bell.ca 554 Cong Li 555 China Telecom 556 China 558 Email: licong@chinatelecom.cn 559 Liang Geng 560 China Mobile 561 China 563 Email: gengliang@chinamobile.com 565 Chang Cao 566 China Unicom 567 China 569 Email: caoc15@chinaunicom.cn 571 Kentaro Ebisawa 572 Toyota Motor Corporation 573 Japan 575 Email: ebisawa@toyota-tokyo.tech 577 Stefano Previdi 578 Individual 579 Italy 581 Email: stefano@previdi.net 583 James N Guichard 584 Futurewei Technologies Ltd. 585 USA 587 Email: jguichar@futurewei.com