Internet-Draft NRP Scalability Considerations December 2021
Dong, et al. Expires 20 June 2022 [Page]
Workgroup:
TEAS Working Group
Internet-Draft:
draft-dong-teas-nrp-scalability-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Dong
Huawei Technologies
Z. Li
Huawei Technologies
L. Gong
China Mobile
G. Yang
China Telecom
J. Guichard
Futurewei Technologies
G. Mishra
Verizon Inc.
F. Qin
China Mobile

Scalability Considerations for Network Resource Partition

Abstract

IETF network slice service aims to meet the connectivity demands of a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. A Network Resource Partition is a set of network resources that are allocated from the underlay network to carry a specific set of network traffic and meet the required SLOs and SLEs. One or multiple IETF network slice services can be mapped to one network resource partition.

With the demand for IETF network slice services increases, scalability would become an important factor for the large scale deployment of IETF network slices. Although the scalability of IETF network slices can be improved by mapping a group of IETF network slices to one network resource partition, there are concerns about the scalability of network resource partitions. This document describes the scalability considerations about network resource partition in the network control plane and data plane, and some optimization mechanisms are proposed.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 June 2022.

▲

Table of Contents

1. Introduction

IETF Network Slice service aims to meet the connectivity demands of a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. [I-D.ietf-teas-ietf-network-slices] defines the terminologies and the characteristics of IETF network slices. It also discusses the general framework, the components and interfaces for requesting and operating IETF network slices. For the realization of IETF network slice services, a concept called network resource partition is introduced, which refers to a set of network resources that are available in the underlay network to carry traffic and meet the SLOs and SLEs.

[I-D.ietf-teas-enhanced-vpn] describes the layered framework and candidate technologies for delivering enhanced VPN (VPN+) services. Enhanced VPN (VPN+) aims to meet the needs of some customers or applications, including the applications that are associated with 5G, which requires connectivity services with advanced characteristics, such as the assurance of Service Level Objectives (SLOs) and specific Service Level Expectations (SLEs). To meet the requirement VPN+ services, Virtual Transport Networks (VTNs) need to be created, each of which has a subset of network resources allocated from the physical underlay network and is associated with a logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. The VPN+ framework and technologies could be used for the realization of IETF network slice services. In the context of IETF network slice, the network resource partition refers to the resource attributes of a VTN.

With the demand for IETF network slice services increases, scalability would become an important factor for the large scale deployment of IETF network slices. Although the scalability of IETF network slices can be improved by mapping a group of IETF network slices to one network resource partition, there are concerns about the scalability of network resource partitions. This document describes the scalability considerations about network resource partition in the network control plane and data plane, and some optimization mechanisms are proposed.

2. Network Resource Partition Scalability Requirements

As described in [I-D.ietf-teas-ietf-network-slices], IETF Network Slices may be grouped together according to characteristics (including SLOs and SLEs). This grouping allows an operator to host a number of slices on a particular set of resources to reduce the amount of state information needed in the network. This can help to avoid the maintenance of per IETF network slice state in the underlay network. The amount of network resource partitions needed in the network depends on the scenarios of IETF network slices.

With the development and evolution of 5G and other services, it is expected that an increasing number of IETF network slices will be deployed. The number of network slices required depends on how IETF network slices will be used, and the progress of network slicing for the vertical industrial services. The potential number of IETF network slice services and network resource partitions is analyzed by classifying the network slice deployment into three typical scenarios:

  1. IETF network slices can be used by a network operator for different types of services. For example, in a converged multi-service network, different IETF network slices can be created to carry mobile transport service, fixed broadband service and enterprise services respectively, each type of service could be managed by a separate department or management team. Some service types, such as multicast service may also be deployed in a dedicated network slice. In this case, a separate network resource partition may need to be created for each service type. It is also possible that a network infrastructure operator provides IETF network slices to other network operators as a wholesale service, and a network resource partition may also be needed for each wholesale service customer. In this scenario, the number of network resource partitions in a network could be relatively small, such as in the order of 10 or so. This could be one of the typical cases in the beginning of IETF network slice deployment.
  2. IETF network slices can be requested by customers in vertical industries, where the assurance of SLOs and the fulfilment of SLEs are quite important. At the early stage of the vertical industrial services, a few top customers in some industries will begin to use IETF network slices to provide performance assurance to their business, such as smart grid, manufacturing, public safety, on-line gaming, etc. The realization of such IETF network slices typically requires to provide different network resource partitions for different industries, and some top customers can require dedicated network resource partitions for strict service performance guarantee. Considering the number of vertical industries, and the number of top customers in each industry, the number of network resource partitions needed may be in the order of 100.
  3. With the evolution of 5G and cloud networks, IETF network slices could be widely used by various vertical industrial customers and enterprise customers who require guaranteed or predictable service performance. The total amount of IETF network slices may increase to thousands or more, although it is expected that the number of IETF network slices would still be less than the number of traditional VPN services in the network. Accordingly, the number of network resource partitions needed may be in the order of 1000.

As defined by 3GPP [TS23501], a 5G network slice is identified using the Single Network Slice Selection Assistance Information (S-NSSAI), which is a 32-bit identifier comprised of 8-bit Slice/Service Type (SST) and 24-bit Slice Differentiator (SD). This allows the mobile networks (the RAN and mobile core networks) to support a large number of 5G network slices. Although it is likely that multiple 5G network slices are mapped to the same IETF network slice, in some cases the number of IETF network slices may be comparable to the number of 5G network slices, and the required network resource partitions may increase as well.

                   8-bit              24-bit
               +------------+-------------------------+
               |    SST     |   Slice Differentiator  |
               +------------+-------------------------+

                Figure 1. Format of S-NSSAI in 3GPP

Thus realization of IETF network slices needs to meet the scalability requirement of IETF network slice services in different scenarios. The increased number of IETF network slice services will introduce additional complexity and overhead both to the control plane and the data plane, especially in the aspects related to the underlay network resource partitions. Although in many cases multiple IETF network slice services can be mapped to the same network resource partition, there still can be scalability challenges with the increased number of network resource partitions.

3. Network Resource Partition Scalability Considerations

In this section, the scalability of Network Resource Partition in the control plane and data plane is analyzed to understand the possible gaps in meeting the scalability requirement of IETF Network Slices.

3.1. Control Plane Scalability

The control plane of network resource partition could be based on the hybrid of a centralized controller and the distributed control plane.

3.1.1. Distributed Control Plane

For the delivery of IETF network slice services, it is necessary to create multiple network resource partitions, each can be associated with a customized logical topology. The network resource attributes and the associated logical topology information of each network resource partition may need to be exchanged among the network nodes. The scalability of the distributed control plane used for the distribution of network resource partition information needs to be considered in the following aspects:

  • The number of control protocol instances maintained on each node
  • The number of protocol sessions maintained on each link
  • The number of routes advertised by each node
  • The amount of attributes associated with each route
  • The number of route computation (i.e. SPF computation) executed by each node

As the number of network resource partitions increases, it is expected that in some of the above aspects, the overhead in the control plane may increase dramatically. For example, the overhead of maintaining separated control protocol instances (e.g. IGP instances) for different network resource partitions is considered higher than maintaining the information of separated network resource partitions in the same control protocol instance with appropriate separation, and the overhead of maintaining separate protocol sessions for different network resource partitions is considered higher than using a shared protocol session for the information exchange of multiple network resource partitions. To meet the requirement of the increasing number of network resource partitions, It is suggested to choose the control plane mechanisms which could improve the scalability while still provide the required functionality.

3.1.2. Centralized Control Plane

By introducing the centralized network controller, the SDN approach can reduce the amount of control plane overhead in the distributed control plane, while it may also transfer some of the scalability concerns from network nodes to the centralized controller, thus the scalability of the controller also needs to be considered.

To provide global optimization for the Traffic Engineered (TE) paths in different network resource partitions, the controller needs to keep the topology and resource information of all the network resource partitions up-to-date. To achieve this, the controller may need to maintain a communication channel with each network node in the network. When there is significant change in the network, or multiple network resource partitions requires global optimization concurrently, there may be a heavy processing burden at the controller, and a heavy load in the network surrounding the controller for the distribution of the updated network state and the TE paths.

3.2. Data Plane Scalability

To provide different IETF network slice services with the required SLOs and SLEs, it is necessary to allocate different subsets of network resources as different network resource partitions to avoid or reduce the unexpected interruption. As the number of network resource partitions increases, it is required that the underlying network can provide fine-granular network resource partitioning, which means the amount of state about the partitioned network resources to be maintained on the network nodes will also increase.

In packet forwarding, IETF network slice service traffic needs to be processed according to the topology and resource attributes of the network resource partition it mapped to, this means that some fields in the data packet needs to be used to identify the network resource partition and its associated topology either directly or implicitly. Different approaches of encapsulating the network resource partition information in data packet can have different scalability implications.

One practical approach is to reuse some of the existing fields in the data packet to additionally identify the network resource partition the packet belongs to. For example, the destination IP addresses or the MPLS forwarding labels may be reused to further identify the network resource partition. This can avoid the cost of introducing new fields in the data packet, while since it introduces additional semantics to the existing fields, the processing of the existing fields in packet forwarding may need to be changed. Moreover, introducing resource semantics to existing identifiers in the packet (e.g. IP addresses, MPLS forwarding labels, etc.) may result in the increase of the amount of the existing IDs in proportion to the number of the network resource partitions, which may cause scalability problem in networks where a relatively large number of network resource partitions is needed.

An alternative approach is to introduce a new dedicated field in the data packet for identifying the network resource partition. This could avoid the impacts to the existing fields in the packet. And if this new field carries a global-significant network resource partition identifier, it could be used together with the existing fields to determine the packet forwarding behavior. The potential issue with this approach is the difficulty in introducing a new field in some of the data plane technologies.

In addition, the introduction of network resource partition specific packet forwarding has impact on the scalability of the forwarding entries on network nodes, as a network node may need to maintain separate forwarding entries for each network resource partition it participates in.

3.3. Gap Analysis of Existing Mechanisms

One candidate mechanism to build network resource partition is to use resource aware Segment Identifiers (either SR-MPLS or SRv6) in the data plane as described in [I-D.ietf-spring-resource-aware-segments] [I-D.ietf-spring-sr-for-enhanced-vpn], and distribute the resource attribute and the associated logical topology of each network resource partition based on either Multi-topology [I-D.ietf-lsr-isis-sr-vtn-mt], Flex-Algo [I-D.zhu-lsr-isis-sr-vtn-flexalgo] or the combination of these mechanisms in the control plane. This mechanism is suitable for networks where a small number of network resource partitions are needed. As the number of network resource partitions increases, there may be several scalability challenges with this approach:

  1. The number of SR SIDs needed will increase in proportion to the number of network resource partitions in the network, which will bring challenges both to the distribution of SIDs and the related information in the control plane, and to the installation of forwarding entries for resource aware SIDs in the data plane.
  2. The number of route computation (e.g. SPF computation) will increase in proportion to the number of network resource partitions in the network, which may introduce significant overhead to the control plane of network nodes.
  3. The maximum number of logical topologies supported by OSPF is 128, and the maximum number of Flex-Algo is 128, which may not meet the required number of network resource partitions in some network scenarios.

4. Proposed Scalability Optimizations

4.1. Control Plane Optimizations

For the distributed control plane, several optimizations can be considered to reduce the control plane overhead and improve the control plane scalability.

The first optimization mechanism is to reduce the amount of control plane sessions used for the establishment and maintenance of the network resource partitions. For multiple network resource partitions which have the same connection relationship between two adjacent network nodes, it is proposed that one single control protocol session is used for such group of network resource partitions. The information of different network resource partitions can be exchanged over the same session, with necessary identification information to distinguish the network resource partitions in the control message. This could reduce the overhead of maintaining a large number of separate control protocol sessions for each network resource partition, and could also reduce the amount of control plane messages flooded in the network.

The second optimization mechanism is to decouple the network resource partition information from the associated logical topology information in the control plane, so that the resource attributes and the topology attributes can be advertised and processed separately. In a network, it is possible that multiple network resource partitions associate with the same logical topology, and multiple network resource partitions may share the same set of network resources on a subset of network nodes and links. Then it is more efficient if only one copy of the topology information is advertised, and multiple network resource partitions sharing the same topology could refer to this topology information. More importantly, with this approach, the result of topology-based route computation could be shared by multiple network resource partitions, so that the overhead of per network resource partition route computation could be avoided. Similarly, information of a subset of network resources reserved on a particular network node or link could be advertised once and may be referred to by multiple network resource partitions which share the same set of resources.

                  O#####O#####O          O*****O*****O
                  #     #     #          *     *     *
                  #     #     #          *     *     *
                  O#####O#####O          O*****O*****O

                      NRP-1                  NRP-2

                             O-----O-----O
                             |     |     |
                             |     |     |
                             O-----O-----O

                         Shared Network Topology

    Legend

    O     Virtual node
    ###   Virtual links with a set of reserved resources
    ***   Virtual links with another set of reserved resources

Figure 2. Topology Sharing between Network Resource Partitions
Figure 1: FIG-2

Figure 2 gives an example of two network resource partitions which share the same logical topology. As shown in the figure, NRP-1 and NRP-2 are associated with the same topology, while the resource attributes of each network resource partition are different. In this case, only one copy of the network topology information needs to be advertised, and the topology-based route computation result can be shared by the two network resource partitions to generate the corresponding routing and forwarding tables.

                    O#####O#####O         O----O#####O
                    #     #     #           \/ #     #
                    #     #     #           /\ #     #
                    O#####O#####O         O----O#####O

                        NRP-1                NRP-2

    Legend

    O     Virtual node
    ###   Virtual links with a set of reserved resource
    ---   Virtual links with another set of reserved resource

Figure 3. Resource Sharing between Network Resource Partitions

Figure 3 gives another example of two network resource partitions which share the same set of network resources on some of the links. In this case, information about the resources allocated on each link only needs to be advertised once, then both NRP-1 and NRP-2 could refer to the reserved link resource for constraint based path computation.

For the optimization of the centralized control plane, it is suggested that the centralized controller is used as a complementary mechanism to the distributed control plane rather than a replacement, so that the workload for network resource partition specific path computation in control plane could be shared by both the centralized controller and the network nodes, and the scalability of both systems could be improved.

4.2. Data Plane Optimizations

To support more IETF network slice services while keeping the amount of data plane state at a reasonable scale, one typical approach is to classify a set of IETF network slice services which have similar service characteristics and performance requirements into a group, and such group of IETF network slice services are mapped to one network resource partition, which is allocated with an aggregated set of network resources and the union of the required logical topologies to meet the service requirement of the whole group of IETF network slice services. Different groups of IETF network slice services can be mapped to different network resource partitions with different set of network resources allocated from the underlay network. With appropriate grouping of IETF network slice services, a reasonable number of network resource partitions with network resources reservation and aggregation could still meet the IETF network slice service requirements.

Another optimization in the data plane is to decouple the identifiers used for topology-based forwarding and the identifier used for the resource-specific processing introduced by network resource partition. One possible mechanism is to introduce a dedicated Network Resource Partition Identifier (NRP-ID) in the packet header to uniquely identify the set of local network resources allocated to a network resource partition on each network node for the processing and forwarding of the received packets. Then the existing identifiers in the packet header used for topology based forwarding (e.g. the destination IP address, MPLS forwarding labels) are kept unchanged. The benefit is the amount of the existing topology-specific identifiers will not be impacted by the increasing number of network resource partitions. Since this new NRP-ID field will be used together with other existing fields to determine the packet forwarding behavior, this may require network nodes to support a hierarchical forwarding table in data plane. Figure 4 shows the concept of using different data plane identifiers for topology-specific and resource-specific packet forwarding and processing respectively.

                        +--------------------------+
                        |       Packet Header      |
                        |                          |
                        | +----------------------+ |
                        | | Topology-specific IDs| |
                        | +----------------------+ |
                        |                          |
                        | +----------------------+ |
                        | |        NRP-ID        | |
                        | +----------------------+ |
                        +--------------------------+

   Figure 4. Decoupled Topology and Resource Identifiers in data packet

In an IPv6 [RFC8200] based network, this could be achieved by introducing a dedicated field in either the IPv6 fixed header or the extension headers to carry the NRP-ID for the resource-specific forwarding, while keeping the destination IP address field used for routing towards the destination prefix in the corresponding topology. Note that the NRP-ID needs to be parsed by every node along the path which is capable of network resource partition aware forwarding. [I-D.dong-6man-enhanced-vpn-vtn-id] introduces the mechanism of carrying the VTN resource ID (which is equivalent to NRP-ID in the context of network slicing) in IPv6 Hop-by-Hop extension header.

In an MPLS [RFC3032] based network, this may be achieved by introducing a dedicated NRP-ID either in the MPLS label stack or following the MPLS label stack. This way, the existing MPLS forwarding labels are used for topology-specific packet forwarding towards the destination node, and the NRP-ID is used to determine the set of network resources for packet processing. This requires that both the forwarding label and the NRP-ID be parsed by nodes along the forwarding path of the packet, and the forwarding behavior may depend on the position of the NRP-ID in the packet. The detailed extensions to MPLS data plane are out of the scope of this document.

5. Solution Evolution for Improved Scalability

Based on the analysis in this document, the control plane and data plane for network resource partition needs to evolve to support the increasing number of IETF network slice services and the increasing number of network resource partitions in the network.

At the first step, by introducing resource-awareness to segment routing SIDs [I-D.ietf-spring-resource-aware-segments], and using Multi-Topology or Flex-Algo as the control plane mechanism to define the logical topology, it could provide a solution for building a limited number of network resource partitions in the network, and can meet the requirement of a relatively small number of IETF network slice services. This mechanism is called the basic SR based NRP.

As the required number of IETF network slice services increases, more network resource partitions may be needed, then the control plane scalability could be improved by decoupling the topology attribute from the resource attribute, so that multiple network resource partitions could share the same topology or resource attribute to reduce the control plane and data plane overhead. The data plane can still be based on the resource-aware SIDs. This mechanism is called the scalable SR based NRP. Both the basic and the scalable SR based NRP mechanisms are described in [I-D.ietf-spring-sr-for-enhanced-vpn].

When the data plane scalability becomes a concern, a dedicated NRP-ID can be introduced in the data packet to decouple the resource-specific identifiers from the topology-specific identifiers in the data plane, this could help to reduce the number of IP addresses or SR SIDs needed to support a large number of network resource partitions. This mechanism is called the NRP-ID based mechanism.

6. Security Considerations

This document describes the scalability considerations about the network control plane and data plane of network resource partitions in the realization of IETF network slice services, and proposes the mechanisms for scalability optimization. The security considerations in[I-D.ietf-teas-ietf-network-slices] and [I-D.ietf-teas-enhanced-vpn] applies to this document.

7. IANA Considerations

This document makes no request of IANA.

8. Contributors 

Zhibo Hu
Email: huzhibo@huawei.com

Hongjie Yang
Email: hongjie.yang@huawei.com

9. Acknowledgments

The authors would like to thank Adrian Farrel for the review and discussion of this document.

10. References

10.1. Normative References

[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) Services", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-09, , <https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-vpn-09.txt>.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-05, , <https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-05.txt>.

10.2. Informative References

[I-D.dong-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-dong-6man-enhanced-vpn-vtn-id-06, , <https://www.ietf.org/archive/id/draft-dong-6man-enhanced-vpn-vtn-id-06.txt>.
[I-D.dong-lsr-sr-enhanced-vpn]
Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., and S. Bryant, "IGP Extensions for Scalable Segment Routing based Enhanced VPN", Work in Progress, Internet-Draft, draft-dong-lsr-sr-enhanced-vpn-06, , <https://www.ietf.org/archive/id/draft-dong-lsr-sr-enhanced-vpn-06.txt>.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-18, , <https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-18.txt>.
[I-D.ietf-lsr-isis-sr-vtn-mt]
Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-sr-vtn-mt-01, , <https://www.ietf.org/archive/id/draft-ietf-lsr-isis-sr-vtn-mt-01.txt>.
[I-D.ietf-spring-resource-aware-segments]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Z., and F. Clad, "Introducing Resource Awareness to SR Segments", Work in Progress, Internet-Draft, draft-ietf-spring-resource-aware-segments-03, , <https://www.ietf.org/archive/id/draft-ietf-spring-resource-aware-segments-03.txt>.
[I-D.ietf-spring-sr-for-enhanced-vpn]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Z., and F. Clad, "Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN", Work in Progress, Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, , <https://www.ietf.org/archive/id/draft-ietf-spring-sr-for-enhanced-vpn-01.txt>.
[I-D.zhu-lsr-isis-sr-vtn-flexalgo]
Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment Routing based VTN", Work in Progress, Internet-Draft, draft-zhu-lsr-isis-sr-vtn-flexalgo-03, , <https://www.ietf.org/archive/id/draft-zhu-lsr-isis-sr-vtn-flexalgo-03.txt>.
[RFC3032]
Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, , <https://www.rfc-editor.org/info/rfc3032>.
[RFC4915]
Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, , <https://www.rfc-editor.org/info/rfc4915>.
[RFC5120]
Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, , <https://www.rfc-editor.org/info/rfc5120>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.
[TS23501]
"3GPP TS23.501", , <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144>.

Authors' Addresses

Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Road
Beijing
100095
China
Liyan Gong
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District
Beijing
China
Guangming Yang
China Telecom
No.109 West Zhongshan Ave., Tianhe District
Guangzhou
China
James N Guichard
Futurewei Technologies
2330 Central Express Way
Santa Clara,
United States of America
Gyan Mishra
Verizon Inc.
Fengwei Qin
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District
Beijing
China