idnits 2.17.00 (12 Aug 2021) /tmp/idnits11662/draft-li-apn-framework-05.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 document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 7, 2022) is 68 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 837, but not defined == Missing Reference: 'S2' is mentioned on line 841, but not defined == Missing Reference: 'P1' is mentioned on line 853, but not defined == Missing Reference: 'P2' is mentioned on line 856, but not defined == Missing Reference: 'P3' is mentioned on line 860, but not defined == Missing Reference: 'P4' is mentioned on line 865, but not defined == Unused Reference: 'RFC8200' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC8578' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'I-D.peng-apn-security-privacy-consideration' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 978, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8578 ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-06) exists of draft-li-apn-problem-statement-usecases-05 ** Downref: Normative reference to an Informational draft: draft-peng-apn-security-privacy-consideration (ref. 'I-D.peng-apn-security-privacy-consideration') Summary: 4 errors (**), 0 flaws (~~), 13 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: September 8, 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 March 7, 2022 17 Application-aware Networking (APN) Framework 18 draft-li-apn-framework-05 20 Abstract 22 A multitude of applications are carried over the network, which have 23 varying needs for network bandwidth, latency, jitter, and packet 24 loss, etc. Some new emerging applications have very demanding 25 performance requirements. However, in current networks, the network 26 and applications are decoupled, that is, the network is not aware of 27 the applications' requirements in a fine granularity. Therefore, it 28 is difficult to provide truly fine-granularity traffic operations for 29 the applications and guarantee their SLA requirements. 31 This document proposes a new framework, named Application-aware 32 Networking (APN), where application-aware information (i.e. APN 33 attribute) including APN identification (ID) and/or APN parameters 34 (e.g. network performance requirements) is encapsulated at network 35 edge devices and carried in packets traversing an APN domain in order 36 to facilitate service provisioning, perform fine-granularity traffic 37 steering and network resource adjustment. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 8, 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. APN Framework and Key Components . . . . . . . . . . . . . . 4 77 5. APN Requirements . . . . . . . . . . . . . . . . . . . . . . 6 78 5.1. APN Attribute Conveying Requirements . . . . . . . . . . 6 79 5.1.1. Protocol Extensions Requirements . . . . . . . . . . 8 80 5.2. APN attribute Handling Requirements . . . . . . . . . . . 9 81 5.2.1. Fine granular SLA Guarantee . . . . . . . . . . . . . 9 82 5.2.2. Fine granular network slicing . . . . . . . . . . . . 10 83 5.2.3. Fine granular deterministic networking . . . . . . . 11 84 5.2.4. Fine granular service function chaining . . . . . . . 11 85 5.2.5. Fine granular network measurement . . . . . . . . . . 12 86 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6.1. Example use case description . . . . . . . . . . . . . . 12 88 6.2. User Group and Application Group Design . . . . . . . . . 13 89 6.3. Derive the User Group and User Group at APN Edge . . . . 15 90 6.4. Access Right Check at the edge of the backbone network . 15 91 6.5. SLA Guarantee in the backbone network . . . . . . . . . . 16 92 6.5.1. Network Measurement . . . . . . . . . . . . . . . . . 16 93 6.5.2. Traffic Steering . . . . . . . . . . . . . . . . . . 17 94 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 98 11. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 102 13.2. Informative References . . . . . . . . . . . . . . . . . 21 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 105 1. Introduction 107 A multitude of applications are carried over the network, which have 108 varying needs for network bandwidth, latency, jitter, and packet 109 loss, etc. Some applications such as online gaming and live video 110 streaming have very demanding network requirements and therefore 111 require special treatment in the network. However, in current 112 networks, the network and applications are decoupled, that is, the 113 network is not aware of the applications' requirements in a fine 114 granularity. Therefore, it is difficult to provide truly fine- 115 granularity traffic operations for the applications and guarantee 116 their SLA requirements accordingly. 117 [I-D.li-apn-problem-statement-usecases] describes the challenges of 118 traditional differentiated service provisioning methods, such as five 119 tuples used for ACL/PBR causing coarse granularity as well as 120 orchestration and SDN-based solution causing long control loops. 122 This document proposes a new framework, named Application-aware 123 Networking (APN), where application-aware information (APN attribute) 124 including application-aware identification (APN ID) and application- 125 aware parameters (APN Parameters), is encapsulated at network edge 126 devices and carried along with the encapsulation of the tunnel that 127 is used by the packet to traverse the APN domain. The APN attribute 128 will facilitate service provisioning and provide fine-granularity 129 services in the APN domain. 131 The APN attribute is acquired based on the existing information in 132 the packet header (i.e. source and destination addresses, incoming L2 133 (or) MPLS encapsulation, incoming physical/virtual port information, 134 the other fields of the 5-tuple if they are not encrypted) at the 135 edge devices of the APN domain, added to the data packets along with 136 the tunnel encapsulation, delivered within the network, and removed 137 when the packets leave the domain together with the tunnel 138 encapsulation. 140 APN aims to apply various policies in different nodes along a network 141 path onto a traffic flow altogether, for example, at the headend to 142 steer into corresponding path, at the midpoint to collect 143 corresponding performance measurement data, and at the service 144 function to execute particular policies. 146 APN is only applied to an edge-to-edge tunnel encapsulation within a 147 limited trusted domain. It means that the source and destination 148 addresses of the packet are the endpoints of the tunnel (i.e. the 149 domain edges), and nothing about the payload source and destination 150 can be deduced, which substantially reduces the privacy concerns. 151 Typically, an APN domain is defined as a Network Operator controlled 152 limited domain (see Figure 1), in which MPLS, VXLAN, SR/SRv6 and 153 other tunnel technologies are adopted to provide network services. 155 2. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 161 appear in all capitals, as shown here. 163 3. Terminology 165 ACL: Access Control List 167 APN: Application-aware Networking 169 APN6: Application-aware Networking for IPv6/SRv6 171 LB: Load Balancing 173 MPLS: Multiprotocol Label Switching 175 PBR: Policy Based Routing 177 QoE: Quality of Experience 179 SDN: Software Defined Networking 181 SLA: Service Level Agreement 183 SR: Segment Routing 185 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), 286 o Application Group ID: identifies an application group of the 287 traffic. 289 o User Group ID: identifies the user group of the traffic. 291 APN ID can be acquired through different ways. In the APN work it 292 MUST be acquired according to the existing available information in 293 the packet header without inspection into the payload. 295 The different combinations of the IDs can be used to provide 296 different granularity of the service provisioning and SLA guarantee 297 for the traffic. 299 The APN parameters are the network performance requirement 300 parameters. The network service requirement can include the 301 following parameters: 303 o Bandwidth: the bandwidth requirement 305 o Latency: the latency requirement 307 o Packet loss ratio: the packet loss ratio requirement 309 o Jitter: the jitter requirement 311 The different combinations of the parameters are for further 312 expressing the more detailed service requirements, conveyed together 313 with the APN ID, which can be used to match to appropriate tunnels/SR 314 Policies and queues that can satisfy these service requirements. 316 APN attribute MUST be encapsulated within tunnels in the network 317 layer. The tunnels include but not limit to MPLS, VxLAN, SR-MPLS, 318 and SRv6. It can be extended according to requirements in the 319 future. 321 [REQ 1a]. APN ID SHOULD include Application Group ID to indicate the 322 application group that the packet belongs to. 324 [REQ 1b]. APN ID SHOULD include User Group ID to indicate the user 325 group that the packet belongs to. 327 [REQ 1c]. APN ID MUST include either Application Group ID or User 328 Group ID. 330 [REQ 1d]. APN ID MUST be acquired from the existing available 331 information of the packet header without interference into the 332 payload. 334 [REQ 1e]. APN parameters is OPTIONAL. 336 [REQ 1f]. APN attribute MUST be carried by the outer tunnel 337 encapsulation. 339 [REQ 1g]. All the nodes along the path SHOULD be able to process the 340 APN attribute if needed. 342 [REQ 1h]. The APN attribute is generated by the APN-Edge though 343 local policy. 345 [REQ 1i]. The APN attribute SHOULD be kept intact when directly 346 copied at the APN-Head and carried in the tunnel encapsulation. 348 [REQ 1j]. The APN attribute MUST be removed along with the tunnel 349 encapsulation by the APN-Edge when the packets leave the APN domain. 351 [REQ 1k]. The APN attribute MUST NOT be encrypted when the APN 352 packet is itself encrypted (e.g., the APN tunnel across the APN 353 domain uses IPsec). 355 5.1.1. Protocol Extensions Requirements 357 The APN attribute is conveyed with the tunnel encapsulation. There 358 are two typical types of tunnels: 360 o MPLS-based tunnel: LDP tunnel, RSVP-TE tunnel, SR-MPLS tunnel or 361 policy, etc. 363 o IPv6-based tunnel: IPv6-based VxLAN tunnel, IPv6-based UDP tunnel, 364 IPv6-based GRE tunnel, SRv6 tunnel or policy, etc. 366 In order to support encapsulation of APN attribute, the MPLS data 367 plane and IPv6 data plane need to be extended. 369 In order to support acquiring the APN attribute according to the 370 existing available information in the packet header, YANG models 371 should be defined to configure the mapping between the application/ 372 user group ID and the existing information in the packet header and 373 configure the corresponding APN attribute for the application/user 374 group. It can also be implemented with protocol extensions such as 375 BGP and PCEP which can advertise the information from the central 376 controller to the APN-Edge. 378 In addition, in the APN domain, the above-mentioned mapping and 379 applying APN parameters may also be advertised from the APN-Edge/APN- 380 Head to other devices or from the network devices to the central 381 controller in the APN domain. IGP extensions or BGP-LS extensions 382 should be introduced to achieve the purposes. 384 [REQ 1-1a] MPLS encapsulation SHOULD be extended to be able to carry 385 the APN attribute for MPLS-based tunnels. 387 [REQ 1-1b] IPv6 encapsulation SHOULD be extended to be able to carry 388 the APN attribute for IPv6-based tunnels. 390 [REQ 1-1c] YANG models SHOULD be defined to implement the mapping 391 between the application/user group ID and the existing available 392 information in the packet header and configure the corresponding APN 393 parameters. 395 [REQ 1-1d] BGP extensions SHOULD be defined to advertise the mapping 396 between the application/user group ID and the existing available 397 information in the packet header and the corresponding APN parameters 398 from the central controller to the APN-Edge in the APN domain. 400 [REQ 1-1e] PCEP extensions SHOULD be defined to advertise the mapping 401 between the application/user group ID and the existing available 402 information in the packet header and the corresponding APN parameters 403 from the central controller to the APN-Edge in the APN domain. 405 [REQ 1-1f] IGP extensions SHOULD be defined to advertise the mapping 406 between the application/user group ID and the existing available 407 information in the packet header and the corresponding APN parameters 408 from the APN-Edge to the network devices in the APN domain. 410 [REQ 1-1g] BGP-LS extensions SHOULD be defined to advertise the 411 mapping between the application/user group ID and the existing 412 available information in the packet header and the corresponding APN 413 parameters from the network devices to the central controller in the 414 APN domain. 416 5.2. APN attribute Handling Requirements 418 The APN Head and APN-Midpoint perform matching operation against the 419 APN attribute, that is, to match IDs and/or service requirements to 420 the corresponding network resources such as tunnels/SR policies and 421 queues. 423 5.2.1. Fine granular SLA Guarantee 425 In order to achieve better Quality of Experience (QoE) of end users 426 and engage customers, the network needs to be able to provide fine- 427 granularity SLA guarantee [I-D.li-apn-problem-statement-usecases]. 429 [REQ 2-1a]. With the APN attribute, the APN-Head SHOULD be able to 430 steer the traffic to the tunnel/SR policy that satisfies the matching 431 operation. 433 [REQ 2-1b]. With the APN attribute, the APN-Head SHOULD be able to 434 trigger the setup of the tunnel/SR policy that satisfies the matching 435 operation. 437 [REQ 2-1c]. With the APN attribute, the APN-Head and APN-Midpoint 438 SHOULD be able to steer the traffic to the queue that satisfies the 439 matching operation. 441 [REQ 2-1d]. With the APN attribute, the APN-Head and APN-Midpoint 442 SHOULD be able to trigger the configuration of the queue that 443 satisfies the matching operation. 445 [REQ 2-1e]. If the tunnels are used to satisfy the performance 446 requirements, the APN-Head SHOULD be able to copy or map the APN 447 attribute conveyed by the packet received from the APN-Edge to the 448 outer tunnel header. 450 [REQ 2-1f]. If the tunnels are used to satisfy the performance 451 requirements and the APN attribute are conveyed along with the outer 452 tunnel, the APN-Endpoint MUST remove the APN attribute along with the 453 outer tunnel. 455 5.2.2. Fine granular network slicing 457 Network slicing provides ways to partition the network infrastructure 458 in either control plane or data plane into multiple network slices 459 that are running in parallel. The resources on each node need to be 460 associated to corresponding slices. 462 APN is to help the operator of a network to steer some of the traffic 463 tagged with an APN attribute to a certain network slice based on the 464 SLA agreement with its customer. 466 [REQ 2-2a]. With the APN attribute, the APN-Head SHOULD be able to 467 steer the traffic to the slice that satisfies the matching operation. 469 [REQ 2-2b]. With the APN attribute, the APN-Midpoint SHOULD be able 470 to associate the traffic to the resources in the slice that satisfies 471 the matching operation. 473 5.2.3. Fine granular deterministic networking 475 Along the path each node needs to provide guaranteed bandwidth, 476 bounded latency, and other properties relevant to the transport of 477 time-sensitive data for the Detnet flows that coexist with the best- 478 effort traffic. 480 APN is to help the operator of a network to steer some of the traffic 481 tagged with an APN attribute to a certain deterministic path based on 482 the SLA agreement with its customer. 484 [REQ 2-3a]. With the APN attribute, the APN-Head SHOULD be able to 485 steer the traffic to the appropriate path that satisfies the matching 486 operation. 488 [REQ 2-3b]. With the APN attribute, the APN-Head SHOULD be able to 489 trigger the setup of the appropriate path that satisfies the matching 490 operation for the Detnet flows. 492 [REQ 2-3c]. With the APN attribute, the APN-Midpoint SHOULD be able 493 to associate the traffic to the resources along the path that 494 satisfies the performance guarantee. 496 [REQ 2-3d]. With the APN attribute, the APN-Midpoint SHOULD be able 497 to reserve the resources for the Detnet flows along the path that 498 satisfies the performance guarantee. 500 5.2.4. Fine granular service function chaining 502 The end-to-end service delivery often needs to go through various 503 service functions, including traditional network service functions 504 such as firewalls, LB as well as new application-specific functions, 505 both physical and virtual. SFC is applicable to both fixed and 506 mobile networks as well as data center networks. 508 APN is to help the operator of a network to steer some of the traffic 509 tagged with an APN attribute to a certain service function chain 510 based on the SLA agreement with its customer. On each service 511 function along the service function chain, the policy can be enforced 512 based on the APN attribute in the outer header. 514 [REQ 2-4a]. With the APN attribute, the App-aware-process devices 515 SHOULD be able to steer the traffic to the appropriate service 516 function. 518 [REQ 2-4b]. The App-aware-process devices including VAS SHOULD be 519 able to process the APN attribute carried in the packets. 521 5.2.5. Fine granular network measurement 523 Network measurement can be used for verifying whether the network 524 performance requirements have been satisfied, as well as locating 525 silent failure and predicting QoE satisfaction, which enables real- 526 time SLA awareness/proactive OAM and potential resource adjustments. 528 APN is to help the operator of a network to trigger performance 529 measurement for the traffic tagged with an APN attribute based on its 530 customer' consent. 532 [REQ 2-5a]. The App-aware-process devices SHOULD be able to perform 533 IOAM based on the APN attribute. 535 [REQ 2-5b]. The network measurement results can be reported based on 536 the APN attribute and verify whether the performance requirements are 537 satisfied. 539 6. Illustration 541 In order to better clarify what APN can enable with the introduced 542 APN attribute compared to the existing network without APN, we 543 illustrate how APN works through an example use case, which is also a 544 typical network service being provisioned nowadays, i.e. the Cloud 545 Leased Line service. In order to make the tunnel description much 546 easier to understand, we use the recent technology in IETF, i.e. 547 SRv6. 549 6.1. Example use case description 551 We take the "SRv6-based Cloud Leased Line Service" as an illustrative 552 example to show how APN is needed and can be beneficial. 554 Enterprises usually buy Cloud Leased Line Service to interconnect 555 their local sites to Cloud. Generally, the Cloud Leased Line Service 556 needs to go across multiple domains which are owned by the same 557 operator and can be controlled by multiple controllers and an 558 orchestrator/super-controller. 560 Due to management reasons, the network information in the 561 intermediate domain cannot be advertised to other domains, so the 562 ingress node cannot set up an appropriate E2E path. In that case, 563 the intermediate domain is treated as a black box, and no fine grain 564 traffic steering and other services can be provisioned. 566 The example of the network to provide the cloud leased lined service 567 reference diagram is shown as the following figure. The network is 568 composed by three network domains including the two metro networks in 569 the City A and City B and the backbone network which connects the two 570 metro networks. The cloud leased line services is provided to the 571 specific enterprise whose branches located in different cities need 572 to access the cloud-based service located in the City B. 574 Domain 1 Domain 2 Domain 3 575 /-------------\ /------------\ /-----------\ 576 +-/-+ City A +-\-+ +-/-+ IPv6 +-\-+ +-/-+ City B +-\-+ 577 Branch---|PE1| |CR1|---|CR2| |CR3|---|CR4| |PE2|--Cloud 578 +-\-+ Metro +-/-+ +-\-+ Backbone +-/-+ +-\-+ Metro +-/-+ 579 \-------------/ \------------/ \-----------/ 581 |<--OSPF/ISIS-->|<-EBGP->|<- IPv6/SRv6 ->|<-EBGP->|<-OSPF/ISIS->| 582 |<----------------------- EBGP VPNv4 Peer --------------------->| 583 |<----------------------- L3VPN over SRv6 --------------------->| 585 Figure 2. Reference diagram for the example use case illustration 587 6.2. User Group and Application Group Design 589 The user groups can be designed as follows: 591 User Group 592 Enterprise A/Branch 1/Office Users 001001001 593 Enterprise A/Branch 1/R&D Users 001001002 594 Enterprise A/Branch 1/IT Users 001001003 595 Enterprise A/Branch 1/VIP Users 001001004 596 Enterprise A/Branch 2/Office Users 001002001 597 Enterprise A/Branch 2/R&D Users 001002002 598 Enterprise A/Branch 2/IT Users 001002003 599 Enterprise A/Branch 2/VIP Users 001002004 600 Enterprise A/Branch 3/Office Users 001003001 601 Enterprise A/Branch 3/R&D Users 001003002 602 Enterprise A/Branch 3/IT Users 001003003 603 Enterprise A/Branch 3/VIP Users 001003004 605 In the IP address design, the IPv6 address blocks allocated to the 606 branches are as follows : 608 IPv6 Address 609 Enterprise A/Branch 1/Office Users 2001:DB8:A:11::/56 610 Enterprise A/Branch 1/R&D Users 2001:DB8:A:12::/56 611 Enterprise A/Branch 1/IT Users 2001:DB8:A:13::/56 612 Enterprise A/Branch 1/VIP Users 2001:DB8:A:1D::/56 613 Enterprise A/Branch 2/Office Users 2001:DB8:A:21::/56 614 Enterprise A/Branch 2/R&D Users 2001:DB8:A:22::/56 615 Enterprise A/Branch 2/IT Users 2001:DB8:A:23::/56 616 Enterprise A/Branch 2/VIP Users 2001:DB8:A:2D::/56 617 Enterprise A/Branch 3/Office Users 2001:DB8:A:31::/ 56 618 Enterprise A/Branch 3/R&D Users 2001:DB8:A:32::/56 619 Enterprise A/Branch 3/IT Users 2001:DB8:A:33::/56 620 Enterprise A/Branch 3/VIP Users 2001:DB8:A:3D::/56 622 The application groups provided by the cloud can be designed as 623 follows: 625 Application Group 626 Enterprise A/Office Audio Applications 101001001 627 Enterprise A/Office Video Applications 101001002 628 Enterprise A/Office Data Applications 101001003 629 Enterprise A/R&D Audio Applications 101002001 630 Enterprise A/R&D Video Applications 101002002 631 Enterprise A/R&D Data Applications 101002003 632 Enterprise A/IT Audio Applications 101003001 633 Enterprise A/IT Video Applications 101003002 634 Enterprise A/IT Data Applications 101003003 636 In the address design, the IPv6 address blocks allocated to the 637 applications of Enterprise A in the cloud is 638 2001:DB8:A1::/48A1::A:/16. The port number can be used to identify 639 different applications. 641 IPv6 Address Port Number 642 Enterprise A/Office Audio Applications 2001:DB8:A1:A1::/64 1718, 1719 643 Enterprise A/Office Video Applications 2001:DB8:A1:A1::/64 5060, 5061 644 Enterprise A/Office Data Applications 2001:DB8:A1:A1::/64 21, 80 645 Enterprise A/R&D Audio Applications 2001:DB8:A1:A2::/64 1718, 1719 646 Enterprise A/R&D Video Applications 2001:DB8:A1:A2::/64 5060, 5061 647 Enterprise A/R&D Data Applications 2001:DB8:A1:A2::/64 21, 80 648 Enterprise A/IT Audio Applications 2001:DB8:A1:A3::/64 1718, 1719 649 Enterprise A/IT Video Applications 2001:DB8:A1:A3::/64 5060, 5061 650 Enterprise A/IT Data Applications 2001:DB8:A1:A3::/64 21, 80 652 6.3. Derive the User Group and User Group at APN Edge 654 The cloud leased line service adopts the SRv6-based L3VPN to traverse 655 the network. The following policy can be applied at the APN edges of 656 the City A1: 658 Match: 659 VPN1 660 Source Address 2001:DB8:A:11::/56 661 Action 662 Set user-group 001001001 664 Match: 665 VPN1 666 destination Address 2001:DB8:A1:A1::/64 667 destination port 1718,1719 668 Action 669 Set app-group 101001001 671 6.4. Access Right Check at the edge of the backbone network 673 The following check can be applied at the edge of the IP backbone 674 network: 676 Match: 677 user-group 001001001 678 app-group 101002001, 101002002, 101002003, 101003001, 101003002, 101003003 679 Action 680 Deny 682 Match: 683 user-group 001001001 684 app-group 101001001, 101001002, 101001003 685 Action 686 Permit 688 The policy means that the office users of the branch 1 can only 689 access the office applications. 691 If the address allocation is changed. For example, one office user 692 of the branch1's IPv6 address is changed to 2001:DB8:A:15::/56 693 because of the mobile office. 695 We only need to add the following policy at the APN edge: 697 Match: 698 VPN1 699 Source Address 2001:DB8:A:15::/56 700 Action 701 Set user-group 001001001 703 The policy in the backbone network which is based on the user group 704 and the application group is not necessary to change. 706 6.5. SLA Guarantee in the backbone network 708 Due to management reasons, the network information in the 709 intermediate domain cannot be advertised to other domains, so the 710 ingress node cannot set up an appropriate TE path, the intermediate 711 domain is treated as a black box and no fine grain traffic steering 712 can be performed. 714 In this case, we consider fine grain traffic steering in Domain 2 on 715 top of the SRv6-based Cloud Leased Line Service for the purpose of 716 SLA Guarantee. 718 6.5.1. Network Measurement 720 In order to guarantee SLA for the VIP users, the following network 721 measurement policy can be applied in the backbone network: 723 Match: 724 User-group 001001004 application group 101001002 725 User-group 001002004 application group 101002002 726 User-group 001003004 application group 101003002 727 Action 728 Apply IOAM 730 The policy is to apply the IOAM as the network measurement for the 731 VIP users of the branches to access the video applications.From the 732 above illustration, there is the following observation: 734 When there is no APN deployed, at CR2, the 5 tuples of the original 735 packets will need to be resolved since they have been encapsulated, 736 and then IOAM can be triggered based on the 5 tuples. This 737 resolution process is costly and consumes a lot of hardware 738 resources. If Domain 3 needs to trigger IOAM, the same resolution 739 process will have to be done at CR4. 741 When there is APN deployed, at CR1, the APN attribute is tagged. 742 When these packets arrive at CR2, only the APN attribute in the outer 743 header will be read out, based on which the IOAM can be triggered in 744 Domain 2. That is, no 5-tuple resolution process is needed at CR2 745 but only checking the APN attribute in the outer header. 747 6.5.2. Traffic Steering 749 If the SLA guarantee of the VIP users accessing the video 750 applications does not satisfy the requirements through the network 751 measurement based on the IOAM, the SRv6 policy can be setup. For 752 example, the SRv6 policy 1 which can satisfy the SLA requirement is 753 set up. Then the following policy can be downloaded to the edge: 755 Match: 756 User-group 001001004 application group 101001002 757 User-group 001002004 application group 101002002 758 User-group 001003004 application group 101003002 759 Action 760 Redirect SRv6 Policy 1 762 The policy is to steer the traffic of the VIP users to the SRv6 763 policy in the backbone to satisfy the requirement . 765 From the above illustration, there is the similar observation as the 766 network measurement: 768 When there is no APN deployed, at CR2, the 5 tuples of the original 769 packets will need to be resolved since they have been encapsulated, 770 and then the traffic can be steered into SRv6 policy 2 based on the 5 771 tuples. This resolution process is costly and consumes a lot of 772 hardware resources. 774 When there is APN deployed, at CR1, the APN attribute is tagged When 775 these packets arrive at CR2, only the APN attribute in the outer 776 header will be read out, based on which the traffic can be steered 777 into SRv6 policy 2 in Domain 2. 779 7. Benefits 781 The APN attribute allows the network devices to only look at one 782 easily-accessible field in the outer header, without having to 783 resolve the 5 tuples of the original packets that are deeply 784 encapsulated in the tunnel encapsulation. 786 The APN attribute allows to simplify the policy control at every 787 policy enforcement point within the network. The APN attribute 788 allows to reducing each matching entry of policy filter since it is 789 only one field and hardware resources are saved. Since APN attribute 790 is relatively stable, it introduces the possibilities of eliminating 791 the "stale" policy filter entries. In most cases, the APN attribute 792 is centralized configured and distributed to all the policy 793 enforcement points, which saves the policy filter configurations per 794 node and simplifies the OM. 796 The structured APN attribute allows to express fine granular service 797 requirements, e.g. MKT-user-group/app-group, RD-user-group/app- 798 group, latency. 800 The structured APN attribute allows to match to the evolving fine 801 granular differentiated network capabilities, e.g. SR policy with 802 low latency and high reliability guaranteed. 804 In a tunnel across multiple domains of the same operator using the 805 APN attribute in the outer header the operator can easily support 806 multiple services not just a single one in a particular domain as 807 illustrated in the usecase illustration section. 809 When there is no APN, to achieve the same, now the operator may have 810 two options: 1. Add all the policy identifiers at the tunnel headend 811 with various further encapsulations and enforce the policies based on 812 them at the intermediate policy enforcement nodes along the tunnel, 813 2. Resolve the original 5 tuples being encapsulated inside the 814 tunnel which will be very costly and sometimes impossible. 816 Moreover, the policy enforcement table in the intermediate policy 817 enforcement nodes is significantly reduced. Because before operator 818 needs to resolve the 5 tuple but now with APN, operator only needs to 819 read the APN attribute in one field of the outer header. 821 Since the 5 tuples of the traffic are changing frequently due to 822 service deployment or management issues the policy enforcement table 823 in the policy enforcement nodes is not stable and there is always a 824 lot of stale entries in the table. But now since the APN attribute 825 is a mapping of the 5 tuples operator will have a relatively stable 826 policy enforcement table on their nodes. 828 8. IANA Considerations 830 This document does not include an IANA request. 832 9. Security Considerations 834 In the APN work, in order to reduce the privacy and security issues, 835 the following specifications are defined: 837 [S1]. The APN attribute MUST be conveyed along with the tunnel 838 information in the APN domain. The APN attribute is encapsulated and 839 removed at the APN-Edge. 841 [S2]. The APN ID (including the Application Group ID and the User 842 Group ID) MUST be acquired from the existing available information in 843 the packet header without interference into the payload. 845 According to the above specifications, the APN attribute is only 846 produced and used locally within the APN domain without the 847 involvement of the host/application side. 849 In order to prevent the malicious attack through the APN attribute, 850 the following policies can be configured at the network devices of 851 the APN domain: 853 [P1]. If the APN attribute is conveyed without the tunnel 854 information, the packet MUST be dropped. 856 [P2]. If the APN attribute is not known to the APN domain, it should 857 trigger the alarm information. The packet can be forwarded without 858 being processed or dropped depending on the local policy. 860 [P3]. If the network service requirements exceed the specification 861 for the specific Application Group ID and/or User Group ID, it should 862 trigger the alarm information. The packet should be discarded to 863 prevent abusing of the resources. 865 [P4]. There should be rate-limiting policy at the APN-Edge to 866 prevent the traffic belonging to a specific Application Group ID and/ 867 or User Group ID from exceeding the preset limit. 869 10. Acknowledgements 871 The authors would like to acknowledge Robert Raszuk (Bloomberg LP), 872 and Yukito Ueno (NTT Communications Corporation) for their valuable 873 reviews and comments. 875 11. Co-authors 877 Kentaro Ebisawa 878 Toyota Motor Corporation 879 Japan 881 Email: ebisawa@toyota-tokyo.tech 883 Stefano Previdi 884 Huawei Technologies 885 Italy 887 Email: stefano@previdi.net 888 James N Guichard 889 Futurewei Technologies Ltd. 890 USA 892 Email: jguichar@futurewei.com 894 12. Contributors 896 Daniel Bernier 897 Bell Canada 899 Email: daniel.bernier@bell.ca 901 Chongfeng Xie 902 China Telecom 904 Email: xiechf@chinatelecom.cn 906 Feng Yang 907 China Mobile 909 Email: yangfeng@chinamobile.com 911 Zhuangzhuang Qin 912 China Unicom 914 Email: qinzhuangzhuang@chinaunicom.cn 916 Chang Liu 917 China Unicom 919 Email: liuc131@chinaunicom.cn 921 Gyan Mishra 922 Verizon 924 Email: hayabusagsm@gmail.com 926 Luis M. Contreras 927 Telefonica 929 Email: contreras.ietf@gmail.com 931 Luc-Fabrice Ndifor Ngwa 932 MTN 934 Email: Luc-Fabrice.Ndifor@mtn.com 936 13. References 938 13.1. Normative References 940 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 941 Requirement Levels", BCP 14, RFC 2119, 942 DOI 10.17487/RFC2119, March 1997, 943 . 945 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 946 (IPv6) Specification", STD 86, RFC 8200, 947 DOI 10.17487/RFC8200, July 2017, 948 . 950 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 951 RFC 8578, DOI 10.17487/RFC8578, May 2019, 952 . 954 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 955 Chaining (SFC) Architecture", RFC 7665, 956 DOI 10.17487/RFC7665, October 2015, 957 . 959 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 960 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 961 May 2017, . 963 [I-D.li-apn-problem-statement-usecases] 964 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 965 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 966 "Problem Statement and Use Cases of Application-aware 967 Networking (APN)", draft-li-apn-problem-statement- 968 usecases-05 (work in progress), December 2021. 970 [I-D.peng-apn-security-privacy-consideration] 971 Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, 972 "APN Security and Privacy Considerations", draft-peng-apn- 973 security-privacy-consideration-02 (work in progress), June 974 2021. 976 13.2. Informative References 978 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 979 Xiao, "Overview and Principles of Internet Traffic 980 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 981 . 983 Authors' Addresses 985 Zhenbin Li 986 Huawei Technologies 987 China 989 EMail: lizhenbin@huawei.com 991 Shuping Peng 992 Huawei Technologies 993 China 995 EMail: pengshuping@huawei.com 997 Daniel Voyer 998 Bell Canada 999 Canada 1001 EMail: daniel.voyer@bell.ca 1003 Cong Li 1004 China Telecom 1005 China 1007 EMail: licong@chinatelecom.cn 1009 Peng Liu 1010 China Mobile 1011 China 1013 EMail: liupengyjy@chinamobile.com 1015 Chang Cao 1016 China Unicom 1017 China 1019 EMail: caoc15@chinaunicom.cn 1020 Gyan Mishra 1021 Verizon Inc. 1022 USA 1024 EMail: gyan.s.mishra@verizon.com