Application-aware IPv6 Networking
draft-li-6man-app-aware-ipv6-network-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Zhenbin Li , Shuping Peng , Cong Li , Chongfeng Xie | ||
| Last updated | 2020-04-19 | ||
| Replaces | draft-li-6man-service-aware-ipv6-network | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-6man-app-aware-ipv6-network-01
Network Working Group Z. Li
Internet-Draft S. Peng
Intended status: Standards Track Huawei Technologies
Expires: October 22, 2020 C. Li
C. Xie
China Telecom
April 20, 2020
Application-aware IPv6 Networking
draft-li-6man-app-aware-ipv6-network-01
Abstract
A multitude of applications are carried over the network, which have
varying needs for network bandwidth, latency, jitter, and packet
loss, etc. Some applications such as online gaming and live video
streaming have very demanding network requirements thereof require
special treatments in the network. However, in current networks, the
network and applications are decoupled, that is, the network is not
aware of the applications' requirements in a finer granularity.
Therefore, it is difficult to provide truly fine-granular traffic
operations for the applications and guarantee their SLA requirements.
This document proposes a new framework, named Application-aware IPv6
Networking, and also the solution to guarantee SLA for applications,
which makes use of IPv6 extensions header in order to convey the
application related information including its requirements along with
the packet to the network so to facilitate the service deployment and
network resources adjustment. Then, it defines the application-aware
options which can be used in the different IPv6 extension headers for
the purpose.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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/.
Li, et al. Expires October 22, 2020 [Page 1]
Internet-Draft App-aware IPv6 Network April 2020
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 October 22, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Demanding Applications . . . . . . . . . . . . . . . . . . . 4
3.1. Online Gaming . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Video streaming . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. App-aware IPv6 Networking Framework . . . . . . . . . . . . . 5
6. Application-aware Options . . . . . . . . . . . . . . . . . . 6
6.1. Application-aware ID Option . . . . . . . . . . . . . . . 7
6.2. Service-Para Option . . . . . . . . . . . . . . . . . . . 8
7. Locations for placing the Application-aware Options . . . . . 11
7.1. Hop-by-Hop Options Header (HBH) . . . . . . . . . . . . . 11
7.2. Destination Options Header (DOH) . . . . . . . . . . . . 11
7.3. Segment Routing Header (SRH) . . . . . . . . . . . . . . 12
7.3.1. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.2. SID Arguments Field . . . . . . . . . . . . . . . . . 12
7.3.3. SRH TAG field . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Li, et al. Expires October 22, 2020 [Page 2]
Internet-Draft App-aware IPv6 Network April 2020
1. Introduction
A multitude of applications are carried over the network, which have
varying needs for network bandwidth, latency, jitter, and packet
loss, etc. Some applications such as online gaming and live video
streaming have very demanding network requirements thereof require
special treatments in the network. However, in current networks, the
network and applications are decoupled, that is, the network is not
aware of the applications' requirements in a finer granularity.
Therefore, it is difficult to provide truly fine-granular traffic
operations for the applications and guarantee their SLA requirements.
Such guarantee would also be provided by adopting the hierarchical
orchestration and the interactions between the orchestrator and
multiple controllers, but it would take a very long time by going
through the control and management elements. Moreover, the
interfaces between those elements require standardizations.
This document proposes a new framework, named Application-aware IPv6
Networking, and also the solution to guarantee SLA for applications,
which makes use of IPv6 extensions header (i.e. Hop-by-Hop Options
Header (HBH), Destination Options Header (DOH), Segment Routing
Header(SRH)) to convey the applications related information including
their identifiers and requirements along with the packet to the
network to facilitate the service deployment and network resource
adjustment. Then it defines the application-aware options (i.e.
application-aware ID option and service-aware para option), which can
be used in the above listed different IPv6 extension headers for the
purpose.
2. Terminologies
ASBR: Autonomous System Boundary Router
ASG: Aggregation Service Gateway
CPE: Customer-Premises Equipment
CSG: Cell Site Gateway
FBB: Fixed Broadband
MBB: Mobile Broadband
RG: Residential Gateway
RSG: Radio Service Gateway
Li, et al. Expires October 22, 2020 [Page 3]
Internet-Draft App-aware IPv6 Network April 2020
3. Demanding Applications
This section shows the various demanding requirements of some
applications. The traffic of these applications needs to be
differentiated from other types of traffic and applied with special
treatments in the network, that is, the network needs to be able to
provide fine-granular traffic operations and acceleration to these
demanding applications. In return, the operators will get their
networks' revenue increased.
3.1. Online Gaming
Good network performance is normally a prerequisite for satisfactory
game play, especially for the online gaming. Shooting or racing
online gaming is normally based on quick action and needs to update
the game status in real time by continuously sending and receiving
updates to/from the game server and/or other players. The online
gaming is very sensitive to the network latency.
3.2. Video streaming
The network latency, jitter, bandwidth, and packet loss are the key
factors for the video streaming. Live video streaming has even more
strict requirements. High quality video source require more
bandwidth in order to stream properly. Real time streaming services
also require real time content delivery from the web server to the
end user ideally via carefully planned explicit TE paths. The online
gaming often involves live video streaming.
4. Problem Statement
[RFC3272] reviews a number of IETF activities which are primarily
intended to evolve the IP architecture to support new service
definitions which allow preferential or differentiated treatment to
be accorded to certain types of traffic. The challenge when using
traditional ways to guarantee SLA is that the packets are not able to
carry enough information of service requirements of applications.
The network devices mainly rely on the 5-tuple of the packets which
cannot provide fine-grained service process. If more information is
needed, it has to refer to DPI which will introduce more cost in the
network and impose security challenges.
In the era of SDN the orchestrator is introduced for the
orchestration of applications and the network. The SDN controller
can be aware of the service requirements of the applications on the
network through the interface interworking with the orchestrator.
The service requirements is used by the controller for traffic
management. The method raises the following problems: 1) The whole
Li, et al. Expires October 22, 2020 [Page 4]
Internet-Draft App-aware IPv6 Network April 2020
loop is long and time-consuming which is not suitable for the real-
time adjustment for applications; 2) Too many interfaces are involved
in the loop which proposes more challenges of standardization and
inter-operability, and it is difficult to be standardized for easy
interworking.
5. App-aware IPv6 Networking Framework
Client Server
+-----+ +-----+
|App x|-\ /->|App x|
+-----+ | +-----+ +--------+ +---------+ +---------+ | +-----+
\->|App- | |App- |-A-|App- |-A-|App- |-/
User side |aware|--|aware |-B-|aware |-B-|aware |
/->|Edge | |Head-End|-C-|Mid-Point|-C-|End-Point|-\
+-----+ | +-----+ +--------+ +---------+ +---------+ | +-----+
|App y|-/ \->|App y|
+-----+ ---------- Uplink ----------> +-----+
Figure 1 App-aware IPv6 Network
In the application-aware IPv6 network shown in Figure 1, there are
following components:
1. Application-aware Apps: The IPv6 enabled applications runs in the
host which can optionally add the service requirements of the
applications in an IPv6 extension header ([RFC8200]) or remove it
from the IPv6 extension header. The service requirement information
includes:
o An IPv6 application-aware ID which identifies the IPv6 packets as
part of the traffic flow belonging to a specific SLA
level/Application/User;
o A set of parameters for the specific service such as bandwidth,
delay, delay variation, packet loss ratio, etc.
The service requirements will be processed by the IPv6 enabled nodes
along the path or the SRv6
([I-D.ietf-spring-srv6-network-programming]) nodes along the SRv6
path.
2. App-aware Edge Device: The Edge Device can add the service
requirements of the applications on network through the IPv6
extension header on behalf of the IPv6 enabled applications or change
the service requirements conveyed by the packets of the application-
aware applications according to local policies which is out of the
scope of this document. The service requirements will be processed
Li, et al. Expires October 22, 2020 [Page 5]
Internet-Draft App-aware IPv6 Network April 2020
by the IPv6 enabled nodes along the path or the SRv6 enabled node
along the SRv6 path which be programmed by the Edge Device. The
application information can also be encapsulated through L2
encapsulation or some tunnel encapsulations appended to the packet
depending on different application scenarios and device capability.
3. App-aware-process Head-End: The service requirements may be
processed as a service path such as a SRv6 Policy path of SFC at the
App-aware-process Head-End. The service requirements conveyed in the
IPv6 packets can be mapped to an existing service path or an existing
Policy which satisfies the specific requirement, trigger to set up
the new service path by the Head-End, or trigger the global traffic
adjustment by the controller according to the information provided by
the network devices. The process depends on the local policy which
is out of the scope this document. The application information
conveyed by the packet received from the App-aware Edge Device can
also be copied or be mapped to the out IPv6 extension header for
further application-aware process.
4. App-aware-process Mid-Point: The Mid-Point provides the path
service according to the service path set up by the Head-End which
satisfies the service requirement conveyed by the IPv6 packets. The
Mid-Point may also adjust the resource locally to guarantee the
service requirements depending on a specific policy and the
applicaton-aware information conveyed by the packet. Policy
definitions and mechanisms are out of the scope of this document.
5. App-aware-process End-Point: The process of the specific service
path will end at the End-Point. The service requirements information
can be removed at the End-Point together with the SRH or go on to be
conveyed with the IPv6 packets.
In this way the network is able to be aware of the service
requirements expressed by the applications explicitly. According to
the service requirement information carried in the IPv6 packets the
network is able to adjust its resources fast in order to satisfy the
service requirement of applications. The flow-driven method also
reduces the challenges of inter-operability and long control loop.
6. Application-aware Options
In order to support the Application-aware IPv6 networking, two
application-aware options are defined:
o Application-aware ID option
o Service-Para Option
Li, et al. Expires October 22, 2020 [Page 6]
Internet-Draft App-aware IPv6 Network April 2020
6.1. Application-aware ID Option
The Application-aware ID option indicates the information of the
applications, users, and application requirements, as illustrated in
the following figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ IPv6 Application-aware ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IPv6 Application-aware ID Option
Option Type: TBD_1
Opt Data Len: 16 octets.
The IPv6 Application-aware ID is 128bits long which has one of the
following structures:
-- Structure I: Any combination of SLA level (e.g. Gold, Silver,
Bronze), APP ID, and/or user ID. The length of each field is
variable, as shown in the following diagram:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA Level | APP ID | User ID | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. IPv6 Application-aware ID Structure I
-- Structure II: Any combination of SLA level (e.g. Gold, Silver,
Bronze), APP ID, and/or user ID plus the arguments which indicating
the service requirements of the identified application, as shown in
the following diagram:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA Level| APP ID | User ID | Flow ID | Arguments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. IPv6 Application-aware ID Structure II
-- Structure III: An SRv6 SID, with its arguments as the information
specified in Structure II, as shown in the following diagram:
Li, et al. Expires October 22, 2020 [Page 7]
Internet-Draft App-aware IPv6 Network April 2020
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Address | Function ID | Arguments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. IPv6 Application-aware ID Structure III
6.2. Service-Para Option
The Service-Para Option is a variable-length option carrying multiple
service requirement parameters for specific application. Each
service requirement parameter is put into the corresponding Service-
Para Sub-TLV, as shown in Figure 6. This Option can be put into the
IPv6 Hop-by-Hop Options, Destination Options, and SRH TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Service-Para Sub-TLVs(Variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. IPv6 Service-Para Option
Option Type TBD
Opt Data Len 8-bit unsigned integer. Length of the
Service-Para Sub-TLVs.
Service-Para Sub-TLVs Variable-length field with Service-
Para Sub-TLVs.
The corresponding Service-Para Sub-TLVs are shown in the following
figures respectively.
1. BW Sub-TLV
This BW sub-TLV indicates the bandwidth requirement of applications.
The format of this sub-TLV is shown in the following diagram:
Li, et al. Expires October 22, 2020 [Page 8]
Internet-Draft App-aware IPv6 Network April 2020
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Class Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. BW Sub-TLV
where:
Type: TBD
Length: 4
Class Type: The Bandwidth Type.
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Bandwidth: This field carries the bandwidth requirement along the
path.
2. Delay Sub-TLV
This Delay Sub-TLV indicates the delay requirement of applications.
The format of this sub-TLV is shown in the following diagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Delay Sub-TLV
where:
Type: TBD
Length: 4
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Li, et al. Expires October 22, 2020 [Page 9]
Internet-Draft App-aware IPv6 Network April 2020
Delay: This 24-bit field carries the delay requirements in
microseconds, encoded as an integer value. When set to the maximum
value 16,777,215 (16.777215 sec), then the delay is at least that
value and may be larger. This value is the highest delay that can be
tolerated.
3. Delay Variation Sub-TLV
This Delay Variation Sub-TLV indicates the delay variation
requirement of applications. The format of this sub-TLV is shown in
the following diagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Delay Variation Sub-TLV
where:
Type: TBD
Length: 4
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Delay Variation: This 24-bit field carries the delay variation
requirements in microseconds, encoded as an integer value.
4. Packet Loss Ratio Sub-TLV
This Packet Loss Ratio Sub-TLV indicates the packet loss ratio
requirement of applications. The format of this sub-TLV is shown in
the following diagram:
Li, et al. Expires October 22, 2020 [Page 10]
Internet-Draft App-aware IPv6 Network April 2020
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Packet Loss Ratio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11. Packet Loss Ratio Sub-TLV
where:
Type: TBD
Length: 4
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Link Loss: This 24-bit field carries link packet loss ratio
requirement. This value is the highest packet-loss ratio that can be
tolerated.
7. Locations for placing the Application-aware Options
The Application-aware options can be placed in several locations in
the IPv6 packet header depend upon the scenarios and implementation
requirements.
7.1. Hop-by-Hop Options Header (HBH)
The application-aware options can be carried in the Hop-by-Hop
Options Header as new options. By using the HBH Options Header, the
information carried can be read by every node along the path.
However, the current processing of the HBH Options Header goes to the
slow path, which will decrease the forwarding performance.
Therefore, we propose a new enhanced HBH Options Header in [I-D.li-
6man-enhanced-extension-header].
7.2. Destination Options Header (DOH)
The application-aware options can be carried in the Destination
Options Header as new options.
Li, et al. Expires October 22, 2020 [Page 11]
Internet-Draft App-aware IPv6 Network April 2020
7.3. Segment Routing Header (SRH)
The Application-aware options can be placed in the segment routing
header (SRH), e.g., in the SRH TLV, the SID Arguments field, or the
TAG field.
7.3.1. SRH TLV
The Application-aware options can be placed in the SRH TLV.
7.3.2. SID Arguments Field
The Application-aware ID option can be put in the SID Arguments
field, which can be read by each node indicated by the SID in the SID
list.
7.3.3. SRH TAG field
The Application-aware ID option can be put in the TAG field, which
can be read by each node that processes the SRH.
8. IANA Considerations
IANA maintains the registry for the Options and Sub-TLVs.
Application-Para Option will require one new type code per sub-TLV
defined in this document:
Type Value
----------------------------------------------------
TBD Application-aware ID Option
TBD Application-Para Option
TBD BW Sub-TLV
TBD Delay Sub-TLV
TBD Delay Variation Sub-TLV
TBD Packet Loss Sub-TLV
Li, et al. Expires October 22, 2020 [Page 12]
Internet-Draft App-aware IPv6 Network April 2020
9. Security Considerations
TBD
10. References
10.1. Normative References
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-15 (work in
progress), March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
10.2. Informative References
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
<https://www.rfc-editor.org/info/rfc3272>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li, et al. Expires October 22, 2020 [Page 13]
Internet-Draft App-aware IPv6 Network April 2020
Shuping Peng
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: pengshuping@huawei.com
Cong Li
China Telecom
China Telecom Information Science&Technology Innovation
park, Beiqijia Town,Changping District
Beijing 102209
China
Phone: +86-10-50902556
Email: licong@chinatelecom.cn
Chongfeng Xie
China Telecom
China Telecom Information Science&Technology Innovation
park, Beiqijia Town,Changping District
Beijing 102209
China
Phone: +86-10-50902116
Email: xiechf@chinatelecom.cn
Li, et al. Expires October 22, 2020 [Page 14]