Internet DRAFT - draft-yang-rtgwg-ipv6-associated-channel
draft-yang-rtgwg-ipv6-associated-channel
RTGWG Working Group F. Yang
Internet-Draft M. Chen
Intended status: Standards Track T. Zhou
Expires: January 13, 2022 Huawei Technologies
July 12, 2021
Associated Channel over IPv6
draft-yang-rtgwg-ipv6-associated-channel-01
Abstract
This document introduces a control channel based on IPv6, called
Associated CHannel over IPv6 (ACH6), that may carry different types
of control and management messages. By using the associated channel,
messages can be transmitted between network nodes to provide
functions like path identification, OAM, automatic protection
switchover signaling, resource reservation, etc., targeting to
provide high quality SLA guarantees to IPv6 services.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [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/.
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 January 13, 2022.
Yang, et al. Expires January 13, 2022 [Page 1]
Internet-Draft IPv6 Associated Channel July 2021
Copyright Notice
Copyright (c) 2021 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture of Associated Channel over IPv6 . . . . . . . . 4
3.1. ACH6 Network Reference Model . . . . . . . . . . . . . . 4
3.2. ACH6 Processing . . . . . . . . . . . . . . . . . . . . . 5
4. Format of Associated Channel over IPv6 . . . . . . . . . . . 5
4.1. Identification of ACH6 . . . . . . . . . . . . . . . . . 5
4.2. Carried Message of ACH6 . . . . . . . . . . . . . . . . . 6
4.3. ACH6 TLV Format . . . . . . . . . . . . . . . . . . . . . 6
4.4. Encapsulation of ACH6 TLV in IPv6 . . . . . . . . . . . . 7
4.4.1. Encapsulated in IPv6 Destination Options Header . . . 7
4.4.2. Encapsulated in IPv6 Hop-by-Hop Options Header . . . 7
4.4.3. Encapsulated in IPv6 Segment Routing Header . . . . . 8
4.4.4. Encapsulated in Payload . . . . . . . . . . . . . . . 9
4.5. Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Path Identification . . . . . . . . . . . . . . . . . . . 10
5.2. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Assist to Protection Switchover . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Yang, et al. Expires January 13, 2022 [Page 2]
Internet-Draft IPv6 Associated Channel July 2021
1. Introduction
IPv6 is becoming widely accepted to provide connectivity in many new
emerging scenarios, including Cloud Network convergence, Cloud-Cloud
interconnection, 5G vertical industries, and Internet of Things etc.
However, due to the best effort forwarding genes, native IP (for both
IPv4 and IPv6) cannot provide the forwarding capabilities such as
explicit path, control and management based on the forwarding path,
to meet the requirements of services accordingly.
Generic Associated Channel (G-ACh) [RFC5586] introduces an associated
control channel to MPLS to provide a set of maintenance functions,
including OAM, performance monitoring, automatic protection switching
and support of management to MPLS Sections, MPLS Label Switched Paths
(LSPs), and MPLS pseudowires (PWs).
Triggered by MPLS G-ACh, to enhance the control and management
capabilities to IPv6, this document introduces an associated channel
to a specific IPv6 path, called Associated Channel over IPv6 (ACH6).
Associated channel over IPv6 intends to create a control channel
associated with the IPv6 data forwarding path for control and
management purposes. By using the associated channel, messages can
be transmitted between the network nodes to provide functions like
path identification, OAM, automatic protection switchover signaling,
resource reservation, etc., targeting to provide high quality SLA
guarantees to services. To identify an IPv6 forwarding path,
associated channel ID is also introduced.
This document defines an ACH6 architecture, a TLV-based format of
ACH6, and discusses how ACH6 format can be encapsulated in IPv6
packet. It also discusses the applicability of ACH6 in IPv6 network.
2. Terminology
This document uses the terminology defined in [RFC8200] , and it also
introduces the following new terms:
OAM: Operations, Administration, and Maintenance
SLA: Service Level Agreement
G-ACh: Generic Associated Channel
ACH6: Associated CHannel over IPv6
Yang, et al. Expires January 13, 2022 [Page 3]
Internet-Draft IPv6 Associated Channel July 2021
3. Architecture of Associated Channel over IPv6
3.1. ACH6 Network Reference Model
Figure 1 gives a network reference model of associated channel over
IPv6. The key components in ACH6 network reference model include
ACH6 Ingress Node, ACH6 Mid-Point Node, and ACH6 Egress Node. These
nodes must be IPv6-capable node.
+----+ +-------+ +---------+ +------+ +----+
----| Nx |---| ACH6 |----| ACH6 |---| ACH6 |---| Ny |----
| | |Ingress| |Mid-Point| |Egress| | |
+----+ +-------+ +---------+ +------+ +----+
|<-----------IPv6 Path----------->|
|<--------------ACH6------------->|
|<-----------------------IPv6 Network---------------------->|
Figure 1 ACH6 Network Reference Model
In the network reference model,
Nx/Ny: IPv6 node, can be either a host or a router.
ACH6 Ingress Node: is the node indicates the entering of control and
management channel over an IPv6 path, where control and management
messages are generated and encapsulated.
ACH6 Mid-Point Node: is the node that has the capability to process
control and management messages over an IPv6 path. For a strict
explicit IPv6 path, all the IPv6 hop(s) forwarded from IPv6 source
address to IPv6 destination address are mid-point node(s).
ACH6 Egress Node: is the node indicates the exiting of control and
management channel over an IPv6 path, where control and management
messages are recovered and delivered to control or management plane
for further process.
IPv6 Path: a specific path from the source node to the destination
node in IPv6 forwarding plane. An IPv6 path can be explicitly or
implicitly represented by forwarding hops from IPv6 source node to
IPv6 destination node.
ACH6: Associated Channel over IPv6
Yang, et al. Expires January 13, 2022 [Page 4]
Internet-Draft IPv6 Associated Channel July 2021
3.2. ACH6 Processing
Regarding to an IPv6 path, an ACH6 control channel is established to
this specific IPv6 path for a required purpose. ACH6 ingress node
acts as the IPv6 source node, and ACH6 egress node is the IPv6
destination node. ACH6 ingress node encapsulates control or
management messages into IPv6 packets, identifies the specific
channel type which carried messages belong to, and sends the IPv6
ACH6 packets to the destination of IPv6 path. The control and
management messages can either piggyback with data packets, or
generated and transmitted separately.
When ACH6 Mid-Point Node receives ACH6 IPv6 packets, it firstly
recognizes ACH6 associated channel to interpret the control protocol,
and then processes the messages. The processing of messages can
include for example READ or/and WRITE, depending on the specification
of protocols used in the associated channel. ACH6 Mid-Point Node
needs to transmit the IPv6 packets carried with the original or
modified ACH6 messages to the destination of IPv6 packet.
ACH6 Egress Node receives ACH6 IPv6 packets and recognizes itself as
the destination. Based on the specific type of control protocol, the
message is delivered to control or management planes for further
process.
4. Format of Associated Channel over IPv6
An associated channel provides a control channel that carries at
least one or more types of control and management messages. The type
of message is not limited to any specific usage. The associated
channel is specified by two pieces of information, including the
identification of the associated channel and the carried message.
4.1. Identification of ACH6
The identification of associated channel, called Associated Channel
ID, indicates the path where the packets of the associated channel
are transmitted on. This identification also indicates the same path
of the service forwarding path with which the associated channel is
associated. When the Associated Channel ID is carried in the
associated channel, ACH6 edge nodes and intermediated nodes should
interpret it to identify the same IPv6 path.
The associated channel ID can be defined either globally unique or
site local, or even link local. The Associated Channel ID can be
self-generated, or designated from management plane, or advertised
and allocated via control protocol.
Yang, et al. Expires January 13, 2022 [Page 5]
Internet-Draft IPv6 Associated Channel July 2021
4.2. Carried Message of ACH6
At least one control or management protocol messages are transmitted
via associated channel over IPv6. When multiple protocols are
running over an IPv6 path, messages of different protocols can be
sent either in separate ACH6 TLVs in one ACH6 packet or in separate
ACH6 packets with only one type of ACH6 TLV.
4.3. ACH6 TLV Format
An Associated CHannel over IPv6 (ACH6) TLV is designed to carry the
identification and carried message of an associated channel. ACH6
TLV has the following format:
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=TBD1 | length | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Associated Channel ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 ACH6 TLV Format
Type: 8 bits, indicates it is an associated channel ACH6 TLV, and
request a value assigned by IANA. The uniform type of TLV
generalizes the applicability of ACH6 TLV to support various types of
messages.
Length: 8 bits, defines the length of Value field in bytes.
Channel Type: is a 16-bit-length fixed portion of Value field. It
indicates the specific type of messages carried in associated
channel. Note that a new ACH6 TLV Channel Type Registry would be
requested to IANA. In later documents which specify application
protocols of associated channel, MUST also specify the applicable
Channel Type field value assigned by IANA.
Associated Channel ID: indicates the identification of associated
channel. The length is TBD.
Value: is a variable portion of Value field. It specifies the
messages indicated by Channel Type and carried in associated channel.
Yang, et al. Expires January 13, 2022 [Page 6]
Internet-Draft IPv6 Associated Channel July 2021
Note that the Value field of ACH6 TLV MAY contain sub-TLVs to provide
additional context information to ACH6 TLV.
4.4. Encapsulation of ACH6 TLV in IPv6
In the context of IPv6, ACH6 TLV can be encapsulated in different
types of IPv6 extension headers, or as an independent IPv6 payload.
Note that, no matter which way ACH6 TLV is applied, there is no
semantic change to IPv6 extension headers.
4.4.1. Encapsulated in IPv6 Destination Options Header
ACH6 TLV can be encapsulated in IPv6 Destination Options Header as
the TLV-encoded options. Figure 2 gives an example of an ACH6 TLV
encapsulated in IPv6 Destination Options Header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Opt Type(ACH6)| Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+
| Channel Type | Associated Channel ID // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Option
~ Value (depends on the specific protocol) ~ Data
~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+
Figure 3 ACH6 TLV in IPv6 Destination Options Header
According to the note 1 and note 3 described in section 4.1
of[RFC8200], ACH6 TLV encapsulated in IPv6 Destination Options Header
can provide two semantics of an associated channel. When only IPv6
Destination Options Header exists or IPv6 Destination Options Header
exists after the Routing Header, an end to end associated channel is
provided to transmit the messages between two endpoints. When both
IPv6 Destination Options Header and Routing Header exist, and IPv6
Destination Options Header exists before the Routing Header, an
associated channel is provided at network nodes of the first
destination that appears in the IPv6 Destination Address field plus
subsequent destinations listed in the Routing header.
4.4.2. Encapsulated in IPv6 Hop-by-Hop Options Header
ACH6 TLV can be encapsulated in IPv6 Hop-by-Hop Options Header as the
TLV-encoded options. Same option type numbering space is used for
both Hop-by-Hop Options header and Destination Options header.
Yang, et al. Expires January 13, 2022 [Page 7]
Internet-Draft IPv6 Associated Channel July 2021
Similarly, the ACH6 TLV in IPv6 Hop-by-Hop Options Header shares the
same encapsulation shown in Figure 3.
When it is encapsulated in IPv6 Hop-by-Hop Options Header, it
provides an associated channel at every node along the forwarding
path. ACH6 ingress node inserts the IPv6 HbH Option Header with ACH6
Option Type, every mid-point node examines, processes and transmits
the IPv6 packet to next forwarding hop. ACH6 egress node receives
the IPv6 packet as the destination node, ACH6 messages are processed
and delivered to control or management plane for further usage.
Processing is limited, can be READ and/or REWRITE.
Routers that are not configured to support Hop-by-Hop Options SHOULD
ignore this option and SHOULD forward the packet.
Routers that support Hop-by-Hop Options, but that are not configured
to support this option SHOULD ignore the option and SHOULD forward
the packet.
4.4.3. Encapsulated in IPv6 Segment Routing Header
ACH6 TLV can be encapsulated in IPv6 Segment Routing Header, as SRH
optional TLV. Figure 3 gives an example of an ACH6 TLV encapsulated
in IPv6 Segment Routing Header.
Yang, et al. Expires January 13, 2022 [Page 8]
Internet-Draft IPv6 Associated Channel July 2021
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Segment List[0] (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Segment List[n] (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=ACH6 | Length | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Associated Channel ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value (depends on the specific protocol) ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Other Optional Type Length Value objects (variable) ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 ACH6 TLV in IPv6 Segment Routing Header
When ACH6 TLV is encapsulated in IPv6 Segment Routing Header, it
provides an associated channel at every SRv6 endpoints along the
path.
4.4.4. Encapsulated in Payload
ACH6 TLV can also be encapsulated in the payload of an IPv6 packet.
The term payload here means the octets after the IPv6 header and
extension headers. A synthetic packet is created with the payload of
messages. and transmitted in an associated channel. The synthetic
packet can use the same routing information with service data whose
associated channel it is associated. For example, synthetic packet
can encapsulate the same segment list as the one used in IPv6 SRH of
service data. If ACH6 TLV format is encapsulated in payload, TLV
Type and Length can be omitted, a new codepoint of IP Protocol
Numbers should be assigned.
Yang, et al. Expires January 13, 2022 [Page 9]
Internet-Draft IPv6 Associated Channel July 2021
4.5. Considerations
When ACH6 TLV is deployed in either IPv6 extension headers or payload
in IPv6 networks, there are serveral considerations needs to be taken
into account:
C1: MTU Increase
Given that ACH6 messages increases the packet size of IPv6 packet, it
may face the risk of exceeding the PMTU. This problem can be solved
by taking two things into considerations. Firstly, the mechanism of
each protocol should clearly specify the maximum size limit of
carried messages in one IPv6 packet. Secondly, operators or hosts
who makes use of ACH6 to carry control and management messages should
carefully design and ensure the addition of messages would not exceed
the agreed PMTU.
C2: Processing of IPv6 Extension Header
Though IPv6 Extension Headers especially IPv6 Hop-by-Hop Option
Header is not widely used in the Internet, there are some limited
environments like Data Centers and Interconnections between Data
Centers are experimentally using IPv6 Option Headers. It is worth to
keep the possibility of carrying ACH6 messages as Option in IPv6
Extension Headers.
5. Applicability
5.1. Path Identification
In a native IPv6 network, packets are transmitted hop by hop, there
is no way to identify an IPv6 forwarding path. The path needs to be
identified when OAM or protection switchover is applied to the path.
5.2. OAM
OAM includes a group of functions such as connectivity verification,
fault indication and detection, and performance measurement of loss
and delay etc. For example, BFD defines a generic control packet
format that can be encapsulated in different data planes to provide
low-overhead and short-duration failure detection function. The
format can also be encapsulated in ACH6 TLV as the option TLV of
Destination Options Header, to provide the same connectivity
verification and fault detect functions without introducing upper
layer protocols. Another example is to encapsulate PDU formats of
Ethernet OAM [ITU-T G.8013] in Value field of ACH6 TLV to provide a
set of OAM functions. By using ACH6 TLV to carry OAM messages in an
associated channel, different OAM functions can be easily integrated.
Yang, et al. Expires January 13, 2022 [Page 10]
Internet-Draft IPv6 Associated Channel July 2021
The OAM functions can be performed in either end-to-end or hop-by-hop
mode. For example, signal degradation that happens on the
intermediate node could be discovered and further indicated in
associated channel to monitor the path status.
5.3. Assist to Protection Switchover
Linear protection [RFC6378] provides a very flexible protection
mechanism in a mesh network because it can operate between any pair
of endpoints. ACH6 TLV can be used to transmit the protection state
control messages on an IPv6 forwarding path to provide the function
of bidirectional protection switchover.
6. IANA Considerations
o This document requests IANA to assign a codepoint of Destination
Options and Hop-by-Hop Options.
o This document requests IANA to assign a codepoint of Segment
Routing Header TLVs to indicate ACH6 TLV.
o This document request IANA to create a new registry of IPv6 ACH6
Channel Types to identify the usage of associated channel.
7. Security Considerations
TBD
8. Acknowledgements
TBD
9. References
9.1. Normative References
[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>.
[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>.
Yang, et al. Expires January 13, 2022 [Page 11]
Internet-Draft IPv6 Associated Channel July 2021
[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>.
9.2. Informative References
[I-D.ietf-spring-srv6-path-segment]
Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi,
"Path Segment for SRv6 (Segment Routing in IPv6)", draft-
ietf-spring-srv6-path-segment-00 (work in progress),
November 2020.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <https://www.rfc-editor.org/info/rfc6378>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
Authors' Addresses
Fan Yang
Huawei Technologies
Beijing
China
Email: shirley.yangfan@huawei.com
Yang, et al. Expires January 13, 2022 [Page 12]
Internet-Draft IPv6 Associated Channel July 2021
Mach(Guoyi) Chen
Huawei Technologies
Beijing
China
Email: mach.chen@huawei.com
Tianran Zhou
Huawei Technologies
Beijing
China
Email: zhoutianran@huawei.com
Yang, et al. Expires January 13, 2022 [Page 13]
