Internet DRAFT - draft-ietf-v6ops-hbh
draft-ietf-v6ops-hbh
Network Working Group S. Peng
Internet-Draft Z. Li
Intended status: Informational Huawei Technologies
Expires: 20 August 2024 C. Xie
China Telecom
Z. Qin
China Unicom
G. Mishra
Verizon Inc.
17 February 2024
Operational Issues with Processing of the Hop-by-Hop Options Header
draft-ietf-v6ops-hbh-10
Abstract
This document describes the processing of the Hop-by-Hop Options
Header (HBH) in current routers in the aspects of standards
specification, common implementations, and default operations. This
document outlines reasons why the Hop-by-Hop Options Header is rarely
utilized in current networks. In addition, this document describes
how HBH Options Header could be used as a powerful mechanism allowing
deployment and operations of new services requiring a more optimized
way to leverage network resources of an infrastructure. The purpose
of this draft is to document reasons why HBH Options Header is rarely
used within networks. It motivates the benefits and requirements
needed to enable wider use of HBH Options.
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 [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
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/.
Peng, et al. Expires 20 August 2024 [Page 1]
Internet-Draft Processing HBH Opt Hdr February 2024
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 August 2024.
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New Services . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Modern Router Architecture . . . . . . . . . . . . . . . . . 5
5. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 6
6. Common Implementations . . . . . . . . . . . . . . . . . . . 7
7. Typical Processing . . . . . . . . . . . . . . . . . . . . . 8
8. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8
9. Migration Strategies . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
When IPv6 was first implemented on high-speed routers, Hop-by-Hop
Options header (HBH) options were not yet well-understood and ASICs
were not as capable as they are today. Due to these historical
reasons, as well as limited IPv6 deployments and few service
requirements, the early common IPv6 implementation was that the node
sends the IPv6 packets with the HBH Options Header to the control
Peng, et al. Expires 20 August 2024 [Page 2]
Internet-Draft Processing HBH Opt Hdr February 2024
plane of the node [RFC9098]. The option type of each option carried
within the HBH Options Header is not even examined before the packet
is sent to the control plane [RFC7045]. Such processing behavior is
often the default configuration or, even worse, is the only behavior
of the IPv6 implementation of the node.
Sending the HBH Options Header to the control plane for processing
could result in Denial of Service (DoS) attack on the router control
plane [RFC9288] and inconsistent packet drops. This is due to rate-
limiting on the interface between the router control plane and
forwarding plane, which impacts packet forwarding. This has in turn
led to configuration of measures (such as infrastructure Access
Control Lists (ACLs)) to mitigate this DoS vector.
This actually introduced a circular problem:
-> Implementations that send packets to the control plane for
processing are at risk for Denial of Service attack.
-> To mitigate the risk of DoS attack, many network operators
configured their nodes to discard all packets containing HBH Options
Header.
-> Because of network operators' configurations that discard packets
containing HBH Options Header, protocol designers stopped defining
new HBH Options.
-> Because protocol designers stopped defining new HBH Options, the
community was not motivated to change the conventional implementation
that caused use of a HBH Option Header to become a DoS vector.
Driven by the wide deployments of IPv6 and ever-emerging new services
in recent years, the HBH Options Header is a valuable container for
carrying the information to facilitate these new services.
The purpose of this work is to:
* Break the endless cycle that resulted in HBH being a DOS vector.
* Enable the HBH options header to be utilized in a safe and secure
way without impacting the control plane.
* Ease the deployments of the new network services that utilize the
HBH Option Header in a multi-vendor scenario that can now be
deployed without operational impact.
Peng, et al. Expires 20 August 2024 [Page 3]
Internet-Draft Processing HBH Opt Hdr February 2024
2. Terminology
The terms Forwarding Plane and Control Plane used in this draft refer
to the terminologies as defined in [I-D.ietf-6man-hbh-processing].
3. New Services
As IPv6 is being rapidly and widely deployed worldwide, more and more
applications and network services are migrating to or directly
adopting IPv6. New services that require hop-by-hop processing are
emerging and the HBH Options header is going to be utilized by the
new services in various scenarios.
In-situ OAM (IOAM) with IPv6 encapsulation [RFC9486] is used to
enhance diagnostics of IPv6 networks and complements other
mechanisms, such as the IPv6 Performance and Diagnostic Metrics
Destination Option described in [RFC8250]. The IOAM data fields are
encapsulated in "option data" fields of the Hop-by-Hop Options
header.
The Alternate Marking Option is defined as a new IPv6 Hop-by-Hop
option to encode an alternate marking technique [RFC9343].
The Minimum Path MTU Hop-by-Hop Option is defined in [RFC9268] to
record the minimum Path MTU along the forward path between a source
host to a destination host. This Hop-by-Hop option is intended to be
used in environments like Data Centers and on paths between Data
Centers as well as other environments including the general Internet.
It provides a useful tool to better take advantage of paths capable
of supporting a large Path MTU.
A Virtual Transport Network (VTN) Option is used to carry the VTN
related information, which could used to identify the set of network
resources allocated to a VTN and the rules for packet processing.
[I-D.ietf-6man-enhanced-vpn-vtn-id].
As more services start utilizing the HBH Options header, more packets
containing HBH Options are going to be injected into the networks. A
currently common configuration in deployed networks is for routers to
send all the packets of the new services to the control plane of the
nodes, with the possible consequence of resulting in a DoS
vulnerability on the control plane. The packets will be dropped and
the normal IP forwarding is severely impacted. The deployment of new
network services involving multi-vendor interoperability is greatly
impeded.
Peng, et al. Expires 20 August 2024 [Page 4]
Internet-Draft Processing HBH Opt Hdr February 2024
4. Modern Router Architecture
The architecture of modern routers deployed by Internet operators
maintains a strict separation of the router control plane and its
forwarding plane [RFC6192], as shown in Figure 1. Either the control
plane or the forwarding plane is composed of both software and
hardware, but each plane is responsible for different functions. In
this document, we focus on only hardware routers following the
architecture as shown in Figure 1 which are typical of core routers
or datacenter routers, as opposed to software-based routers such as
home routers or hotspot routers in a smartphone.
+----------------+
| Router Control |
| Plane |
+------+-+-------+
| |
Interface Z
| |
+------+-+-------+
| Forwarding |
Interface X ==[ Plane ]== Interface Y
+----------------+
Figure 1. IP router architecture splitting the control and forwarding planes
Many of the packet-processing devices employed in current router
designs are fixed-function ASICs that handle common functions,
however there is a trend towards programmable device datapaths such
as P4 [P4]. While these devices can be very efficient for the set of
functions they are designed for, they can be very inflexible. There
is a tradeoff of price, performance and flexibility when vendors make
a choice to use a fixed function ASIC as opposed to Network
Processing Unit (NPU). Due to the inflexibility of the fixed
function ASIC, tasks that require additional processing such as IPv6
HBH header processing must be punted to the control plane.
This problem is still a challenge today and is the reason why
operators drop or ignore HBH options to protect against control plane
DOS attack. Semiconductor chip technology has advanced significantly
in the last decade. An industry trend is for intelligent multi-core
CPU hardware using modern NPUs for forwarding packets at line rate
while still being able to perform other complex tasks such as HBH
forwarding options processing without having to punt to the control
plane increasing the viability of ubiquitous HBH use cases.
Peng, et al. Expires 20 August 2024 [Page 5]
Internet-Draft Processing HBH Opt Hdr February 2024
Parsing buffers with a limited size are commonly used in router
implementations. The parsing buffer contains the headers of a packet
that can be processed in the fast path and typically have sizes like
128, 256, 284 bytes. A source node is permitted to encode hundreds
of options in 2,048 bytes [I-D.ietf-6man-eh-limits]. With today's
technology it would be cost prohibitive to be able to process
hundreds of options with either NPU or proprietary fixed function
ASIC [I-D.ietf-6man-eh-limits].
IPv6 Extended Header limitations that need to be addressed to make
HBH processing more efficient and viable in the forwarding plane.
[I-D.ietf-6man-eh-limits] defines the IPv6 router requirements and
how to protect a router from excessive header chain and excessive
header options with various limitations that can be defined on a
router. Per [RFC8200] HBH options must be processed serially.
However, an implementation of options processing can be done with
more parallelism in serial processing by grouping similar options to
be processed in parallel.
Each Option is encoded in a TLV and so processing of a long list of
TLVs is expensive. Zero data length encoded options TLVs are a valid
option with a minimum length of two bytes. A DOS vector could be
easily generated by encoding around 700 HBH options (Zero data
length) in a standard 1500 MTU packet. Limiting the number of
options that are processed could avoid an arbitrary large amount of
processing for a single EH.
5. Specification of RFC 8200
As specified in [RFC8200], the HBH Options header is used to carry
optional information that will be examined and processed by every
node along a packet's delivery path, and it is identified by a Next
Header value of zero in the IPv6 header.
As per [RFC8200], it is now expected that nodes along a packet's
delivery path only examine and process the Hop-by-Hop Options header
if explicitly configured to do so. This means that the HBH
processing behavior in a node depends on its configuration.
However, in the current [RFC8200], there is no explicit specification
of the possible configurations leading to likely uncertain processing
behaviors, that is, the nodes may be configured to ignore the HBH
Options Header, drop packets containing a HBH Options Header, or
assign packets containing a HBH Options Header to the control plane
[RFC8200]. This specification is updated in
[I-D.ietf-6man-hbh-processing].
Peng, et al. Expires 20 August 2024 [Page 6]
Internet-Draft Processing HBH Opt Hdr February 2024
6. Common Implementations
Current routers deployed by operators usually process an IPv6 packet
that has a Next Header field set to 0 by directly forwarding it to
the control plane of the node. With such implementations, the value
of the Next Header field in the IPv6 header is the only trigger for
the default processing behavior. The option type of each option
carried within the HBH Options Header is not even examined before the
packet is sent to the control plane.
Very often, such processing behavior is the default configuration on
the node, which is embedded in the implementation and cannot be
changed or reconfigured.
Another critical component of IPv6 HBH processing, in some cases
overlooked, is that an operator core network can be designed to use
the global Internet routing table for internet traffic and in other
cases use an overlay MPLS VPN to carry Internet traffic.
In the global Internet routing table scenario where only an underlay
global routing table exists, and no VPN overlay carrying customer
Internet traffic, the IPv6 HBH options could be used as a DOS attack
vector for both the operator nodes, adjacent inter-AS peer nodes, as
well as customer nodes along a path.
In a case where the Internet routing table is carried in an MPLS VPN
overlay payload, the HBH options header does not impact the operator
underlay framework and only impacts the VPN overlay payload. Thus
the operator underlay top most label global table routing FEC LSP
instantiation is not impacted as the operator underlay is within the
operators closed domain.
However, the HBH options DOS attack vector in the VPN overlay can
still impact the customer end nodes as well as other adjacent inter-
AS operators that only use the underlay global Internet routing
table. In an operator domain where an MPLS VPN overlay is utilized
to carry internet traffic, the operator has full control of the
underlay and IPv6 Extension Header chain length as well as the number
of HBH options encoded [I-D.ietf-6man-eh-limits].
In the global routing table scenario for Internet traffic there is no
way to control the IPv6 Extended header chain length as well as the
number of HBH options encoded.
When IPv6 was first implemented on high-speed routers, HBH options
were not yet well-understood and ASICs were not as capable as they
are today. So, early IPv6 implementations dispatched all packets
that contain HBH options to their control plane. Such implementation
Peng, et al. Expires 20 August 2024 [Page 7]
Internet-Draft Processing HBH Opt Hdr February 2024
introduces a risk of a DoS attack on the control plane of the node,
and a large flow of IPv6 packets could congest the control plane,
causing other critical functions (including routing and network
management) that are executed on the control plane to fail. Rate
limiting mechanisms will cause inconsistent packet drops and impact
the normal IP forwarding of packets.
7. Typical Processing
To mitigate this DoS vulnerability, many operators have deployed
Access Control Lists (ACLs) that discard all packets containing HBH
Options [RFC9288].
[RFC6564] shows the Reports from the field indicating that some IP
routers deployed within the global Internet are configured either to
ignore or to drop packets having a hop-by-hop header. As stated in
[RFC7872], many network operators perceive HBH Options to be a breach
of the separation between the forwarding and control planes.
Therefore, several network operators configured their nodes so as to
discard all packets containing the HBH Options Extension Header,
while others configured nodes to forward the packet but to ignore the
HBH Options. [RFC7045] also states that hop-by-hop options are not
handled by many high-speed routers or are processed only on a control
plane. [I-D.vyncke-v6ops-james] shows that the HBH options header
cannot reliably traverse the global Internet; only small headers with
'skippable' options have some chances.
Due to such behaviors observed and described in these specifications,
[RFC8200] did not recommend new HBH Options, which limited the
usability of HBH Options.
Besides service providers' networks, other sectors such as industrial
IoT networks are slowly replacing a dozen of semi-proprietary
protocols in industrial automation into IP. The proper processing of
the HBH options header is also required
[I-D.pthubert-detnet-ipv6-hbh].
8. Design Principles
Here are some design principles for HBH Options Header and its
carrying Options.
* The HBH Options Header should not become a possible DDoS Vector.
Therefore, the control plane needs to be preserved from unwanted
incoming traffic due to HBH header present in the packet.
Peng, et al. Expires 20 August 2024 [Page 8]
Internet-Draft Processing HBH Opt Hdr February 2024
* HBH Options need to be designed in a manner so that they don't
reduce the probability of packet delivery, especially in length
limit.
* HBH processing implementations need to perform well at a
reasonable cost without endangering the security of the router.
* The Router Alert Option needs not to impact the processing of
other HBH Options that should be processed more quickly
[I-D.ietf-6man-hbh-processing].
* HBH Options can influence how a packet is forwarded. However,
with the exception of the Router Alert Option, an HBH Option must
not cause control plane state to be created, modified or destroyed
on the processing node. As per [RFC6398], protocol developers
SHOULD avoid future use of the Router Alert Option.
* The limits specified in [I-D.ietf-6man-eh-limits] need to be
configurable to manage HBH processing so it doesn't become a
bottleneck.
* MLDv2 [RFC3810] should not be forbidden.
9. Migration Strategies
In order to make the HBH Options Header usable and facilitate the
ever-emerging new services to be deployed across multiple vendors'
devices, the new specifications related to the processing of HBH
Options Header need to be designed to allow a smooth migration from
old to new behavior without disruption time.
10. Security Considerations
The security considerations can refer to
[I-D.ietf-6man-hbh-processing], [RFC7045], [RFC7112], [RFC8200],
[RFC4302], and [RFC4303].
11. IANA Considerations
This document does not include an IANA request.
12. Acknowledgements
The authors would like to acknowledge Ron Bonica, Fred Baker, Bob
Hinden, Stefano Previdi, and Donald Eastlake, Gorry Fairhurst, Nick
Hilliard, Tom Herbert, Haisheng Yu, Nalini Elkins, and Alexandre
Petrescu for their valuable review and comments.
Peng, et al. Expires 20 August 2024 [Page 9]
Internet-Draft Processing HBH Opt Hdr February 2024
13. References
13.1. Normative References
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-12, 21 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-12>.
[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>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999,
<https://www.rfc-editor.org/info/rfc2711>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Peng, et al. Expires 20 August 2024 [Page 10]
Internet-Draft Processing HBH Opt Hdr February 2024
[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>.
13.2. Informative References
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Virtual Transport Network (VTN) Information in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-05, 6 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-05>.
[I-D.pthubert-detnet-ipv6-hbh]
Thubert, P. and F. Yang, "IPv6 Options for DetNet", Work
in Progress, Internet-Draft, draft-pthubert-detnet-ipv6-
hbh-07, 22 February 2022,
<https://datatracker.ietf.org/doc/html/draft-pthubert-
detnet-ipv6-hbh-07>.
[I-D.vyncke-v6ops-james]
Vyncke, E., Léas, R., and J. Iurman, "Just Another
Measurement of Extension header Survivability (JAMES)",
Work in Progress, Internet-Draft, draft-vyncke-v6ops-
james-03, 9 January 2023,
<https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-
james-03>.
[P4] https://p4.org/, "P4".
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>.
Peng, et al. Expires 20 August 2024 [Page 11]
Internet-Draft Processing HBH Opt Hdr February 2024
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014,
<https://www.rfc-editor.org/info/rfc7112>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9288] Gont, F. and W. Liu, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers at Transit
Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022,
<https://www.rfc-editor.org/info/rfc9288>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
In Situ Operations, Administration, and Maintenance
(IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
<https://www.rfc-editor.org/info/rfc9486>.
Authors' Addresses
Shuping Peng
Huawei Technologies
Beijing
China
Email: pengshuping@huawei.com
Peng, et al. Expires 20 August 2024 [Page 12]
Internet-Draft Processing HBH Opt Hdr February 2024
Zhenbin Li
Huawei Technologies
Beijing
China
Email: lizhenbin@huawei.com
Chongfeng Xie
China Telecom
China
Email: xiechf@chinatelecom.cn
Zhuangzhuang Qin
China Unicom
Beijing
China
Email: qinzhuangzhuang@chinaunicom.cn
Gyan Mishra
Verizon Inc.
United States of America
Email: gyan.s.mishra@verizon.com
Peng, et al. Expires 20 August 2024 [Page 13]
