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