idnits 2.17.1 draft-li-apn-framework-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 25 instances of too long lines in the document, the longest one being 12 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 date (October 25, 2021) is 914 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) == Missing Reference: 'S1' is mentioned on line 834, but not defined == Missing Reference: 'S2' is mentioned on line 838, but not defined == Missing Reference: 'P1' is mentioned on line 850, but not defined == Missing Reference: 'P2' is mentioned on line 853, but not defined == Missing Reference: 'P3' is mentioned on line 857, but not defined == Missing Reference: 'P4' is mentioned on line 862, but not defined == Unused Reference: 'I-D.peng-apn-security-privacy-consideration' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'RFC8578' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 951, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-04 ** 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: 4 errors (**), 0 flaws (~~), 13 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: April 28, 2022 D. Voyer 6 Bell Canada 7 C. Li 8 China Telecom 9 P. Liu 10 China Mobile 11 C. Cao 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 October 25, 2021 23 Application-aware Networking (APN) Framework 24 draft-li-apn-framework-04 26 Abstract 28 A multitude of applications are carried over the network, which have 29 varying needs for network bandwidth, latency, jitter, and packet 30 loss, etc. Some new emerging applications have very demanding 31 performance requirements. However, in current networks, the network 32 and applications are decoupled, that is, the network is not aware of 33 the applications' requirements in a fine granularity. Therefore, it 34 is difficult to provide truly fine-granularity traffic operations for 35 the applications and guarantee their SLA requirements. 37 This document proposes a new framework, named Application-aware 38 Networking (APN), where application-aware information (i.e. APN 39 attribute) including APN identification (ID) and/or APN parameters 40 (e.g. network performance requirements) is encapsulated at network 41 edge devices and carried in packets traversing an APN domain in order 42 to facilitate service provisioning, perform fine-granularity traffic 43 steering and network resource adjustment. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on April 28, 2022. 62 Copyright Notice 64 Copyright (c) 2021 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 81 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 4. APN Framework and Key Components . . . . . . . . . . . . . . 5 83 5. APN Requirements . . . . . . . . . . . . . . . . . . . . . . 6 84 5.1. APN Attribute Conveying Requirements . . . . . . . . . . 7 85 5.1.1. Protocol Extensions Requirements . . . . . . . . . . 8 86 5.2. APN attribute Handling Requirements . . . . . . . . . . . 9 87 5.2.1. Fine granular SLA Guarantee . . . . . . . . . . . . . 10 88 5.2.2. Fine granular network slicing . . . . . . . . . . . . 10 89 5.2.3. Fine granular deterministic networking . . . . . . . 11 90 5.2.4. Fine granular service function chaining . . . . . . . 11 91 5.2.5. Fine granular network measurement . . . . . . . . . . 12 92 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 93 6.1. Example use case description . . . . . . . . . . . . . . 12 94 6.2. User Group and Application Group Design . . . . . . . . . 13 95 6.3. Derive the User Group and User Group at APN Edge . . . . 15 96 6.4. Access Right Check at the edge of the backbone network . 15 97 6.5. SLA Guarantee in the backbone network . . . . . . . . . . 16 98 6.5.1. Network Measurement . . . . . . . . . . . . . . . . . 16 99 6.5.2. Traffic Steering . . . . . . . . . . . . . . . . . . 17 100 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 104 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 107 12.2. Informative References . . . . . . . . . . . . . . . . . 21 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 110 1. Introduction 112 A multitude of applications are carried over the network, which have 113 varying needs for network bandwidth, latency, jitter, and packet 114 loss, etc. Some applications such as online gaming and live video 115 streaming have very demanding network requirements and therefore 116 require special treatment in the network. However, in current 117 networks, the network and applications are decoupled, that is, the 118 network is not aware of the applications' requirements in a fine 119 granularity. Therefore, it is difficult to provide truly fine- 120 granularity traffic operations for the applications and guarantee 121 their SLA requirements accordingly. 122 [I-D.li-apn-problem-statement-usecases] describes the challenges of 123 traditional differentiated service provisioning methods, such as five 124 tuples used for ACL/PBR causing coarse granularity as well as 125 orchestration and SDN-based solution causing long control loops. 127 This document proposes a new framework, named Application-aware 128 Networking (APN), where application-aware information (APN attribute) 129 including application-aware identification (APN ID) and application- 130 aware parameters (APN Parameters), is encapsulated at network edge 131 devices and carried along with the encapsulation of the tunnel that 132 is used by the packet to traverse the APN domain. The APN attribute 133 will facilitate service provisioning and provide fine-granularity 134 services in the APN domain. 136 The APN attribute is acquired based on the existing information in 137 the packet header such as 5-tuple and QinQ (S-VLAN and C-VLAN) at the 138 edge devices of the APN domain, added to the data packets along with 139 the tunnel encapsulation, delivered within the network, and removed 140 when the packets leave the domain together with the tunnel 141 encapsulation. 143 APN aims to apply various policies in different nodes along a network 144 path onto a traffic flow altogether, for example, at the headend to 145 steer into corresponding path, at the midpoint to collect 146 corresponding performance measurement data, and at the service 147 function to execute particular policies. 149 APN works within a limited trusted domain. Typically, an APN domain 150 is defined as a Network Operator controlled limited domain (see 151 Figure 1), in which MPLS, VXLAN, SR/SRv6 and other tunnel 152 technologies are adopted to provide network services. 154 2. Specification of Requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 This document is not a protocol specification and the key words in 161 this document are used for clarity and emphasis of requirements 162 language. 164 3. Terminology 166 ACL: Access Control List 168 APN: Application-aware Networking 170 APN6: Application-aware Networking for IPv6/SRv6 172 LB: Load Balancing 174 MPLS: Multiprotocol Label Switching 176 PBR: Policy Based Routing 178 QoE: Quality of Experience 180 SDN: Software Defined Networking 182 SLA: Service Level Agreement 184 SR: Segment Routing 186 SR-MPLS: Segment Routing over MPLS dataplane 187 SRv6: Segment Routing over IPv6 dataplane 189 4. APN Framework and Key Components 191 The APN framework is shown in Figure 1. The key components include 192 App-aware Edge Device (APN-Edge), App-aware-process Head-End (APN- 193 Head), App-aware-process Mid-Point (APN-Midpoint), and App-aware- 194 process End-Point (APN-Endpoint). 196 Packets carry application characteristic information (i.e. APN 197 attribute) which includes the following information: 199 o Application-aware identification (APN ID): identifies the set of 200 attributes, indicating that all packets belonging to the same flow 201 will be given the same treatment by the network. ; 203 o Application-aware parameters (APN parameters): The typical 204 application-aware parameters are the network performance 205 requirement parameters including bandwidth, delay, delay 206 variation, packet loss ratio, etc. 208 Client Server 209 +-----+ +-----+ 210 |App x|-\ /->|App x| 211 +-----+ | +-----+ +-----+ +---------+ +--------+ +-----+ | +-----+ 212 \->|APN | |APN |-A-|APN |-A-|APN | |APN |->/ 213 User side |- |-|- |-B-|- |-B-|- |-|- | 214 /->|Edge | |Head |-C-|Midpoint |-C-|Endpoint| |Edge |->\ 215 +-----+ | +-----+ +-----+ +---------+ +--------+ +-----+ | +-----+ 216 |App y|-/ |------------------APN Domain--------------| \->|App y| 217 +-----+ +-----+ 219 Figure 1: Framework and Key Components 221 The key components are introduced as follows. 223 o App-aware Edge Device (APN-Edge): this network device receives 224 packets from applications and obtains the APN attribute based on 225 the configuration on this device according to the existing 226 information in the packet header, such as 5-tuple, VLAN or double 227 VLAN tagging (C-VLAN and S-VLAN). The APN-Edge device adds the 228 APN attribute in the tunnel encapsulation. The packets carrying 229 the APN attribute will be sent to the APN-Head, and the APN 230 attribute will be used to apply various policies in different 231 nodes along the network path onto the traffic flow, e.g., at the 232 headend to steer into corresponding path satisfying SLAs, at the 233 midpoint to collect corresponding performance measurement data, at 234 the service function to execute particular policies. When the 235 packets leave the APN domain, the APN attribute will be removed 236 together with the tunnel encapsulation. 238 o App-aware-process Head-End (APN-Head): This network device 239 receives packets from the APN-Edge, obtains the APN attribute, and 240 initiates the corresponding process. Generally, in order to 241 satisfy different SLA requirements, a set of paths, tunnels or SR 242 policies, are set up between the APN-Head and the APN-Endpoint. 243 These multiple parallel paths have different SLA guarantees. The 244 APN-Head maintains the matching relationship between the APN 245 attribute and the paths between the APN-Head and the APN-Endpoint. 246 The APN-Head determines the path between the APN-Head and the APN- 247 Endpoint according to the APN attribute carried in the packets and 248 the matching relationship with it, which satisfies the service 249 requirements of the applications. The APN-Head forwards the 250 packets along the path. The APN attribute conveyed by the packet 251 received from the APN-Edge can also be copied or be mapped to the 252 outgoing packet header. 254 o App-aware-process Mid-Point (APN-Midpoint): the APN-Midpoint 255 provides the path service and enforces various policies according 256 to the APN attribute carried in the packets. The APN-Midpoint may 257 also adjust the resource locally to guarantee the service 258 requirements depending on a specific policy and the APN attribute 259 conveyed by the packet. Policy definitions and mechanisms are out 260 of the scope of this document. 262 o App-aware-process End-Point (APN-Endpoint): the process of the 263 specific service path will end at the APN-Endpoint. If the outer 264 tunnel header for the path between the APN-Head and the APN- 265 Endpoint exists, it will be removed by the APN-Endpoint. If the 266 APN attribute is copied or mapped to the outer tunnel header by 267 the APN-Head, it will also be removed along with the outer tunnel 268 header. 270 Note that in the actual implementation, the APN-Edge can co-exist 271 with the APN-Head or APN-Endpoint, that is, one network device can 272 implement the functionalities of both APN-Edge and the APN-Head/APN- 273 Endpoint. 275 5. APN Requirements 277 This section specifies the requirements for supporting the APN 278 framework, including the requirements for conveying and handling the 279 APN attribute. 281 5.1. APN Attribute Conveying Requirements 283 The APN attribute consists of APN ID and APN parameters. 285 APN ID includes the following identifiers (IDs), 287 o Application Group ID: identifies an application group of the 288 traffic. 290 o User Group ID: identifies the user group of the traffic. 292 APN ID can be acquired through different ways. In the APN work it 293 MUST be acquired according to the existing available information in 294 the packet header without inspection into the payload. 296 The different combinations of the IDs can be used to provide 297 different granularity of the service provisioning and SLA guarantee 298 for the traffic. 300 The APN parameters are the network performance requirement 301 parameters. The network service requirement can include the 302 following parameters: 304 o Bandwidth: the bandwidth requirement 306 o Latency: the latency requirement 308 o Packet loss ratio: the packet loss ratio requirement 310 o Jitter: the jitter requirement 312 The different combinations of the parameters are for further 313 expressing the more detailed service requirements, conveyed together 314 with the APN ID, which can be used to match to appropriate tunnels/SR 315 Policies and queues that can satisfy these service requirements. 317 APN attribute MUST be encapsulated within tunnels in the network 318 layer. The tunnels include but not limit to MPLS, VxLAN, SR-MPLS, 319 and SRv6. It can be extended according to requirements in the 320 future. 322 [REQ 1a]. APN ID SHOULD include Application Group ID to indicate the 323 application group that the packet belongs to. 325 [REQ 1b]. APN ID SHOULD include User Group ID to indicate the user 326 group that the packet belongs to. 328 [REQ 1c]. APN ID MUST include either Application Group ID or User 329 Group ID. 331 [REQ 1d]. APN ID MUST be acquired from the existing available 332 information of the packet header without interference into the 333 payload. 335 [REQ 1e]. APN parameters is OPTIONAL. 337 [REQ 1f]. APN attribute MUST be carried by the outer tunnel 338 encapsulation. 340 [REQ 1g]. All the nodes along the path SHOULD be able to process the 341 APN attribute if needed. 343 [REQ 1h]. The APN attribute is generated by the APN-Edge though 344 local policy. 346 [REQ 1i]. The APN attribute SHOULD be kept intact when directly 347 copied at the APN-Head and carried in the tunnel encapsulation. 349 [REQ 1j]. The APN attribute MUST be removed along with the tunnel 350 encapsulation by the APN-Edge when the packets leave the APN domain. 352 5.1.1. Protocol Extensions Requirements 354 The APN attribute is conveyed with the tunnel encapsulation. There 355 are two typical types of tunnels: 357 o MPLS-based tunnel: LDP tunnel, RSVP-TE tunnel, SR-MPLS tunnel or 358 policy, etc. 360 o IPv6-based tunnel: IPv6-based VxLAN tunnel, IPv6-based UDP tunnel, 361 IPv6-based GRE tunnel, SRv6 tunnel or policy, etc. 363 In order to support encapsulation of APN attribute, the MPLS data 364 plane and IPv6 data plane need to be extended. 366 In order to support acquiring the APN attribute according to the 367 existing available information in the packet header, YANG models 368 should be defined to configure the mapping between the application/ 369 user group ID and the existing information in the packet header and 370 configure the corresponding APN attribute for the application/user 371 group. It can also be implemented with protocol extensions such as 372 BGP and PCEP which can advertise the information from the central 373 controller to the APN-Edge. 375 In addition, in the APN domain, the above-mentioned mapping and 376 applying APN parameters may also be advertised from the APN-Edge/APN- 377 Head to other devices or from the network devices to the central 378 controller in the APN domain. IGP extensions or BGP-LS extensions 379 should be introduced to achieve the purposes. 381 [REQ 1-1a] MPLS encapsulation SHOULD be extended to be able to carry 382 the APN attribute for MPLS-based tunnels. 384 [REQ 1-1b] IPv6 encapsulation SHOULD be extended to be able to carry 385 the APN attribute for IPv6-based tunnels. 387 [REQ 1-1c] YANG models SHOULD be defined to implement the mapping 388 between the application/user group ID and the existing available 389 information in the packet header and configure the corresponding APN 390 parameters. 392 [REQ 1-1d] BGP extensions SHOULD be defined to advertise the mapping 393 between the application/user group ID and the existing available 394 information in the packet header and the corresponding APN parameters 395 from the central controller to the APN-Edge in the APN domain. 397 [REQ 1-1e] PCEP extensions SHOULD be defined to advertise the mapping 398 between the application/user group ID and the existing available 399 information in the packet header and the corresponding APN parameters 400 from the central controller to the APN-Edge in the APN domain. 402 [REQ 1-1f] IGP extensions SHOULD be defined to advertise the mapping 403 between the application/user group ID and the existing available 404 information in the packet header and the corresponding APN parameters 405 from the APN-Edge to the network devices in the APN domain. 407 [REQ 1-1g] BGP-LS extensions SHOULD be defined to advertise the 408 mapping between the application/user group ID and the existing 409 available information in the packet header and the corresponding APN 410 parameters from the network devices to the central controller in the 411 APN domain. 413 5.2. APN attribute Handling Requirements 415 The APN Head and APN-Midpoint perform matching operation against the 416 APN attribute, that is, to match IDs and/or service requirements to 417 the corresponding network resources such as tunnels/SR policies and 418 queues. 420 5.2.1. Fine granular SLA Guarantee 422 In order to achieve better Quality of Experience (QoE) of end users 423 and engage customers, the network needs to be able to provide fine- 424 granularity SLA guarantee [I-D.li-apn-problem-statement-usecases]. 426 [REQ 2-1a]. With the APN attribute, the APN-Head SHOULD be able to 427 steer the traffic to the tunnel/SR policy that satisfies the matching 428 operation. 430 [REQ 2-1b]. With the APN attribute, the APN-Head SHOULD be able to 431 trigger the setup of the tunnel/SR policy that satisfies the matching 432 operation. 434 [REQ 2-1c]. With the APN attribute, the APN-Head and APN-Midpoint 435 SHOULD be able to steer the traffic to the queue that satisfies the 436 matching operation. 438 [REQ 2-1d]. With the APN attribute, the APN-Head and APN-Midpoint 439 SHOULD be able to trigger the configuration of the queue that 440 satisfies the matching operation. 442 [REQ 2-1e]. If the tunnels are used to satisfy the performance 443 requirements, the APN-Head SHOULD be able to copy or map the APN 444 attribute conveyed by the packet received from the APN-Edge to the 445 outer tunnel header. 447 [REQ 2-1f]. If the tunnels are used to satisfy the performance 448 requirements and the APN attribute are conveyed along with the outer 449 tunnel, the APN-Endpoint MUST remove the APN attribute along with the 450 outer tunnel. 452 5.2.2. Fine granular network slicing 454 Network slicing provides ways to partition the network infrastructure 455 in either control plane or data plane into multiple network slices 456 that are running in parallel. The resources on each node need to be 457 associated to corresponding slices. 459 APN is to help the operator of a network to steer some of the traffic 460 tagged with an APN attribute to a certain network slice based on the 461 SLA agreement with its customer. 463 [REQ 2-2a]. With the APN attribute, the APN-Head SHOULD be able to 464 steer the traffic to the slice that satisfies the matching operation. 466 [REQ 2-2b]. With the APN attribute, the APN-Midpoint SHOULD be able 467 to associate the traffic to the resources in the slice that satisfies 468 the matching operation. 470 5.2.3. Fine granular deterministic networking 472 Along the path each node needs to provide guaranteed bandwidth, 473 bounded latency, and other properties relevant to the transport of 474 time-sensitive data for the Detnet flows that coexist with the best- 475 effort traffic. 477 APN is to help the operator of a network to steer some of the traffic 478 tagged with an APN attribute to a certain deterministic path based on 479 the SLA agreement with its customer. 481 [REQ 2-3a]. With the APN attribute, the APN-Head SHOULD be able to 482 steer the traffic to the appropriate path that satisfies the matching 483 operation. 485 [REQ 2-3b]. With the APN attribute, the APN-Head SHOULD be able to 486 trigger the setup of the appropriate path that satisfies the matching 487 operation for the Detnet flows. 489 [REQ 2-3c]. With the APN attribute, the APN-Midpoint SHOULD be able 490 to associate the traffic to the resources along the path that 491 satisfies the performance guarantee. 493 [REQ 2-3d]. With the APN attribute, the APN-Midpoint SHOULD be able 494 to reserve the resources for the Detnet flows along the path that 495 satisfies the performance guarantee. 497 5.2.4. Fine granular service function chaining 499 The end-to-end service delivery often needs to go through various 500 service functions, including traditional network service functions 501 such as firewalls, LB as well as new application-specific functions, 502 both physical and virtual. SFC is applicable to both fixed and 503 mobile networks as well as data center networks. 505 APN is to help the operator of a network to steer some of the traffic 506 tagged with an APN attribute to a certain service function chain 507 based on the SLA agreement with its customer. On each service 508 function along the service function chain, the policy can be enforced 509 based on the APN attribute in the outer header. 511 [REQ 2-4a]. With the APN attribute, the App-aware-process devices 512 SHOULD be able to steer the traffic to the appropriate service 513 function. 515 [REQ 2-4b]. The App-aware-process devices including VAS SHOULD be 516 able to process the APN attribute carried in the packets. 518 5.2.5. Fine granular network measurement 520 Network measurement can be used for verifying whether the network 521 performance requirements have been satisfied, as well as locating 522 silent failure and predicting QoE satisfaction, which enables real- 523 time SLA awareness/proactive OAM and potential resource adjustments. 525 APN is to help the operator of a network to trigger performance 526 measurement for the traffic tagged with an APN attribute based on its 527 customer' consent. 529 [REQ 2-5a]. The App-aware-process devices SHOULD be able to perform 530 IOAM based on the APN attribute. 532 [REQ 2-5b]. The network measurement results can be reported based on 533 the APN attribute and verify whether the performance requirements are 534 satisfied. 536 6. Illustration 538 In order to better clarify what APN can enable with the introduced 539 APN attribute compared to the existing network without APN, we 540 illustrate how APN works through an example use case, which is also a 541 typical network service being provisioned nowadays, i.e. the Cloud 542 Leased Line service. In order to make the tunnel description much 543 easier to understand, we use the recent technology in IETF, i.e. 544 SRv6. 546 6.1. Example use case description 548 We take the "SRv6-based Cloud Leased Line Service" as an illustrative 549 example to show how APN is needed and can be beneficial. 551 Enterprises usually buy Cloud Leased Line Service to interconnect 552 their local sites to Cloud. Generally, the Cloud Leased Line Service 553 needs to go across multiple domains which are owned by the same 554 operator and can be controlled by multiple controllers and an 555 orchestrator/super-controller. 557 Due to management reasons, the network information in the 558 intermediate domain cannot be advertised to other domains, so the 559 ingress node cannot set up an appropriate E2E path. In that case, 560 the intermediate domain is treated as a black box, and no fine grain 561 traffic steering and other services can be provisioned. 563 The example of the network to provide the cloud leased lined service 564 reference diagram is shown as the following figure. The network is 565 composed by three network domains including the two metro networks in 566 the City A and City B and the backbone network which connects the two 567 metro networks. The cloud leased line services is provided to the 568 specific enterprise whose branches located in different cities need 569 to access the cloud-based service located in the City B. 571 Domain 1 Domain 2 Domain 3 572 /-------------\ /------------\ /-----------\ 573 +-/-+ City A +-\-+ +-/-+ IPv6 +-\-+ +-/-+ City B +-\-+ 574 Branch---|PE1| |CR1|---|CR2| |CR3|---|CR4| |PE2|--Cloud 575 +-\-+ Metro +-/-+ +-\-+ Backbone +-/-+ +-\-+ Metro +-/-+ 576 \-------------/ \------------/ \-----------/ 578 |<--OSPF/ISIS-->|<-EBGP->|<- IPv6/SRv6 ->|<-EBGP->|<-OSPF/ISIS->| 579 |<----------------------- EBGP VPNv4 Peer --------------------->| 580 |<----------------------- L3VPN over SRv6 --------------------->| 582 Figure 2. Reference diagram for the example use case illustration 584 6.2. User Group and Application Group Design 586 The user groups can be designed as follows: 588 User Group 589 Enterprise A/Branch 1/Office Users 001001001 590 Enterprise A/Branch 1/R&D Users 001001002 591 Enterprise A/Branch 1/IT Users 001001003 592 Enterprise A/Branch 1/VIP Users 001001004 593 Enterprise A/Branch 2/Office Users 001002001 594 Enterprise A/Branch 2/R&D Users 001002002 595 Enterprise A/Branch 2/IT Users 001002003 596 Enterprise A/Branch 2/VIP Users 001002004 597 Enterprise A/Branch 3/Office Users 001003001 598 Enterprise A/Branch 3/R&D Users 001003002 599 Enterprise A/Branch 3/IT Users 001003003 600 Enterprise A/Branch 3/VIP Users 001003004 602 In the IP address design, the IPv6 address blocks allocated to the 603 branches are as follows : 605 IPv6 Address 606 Enterprise A/Branch 1/Office Users 2001:DB8:A:11::/56 607 Enterprise A/Branch 1/R&D Users 2001:DB8:A:12::/56 608 Enterprise A/Branch 1/IT Users 2001:DB8:A:13::/56 609 Enterprise A/Branch 1/VIP Users 2001:DB8:A:1D::/56 610 Enterprise A/Branch 2/Office Users 2001:DB8:A:21::/56 611 Enterprise A/Branch 2/R&D Users 2001:DB8:A:22::/56 612 Enterprise A/Branch 2/IT Users 2001:DB8:A:23::/56 613 Enterprise A/Branch 2/VIP Users 2001:DB8:A:2D::/56 614 Enterprise A/Branch 3/Office Users 2001:DB8:A:31::/ 56 615 Enterprise A/Branch 3/R&D Users 2001:DB8:A:32::/56 616 Enterprise A/Branch 3/IT Users 2001:DB8:A:33::/56 617 Enterprise A/Branch 3/VIP Users 2001:DB8:A:3D::/56 619 The application groups provided by the cloud can be designed as 620 follows: 622 Application Group 623 Enterprise A/Office Audio Applications 101001001 624 Enterprise A/Office Video Applications 101001002 625 Enterprise A/Office Data Applications 101001003 626 Enterprise A/R&D Audio Applications 101002001 627 Enterprise A/R&D Video Applications 101002002 628 Enterprise A/R&D Data Applications 101002003 629 Enterprise A/IT Audio Applications 101003001 630 Enterprise A/IT Video Applications 101003002 631 Enterprise A/IT Data Applications 101003003 633 In the address design, the IPv6 address blocks allocated to the 634 applications of Enterprise A in the cloud is 635 2001:DB8:A1::/48A1::A:/16. The port number can be used to identify 636 different applications. 638 IPv6 Address Port Number 639 Enterprise A/Office Audio Applications 2001:DB8:A1:A1::/64 1718, 1719 640 Enterprise A/Office Video Applications 2001:DB8:A1:A1::/64 5060, 5061 641 Enterprise A/Office Data Applications 2001:DB8:A1:A1::/64 21, 80 642 Enterprise A/R&D Audio Applications 2001:DB8:A1:A2::/64 1718, 1719 643 Enterprise A/R&D Video Applications 2001:DB8:A1:A2::/64 5060, 5061 644 Enterprise A/R&D Data Applications 2001:DB8:A1:A2::/64 21, 80 645 Enterprise A/IT Audio Applications 2001:DB8:A1:A3::/64 1718, 1719 646 Enterprise A/IT Video Applications 2001:DB8:A1:A3::/64 5060, 5061 647 Enterprise A/IT Data Applications 2001:DB8:A1:A3::/64 21, 80 649 6.3. Derive the User Group and User Group at APN Edge 651 The cloud leased line service adopts the SRv6-based L3VPN to traverse 652 the network. The following policy can be applied at the APN edges of 653 the City A1: 655 Match: 656 VPN1 657 Source Address 2001:DB8:A:11::/56 658 Action 659 Set user-group 001001001 661 Match: 662 VPN1 663 destination Address 2001:DB8:A1:A1::/64 664 destination port 1718,1719 665 Action 666 Set app-group 101001001 668 6.4. Access Right Check at the edge of the backbone network 670 The following check can be applied at the edge of the IP backbone 671 network: 673 Match: 674 user-group 001001001 675 app-group 101002001, 101002002, 101002003, 101003001, 101003002, 101003003 676 Action 677 Deny 679 Match: 680 user-group 001001001 681 app-group 101001001, 101001002, 101001003 682 Action 683 Permit 685 The policy means that the office users of the branch 1 can only 686 access the office applications. 688 If the address allocation is changed. For example, one office user 689 of the branch1's IPv6 address is changed to 2001:DB8:A:15::/56 690 because of the mobile office. 692 We only need to add the following policy at the APN edge: 694 Match: 695 VPN1 696 Source Address 2001:DB8:A:15::/56 697 Action 698 Set user-group 001001001 700 The policy in the backbone network which is based on the user group 701 and the application group is not necessary to change. 703 6.5. SLA Guarantee in the backbone network 705 Due to management reasons, the network information in the 706 intermediate domain cannot be advertised to other domains, so the 707 ingress node cannot set up an appropriate TE path, the intermediate 708 domain is treated as a black box and no fine grain traffic steering 709 can be performed. 711 In this case, we consider fine grain traffic steering in Domain 2 on 712 top of the SRv6-based Cloud Leased Line Service for the purpose of 713 SLA Guarantee. 715 6.5.1. Network Measurement 717 In order to guarantee SLA for the VIP users, the following network 718 measurement policy can be applied in the backbone network: 720 Match: 721 User-group 001001004 application group 101001002 722 User-group 001002004 application group 101002002 723 User-group 001003004 application group 101003002 724 Action 725 Apply IOAM 727 The policy is to apply the IOAM as the network measurement for the 728 VIP users of the branches to access the video applications.From the 729 above illustration, there is the following observation: 731 When there is no APN deployed, at CR2, the 5 tuples of the original 732 packets will need to be resolved since they have been encapsulated, 733 and then IOAM can be triggered based on the 5 tuples. This 734 resolution process is costly and consumes a lot of hardware 735 resources. If Domain 3 needs to trigger IOAM, the same resolution 736 process will have to be done at CR4. 738 When there is APN deployed, at CR1, the APN attribute is tagged. 739 When these packets arrive at CR2, only the APN attribute in the outer 740 header will be read out, based on which the IOAM can be triggered in 741 Domain 2. That is, no 5-tuple resolution process is needed at CR2 742 but only checking the APN attribute in the outer header. 744 6.5.2. Traffic Steering 746 If the SLA guarantee of the VIP users accessing the video 747 applications does not satisfy the requirements through the network 748 measurement based on the IOAM, the SRv6 policy can be setup. For 749 example, the SRv6 policy 1 which can satisfy the SLA requirement is 750 set up. Then the following policy can be downloaded to the edge: 752 Match: 753 User-group 001001004 application group 101001002 754 User-group 001002004 application group 101002002 755 User-group 001003004 application group 101003002 756 Action 757 Redirect SRv6 Policy 1 759 The policy is to steer the traffic of the VIP users to the SRv6 760 policy in the backbone to satisfy the requirement . 762 From the above illustration, there is the similar observation as the 763 network measurement: 765 When there is no APN deployed, at CR2, the 5 tuples of the original 766 packets will need to be resolved since they have been encapsulated, 767 and then the traffic can be steered into SRv6 policy 2 based on the 5 768 tuples. This resolution process is costly and consumes a lot of 769 hardware resources. 771 When there is APN deployed, at CR1, the APN attribute is tagged When 772 these packets arrive at CR2, only the APN attribute in the outer 773 header will be read out, based on which the traffic can be steered 774 into SRv6 policy 2 in Domain 2. 776 7. Benefits 778 The APN attribute allows the network devices to only look at one 779 easily-accessible field in the outer header, without having to 780 resolve the 5 tuples of the original packets that are deeply 781 encapsulated in the tunnel encapsulation. 783 The APN attribute allows to simplify the policy control at every 784 policy enforcement point within the network. The APN attribute 785 allows to reducing each matching entry of policy filter since it is 786 only one field and hardware resources are saved. Since APN attribute 787 is relatively stable, it introduces the possibilities of eliminating 788 the "stale" policy filter entries. In most cases, the APN attribute 789 is centralized configured and distributed to all the policy 790 enforcement points, which saves the policy filter configurations per 791 node and simplifies the OM. 793 The structured APN attribute allows to express fine granular service 794 requirements, e.g. MKT-user-group/app-group, RD-user-group/app- 795 group, latency. 797 The structured APN attribute allows to match to the evolving fine 798 granular differentiated network capabilities, e.g. SR policy with 799 low latency and high reliability guaranteed. 801 In a tunnel across multiple domains of the same operator using the 802 APN attribute in the outer header the operator can easily support 803 multiple services not just a single one in a particular domain as 804 illustrated in the usecase illustration section. 806 When there is no APN, to achieve the same, now the operator may have 807 two options: 1. Add all the policy identifiers at the tunnel headend 808 with various further encapsulations and enforce the policies based on 809 them at the intermediate policy enforcement nodes along the tunnel, 810 2. Resolve the original 5 tuples being encapsulated inside the 811 tunnel which will be very costly and sometimes impossible. 813 Moreover, the policy enforcement table in the intermediate policy 814 enforcement nodes is significantly reduced. Because before operator 815 needs to resolve the 5 tuple but now with APN, operator only needs to 816 read the APN attribute in one field of the outer header. 818 Since the 5 tuples of the traffic are changing frequently due to 819 service deployment or management issues the policy enforcement table 820 in the policy enforcement nodes is not stable and there is always a 821 lot of stale entries in the table. But now since the APN attribute 822 is a mapping of the 5 tuples operator will have a relatively stable 823 policy enforcement table on their nodes. 825 8. IANA Considerations 827 This document does not include an IANA request. 829 9. Security Considerations 831 In the APN work, in order to reduce the privacy and security issues, 832 the following specifications are defined: 834 [S1]. The APN attribute MUST be conveyed along with the tunnel 835 information in the APN domain. The APN attribute is encapsulated and 836 removed at the APN-Edge. 838 [S2]. The APN ID (including the Application Group ID and the User 839 Group ID) MUST be acquired from the existing available information in 840 the packet header without interference into the payload. 842 According to the above specifications, the APN attribute is only 843 produced and used locally within the APN domain without the 844 involvement of the host/application side. 846 In order to prevent the malicious attack through the APN attribute, 847 the following policies can be configured at the network devices of 848 the APN domain: 850 [P1]. If the APN attribute is conveyed without the tunnel 851 information, the packet MUST be dropped. 853 [P2]. If the APN attribute is not known to the APN domain, it should 854 trigger the alarm information. The packet can be forwarded without 855 being processed or dropped depending on the local policy. 857 [P3]. If the network service requirements exceed the specification 858 for the specific Application Group ID and/or User Group ID, it should 859 trigger the alarm information. The packet should be discarded to 860 prevent abusing of the resources. 862 [P4]. There should be rate-limiting policy at the APN-Edge to 863 prevent the traffic belonging to a specific Application Group ID and/ 864 or User Group ID from exceeding the preset limit. 866 10. Acknowledgements 868 The authors would like to acknowledge Robert Raszuk (Bloomberg LP), 869 and Yukito Ueno (NTT Communications Corporation) for their valuable 870 reviews and comments. 872 11. Contributors 874 Daniel Bernier 875 Bell Canada 877 Email: daniel.bernier@bell.ca 879 Chongfeng Xie 880 China Telecom 882 Email: xiechf@chinatelecom.cn 884 Feng Yang 885 China Mobile 886 Email: yangfeng@chinamobile.com 888 Zhuangzhuang Qin 889 China Unicom 891 Email: qinzhuangzhuang@chinaunicom.cn 893 Chang Liu 894 China Unicom 896 Email: liuc131@chinaunicom.cn 898 Gyan Mishra 899 Verizon 901 Email: hayabusagsm@gmail.com 903 Luis M. Contreras 904 Telefonica 906 Email: contreras.ietf@gmail.com 908 Luc-Fabrice Ndifor Ngwa 909 MTN 911 Email: Luc-Fabrice.Ndifor@mtn.com 913 12. References 915 12.1. Normative References 917 [I-D.li-apn-problem-statement-usecases] 918 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 919 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 920 "Problem Statement and Use Cases of Application-aware 921 Networking (APN)", draft-li-apn-problem-statement- 922 usecases-04 (work in progress), June 2021. 924 [I-D.peng-apn-security-privacy-consideration] 925 Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, 926 "APN Security and Privacy Considerations", draft-peng-apn- 927 security-privacy-consideration-02 (work in progress), June 928 2021. 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, 932 DOI 10.17487/RFC2119, March 1997, 933 . 935 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 936 Chaining (SFC) Architecture", RFC 7665, 937 DOI 10.17487/RFC7665, October 2015, 938 . 940 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 941 (IPv6) Specification", STD 86, RFC 8200, 942 DOI 10.17487/RFC8200, July 2017, 943 . 945 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 946 RFC 8578, DOI 10.17487/RFC8578, May 2019, 947 . 949 12.2. Informative References 951 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 952 Xiao, "Overview and Principles of Internet Traffic 953 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 954 . 956 Authors' Addresses 958 Zhenbin Li 959 Huawei Technologies 960 China 962 Email: lizhenbin@huawei.com 964 Shuping Peng 965 Huawei Technologies 966 China 968 Email: pengshuping@huawei.com 970 Daniel Voyer 971 Bell Canada 972 Canada 974 Email: daniel.voyer@bell.ca 975 Cong Li 976 China Telecom 977 China 979 Email: licong@chinatelecom.cn 981 Peng Liu 982 China Mobile 983 China 985 Email: liupengyjy@chinamobile.com 987 Chang Cao 988 China Unicom 989 China 991 Email: caoc15@chinaunicom.cn 993 Gyan Mishra 994 Verizon Inc. 995 USA 997 Email: gyan.s.mishra@verizon.com 999 Kentaro Ebisawa 1000 Toyota Motor Corporation 1001 Japan 1003 Email: ebisawa@toyota-tokyo.tech 1005 Stefano Previdi 1006 Huawei Technologies 1007 Italy 1009 Email: stefano@previdi.net 1011 James N Guichard 1012 Futurewei Technologies Ltd. 1013 USA 1015 Email: jguichar@futurewei.com