idnits 2.17.1 draft-yang-apn-sd-wan-usecase-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (4 March 2022) is 784 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.li-6man-app-aware-ipv6-network' is defined on line 270, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-li-apn-framework-04 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Yang 3 Internet-Draft W. Cheng 4 Intended status: Informational China Mobile 5 Expires: 5 September 2022 S. Peng 6 Z. Li 7 Huawei 8 4 March 2022 10 Usage scenarios of Application-aware Networking (APN) for SD-WAN 11 draft-yang-apn-sd-wan-usecase-04 13 Abstract 15 This document describes the usage of Application-aware Networking 16 (APN) in SD-WAN scenarios. In these scenarios, APN is able to 17 identify a application group, steer its traffic flows along explicit 18 path across the network, and provide SLA guaranteed network services 19 such as low latency and high reliability. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 5 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Usage Scenarios of APN for SD-WAN . . . . . . . . . . . . . . 3 62 2.1. APN for Traffic Steering into Dedicated WAN . . . . . . . 3 63 2.2. APN for Traffic Steering into Particular Cloud . . . . . 3 64 2.3. APN for Value-added Service Provisioning in SD-WAN . . . 4 65 2.4. APN for Data Processing in SD-WAN . . . . . . . . . . . . 4 66 3. APN with SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. APN with In-Flow OAM . . . . . . . . . . . . . . . . . . . . 5 68 5. APN with Intention based Policy . . . . . . . . . . . . . . . 5 69 6. Business Model of APN enhanced SD-WAN . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 As more and more applications are moved to the cloud, the traditional 78 WAN architecture starts facing challenges. Software-defined Wide 79 Area Network (SD-WAN) provides a cloud-friendly way of 80 interconnecting branch offices and applications in the cloud over any 81 combination of transport services such as MPLS and 4G LTE, which is 82 able to optimising application performance with low costs. 84 Application-aware Networking (APN) is introduced in 85 [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. 86 APN conveys application-aware information (i.e. APN attribute) along 87 data packets traversing across the APN domain and facilitate fine- 88 granularity network service provisioning and guarantee their SLA 89 requirements. The ever-emerging network services such as network 90 slicing and IOAM can be further enhanced with APN. 92 This document describes the usage scenarios of APN for SD-WAN. 94 2. Usage Scenarios of APN for SD-WAN 96 This section describes the scenarios that can use APN to meet the 97 fine-granularity service operations in SD-WAN. 99 2.1. APN for Traffic Steering into Dedicated WAN 101 In CPE, different application groups are identified based on the 102 existing information in the packet header, and APN attribute is added 103 to the packets along with the tunnel encapsulation. Then the traffic 104 flows can be steered into different WANs that can guarantee their 105 corresponding SLA requirements. 107 +------+ +-----------+ +------+ 108 | APP1 | /------| WAN1 |------\ | APP1 | 109 +------+ / +-----------+ \ +------+ 110 +------+ +-------+ +-----------+ +--------+ +------+ 111 | APP2 |-----| CPE |------| WAN2 |------| CPE |-----| APP2 | 112 +------+ +-------+ +-----------+ +--------+ +------+ 113 +------+ \ +-----------+ / +------+ 114 | APP3 | \------| WAN3 |------/ | APP3 | 115 +------+ +-----------+ +------+ 117 Figure 1: Traffic Steering into WAN 119 2.2. APN for Traffic Steering into Particular Cloud 121 In the multi-cloud scenario, a CPE can be deployed by an enterprise 122 as its gateway to access different clouds. In the CPE (e.g. an 123 universial CPE, called uCPE), different application groups can be 124 identified based on the existing information in the packet header, 125 and APN attribute is added to the packets along with the tunnel 126 encapsulation. The traffic flows are steered into the corresponding 127 cloud where the application servers are running through the 128 corresponding WANs. 130 +------+ +-----------+ +----------+ 131 | APP1 | /---------| WAN1 |-----| Cloud1 | 132 +------+ / +-----------+ +----------+ 133 +------+ +--------+ +-----------+ +----------+ 134 | APP2 |-----| CPE |-----| WAN2 |-----| Cloud2 | 135 +------+ +--------+ +-----------+ +----------+ 136 +------+ \ +-----------+ +----------+ 137 | APP3 | \---------| WAN3 |-----| Cloud3 | 138 +------+ +-----------+ +----------+ 140 Figure 2: Traffic Steering into Cloud 142 2.3. APN for Value-added Service Provisioning in SD-WAN 144 APN can faciliate the value-added service provisioning in SD-WAN, 145 either at the CPE or the POP. 147 At the CPE, network security and application acceleration services 148 can be provided. With APN, certain malicious traffic can be 149 identified and blocked, while the traffic that requires acceleration 150 can be steered through the acceleration service. 152 At the POP, value-added service can be provisioned for certain 153 application groups according to the APN attribute carried in their 154 packets. 156 +------------+ 157 |POP(VAS/SFC)| 158 +------------+ 159 | 160 +-----+ +------------+ +------------+ +------------+ +-----+ 161 | APP |----|CPE(VAS/SFC)|-----| WAN |-----|CPE(VAS/SFC)|-----| APP | 162 +-----+ +------------+ +------------+ +------------+ +-----+ 164 Figure 3: VAS Provisioning 166 2.4. APN for Data Processing in SD-WAN 168 In enterprise, usually important data is kept locally and it is 169 preferred to be processed locally, while other data can be processed 170 with the complex processing capabilities in the cloud. 172 With APN, the traffic can be steered according to the localization 173 characteristics of the data, either being processed locally or in the 174 cloud. 176 +------+ +-------+ +------------+ +------------------+ 177 | Data |-----| CPE |-----| WAN |-----| Cloud (Computing)| 178 +------+ +-------+ +------------+ +------------------+ 179 \ 180 \ +---------------------------+ 181 --- | Local DC (Data Processing)| 182 +---------------------------+ 184 Figure 4: Data Processing 186 3. APN with SRv6 188 By carrying the APN attribute (including APN ID and APN parameters) 189 through data packets, i.e., the delivery of application-aware 190 information and ensuring the security and reliability of application- 191 aware information, the network senses the application groups' 192 requirements and provides high-quality differentiated services 193 according to the demand of the applications. And when the network 194 transmits the data packets, it matches the network correspondence 195 policy according to the APN attribute in the data packets and selects 196 the corresponding SRv6 path to transmit the data packets (e.g., low 197 latency path) to meet the SLA requirements and service chain in order 198 to improve the service quality. 200 +------+ +-----------+ +------+ 201 | APP1 | /-----| SRv6 path1|-----\ | APP1 | 202 +------+ / +-----------+ \ +------+ 203 +------+ +-------+ +-----------+ +--------+ +------+ 204 | APP2 |---| CPE |----| SRv6 path2|---| CPE |---| APP2 | 205 +------+ +-------+ +-----------+ +--------+ +------+ 206 +------+ \ +-----------+ / +------+ 207 | APP3 | \-----| SRv6 path3|-----/ | APP3 | 208 +------+ +-----------+ +------+ 210 Figure 5: SRv6 enabled SD-WAN 212 4. APN with In-Flow OAM 214 SD-WAN needs to guarantee the experience of critical applications, 215 and APNs can be used to carry application information to 216 differentiate between different application traffic. At the same 217 time, it is necessary to conduct end-to-end application-level network 218 quality awareness to achieve closed-loop control of network quality. 219 SD-WAN uses Overlay to establish connectivity, which enable flow 220 classification with APN, and work with In-Flow OAM detection to 221 identify critical applications from thousands of streams, thus 222 simplifying network quality assurance technology complexity for 223 critical applications. 225 5. APN with Intention based Policy 227 By using APNs to identify services, SD-WAN can relate global policies 228 to user service. This allows SD-WAN to automatically enforce 229 performance goals and access security for users, regardless of their 230 location. By identifying and sensing the service type, the global 231 policy automatically selects a path for the service, such as 232 Internet, to offload bandwidth-hungry services to the lower-cost 233 Internet. Based on the global policy, rather than the network 234 architecture, decisions can be made on how to isolate between 235 endpoints, applications, and the cloud. Global policies also can be 236 visualized and changed in real time to achieve sustainable trust as 237 the network evolves. 239 6. Business Model of APN enhanced SD-WAN 241 With the digital transformation, the network infrastructure and 242 cloud-based applications are emerging as an integrated service of 243 network operators to provide a complete solution to customer. As an 244 overlay technology, SD-WAN is able to simplify the network and make 245 it more service-focused, which has become the de facto option for the 246 Enterprise WAN Edge. SD-WAN enables the network service providers to 247 reshape their network to provide more complex products to meet 248 customers' various requirements. 250 When SD-WAN is integrated with APN, service providers are able to 251 provide network services together with cloud services in a fine- 252 granularity SaaS-like model. The latest functionalities can be 253 delivered via cloud. Customers benefit from the pay-for-use model in 254 per application granularity and have the agility to adjust the level 255 of functionality, capability, and capacity. According to the APN 256 attribute carried by the packets, corresponding paths/WANs can be 257 selected, the SLA can be guaranteed, and value-added services can be 258 provisioned. 260 7. Security Considerations 262 The security consideration can refer to [I-D.li-apn-framework] . 264 8. IANA Considerations 266 There are no IANA considerations in this document. 268 9. Normative References 270 [I-D.li-6man-app-aware-ipv6-network] 271 Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, 272 P., Cao, C., and K. Ebisawa, "Application-aware IPv6 273 Networking (APN6) Encapsulation", Work in Progress, 274 Internet-Draft, draft-li-6man-app-aware-ipv6-network-03, 275 22 February 2021, . 278 [I-D.li-apn-framework] 279 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 280 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 281 "Application-aware Networking (APN) Framework", Work in 282 Progress, Internet-Draft, draft-li-apn-framework-04, 25 283 October 2021, . 286 [I-D.li-apn-problem-statement-usecases] 287 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 288 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 289 "Problem Statement and Use Cases of Application-aware 290 Networking (APN)", Work in Progress, Internet-Draft, 291 draft-li-apn-problem-statement-usecases-05, 20 December 292 2021, . 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 Authors' Addresses 302 Feng Yang 303 China Mobile 304 Beijing 305 China 306 Email: yangfeng@chinamobile.com 308 Weiqiang Cheng 309 China Mobile 310 Beijing 311 China 312 Email: chengweiqiang@chinamobile.com 314 Shuping Peng 315 Huawei 316 Beijing 317 China 318 Email: pengshuping@huawei.com 320 Zhenbin Li 321 Huawei 322 Beijing 323 China 324 Email: lizhenbin@huawei.com