Internet Engineering Task Force Q. Wang, Ed.
Internet-Draft ZTE Corporation
Intended status: Informational R. Valiveti, Ed.
Expires: May 11, 2022 Infinera Corp
H. Zheng, Ed.
Huawei
H. Helvoort
Hai Gaoming B.V
S. Belotti
Nokia
November 7, 2021
Applicability of GMPLS for Beyond 100G Optical Transport Network
draft-ietf-ccamp-gmpls-otn-b100g-applicability-08
Abstract
This document examines the applicability of using existing GMPLS
routing and signalling mechanisms to set up Optical Data Unit-k
(ODUk) LSPs over Optical Data Unit-Cn (ODUCn) links as defined in the
2020 version of G.709.
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 May 11, 2022.
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
Wang, et al. Expires May 11, 2022 [Page 1]
Internet-Draft B100G Extensions November 2021
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. OTN terminology used in this document . . . . . . . . . . . . 3
3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 4
3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Tributary Slot Granularity . . . . . . . . . . . . . . . 6
3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 6
3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 7
4. GMPLS Implications and Applicability . . . . . . . . . . . . 8
4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 8
4.2. Implications and Applicability for GMPLS Signalling . . . 8
4.3. Implications and Applicability for GMPLS Routing . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The current GMPLS routing [RFC7138] and signalling [RFC7139]
extensions support the control of OTN signals and capabilities that
were defined in the 2012 version of G.709 [ITU-T_G709_2012].
In 2016 a further version of G.709 was published: [ITU-T_G709_2016].
This version introduced higher rate OTU and ODU signals, termed OTUCn
and ODUCn respectively, which have a nominal rate of n x 100 Gbit/s.
According to the definition in [ITU-T_G709_2016], OTUCn and ODUCn
perform only section layer role and ODUCn supports only ODUk clients.
This document focuses on the use of existing GMPLS mechanisms to set
up ODUk (e.g., ODUflex) LSPs over ODUCn links, independently from how
these links have been set up.
Wang, et al. Expires May 11, 2022 [Page 2]
Internet-Draft B100G Extensions November 2021
Since the [ITU-T_G709_2020] does not introduce any new features to
OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts
with [ITU-T_G709_2020] by first presenting an overview of the OTUCn
and ODUCn signals, and then analysing how the current GMPLS routing
and signalling mechanisms can be utilized to set up ODUk (e.g.,
ODUflex) LSPs over ODUCn links.
2. OTN terminology used in this document
a. LSP: Label Switched Path.
b. ODU: Optical Data Unit.
c. ODUCn: Optical Data Unit-Cn.
d. ODUflex: Optical Data Unit - flexible.
e. ODUk: Optical Data Unit-k
f. OPUCn: Optical Payload Unit-Cn. Where Cn indicates that the bit
rate is approximately n*100G.
g. OTUCn: Fully standardized Optical Transport Unit-Cn.
h. OTUCn-M: This signal is an extension of the OTUCn signal
introduced above. This signal contains the same amount of
overhead as the OTUCn signal, but contains a reduced amount of
payload area. Specifically, the payload area consists of M 5G
tributary slots (where M is strictly less than 20*n).
i. OTN: Optical Transport Network.
j. PSI: OPU Payload Structure Indicator. This is a 256-byte signal
that describes the composition of the OPU signal. This field is
a concatenation of the Payload type (PT) and the Multiplex
Structure Indicator (MSI) defined below.
k. MSI: Multiplex Structure Indicator. This structure indicates the
grouping of the tributary slots in an OPU payload area that
realizes a client signal which is multiplexed into an OPU. The
individual clients multiplexed into the OPU payload area are
distinguished by the Tributary Port Number (TPN).
Detailed description of these terms can be found in
[ITU-T_G709_2020].
Wang, et al. Expires May 11, 2022 [Page 3]
Internet-Draft B100G Extensions November 2021
3. Overview of the OTUCn/ODUCn in G.709
This section provides an overview of OTUCn/ODUCn signals defined in
[ITU-T_G709_2020]. The text in this section is purely descriptive
and is not normative. For a full description of OTUCn/ODUCn signals
please refer to [ITU-T_G709_2020]. In the event of any discrepancy
between this text and [ITU-T_G709_2020], that other document is
definitive.
3.1. OTUCn
In order to carry client signals with rates greater than 100 Gbit/s,
[ITU-T_G709_2020] takes a general and scalable approach that
decouples the rates of OTU signals from the client rate. The new OTU
signal is called OTUCn, and this signal is defined to have a rate of
(approximately) n*100G. The following are the key characteristics of
the OTUCn signal:
a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals
perform digital section roles only (see
[ITU-T_G709_2020]:Section 6.1.1)
b. The OTUCn signals can be viewed as being formed by interleaving n
OTUC signals (which are labeled 1, 2, ..., n), each of which has
the format of a standard OTUk signal without the FEC columns (per
[ITU-T_G709_2020] Figure 7-1). The OTUC signal contains the ODUC
signals.
c. Each of the OTUC instance have the same overhead as the standard
OTUk signal in [ITU-T_G709_2020]. The combined signal OTUCn has
n instances of OTUC overhead, ODUC overhead.
d. The OTUC signal has a slightly higher rate compared to the OTU4
signal (without FEC); this is to ensure that the OPUC payload
area can carry an ODU4 signal.
The OTUCn, ODUCn and OPUCn signal structures are presented in a
(physical) interface independent manner, by means of n OTUC, ODUC and
OPUC instances that are marked #1 to #n.
OTUCn interfaces can be categorized as follows, based on the type of
peer network element:
a. inter-domain interfaces: These types of interfaces are used for
connecting OTN edge nodes to (a) client equipment (e.g. routers)
or (b) hand-off points from other OTN networks. ITU-T
Recommendation [ITU-T_G709.1] specifies a flexible interoperable
short-reach OTN interface over which an OTUCn (n >=1) is
Wang, et al. Expires May 11, 2022 [Page 4]
Internet-Draft B100G Extensions November 2021
transferred, using bonded FlexO interfaces which belong to a
FlexO group.
b. intra-domain interfaces: In these cases, the OTUCn is transported
using a proprietary (vendor specific) encapsulation, FEC etc. It
is also possible to transport OTUCn for intra-domain links using
FlexO.
3.1.1. OTUCn-M
The standard OTUCn signal has the same rate as that of the ODUCn
signal. This implies that the OTUCn signal can only be transported
over wavelength groups which have a total capacity of multiples of
(approximately) 100G. Modern DSPs support a variety of bit rates per
wavelength, depending on the reach requirements for the optical path.
If the total rate of the ODUk LSPs planned to be carried over an
ODUCn link is smaller than n*100G, it is possible to "crunch" the
OTUCn not to transmit some of unused tributary slots. ITU-T supports
the notion of a reduced rate OTUCn signal, termed the OTUCn-M. The
OTUCn-M signal is derived from the OTUCn signal by retaining all the
n instances of overhead (one per OTUC instance) but with only M (M is
less than 20*n) OPUCn tributary slots available to carry ODUk LSPs.
3.2. ODUCn
The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being
formed by the appropriate interleaving of content from n ODUC signal
instances. The ODUC frames have the same structure as a standard ODU
-- in the sense that it has the same Overhead area, and the payload
area -- but has a higher rate since its payload area can embed an
ODU4 signal.
The ODUCn is a multiplex section ODU signal, and is mapped into an
OTUCn signal which provides the regenerator section layer. In some
scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e.
they will have identical source/sink locations. [ITU-T_G709_2020]
allows for the ODUCn signal to pass through a digital regenerator
node which will terminate the OTUCn layer, but will pass the
regenerated (but otherwise untouched) ODUCn towards a different OTUCn
interface where a fresh OTUCn layer will be initiated (see Figure 1).
In this case, the ODUCn is carried by 3 OTUCn segments.
Specifically, the OPUCn signal flows through these regenerators
unchanged. That is, the set of client signals, their TPNs, trib-slot
allocation remains unchanged.
Wang, et al. Expires May 11, 2022 [Page 5]
Internet-Draft B100G Extensions November 2021
+--------+ +--------+
| +-----------+ |
| OTN |-----------| OTN |
| DXC +-----------+ DXC +
| | | |
+--------+ +--------+
<--------ODUCn------->
<-------OTUCn------>
+--------+ +--------+ +--------+ +--------+
| +--------+ | | +----------+ |
| OTN |--------| OTN | | OTN |----------| OTN |
| DXC +--------+ WXC +--------+ WXC +----------+ DXC |
| | | 3R | | 3R | | |
+--------+ +--------+ +--------+ +--------+
<-------------------------ODUCn-------------------------->
<---------------> <---------------> <------------------>
OTUCn OTUCn OTUCn
Figure 1: ODUCn signal
3.3. Tributary Slot Granularity
[ITU-T_G709_2012] introduced the support for 1.25G granular tributary
slots in OPU2, OPU3, and OPU4 signals. [ITU-T_G709_2020] defined the
OPUC with a 5G tributary slot granularity. This means that the ODUCn
signal has 20*n tributary slots (of 5 Gbit/s capacity). The range of
tributary port number (TPN) is 10*n instead of 20*n, which restricts
the maximum client signals that could be carried over one single
ODUC1.
3.4. Structure of OPUCn MSI with Payload type 0x22
As mentioned above, the OPUCn signal has 20*n 5G tributary slots.
The OPUCn MSI field has a fixed length of 40*n bytes and indicates
the availability and occupation of each TS. Two bytes are used for
each of the 20*n tributary slots, and each such information structure
has the following format ([ITU-T_G709_2020]:Section 20.4.1):
a. The TS availability bit indicates if the tributary slot is
available or unavailable
b. The TS occupation bit indicates if the tributary slot is
allocated or unallocated
c. The tributary port number (14 bits) of the client signal that is
being carried in this specific TS. A flexible assignment of
Wang, et al. Expires May 11, 2022 [Page 6]
Internet-Draft B100G Extensions November 2021
tributary port to tributary slots is possible. Numbering of
tributary ports is from 1 to 10*n.
3.5. Client Signal Mappings
The approach taken by the ITU-T to map non-OTN client signals to the
appropriate ODU containers is as follows:
a. All client signals are mapped into an ODUk (e.g., ODUflex) as
specified in clause 17 of [ITU-T_G709_2020].
b. ODU Virtual Concatenation has been deprecated. This simplifies
the network, and the supporting hardware since multiple different
mappings for the same client are no longer necessary. Note that
legacy implementations that transported sub-100G clients using
ODU VCAT shall continue to be supported.
c. ODUflex signals are low-order signals only. If the ODUflex
entities have rates of 100G or less, they can be transported over
either an ODUk (k=1..4) or an ODUCn. For ODUflex connections
with rates greater than 100G, ODUCn is required.
Clients (e.g. SONET/SDH, Ethernet)
+ + +
| | |
+------------------+-------+------+------------------------+
| OPUk |
+----------------------------------------------------------+
| ODUk |
+-----------------------+---------------------------+------+
| OTUk, OTUk.V, OTUkV | OPUk | |
+----------+----------------------------------------+ |
| OTLk.n | | ODUk | |
+----------+ +---------------------+-----+ |
| OTUk, OTUk.V, OTUkV | OPUCn |
+----------+-----------------------+
| OTLk.n | | ODUCn |
+----------+ +------------+
| OTUCn |
+------------+
Figure 2: Digital Structure of OTN interfaces (from G.709:Figure 6-1)
Wang, et al. Expires May 11, 2022 [Page 7]
Internet-Draft B100G Extensions November 2021
4. GMPLS Implications and Applicability
4.1. TE-Link Representation
Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with
TE-Links in GMPLS. Similar to that, ODUCn links can also be
represented as TE-Links, which can be seen in the Figure 4.
+-----+ +-----+
| | | |
| A |<-OTUCn Link->| B |
| | | |
+-----+ +-----+
|<--- ODUCn Link -->|
|<---- TE-Link ---->|
3R 3R
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
|<----------------------- ODUCn Link ------------------------>|
|<------------------------ TE-Link -------------------------->|
Figure 3: ODUCn TE-Links
The two endpoints of a TE-Link are configured with the supported
resource information, which may include whether the TE-Link is
supported by an ODUCn or an ODUk or an OTUk, as well as the link
attribute information (e.g., slot granularity, list of available
tributary slot).
4.2. Implications and Applicability for GMPLS Signalling
Once the ODUCn TE-Link is configured, the GMPLS mechanisms defined in
[RFC7139] can be reused to set up ODUk/ODUflex LSPs with no changes.
As the resource on the ODUCn link which can be seen by the client
ODUk/ODUflex is a set of 5G slots, the label defined in [RFC7139] is
able to accommodate the requirement of the setup of ODUk/ODUflex over
ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is
used to indicate how the LO ODUj signal is multiplexed into the HO
ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object
is used to indicate how the ODUk signal is multiplexed into the ODUCn
link. The ODUk Signal Type is indicated by Traffic Parameters. The
IF_ID RSVP_HOP object provides a pointer to the interface associated
Wang, et al. Expires May 11, 2022 [Page 8]
Internet-Draft B100G Extensions November 2021
with TE-Link and therefore the two nodes terminating the TE-link know
(by internal/local configuration) the attributes of the ODUCn TE
Link.
Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14
bits, while this field in [RFC7139] only has 12 bits, some extension
work is needed. Given that a 12-bit TPN field can support ODUCn
links with up to n=400 (i.e. 40Tbit/s links), this extension is not
urgently needed.
An example is given in Figure 5 to illustrate the label format
defined in [RFC7139] for multiplexing ODU4 onto ODUC10. One ODUC10
has 200 5G slots, and twenty of them are allocated to the ODU4.
Along with the increase of "n", the label may become lengthy, an
optimized label format may be needed.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 3 | Reserved | Length = 200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Padding Bits(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Label format
4.3. Implications and Applicability for GMPLS Routing
For routing, it is deemed that no extension to current mechanisms
defined in [RFC7138] are needed. Because, once an ODUCn link is up,
the resources that need to be advertised are the resources that
exposed by this ODUCn link and the multiplexing hierarchy on this
link. Since the ODUCn link is the lowest layer of the ODU
multiplexing hierarchy, there is no need to explicitly define a new
Wang, et al. Expires May 11, 2022 [Page 9]
Internet-Draft B100G Extensions November 2021
value to represent the ODUCn signal type in the OSPF-TE routing
protocol.
The OSPF-TE extension defined in section 4 of [RFC7138] can be reused
to advertise the resource information on the ODUCn link to help
finish the setup of ODUk/ODUflex.
5. Acknowledgements
6. Authors (Full List)
Qilei Wang (editor)
ZTE
Nanjing, China
Email: wang.qilei@zte.com.cn
Radha Valiveti (editor)
Infinera Corp
Sunnyvale, CA, USA
Email: rvaliveti@infinera.com
Haomian Zheng (editor)
Huawei
CN
EMail: zhenghaomian@huawei.com
Huub van Helvoort
Hai Gaoming B.V
Wang, et al. Expires May 11, 2022 [Page 10]
Internet-Draft B100G Extensions November 2021
EMail: huubatwork@gmail.com
Sergio Belotti
Nokia
EMail: sergio.belotti@nokia.com
7. Contributors
Iftekhar Hussain, Infinera Corp, Sunnyvale, CA, USA,
IHussain@infinera.com
Daniele Ceccarelli, Ericsson, daniele.ceccarelli@ericsson.com
Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com
Fatai Zhang, Huawei,zhangfatai@huawei.com
Italo Busi, Huawei,italo.busi@huawei.com
Dieter Beller, Nokia, Dieter.Beller@nokia.com
Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn
Zafar Ali, Cisco Systems, zali@cisco.com
Daniel King, d.king@lancaster.ac.uk
Manoj Kumar, Cisco Systems, manojk2@cisco.com
Antonello Bonfanti, Cisco Systems, abonfant@cisco.com
Yuji Tochio, Fujitsu, tochio@fujitsu.com
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
This document analyses and reuses the protocol extensions in
[RFC7138] and [RFC7139] without introducing any new extensions.
Therefore, this document introduces no new security considerations to
the existing signalling protocol and routing protocol comparing to
[RFC7138] and [RFC7139]. Please refer to [RFC7138] and [RFC7139] for
further details of the specific security measures. Additionally,
Wang, et al. Expires May 11, 2022 [Page 11]
Internet-Draft B100G Extensions November 2021
[RFC5920] addresses the security aspects that are relevant in the
context of GMPLS.
10. References
10.1. Normative References
[ITU-T_G709_2020]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
06/2020", https://www.itu.int/rec/T-REC-
G.709-202006-I/en, June 2020.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/info/rfc7139>.
10.2. Informative References
[ITU-T_G709.1]
ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
2018", , 2018.
[ITU-T_G709_2012]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
02/2012", http://www.itu.int/rec/T-REC-
G..709-201202-S/en, February 2012.
[ITU-T_G709_2016]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
07/2016", http://www.itu.int/rec/T-REC-
G..709-201606-P/en, July 2016.
Wang, et al. Expires May 11, 2022 [Page 12]
Internet-Draft B100G Extensions November 2021
Authors' Addresses
Qilei Wang (editor)
ZTE Corporation
Nanjing
China
Email: wang.qilei@zte.com.cn
Radha Valiveti (editor)
Infinera Corp
Sunnyvale
USA
Email: rvaliveti@infinera.com
Haomian Zheng (editor)
Huawei
China
Email: zhenghaomian@huawei.com
Huub van Helvoort
Hai Gaoming B.V
Almere
Netherlands
Email: huubatwork@gmail.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Wang, et al. Expires May 11, 2022 [Page 13]