idnits 2.17.00 (12 Aug 2021) /tmp/idnits18998/draft-li-apn-problem-statement-usecases-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The 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) ** Downref: Normative reference to an Informational RFC: RFC 8578 ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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. Xie 8 China Telecom 9 P. Liu 10 China Mobile 11 Z. Qin 12 China Unicom 13 G. Mishra 14 Verizon Inc. 15 March 7, 2022 17 Problem Statement and Use Cases of Application-aware Networking (APN) 18 draft-li-apn-problem-statement-usecases-06 20 Abstract 22 Network operators are facing the challenge of providing better 23 network services for users. As the ever-developing 5G and industrial 24 verticals evolve, more and more services that have diverse network 25 requirements such as ultra-low latency and high reliability are 26 emerging, and therefore differentiated service treatment is desired 27 by users. On the other hand, as network technologies such as 28 Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep 29 evolving, the network has the capability to provide more fine- 30 granularity differentiated services. However, network operators are 31 typically unware of the applications that are traversing their 32 network infrastructure, which means that not very effective 33 differentiated service treatment can be provided to the traffic 34 flows. As network technologies evolve including deployments of IPv6, 35 SRv6, Segment Routing over MPLS dataplane, the programmability 36 provided by IPv6 and Segment Routing can be augmented by conveying 37 application related information into the network satifying the fine- 38 granularity requirements. 40 This document analyzes the existing problems caused by lack of 41 service awareness, and outlines various use cases that could benefit 42 from an Application-aware Networking (APN) framework. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on September 8, 2022. 61 Copyright Notice 63 Copyright (c) 2022 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 81 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 82 4.1. Challenges of lack of fine-granularity service 83 information . . . . . . . . . . . . . . . . . . . . . . . 4 84 4.2. Challenges of Traditional Differentiated Service 85 Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 86 4.3. Challenges of Supporting New 5G and Edge Computing 87 Technologies . . . . . . . . . . . . . . . . . . . . . . 6 88 5. Key Elements of Application-aware Networking (APN) . . . . . 7 89 6. Scenarios of APN Domains . . . . . . . . . . . . . . . . . . 8 90 7. Use cases for Application-aware Networking (APN) . . . . . . 10 91 7.1. Application-aware SLA Guarantee . . . . . . . . . . . . . 10 92 7.2. Application-aware network slicing . . . . . . . . . . . . 11 93 7.3. Application-aware Deterministic Networking . . . . . . . 11 94 7.4. Application-aware Service Function Chaining . . . . . . . 12 95 7.5. Application-aware Network Measurement . . . . . . . . . . 12 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 99 11. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 103 13.2. Informative References . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 Due to the requirement for differentiated traffic treatment driven by 109 diverse new services, the ability to convey the application-aware 110 information and program the network infrastructure accordingly to 111 provide fine-grained services is becoming increasingly necessary for 112 network operators. The Application-aware Networking (APN) framework 113 is being defined to address the requirements and use cases are 114 described in this document. APN takes advantage of network 115 programmability by conveying application related information in the 116 data plane to facilitate network operators to provide fine-grained 117 services. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 125 appear in all capitals, as shown here. 127 3. Terminology 129 ACL: Access Control List 131 APN: Application-aware Networking 133 APN6: Application-aware Networking for IPv6/SRv6 135 DPI: Deep Packet Inspection 137 PBR: Policy Based Routing 139 QoE: Quality of Experience 141 SDN: Software Defined Networking 143 SLA: Service Level Agreement 144 MPLS: Multiprotocol Label Switching 146 SR: Segment Routing 148 SRv6: Segment Routing over IPv6 dataplane 150 SR-MPLS: Segment Routing over MPLS dataplane 152 VPN: Virtual Private Network 154 TE: Traffic Engineering 156 FRR: Fast Reroute 158 CAPEX: Capital expenditures 160 OPEX: Operating expenditures 162 4. Problem Statement 164 This section summarizes the challenges currently faced by network 165 operators when attempting to provide fine-grained traffic operations 166 to satisfy the various requirements demanded by new applications that 167 require differentiated service treatment. 169 4.1. Challenges of lack of fine-granularity service information 171 In today's networks, the infrastructure through which the traffic is 172 forwarded is not able to obtain the fine-granularity service 173 information. It is therefore difficult for network operators to 174 provide fine-grained traffic operations for various performance- 175 demanding applications. In order to satisfy the SLA requirements 176 network operators continue to increase the network bandwidth but only 177 carrying very light traffic load (in general, around 30%-40% of its 178 capacity). 180 As network technologies keep evolving, the network capability has 181 been greatly enhanced and is able to provide fine-granularity service 182 provisioning. For example, 184 H-QoS: provides hierarchical fine-grained QoS services. 186 SR Policy: provides the ability to handle a large number of explicit 187 and flexible SR paths in order for services to select to satisfy 188 their SLA requirements. 190 Network Slicing: provides the ability to define a number of network 191 slices with guaranteed resources to satisfy highly demanding service 192 requirements. 194 IOAM: provides more accurate performance measurement of the traffic 195 flow. 197 In summary, driven by the ever-emerging diverse demanding services, 198 the lack of the fine-granularity information about the services in 199 the network will cause the following issues: 1) the service 200 information is not clearly described and known by the network, 2) the 201 fine-granularity service provisioning capability is not fully 202 utilised, 3) a fine-granularity service scheduling and measurement 203 cannot be achieved. 205 4.2. Challenges of Traditional Differentiated Service Provisioning 207 The traditional ways used to provide fine-grained service 208 provisioning face some challenges. The network devices mainly rely 209 on the 5-tuple of the packets or DPI. However, there are some 210 challenges for these traditional methods in differentiated service 211 provisioning: 213 1. Five Tuples used for ACL/PBR: five tuples are widely used for 214 ACL/PBR matching of traffic. However, these features cannot 215 provide enough information for the fine-grained service process, 216 and can only provide indirect application-level information which 217 needs to be translated. Generally, ACLs involve high overhead on 218 the forwarding process. Moreover, in some cases such as tunnel 219 encapsulation and IPv6 data plane with a list of extension 220 headers, it becomes impossible to resolve the 5 tuples due to the 221 transport layer information being pushed very deep in the packet. 223 2. Deep Packet Inspection (DPI): If more information is needed, it 224 must be extracted using DPI which can inspect deep into the 225 packets for application specific information. However, this will 226 introduce more CAPEX and OPEX for the network operator and impose 227 security and privacy challenges. 229 3. Orchestration and SDN-based Solution: In the era of SDN, 230 typically, an SDN controller is used to manage and operate the 231 network infrastructure and orchestrator elements introduce 232 application requirements so that the network is programmed 233 accordingly. The SDN controller can be aware of the service 234 requirements of the applications on the network through the 235 interface with the orchestrator, and the service requirement is 236 used by the controller for traffic management over the network. 237 However, this method raises the following problems: 239 A. The whole loop is long and time-consuming which is not 240 suitable for fast service provisioning for critical 241 applications; 243 B. Too many interfaces are involved in the loop, as shown in 244 Figure 1, which introduce challenges of standardization and 245 inter-operability. 247 +--------------+ 248 +-----| Orchestrator | -------------------+ 249 | +--------------+ Resource | 250 APP Req. | | Management | 251 +---------+ +---------+ & +---------+ 252 |SDN Ctrl1| |SDN Ctrl2| Service |SDN Ctrl3| 253 +---------+ +---------+ Provisioning +---------+ 254 App Req./ | | \ | \ 255 / | | \ | \ 256 / | | \ | \ 257 +---+ +-----+ +--------+ +-------+ +-------+ +-------+ 258 |APP| | DCN | |Network |..|Network| |Network|..|Network| 259 +---+ +-----+ | D1 | | D3 | | D4 | | D6 | 260 +--------+ +-------+ +-------+ +-------+ 262 Figure 1: Multiple interfaces involved in the long service- 263 provisioning loop 265 In [I-D.peng-apn-scope-gap-analysis], some mechanisms that have been 266 specified in IETF and using attribute/identifier to perform traffic 267 steering and service provisioning are analyzed. The existing 268 solutions are specific to a particular scenario or data plane, and a 269 generalized method used for fine-grained service provisioning is 270 still missing. 272 4.3. Challenges of Supporting New 5G and Edge Computing Technologies 274 New technologies such as 5G, IoT, and edge computing, are 275 continuously developing leading to more and more new types of 276 services accessing the network. Large volumes of network traffic 277 with diverse requirements such as low latency and high reliability 278 are therefore rapidly increasing. If traditional methods for 279 differentiation of traffic continue to be utilized, it will cause 280 much higher CAPEX and OPEX to satisfy the ever-developing 281 applications' diverse requirements. 283 5. Key Elements of Application-aware Networking (APN) 285 Application-aware Networking (APN) aims to address the problems 286 mentioned in Section 4, associated with fine-grained traffic 287 operations that are required in order to satisfy the various 288 application-awareness requirements demanded by new services that need 289 differentiated service treatment. 291 In APN, the application-aware information (APN Attribute) is derived 292 according to the existing information in the packet header and 293 encapsulated along with the encapsulation of the tunnel. With the 294 APN attribute, fine-granularity network services can be provisioned 295 within the APN domain accordingly. The APN attribute can include 296 application-aware ID (APN ID) and application-aware parameters (APN 297 Parameters). APN ID can be derived through the mapping from the 298 existing information of the packet header and the APN parameters can 299 be applied for the APN ID according to the local policy. The typical 300 APN parameters are the network performance requirements. 302 APN has the following key elements: 304 1. Application-aware information (APN attribute) is conveyed in the 305 data plane through augmentation of existing encapsulations such 306 as IPv6, SRv6 and MPLS. The conveyed APN attribute includes APN 307 ID and/or APN parameters. This information is acquired at the 308 edge of the APN domain according to the existing information in 309 the packet header. When a data packet uses APN and conveys the 310 application-aware information, it is referred in this document as 311 an APN packet. 313 2. Application-aware information and network service provisioning 314 matching providing fine-granularity network service provisioning 315 (traffic operations) and SLA guarantee based on the APN attribute 316 carried in APN packets. According to the APN attribute, 317 appropriate network services are selected, provisioned, and 318 provided to the demanding applications to satisfy their service 319 requirements. 321 3. Measurement of the network performance so to maintain the match 322 between the applications requirements and corresponding network 323 services for a better fine-granularity SLA compliance. The 324 network measurement methods include in-band and out-of-band, 325 passive, active, per-packet, per-flow, per node, end-to-end, etc. 326 These methods can also be integrated. 328 APN Network 330 Element 1: Conveying -------------------> 331 /|\ 332 APN attribute | Network capabilities 333 | (SLA guarantee) 334 | /|\ 335 Element 2: Matching | 336 | 337 Element 3: Network Measurement 339 Figure 2: Illustration of the key elements of APN 341 6. Scenarios of APN Domains 343 1. SD-WAN scenario 345 The SD-WAN scenario is shown in the following figure. With APN, at 346 the edge node, i.e. CPE, of the SD-WAN, the 5-tuple, plus information 347 related to user or application group-level requirements is 348 constructed into the APN attribute. When the packet is sent from the 349 CPE, the attribute is added along with the tunnel encapsulation. 350 This attribute is only meaningful for the network operators to apply 351 various policies in different nodes/service functions, which can be 352 enforced from the Controllers. 354 +-----------------+ 355 +---------|SD-WAN Controller|---------+ 356 | +--------|--------+ | 357 | | | 358 | +-------|-------+ | 359 | |SDN Controller| | 360 | +-------|-------+ | 361 +-----+ | | | +-----+ 362 |App x|-\ | | | /-|App x| 363 +-----+ | +--|--+ +-----------|-----------+ +--|--+ | +-----+ 364 \-| | | Application-aware | | |-/ 365 |CPE 1|---| Network |---|CPE 2| 366 /-| | | Service Provisioning | | |-\ 367 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 368 |App y|-/ | | \-|App y| 369 +-----+ |<--- APN Domain --->| +-----+ 371 Figure 2. APN Domain in the Scenario of SD-WAN 373 2. Home broadband scenario 374 In the home broadband scenario, generally a home broadband user is 375 authorized by the BNG. If the validation is passed and the access 376 control is released, so the user group can start enjoying the value- 377 added service. With APN, when the traffic traverses the metro 378 network, the traffic flow can be indicated by the APN attribute that 379 is added/removed at the edge devices of the Metro Network (APN 380 domain) based on the mapping from the existing information (e.g. the 381 QinQ which is composed of C-VLAN and S-VLAN) in the packet header and 382 then carried in the tunnel encapsulation header. The APN attribute 383 will facilitate the fine-granular service in the APN domain. Once 384 the packets leave the APN domain, the APN attribute will be removed 385 together with the tunnel encapsulation header. 387 |---- APN Domain ---| 388 +----+ .-----. 389 | PC | \ ( ) 390 +----+ \--\ .--( )--. 391 +-----+ \+----+ +----+ ( ) +-------+ 392 | STB |----| RG |--| AN |----( Metro Network )-----| BNG |---> 393 +-----+ /+----+ +----+ ( ) +-------+ 394 +-----+ /--/ '--( )--' 395 |Phone|/ ( ) 396 +-----+ '-----' 397 QinQ QinQ 398 |----|---- Tunnel ----|----| 400 Figure 2. Home Broadband Scenario 402 3. Mobile broadband scenario 404 In the mobile broadband scenario, a UE is authorized by the 5GC 405 function, and the traffic steering and QoS policy are enforced by the 406 UPF (User Plane Function) node. If the validation is passed and the 407 access control is released, so the user can start enjoying the value- 408 added service. With APN, when the traffic traverses the mobile 409 transport network, the traffic flow can be indicated by the APN 410 attribute that is added at the edge devices of the mobile transport 411 network (APN domain) based on mapping from the existing information 412 (e.g. GTP-u tunnel encapsulation information) in the packet header 413 and then carried in the tunnel encapsulation header. The APN 414 attribute will facilitate the fine-granular service in the APN 415 domain. Once the packets leave the APN domain, the APN attribute 416 will be removed together with the tunnel encapsulation header. 418 |-- APN Domain ---| 420 +----+ .-----. 421 | PC | ( ) 422 +----+ .--( )--. 423 +----+ +------+ ( ) +-------+ 424 | UE | --- | gNB |------( Mobile Transport )------| UPF |----> 425 +----+ +------+ ( Network ) +-------+ 426 +-----+ '--( )--' 427 | CPE | ( ) 428 +-----+ '-----' 430 |---- Tunnel ----| 432 |--------- GTP-u Tunnel --------| 434 Figure 3. Mobile Broadband Scenario 436 7. Use cases for Application-aware Networking (APN) 438 This section illustrates some of the use cases that can benefit from 439 APN. The corresponding requirements for APN are also outlined. 441 7.1. Application-aware SLA Guarantee 443 One of the key objectives of APN is for network operators to provide 444 fine-granularity SLA guarantees instead of coarse-grain traffic 445 operations. This will allow to provide differentiated services for 446 different applications and increase revenue accordingly. Among 447 various applications being carried and running in the network, some 448 revenue-producing applications such as online gaming, video 449 streaming, and enterprise video conferencing have much more demanding 450 performance requirements such as low network latency and high 451 bandwidth. In order to achieve better Quality of Experience (QoE) 452 for end users and engage customers, the network needs to be able to 453 provide fine-granularity and even application group-level SLA 454 guarantee. Differentiated service provisioning is also desired. 456 The APN architecture MUST address the following requirements: 458 o APN needs to perform the three key elements as described in 459 Section 5. 461 o Support application group-level fine-granularity traffic operation 462 that may include finer QoS scheduling. 464 7.2. Application-aware network slicing 466 More and more applications/services with diverse requirements are 467 being carried over and sharing a common operators' network 468 infrastructure. However, it is still desirable to have customized 469 network transport that can support some applications' specific 470 requirements, taking into consideration service and resource 471 isolation, which drives the concept of network slicing. 473 Network slicing provides ways to partition the network infrastructure 474 in either the control plane or data plane into multiple network 475 slices that are running in parallel. These network slices can serve 476 diverse services and fulfill their various requirements at the same 477 time. For example, the mission critical application that requires 478 ultra-low latency and high reliability can be provisioned over a 479 separate network slice. 481 The APN architecture MUST address the following requirements: 483 o APN needs to perform the three key elements as described in 484 Section 5 in the context of network slicing. 486 o For the element 2, the APN architecture MUST allow to assign a 487 given traffic flow to specific network slice according to the APN 488 attribute carried in the APN packet. 490 o For the element 3, the APN architecture MUST allow the network 491 measurement of each network slice. 493 7.3. Application-aware Deterministic Networking 495 [RFC8578] documents use cases for diverse industry applications that 496 require deterministic flows over multi-hop paths. Deterministic 497 flows provide guaranteed bandwidth, bounded latency, and other 498 properties relevant to the transport of time-sensitive data, and can 499 coexist on an IP network with best-effort traffic. It also provides 500 for highly reliable flows through provision for redundant paths. 502 The APN architecture MUST address the following requirements: 504 o APN needs to perform the three key elements as described in 505 Section 5 in the context of deterministic networking. 507 o For the element 2, the APN architecture MUST allow to assign a 508 given traffic flow to a specific deterministic path according to 509 the APN attribute carried in the APN packet. 511 o For the element 3, the APN architecture MUST allow the network 512 measurement of each application-aware deterministic path. 514 7.4. Application-aware Service Function Chaining 516 End-to-end service delivery often needs to go through various service 517 functions including traditional network service functions such as 518 firewalls, DPIs as well as new application-specific functions, both 519 physical and virtual. The definition and instantiation of an ordered 520 set of service functions and subsequent steering of the traffic 521 through them is called Service Function Chaining (SFC) [RFC7665]. 522 SFC is applicable to both fixed and mobile networks as well as data 523 center networks. 525 Generally, in order to manipulate a specific traffic flow along the 526 SFC, a DPI needs to be deployed as the first service function of the 527 chain to detect the application, which will impose high CAPEX and 528 consume long processing time. For encrypted traffic, it even becomes 529 impossible to inspect the traffic flow. 531 The APN architecture MUST address the following requirements: 533 o APN needs to perform the three key elements as described in 534 Section 5 in the context of service function chaining. 536 o For the element 1, class information can be conveyed. 538 o For the element 2, the APN architecture MUST allow to assign a 539 given traffic flow to a specific service function chain and MUST 540 allow the subsequent steering according to the APN attribute 541 carried in the APN packets. 543 o For the element 3, the APN architecture MUST allow the network 544 measurement of each application-aware service function chain. 546 7.5. Application-aware Network Measurement 548 Network measurement can be used for locating silent failure and 549 predicting QoE satisfaction, which enables real-time SLA awareness/ 550 proactive OAM. Operations, Administration, and Maintenance (OAM) 551 refers to a toolset for fault detection and isolation, and network 552 performance measurement. In-situ Operations, Administration, and 553 Maintenance (IOAM) records operational and telemetry information in 554 the packet while the packet traverses a path between two points in 555 the network. 557 The APN architecture MUST address the following requirements: 559 o APN needs to perform the two key elements as described in 560 Section 5 in the context of network measurement. The network 561 measurement in the element 3 does not need to be considered here. 563 8. IANA Considerations 565 This document does not include an IANA request. 567 9. Security Considerations 569 In the APN work, in order to reduce the privacy and security issues, 570 the APN attribute MUST be conveyed along with the tunnel information 571 in the APN domain. The APN attribute is encapsulated and removed at 572 the edge of the APN domain. The APN ID MUST be acquired from the 573 existing available information in the packet header without 574 interference into the payload. 576 According to the above specifications, the APN attribute is only 577 produced and used locally within the APN domain without the 578 involvement of the host/application side. 580 In order to prevent the malicious attack through the APN attribute, 581 the following policies can be configured at the network devices of 582 the APN domain. If the APN attribute is conveyed without the tunnel 583 information, the packet MUST be dropped. If the APN attributes are 584 not known to the APN domain, it should trigger the alarm information. 585 The packet can be forwarded without being processed or dropped 586 depending on the local policy. If the network service requirements 587 exceed the specification for the specific APN ID, it should trigger 588 the alarm information. The packet should be discarded to prevent 589 abusing of the resources. There should be rate-limiting policy at 590 the edge of the APN domain to prevent the traffic belonging to a 591 specific APN ID from exceeding the preset limit. 593 10. Acknowledgements 595 The authors would like to acknowledge Robert Raszuk (Bloomberg LP) 596 and Yukito Ueno (NTT Communications Corporation) for their valuable 597 review and comments. 599 11. Co-authors 601 Kentaro Ebisawa 602 Toyota Motor Corporation 603 Japan 605 Email: ebisawa@toyota-tokyo.tech 606 Stefano Previdi 607 Huawei Technologies 608 Italy 610 Email: stefano@previdi.net 612 James N Guichard 613 Futurewei Technologies Ltd. 614 USA 616 Email: jguichar@futurewei.com 618 12. Contributors 620 Daniel Bernier 621 Bell Canada 622 Canada 624 Email: daniel.bernier@bell.ca 626 Liang Geng 627 China Mobile 628 China 630 Email: gengliang@chinamobile.com 632 Chang Cao 633 China Unicom 634 China 636 Email: caoc15@chinaunicom.cn 638 Chang Liu 639 China Unicom 640 China 642 Email: liuc131@chinaunicom.cn 644 Cong Li 645 China Telecom 646 China 648 Email: licong@chinatelecom.cn 650 13. References 652 13.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 664 RFC 8578, DOI 10.17487/RFC8578, May 2019, 665 . 667 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 668 Chaining (SFC) Architecture", RFC 7665, 669 DOI 10.17487/RFC7665, October 2015, 670 . 672 13.2. Informative References 674 [I-D.peng-apn-scope-gap-analysis] 675 Peng, S., Li, Z., and G. Mishra, "APN Scope and Gap 676 Analysis", draft-peng-apn-scope-gap-analysis-04 (work in 677 progress), March 2022. 679 Authors' Addresses 681 Zhenbin Li 682 Huawei Technologies 683 China 685 EMail: lizhenbin@huawei.com 687 Shuping Peng 688 Huawei Technologies 689 China 691 EMail: pengshuping@huawei.com 692 Daniel Voyer 693 Bell Canada 694 Canada 696 EMail: daniel.voyer@bell.ca 698 Chongfeng Xie 699 China Telecom 700 China 702 EMail: xiechf@chinatelecom.cn 704 Peng Liu 705 China Mobile 706 China 708 EMail: liupengyjy@chinamobile.com 710 Zhuangzhuang Qin 711 China Unicom 712 China 714 EMail: qinzhuangzhuang@chinaunicom.cn 716 Gyan Mishra 717 Verizon Inc. 718 USA 720 EMail: gyan.s.mishra@verizon.com