idnits 2.17.1 draft-dong-teas-enhanced-vpn-vtn-scalability-02.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 (February 22, 2021) is 1157 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-01 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: August 26, 2021 F. Qin 6 China Mobile 7 G. Yang 8 China Telecom 9 J. Guichard 10 Futurewei Technologies 11 February 22, 2021 13 Scalability Considerations for Enhanced VPN (VPN+) 14 draft-dong-teas-enhanced-vpn-vtn-scalability-02 16 Abstract 18 Enhanced VPN (VPN+) aims to provide enhancements to existing VPN 19 services to support the needs of new applications, particularly 20 including the applications that are associated with 5G services. 21 VPN+ could be used to provide network slicing, and may also be of use 22 in more generic scenarios, such as enterprise services which have 23 demanding requirement. With the requirement for VPN+ services 24 increase, scalability would become an important factor for the 25 deployment of VPN+. This document describes the scalability 26 considerations in the control plane and data plane to enable VPN+ 27 services, some optimization mechanisms are also described. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 26, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. VPN+ Scalability Requirements . . . . . . . . . . . . . . . . 3 65 3. VPN+ Scalability Considerations . . . . . . . . . . . . . . . 5 66 3.1. Control Plane Scalability . . . . . . . . . . . . . . . . 5 67 3.1.1. Distributed Control Plane . . . . . . . . . . . . . . 5 68 3.1.2. Centralized Control Plane . . . . . . . . . . . . . . 6 69 3.2. Data Plane Scalability . . . . . . . . . . . . . . . . . 6 70 3.3. Gap Analysis of Existing Mechanisms . . . . . . . . . . . 7 71 4. Possible Scalability Optimizations . . . . . . . . . . . . . 7 72 4.1. Control Plane Optimizations . . . . . . . . . . . . . . . 7 73 4.2. Data Plane Optimizations . . . . . . . . . . . . . . . . 9 74 5. Solution Evolution for Improved Scalability . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 10. Informative References . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Virtual Private Networks (VPNs) have served the industry well as a 85 means of providing different groups of users with logically isolated 86 connectivity over a common network infrastructure. The VPN service 87 is provided with two network layers: the overlay and the underlay. 88 The underlay is responsible for establishing network connectivity and 89 managing network resources to meet the service requirement. The 90 overlay is used to distribute the membership and reachability 91 information of the tenants, and provide logical separation of service 92 delivery between different tenants. 94 Enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is targeted 95 at new applications which require better isolation between tenants 96 and/or services, and have more stringent performance requirements 97 than can be provided with existing VPNs. To meet the requirement of 98 VPN+ services, Virtual Transport Networks (VTN) need to be created, 99 each has a subset of the underlay network topology and a set of 100 network resources allocated to meet the requirements of one or a 101 group of VPN+ services. The VPN together with the corresponding VTN 102 in the underlay provide the VPN+ service. 104 [I-D.ietf-teas-enhanced-vpn] provides some general analysis of the 105 scalability of VPN+. This document gives detailed analysis of the 106 scalability considerations when enabling VPN+ services. The focus of 107 this document is mainly on the scalability of the underlay of VPN+, 108 i.e. the VTN. 110 2. VPN+ Scalability Requirements 112 As described in [I-D.ietf-teas-enhanced-vpn], VPN+ services may 113 require additional state to be introduced into the network to take 114 advantage of the enhanced functionality. This introduces some 115 scalability considerations to the network. This section gives some 116 analysis of the number of VPN+ services that might be needed in a 117 network. 119 There are several use cases where VPN+ may be needed, and these 120 determine how many VPN+ will be required in a network. One typical 121 use case of VPN+ is to deliver IETF network slice 122 [I-D.ietf-teas-ietf-network-slice-definition] for applications or 123 services in 5G and other scenarios, thus the number of IETF network 124 slices needed could reflect the number of VPN+ services. With the 125 development and evolution of 5G, it is expected that more and more 126 network slices will be deployed. The number of network slices 127 required is relevant to how network slicing will be used, and the 128 progress of 5G for the vertical industrial services. The potential 129 number of network slices is analyzed by classifying the network 130 slicing deployment into three typical scenarios: 132 1. Network slicing can be used by a network operator internally to 133 isolate different types of services. For example, in a converged 134 multi-service network, different network slices can be created to 135 carry mobile transport service, fixed broadband service and 136 enterprise services respectively, each type of service could be 137 managed by a separate department or management team. Some 138 service types, such as multicast service may also be deployed in 139 a dedicated network slice. It is also possible that an 140 infrastructure network operator provides network slices to other 141 network operators as a wholesale service. In this scenario, the 142 number of network slices in a network would be relatively small, 143 such as on the order of 10 or so. This could be the typical case 144 in the beginning of the network slicing deployment. 146 2. Network slicing can be used to provide isolated and customized 147 virtual networks for tenants in different vertical industries. 148 At the early stage of the vertical industrial service deployment, 149 a few top tenants in some typical industries will begin to use 150 network slicing to support their business, such as smart grid, 151 manufacturing, public safety, on-line gaming, etc. Considering 152 the number of the vertical industries, and the number of top 153 tenants in each industry, the number of network slices may 154 increase to the order of 100. 156 3. With the evolution of 5G, network slicing could be widely used by 157 both vertical industrial tenants and enterprise tenants which 158 require guaranteed or predictable service performance. The total 159 amount of network slices may increase to the order of 1000 or 160 more. However, it is expected that the number of network slices 161 would still be less than the number of traditional VPN services 162 in the network. 164 In 3GPP [TS23501], a 5G network slice is identified using Single 165 Network Slice Selection Assistance Information (S-NSSAI), which is a 166 32-bit identifier comprised of 8-bit Slice/Service Type (SST) and 167 24-bit Slice Differentiator (SD). This allows the mobile networks 168 (RAN and CN) to provide a large number of network slices. Although 169 it is possible that multiple network slices in RAN and CN can be 170 mapped to the same IETF network slice, the number of IETF network 171 slices may still be comparable with the number of 5G network slices. 172 Thus the scalability of IETF network slices needs to be taken into 173 consideration. 175 8-bit 24-bit 176 +------------+-------------------------+ 177 | SST | Slice Differentiator | 178 +------------+-------------------------+ 180 Figure 1. Format of S-NSSAI in 3GPP 182 VPN+ needs to meet the scalability requirement of network slicing in 183 different scenarios. The increased number of VPN+ will introduce 184 additional complexity and overhead to both the control plane and data 185 plane, especially in the aspects related to the underlying VTNs. 186 Although multiple VPN+ services can be mapped to the same VTN as the 187 underlay, there still can be scalability challenges with the 188 increased number of VTNs. 190 3. VPN+ Scalability Considerations 192 In this section, the scalability in the control plane and data plane 193 is analyzed to understand the possible gaps in meeting the 194 scalability requirement of VPN+. 196 3.1. Control Plane Scalability 198 As described in [I-D.ietf-teas-enhanced-vpn], the control plane of 199 VPN+ could be based on the hybrid of a centralized controller and the 200 distributed control plane. 202 3.1.1. Distributed Control Plane 204 At part of the construction of VPN+ services, it is necessary to 205 create different VTNs that provide customized topology and resource 206 attributes. The attributes and state information of each VTN needs 207 to be exchanged in the control plane. The scalability of the 208 distributed control plane for the establishment and maintenance of 209 VTNs needs to be considered in the following aspects: 211 o The number of control protocol instances maintained on each node 213 o The number of protocol sessions maintained on each link 215 o The number of routes advertised by each node 217 o The amount of attributes associated with each route 219 o The number of route computation (i.e. SPF computation) executed 220 on each node 222 As the number of VTNs increases, it is expected that for some of the 223 above aspects, the overhead in the control plane may increase 224 dramatically. For example, the overhead of maintaining separated 225 control protocol instances (e.g. IGP instances) for different VTNs 226 is considered higher than maintaining the information of separated 227 VTNs in the same control protocol instance, and the overhead of 228 maintaining separate protocol sessions for different VTNs is 229 considered higher than using a shared protocol session for the 230 information exchange of multiple VTNs. To meet the requirement of 231 the increasing number of VTNs, It is suggested to choose the control 232 plane mechanisms which could improve the scalability while still 233 provide the required functionality. 235 3.1.2. Centralized Control Plane 237 Although the SDN approach can reduce the amount of control plane 238 overhead in the distributed control plane, it may transfer some of 239 the scalability concerns from network nodes to the centralized 240 controller, thus the scalability of the controller also needs to be 241 considered. 243 To provide global optimization for the Traffic Engineered (TE) paths 244 in different VTNs, the controller needs to keep the topology and 245 resource information of all the VTNs up to date. To achieve this, 246 the controller may need to maintain a communication channel with each 247 network node in the network. When there is significant change in the 248 network, or multiple VTNs requires global optimization concurrently, 249 there may be a heavy processing burden at the controller, and a heavy 250 load in the network surrounding the controller for the distribution 251 of the updated network state. 253 3.2. Data Plane Scalability 255 To provide different VPN+ services with the required isolation and 256 performance characteristics, it is necessary to allocate different 257 sets of network resources to different VTNs. As the number of VPN+ 258 increases, the number of VTNs will increase accordingly. This 259 requires the underlying network to provide finer-granular network 260 resource partitioning, which means the amount of state about the 261 reserved network resources to be maintained on network nodes will 262 also increase. 264 In data plane, traffic of different VPN+ services need to be 265 processed separately according to the topology and resource 266 constraints of the associated VTN , thus the identifier of VTN needs 267 to be carried either directly or implicitly in the data packet. 268 Different representations of the VTN information in data packet can 269 have different scalability implications. 271 One approach is to reuse some existing fields in the data packet to 272 additionally identify the VTN the packet belongs to. This avoids the 273 cost of defining new fields in the data packet, while since it 274 introduces additional semantics to an existing field, it may change 275 the processing of the existing field in packet forwarding. To 276 distinguish different VTNs, the number of identifiers which were used 277 to identify a node or link may be increased in proportion to the 278 number of the VTNs, which may cause scalability problem in some 279 networks. 281 An alternative approach is to introduce a dedicated field in the 282 packet for VTN identification. This could avoid the impact to the 283 existing fields in the packet. And if this new field carries a 284 global-significant VTN identifier, it could be used together with the 285 existing fields to determine the VTN-specific packet forwarding. The 286 potential issue with this approach is the difficulty in introducing a 287 new field in some types of the data plane. 289 In addition, the introduction of per VTN packet forwarding has impact 290 on the scalability of the forwarding entries on network nodes, as a 291 network node needs to maintain separate forwarding entries for a 292 target node in each VTN it participates. 294 3.3. Gap Analysis of Existing Mechanisms 296 One candidate approach to build VTN is to use Segment Routing (either 297 SR-MPLS or SRv6) as the data plane, and define and distribute the 298 customized topology and resource attribute of each VTN based on 299 Multi-topology [RFC4915] [RFC5120], Flex-Algo 300 [I-D.ietf-lsr-flex-algo] or the combination of these mechanisms in 301 the control plane. As the number of VTNs increases, there may be 302 several scalability concerns with this approach: 304 1. The number of SR SIDs needed will increase dependent upon the 305 number of VTNs in the network, which will bring challenges both 306 to the SID information distribution in the control plane and to 307 the installation of forwarding entries for the SIDs in data 308 plane. 310 2. The number of SPF computation will increase in proportion to the 311 number of VTNs in the network, which can introduce significant 312 overhead of the computing resources on network nodes. 314 3. The maximum number of network topology supported by OSPF Multi- 315 topology is 128, and the maximum number of Flex-Algo is 128, 316 which may not meet the required number of VTNs in some networks. 318 4. Possible Scalability Optimizations 320 4.1. Control Plane Optimizations 322 For the distributed control plane, several optimizations can be 323 considered to reduce the overhead and improve the scalability. 325 The first optimization mechanism is to reduce the amount of control 326 plane sessions used for the establishment and maintenance of the 327 VTNs. For multiple VTNs which have the same peering relationship 328 between two adjacent network nodes, it is proposed that one single 329 control session is used for the establishment of multiple VTNs. 330 Information of different VTNs can be exchanged over the same control 331 session, with necessary identification information to distinguish 332 them in the control messages. This could reduce the overhead of 333 maintaining a large number of control protocol sessions, and could 334 also reduce the amount of control plane message flooding in the 335 network. 337 The second optimization mechanism is to decompose the attributes of a 338 VTN into different groups, so that different types of attribute can 339 be advertised and processed separately in control plane. For a VTN, 340 there are two basic types of attributes: the topology attribute and 341 the associated network resource attribute. In a network, it is 342 possible that multiple VTNs share the same topology, and multiple 343 VTNs may share the same set of network resource on particular network 344 segments. It is more efficient if only one copy of the topology 345 attribute is advertised, then multiple VTNs sharing the same topology 346 could refer to the topology information. More importantly, the 347 result of topology-based route computation could be shared by these 348 VTNs, so that the overhead of per-VTN route computation could be 349 reduced. Similarly, information of a subset of network resources 350 reserved on network segments could be advertised once and then be 351 used by multiple VTNs. This methodology could also apply to other 352 attributes of VTN which may be introduced later and can be processed 353 independently. 355 O#####O#####O O*****O*****O 356 # # # * * * 357 # # # * * * 358 O#####O#####O O*****O*****O 360 VTN-1 VTN-2 362 O-----O-----O 363 | | | 364 | | | 365 O-----O-----O 367 Shared Network Topology 369 Legend 371 O Virtual node 372 ### Virtual links with a set of reserved resources 373 *** Virtual links with another set of reserved resources 375 Figure 2. Topology Sharing between VTNs 377 FIG-2 379 Figure 2 gives an example of multiple VTNs which share the same 380 topology attribute. As shown in the figure, VTN-1 and VTN-2 have the 381 same topology, while the link resource attributes of each VTN are 382 different. In this case, only one copy of the network topology 383 information needs to be advertised, and the topology-based route 384 computation result can be used by both VTNs to generate the routing 385 tables. 387 O#####O#####O O- -O#####O 388 # # # \/ # # 389 # # # /\ # # 390 O#####O#####O O- -O#####O 392 VTN-1 VTN-2 394 Legend 396 O Virtual node 397 ### Virtual links with a set of reserved resource 398 --- Virtual links with another set of reserved resource 400 Figure 3. Resource Sharing between VTNs 402 Figure 3 gives another example of multiple VTNs which shares the same 403 set of network resources on some links. In this case, information 404 about the reserved resource on each link only needs to be advertised 405 once, then both VTN-1 and VTN-2 could refer to the link resource for 406 constraint based path computation. 408 For the centralized control plane, it is suggested that the 409 centralized controller is deployed as a complementary mechanism to 410 the distributed control plane rather than a replacement, so that the 411 VTN specific path computation burden in control plane could be shared 412 by both the centralized controller and the network nodes, thus the 413 scalability of both systems could be improved. 415 4.2. Data Plane Optimizations 417 To support more VPN+ services while keeping the amount of data plane 418 state at a reasonable scale, one possible approach is to classify a 419 set of VPN+ services which have similar service characteristics and 420 performance requirements into a group, and such group of VPN+ is 421 mapped to one VTN, which is allocated with an aggregated set of 422 network topology and resources to meet the service requirement of the 423 whole group of VPN+. Different groups of VPN+ need to be mapped to 424 different VTNs with different set of network resources allocated. 425 With appropriate grouping of VPN+ services, a reasonable number of 426 VTNs with network resources reservation and aggregation could still 427 meet the service requirements. 429 Another optimization in the data plane is to decouple the identifier 430 used for topology-based forwarding and the identifier used for the 431 resource-specific processing introduced by VTN. One possible 432 mechanism is to introduce a dedicated field in the packet header to 433 uniquely identify the set of local network resources allocated to a 434 VTN on each network node for the processing and forwarding of the 435 received packet. Then the existing identifier in the packet header 436 used for topology based forwarding is kept unchanged. The benefit is 437 the number of existing topology-specific identifiers will only 438 increase in proportion to the number of topologies rather than the 439 number of VTNs, so that its scalability will not be impacted by the 440 increase of VTN. Since this new VTN field will be used together with 441 the existing fields to determine the VTN-specific packet forwarding, 442 this probably requires network nodes to support a hierarchical 443 forwarding table in the data plane. Figure 4 shows the concept of 444 using different data plane identifiers for topology-based and VTN 445 resource-based packet processing respectively. 447 +--------------------------+ 448 | Packet Header | 449 | | 450 | +----------------------+ | 451 | | Topology-specific ID | | 452 | +----------------------+ | 453 | | 454 | +----------------------+ | 455 | | VTN Resource ID | | 456 | +----------------------+ | 457 +--------------------------+ 459 Figure 4. Decoupled Data Plane Identifiers 461 In an IPv6 [RFC8200] based network, this could be achieved by 462 introducing a dedicated field in either the IPv6 fixed header or one 463 of the extension headers to carry the VTN identifier for the 464 resource-specific forwarding, while keeping the destination IP 465 address field used for routing towards the destination prefix in the 466 corresponding topology. Note that the VTN ID needs to be parsed by 467 every node along the path which is capable of VTN-specific 468 forwarding. In an MPLS [RFC3032] based network, this may be achieved 469 by introducing a dedicated MPLS label to identify the VTN instance, 470 while the existing MPLS labels could be used for topology-based 471 packet forwarding towards the associated destination prefix. This 472 requires that both labels be parsed by each node along the forwarding 473 path of the packet. Another option with MPLS data plane is to 474 introduce a new VTN header which follows the MPLS label stack. The 475 detailed extensions in IPv6 and MPLS encapsulation are out of the 476 scope of this document. 478 5. Solution Evolution for Improved Scalability 480 Based on the analysis in this document, the control plane and data 481 plane for VPN+ needs to evolve to support the increasing number of 482 VPN+ services in the network. 484 As the first step, by introducing resource-awareness to segment 485 routing SIDs [I-D.ietf-spring-resource-aware-segments], and using 486 Multi-Topology or Flex-Algo as the control plane, it could provide a 487 solution for building a limited number of VTNs in the network to meet 488 the requirement of a small number of VPN+ services in the network. 489 This mechanism is considered as the basic SR VTN. 491 As the number of required VPN+ services increases, more VTNs may need 492 to be created, then the control plane scalability could be improved 493 by decoupling the topology attribute from other attributes (e.g. 494 resource attribute) of VTN, so that multiple VTNs could share the 495 same topology or resource attribute. This mechanism is considered as 496 the optimized SR VTN. Both the basic and the optimized SR VTN 497 mechanisms are described in [I-D.ietf-spring-sr-for-enhanced-vpn]. 499 If the data plane scalability becomes a concern, dedicated data plane 500 VTN identifiers can be introduced to decouple the topology-specific 501 identifiers from the VTN-specific resource identifier in the data 502 plane, this could help to reduce the number of SR SIDs needed to 503 support . This mechanism is considered as resource-independent VTNs. 505 6. Security Considerations 507 TBD 509 7. IANA Considerations 511 This document makes no request of IANA. 513 8. Contributors 515 Zhibo Hu 516 Email: huzhibo@huawei.com 518 9. Acknowledgments 520 The authors would like to thank Adrian Farrel for the review and 521 discussion of this document. 523 10. Informative References 525 [I-D.ietf-lsr-flex-algo] 526 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 527 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 528 algo-13 (work in progress), October 2020. 530 [I-D.ietf-spring-resource-aware-segments] 531 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 532 Z., and F. Clad, "Introducing Resource Awareness to SR 533 Segments", draft-ietf-spring-resource-aware-segments-01 534 (work in progress), January 2021. 536 [I-D.ietf-spring-sr-for-enhanced-vpn] 537 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 538 Z., and F. Clad, "Segment Routing based Virtual Transport 539 Network (VTN) for Enhanced VPN", February 2021, 540 . 543 [I-D.ietf-teas-enhanced-vpn] 544 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 545 Framework for Enhanced Virtual Private Networks (VPN+) 546 Service", draft-ietf-teas-enhanced-vpn-06 (work in 547 progress), July 2020. 549 [I-D.ietf-teas-ietf-network-slice-definition] 550 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 551 Tantsura, "Definition of IETF Network Slices", draft-ietf- 552 teas-ietf-network-slice-definition-00 (work in progress), 553 January 2021. 555 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 556 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 557 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 558 . 560 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 561 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 562 RFC 4915, DOI 10.17487/RFC4915, June 2007, 563 . 565 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 566 Topology (MT) Routing in Intermediate System to 567 Intermediate Systems (IS-ISs)", RFC 5120, 568 DOI 10.17487/RFC5120, February 2008, 569 . 571 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 572 (IPv6) Specification", STD 86, RFC 8200, 573 DOI 10.17487/RFC8200, July 2017, 574 . 576 [TS23501] "3GPP TS23.501", 2016, 577 . 580 Authors' Addresses 582 Jie Dong 583 Huawei Technologies 584 Huawei Campus, No. 156 Beiqing Road 585 Beijing 100095 586 China 588 Email: jie.dong@huawei.com 590 Zhenbin Li 591 Huawei Technologies 592 Huawei Campus, No. 156 Beiqing Road 593 Beijing 100095 594 China 596 Email: lizhenbin@huawei.com 598 Fengwei Qin 599 China Mobile 600 No. 32 Xuanwumenxi Ave., Xicheng District 601 Beijing 602 China 604 Email: qinfengwei@chinamobile.com 605 Guangming Yang 606 China Telecom 607 No.109 West Zhongshan Ave., Tianhe District 608 Guangzhou 609 China 611 Email: yangguangm@chinatelecom.cn 613 James N Guichard 614 Futurewei Technologies 615 2330 Central Express Way 616 Santa Clara 617 USA 619 Email: james.n.guichard@futurewei.com