idnits 2.17.00 (12 Aug 2021) /tmp/idnits16887/draft-li-apn6-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 (November 04, 2019) is 922 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 476, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC8578' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-li-apn6-problem-statement-usecases-00 ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8578 Summary: 2 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: May 7, 2020 D. Voyer 6 Bell Canada 7 C. Xie 8 China Telecom 9 P. Liu 10 China Mobile 11 C. Liu 12 China Unicom 13 K. Ebisawa 14 Toyota Motor Corporation 15 S. Previdi 16 Individual 17 J. Guichard 18 Futurewei Technologies Ltd. 19 November 04, 2019 21 Application-aware IPv6 Networking (APN6) Framework 22 draft-li-apn6-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 IPv6 36 Networking (APN6), which makes use of IPv6 encapsulation to convey 37 the application characteristic information such as application 38 identification and its network performance requirements into the 39 network to facilitate service provisioning, perform application-level 40 traffic 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 May 7, 2020. 59 Copyright Notice 61 Copyright (c) 2019 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. APN6 Framework and Key Components . . . . . . . . . . . . . . 4 80 5. APN6 Requirements . . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. Application-aware Information Conveying Requirements . . 6 82 5.2. Application-aware Information Handling Requirements . . . 7 83 5.2.1. App-aware SLA Guarantee . . . . . . . . . . . . . . . 7 84 5.2.2. App-aware network slicing . . . . . . . . . . . . . . 8 85 5.2.3. App-aware deterministic networking . . . . . . . . . 8 86 5.2.4. App-aware service function chaining . . . . . . . . . 9 87 5.2.5. App-aware network measurement . . . . . . . . . . . . 9 88 5.3. Security requirements . . . . . . . . . . . . . . . . . . 9 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 92 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 95 10.2. Informative References . . . . . . . . . . . . . . . . . 11 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 IPv6 117 Networking, aiming to guarantee fine-granularity SLA requirements of 118 applications, which make use of IPv6 encapsulation to convey the 119 application characteristic such as application identification and its 120 network performance requirements into the network to determine the 121 path, steer traffic, and perform network resource adjustment. 123 2. Specification of Requirements 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 This document is not a protocol specification and the key words in 130 this document are used for clarity and emphasis of requirements 131 language. 133 3. Terminology 135 ACL: Access Control List 137 APN6: Application-aware IPv6 Networking 139 DPI: Deep Packet Inspection 141 PBR: Policy Based Routing 143 QoE: Quality of Experience 145 4. APN6 Framework and Key Components 147 The APN6 framework is shown in Figure 1. The key components include 148 Application-aware App, App-aware Edge Device, App-aware-process Head- 149 End, App-aware-process Mid-Point, and App-aware-process End-Point. 151 Packets carry application characteristic information (i.e. 152 application-aware information) which includes the following 153 information: 155 o Application-aware identification information: identifying 156 application, the user of application, i.e. the packets as part of 157 the traffic flow belonging to a specific SLA level/Application/ 158 User; 160 o Network performance requirements information: specifying at least 161 one of the following parameters: bandwidth, delay, delay 162 variation, packet loss ratio, security, etc. 164 Client Server 165 +-----+ +-----+ 166 |App x|-\ /->|App x| 167 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 168 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 169 User side |aware|--|process |-B-|process |-B-|process | 170 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 171 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 172 |App y|-/ \->|App y| 173 +-----+ ---------- Uplink ----------> +-----+ 175 Figure 1 APN6 Framework and Key Components 177 The key components are introduced as follows. 179 1. Application-aware App: The host obtains the application 180 characteristic information of the Application-aware App and generates 181 the packets which carry the application characteristic information in 182 IPv6 encapsulation. If carried in the packets, this information is 183 used by the App-aware-process Head-End to determine the path between 184 the App-aware-process Head-End and the App-aware-process End-Point 185 for forwarding the packets to their destination, that is, to steer 186 the packet in to a given policy which satisfies the application 187 requirements. In the APN6 framework, the application is not 188 mandatory to be application-aware. 190 2. App-aware Edge Device: This network device receives packets from 191 applications and obtains the application characteristic information. 192 If the application is not Application-aware App, the application 193 characteristic information can be obtained by packet inspection, 194 derived from services information such as double VLAN tagging (C-VLAN 195 and S-VLAN), or added according to the local policies which is out of 196 the scope of this document. The App-aware Edge Device adds the 197 application characteristic information in IPv6 encapsulation on 198 behalf of the application. The packets carrying the application 199 characteristic information will be sent to the App-aware-process 200 Head-End, and the application characteristic information will be used 201 to determine the path between the App-aware-process Head-End and the 202 App-aware-process End-Point for forwarding the packets. 204 3. App-aware-process Head-End: This network device receives packets 205 and obtains the application characteristic information. A set of 206 paths, tunnels or SR policy, exist between the App-aware-process 207 Head-End and the App-aware-process End-Point. The App-aware-process 208 Head-End maintains the matching relationship between the application 209 characteristic information and the paths between the App-aware- 210 process Head-End and the App-aware-process End-Point. The App-aware- 211 process Head-End determines the path between the App-aware-process 212 Head-End and the App-aware-process End-Point according to the 213 application characteristic information carried in the packets and the 214 matching relationship with it, which satisfies the service 215 requirements of the application. If there is no such matching path 216 found, the App-aware-process Head-End can set up a path towards the 217 App-aware-process End-Point, and the matching relationship will be 218 stored. The App-aware-process Head-End forwards the packets along 219 the path. The application information conveyed by the packet 220 received from the App-aware Edge Device can also be copied or be 221 mapped to the out IPv6 extension header for further application-aware 222 process. 224 4. App-aware-process Mid-Point: The Mid-Point provides the path 225 service according to the path set up by the App-aware-process Head- 226 End which satisfies the service requirements conveyed by the IPv6 227 packets. The Mid-Point may also adjust the resource locally to 228 guarantee the service requirements depending on a specific policy and 229 the application-aware information conveyed by the packet. Policy 230 definitions and mechanisms are out of the scope of this document. 232 5. App-aware-process End-Point: The process of the specific service 233 path will end at the End-Point. The service requirements information 234 can be removed at the End-Point together with the outer IPv6 235 encapsulation or go on to be conveyed with the IPv6 packets. 237 In this way the network is aware of the service requirements 238 expressed by the applications explicitly. According to the service 239 requirement information carried in the IPv6 packets the network is 240 able to adjust its resources fast in order to satisfy the service 241 requirement of applications. The flow-driven method also reduces the 242 challenges of inter-operability and long control loop. 244 5. APN6 Requirements 246 Utilizing IPv6 encapsulation (e.g. IPv6 header as well as, possibly, 247 extension headers), the application-aware information is conveyed 248 into the network which performs service provisioning, traffic 249 steering, and SLA guarantee according to such information. This 250 section specifies the requirements for supporting the APN6 framework, 251 including the requirements for conveying and handling the 252 application-aware information and related security requirements. 254 5.1. Application-aware Information Conveying Requirements 256 The application-aware information includes application-aware 257 identification information and network performance requirements 258 information. 260 1. Application-aware identification information includes the 261 following identifiers (IDs), 263 * SLA level: indicating the level of SLA requirement of the 264 application such as Gold, Silver, Bronze. In some cases, 265 color (e.g. red, green) can be used to indicate the SLA level. 267 * Application ID: identifying an application. 269 * User ID: identifying the user of the application. 271 * Flow ID: identifying the flow which the application traffic 272 belongs to. 274 The different combinations of the IDs can be used to provide 275 different granularity of the service provisioning and SLA 276 guarantee for the traffic. 278 2. Network performance requirements information includes the 279 following parameters, 281 * Bandwidth: the bandwidth requirement of the application 282 traffic 284 * Latency: the latency requirement of the application 286 * Jitter: the jitter requirement of the application 287 The different combinations of the parameters are for further 288 expressing the more detailed service requirements of an 289 application, conveyed together with the Application-aware 290 identifiers, which can be used to match to appropriate tunnels/SR 291 Policies, queues that can satisfy these service requirements. If 292 not available, new tunnels/SR Policies can also be triggered to 293 be set up. 295 [REQ 1a]. Application-aware identification information MUST include 296 Application ID to indicate the application that generates the packet. 298 [REQ 1b]. SLA level is RECOMMENDED to be included in the 299 Application-aware identification information. 301 [REQ 1c]. User ID and Flow ID are OPTIONAL to be included in the 302 Application-aware identification information. 304 [REQ 1d]. Network performance requirements information is OPTIONAL. 306 [REQ 1e]. All the nodes along the path SHOULD be able to process the 307 application-aware information if needed. 309 [REQ 1f]. The application-aware information can be generated 310 directly by application, or by the application-aware edge devices 311 though packet inspection or local policy. 313 [REQ 1g]. The application-aware information SHOULD be kept intact 314 when directly copied from the application-aware edge devices and 315 carried in the IPv6 encapsulation. 317 5.2. Application-aware Information Handling Requirements 319 The app-aware-process Head-End and app-aware-process Mid-Point 320 perform matching operation against the application-aware information, 321 that is, to match IDs and/or service requirements to the 322 corresponding network resources (tunnels/SR policies, queues). 324 5.2.1. App-aware SLA Guarantee 326 In order to achieve better Quality of Experience (QoE) of end users 327 and engage customers, the network needs to be able to provide fine- 328 granularity and even application-level SLA guarantee 329 [I-D.li-apn6-problem-statement-usecases]. 331 [REQ 2-1a]. With the application-aware information, the App-aware- 332 process Head-End SHOULD be able to steer the traffic to the tunnel/SR 333 policy that satisfies the matching operation. 335 [REQ 2-1b]. With the application-aware information, the App-aware- 336 process Head-End SHOULD be able to trigger the setup of the tunnel/SR 337 policy that satisfies the matching operation. 339 [REQ 2-1c]. With the application-aware information, the App-aware- 340 process Head-End and Mid-Point SHOULD be able to steer the traffic to 341 the queue that satisfies the matching operation. 343 [REQ 2-1d]. With the application-aware information, the App-aware- 344 process Head-End and Mid-Point SHOULD be able to trigger the 345 configuration of the queue that satisfies the matching operation. 347 5.2.2. App-aware network slicing 349 Network slicing provides ways to partition the network infrastructure 350 in either control plane or data plane into multiple network slices 351 that are running in parallel. The resources on each node need to be 352 associated to corresponding slices. 354 [REQ 2-2a]. With the application-aware information, the App-aware- 355 process Head-End SHOULD be able to steer the traffic to the slice 356 that satisfies the matching operation. 358 [REQ 2-2a]. With the application-aware information, the App-aware- 359 process Mid-Point SHOULD be able to associate the traffic to the 360 resources in the slice that satisfies the matching operation. 362 5.2.3. App-aware deterministic networking 364 Along the path each node needs to provide guaranteed bandwidth, 365 bounded latency, and other properties relevant to the transport of 366 time-sensitive data for the Detnet flows that coexist with the best- 367 effort traffic. 369 [REQ 2-3a]. With the application-aware information, the App-aware- 370 process Head-End SHOULD be able to steer the traffic to the 371 appropriate path that satisfies the matching operation. 373 [REQ 2-3b]. With the application-aware information, the App-aware- 374 process Head-End SHOULD be able to trigger the setup of the 375 appropriate path that satisfies the matching operation for the Detnet 376 flows. 378 [REQ 2-3c]. With the application-aware information, the App-aware- 379 process Mid-Point SHOULD be able to associate the traffic to the 380 resources along the path that satisfies the performance guarantee. 382 [REQ 2-3d]. With the application-aware information, the App-aware- 383 process Mid-Point SHOULD be able to reserve the resources for the 384 Detnet flows along the path that satisfies the performance guarantee. 386 5.2.4. App-aware service function chaining 388 The end-to-end service delivery often needs to go through various 389 service functions, including traditional network service functions 390 such as firewalls, DPI as well as new application-specific functions, 391 both physical and virtual. SFC is applicable to both fixed and 392 mobile networks as well as data center networks. 394 [REQ 2-4a]. With the application-aware information, the App-aware- 395 process devices SHOULD be able to steer the traffic to the 396 appropriate service function. 398 [REQ 2-4b]. The App-aware-process devices SHOULD be able to process 399 the application-aware information carried in the packets. 401 5.2.5. App-aware network measurement 403 Network measurement can be used for locating silent failure and 404 predicting QoE satisfaction, which enables real-time SLA awareness/ 405 proactive OAM. 407 [REQ 2-5a]. With the application-aware identification information, 408 the App-aware-process devices SHOULD be able to perform IOAM based on 409 the Application ID. 411 [REQ 2-5a]. With the application-aware information, the network 412 measurement results can be reported based on the Application ID and 413 verify whether the performance requirements of the application are 414 satisfied. 416 5.3. Security requirements 418 [REQ 3a]. The security mechanism defined for APN6 MUST allow an 419 operator to prevent applications sending arbitrary application-aware 420 information without agreement with the operator. 422 [REQ 3b]. The security mechanism defined for APN6 MUST prevent an 423 application requesting a service that is not entitled to get. 425 6. IANA Considerations 427 This document does not include an IANA request. 429 7. Security Considerations 431 [I-D.li-apn6-problem-statement-usecases] and section 5.3 describe the 432 security considerations and requirements for APN6. 434 8. Acknowledgements 436 The authors would like to acknowledge Robert Raszuk (Bloomberg LP) 437 and Yukito Ueno (NTT Communications Corporation) for their valuable 438 reviews and comments. 440 9. Contributors 442 Liang Geng 443 China Mobile 444 China 446 Email: gengliang@chinamobile.com 448 Chang Cao 449 China Unicom 450 China 452 Email: caoc15@chinaunicom.cn 454 Cong Li 455 China Telecom 456 China 458 Email: licong.bri@chinatelecom.cn 460 10. References 462 10.1. Normative References 464 [I-D.li-apn6-problem-statement-usecases] 465 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 466 Ebisawa, K., Ueno, Y., Previdi, S., and J. Guichard, 467 "Problem statement and use cases of Application-aware IPv6 468 Networking (APN6)", draft-li-apn6-problem-statement- 469 usecases-00 (work in progress), September 2019. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997, 474 . 476 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 477 Chaining (SFC) Architecture", RFC 7665, 478 DOI 10.17487/RFC7665, October 2015, 479 . 481 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 482 (IPv6) Specification", STD 86, RFC 8200, 483 DOI 10.17487/RFC8200, July 2017, 484 . 486 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 487 RFC 8578, DOI 10.17487/RFC8578, May 2019, 488 . 490 10.2. Informative References 492 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 493 Xiao, "Overview and Principles of Internet Traffic 494 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 495 . 497 Authors' Addresses 499 Zhenbin Li 500 Huawei Technologies 501 China 503 Email: lizhenbin@huawei.com 505 Shuping Peng 506 Huawei Technologies 507 China 509 Email: pengshuping@huawei.com 511 Daniel Voyer 512 Bell Canada 513 Canada 515 Email: daniel.voyer@bell.ca 516 Chongfeng Xie 517 China Telecom 518 China 520 Email: xiechf.bri@chinatelecom.cn 522 Peng Liu 523 China Mobile 524 China 526 Email: liupengyjy@chinamobile.com 528 Chang Liu 529 China Unicom 530 China 532 Email: liuc131@chinaunicom.cn 534 Kentaro Ebisawa 535 Toyota Motor Corporation 536 Japan 538 Email: ebisawa@toyota-tokyo.tech 540 Stefano Previdi 541 Individual 542 Italy 544 Email: stefano@previdi.net 546 James N Guichard 547 Futurewei Technologies Ltd. 548 USA 550 Email: jguichar@futurewei.com