Network Working Group Xian Zhang
Internet-Draft Young Lee
Intended status: Standards Track Huawei
Ramon Casellas
CTTC
Oscar Gonzalez de Dios
Telefonica I+D
Expires: April 17, 2013 October 18, 2012
Path Computation Element (PCE) Protocol Extension for Stateful PCE
Usage in GMPLS Networks
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2013.
Abstract
Zhang Expires April 2013 [Page 1]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
The Path Computation Element (PCE) facilitates Traffic Engineering
(TE) based path calculation in large, multi-domain, multi-region, or
multi-layer networks. PCE can be stateless or stateful. With the LSP
state information acquired from the network, a stateful PCE enables
a wide variety of applications, especially in GMPLS networks, such
as impairment-aware routing and wavelength assignment in wavelength-
switched optical networks (WSON), time-based scheduling applications.
This memo provides extensions required for PCE communication
protocol (i.e. PCEP) so as to enable the usage of a stateful PCE
capability in GMPLS networks. To be more specific, the PCEP
extensions specified in this memo include not only new objects but
also modification of existing objects in PCEP messages.
Conventions used in this document
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].
Table of Contents
Table of Contents .............................................. 2
1. Introduction ................................................ 3
2. PCEP Extensions ............................................. 4
2.1. Overview ............................................... 4
2.2. PCEP Extension for Stateful PCE Capability Advertisement and
Negotiation ................................................. 4
2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer
Networks ................................................. 5
2.3. LSP Delegation ......................................... 5
2.4. PCEP Extensions for LSP Synchronization .................6
2.5. Modification of Existing PCEP Messages and Procedures....6
2.6. Application-specific PCEP extensions for stateful PCE....7
2.6.1. Time-based Scheduling.............................. 7
2.6.1.1. PCEP Extension................................ 8
2.6.2. RWA in Impairment-aware Wavelength-switched Optical
Networks (WSON) ......................................... 10
3. IANA Considerations ........................................ 11
3.1. LayerCapability TLV.................................... 11
3.2. SERVICE-TIME Object.................................... 11
3.3. Extension to METRIC Object............................. 11
4. Manageability Considerations................................ 11
5. Security Considerations..................................... 11
6. References ................................................. 11
6.1. Normative References................................... 11
6.2. Informative References................................. 11
7. Contributors' Address....................................... 12
Zhang Expires April 2013 [Page 2]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
Authors' Addresses ............................................ 13
1. Introduction
[RFC 4655] presents the architecture of a Path Computation Element
(PCE)-based model for computing Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering Label Switched
Paths (TE LSPs). To perform such a constrained computation, a PCE
stores the network topology (i.e., TE links and nodes) and resource
information (i.e., TE attributes) in its TE Database (TED). To
request path computation services to a PCE, [RFC 5440] defines the
PCE Communication Protocol (PCEP) for communications between a Path
Computation Client (PCC) and a PCE, or between two PCEs. A PCC can
initiate a path computation request to a PCE through a Path
Computation Request (PCReq) message, and then the PCE will return
the computed route to the requesting PCC in response to a previously
received PCReq message through a PCEP Path Computation Reply (PCRep)
message.
As per [RFC 4655], a PCE can be stateless or stateful. Compared to a
stateless PCE, a stateful PCE stores not only the network state, but
also the set of computed paths and reserved resources in use in the
network. Note that [RFC4655] further specifies that the TED contains
link state and bandwidth availability as distributed by IGPs or
collected via other means. Even if such information can provide
finer granularity and more details, it is not state information in
the PCE context and so a model that uses it is still described as a
stateless PCE.
Stateful PCE(s) are shown to be helpful in many application
scenarios, especially in GMPLS networks, as illustrated in
[Stateful-APP]. In order for these applications to able to exploit
the capability of stateful PCE(s), extensions to the PCE
communication protocol (i.e., PCEP) are required.
It is expected that the PCEP extensions enabling stateful PCEs in
GMPLS networks will share common aspects with the extensions
developed for MPLS networks [Stateful-PCE]. Therefore, this document
focuses on the extensions unique to GMPLS networks while maintains a
complete picture of the PCEP extensions required for a stateful PCE
in general. In summary, this draft gives an overview of PCEP
extensions necessary for stateful PCE usage in GMPLS networks as
well as the details of required PCEP extension unique to stateful
PCE usage in GMPLS networks.
Zhang Expires April 2013 [Page 3]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
2. PCEP Extensions
2.1. Overview
According to the description in [Stateful-APP], the PCEP extensions
required for a stateful PCE in GMPLS networks should cover, at least,
the following two main functional requirements:
o Advertisement and negotiation of stateful PCE capability;
o LSP synchronization;
Attention should be paid in terms of the general considerations as
discussed in [Stateful-APP]. Since the extensions to these two
aspects are straightforward and have already been covered in
[Stateful-PCE], we only cover the points that are either relevant to
GMPLS or still missing in [Stateful-PCE].
In addition, the next functional requirements
o LSP Delegation;
As explained in [Stateful-APP], the ability to collect LSP state
information should be mandatory. As for PCE's ability to modify the
LSP attributes as presented in [Stateful-PCE] as well as how it is
enabled (per PCE base, per LSP base, or per NE base?) should be
operator-dependent and is for further study.
o Application-specific extensions;
[Stateful-APP] identifies the applications that a stateful PCE
enables. Such applications require PCEP extensions that are provided
in this document.
Since the LSP state is part of the information that a stateful PCE
possesses, some simplifications to PCEP are possible and explained
in this draft.
2.2. PCEP Extension for Stateful PCE Capability Advertisement and
Negotiation
Whether a PCE has stateful capability or not can be negotiated
during the PCEP session establishment process. It can also be
advertised through routing protocols as described in [RFC5088]. In
either case, the following additional aspects should also be
considered.
Zhang Expires April 2013 [Page 4]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer Networks
In multi-layer network scenarios where there is a PCE responsible
for each layer, then the PCCs should be informed of which PCE they
should synchronize their LSP states with as well as send path
computation requests to.
A new LayerCapability TLV is defined as shown below to denote to
which layer a PCE is in charge of LSP synchronization as well as
path computation. It can be included in the OPEN Object if
applicable. Alternatively, the extension to current OSPF PCED TLV is
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (T.B.D.) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Switching Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Switching Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3. LSP Delegation
The LSP state synchronization/update capability for LSPs that span
multiple domains adds additional complexity for the stateful PCE(s).
For instance, in a multi-domain networks where one PCE per domain is
adopted, each PCE is responsible for synchronizing, updating or
modifying the segment or part of the LSP within the network for
which the PCE is deployed. Moreover, a modification action of a
stateful PCE for partial LSP may trigger a chain of LSP updating
actions (e.g., informing other PCEs of the modification or
requesting other PCEs for additional modification).
This needs to be considered carefully and modification capability
specifications might be needed to limit the scope of LSP attribute
modification action to avoid conflicts.
[Editor Note: this needs clarification and further discussion. The
scenario with mixed stateful/stateless PCE might also cause
potential issues for LSP delegation ability. A use case and clearly
Zhang Expires April 2013 [Page 5]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
defined requirements are needed so not to try to cover all possible
cases, in view of concrete implementations]
2.4. PCEP Extensions for LSP Synchronization
For LSP state synchronization of stateful PCE(s) in GMPLS networks,
the LSP attributes, such as its bandwidth, associated label as well
as protection information etc, should be updated by PCC(s) to PCE
LSP database (LSP-DB).
As per [Stateful-PCE], it only covers LSP attributes pertaining to
MPLS networks, based on [RFC5440]. Therefore, extensions of PCEP
protocol for stateful PCE usage in GMPLS networks are required. The
following presents a list of objects/TLVs that should be used by
stateful PCE for LSP synchronization purpose when applied in GMPLS
networks:
o GENERALIZED BANDWIDTH
o PROTECTION ATTRIBUTE
o Extended Objects to support the inclusion of label sub-object
- RP
- IRO
- XRO
Note that the list above should also be used for path computation
requests/replies. Refer to [PCEP-GMPLS] for the details of these
objects/TLVs.
2.5. Modification of Existing PCEP Messages and Procedures
One of the advantages mentioned in [Stateful-APP] is that the
stateful nature of a PCE simplifies the information conveyed in PCEP
messages, notably between PCC and PCE, since it is possible to refer
to PCE managed state for active LSPs. To be more specific, with a
stateful PCE, it is possible to refer to a LSP with a unique
identifier in the scope of the PCC-PCEP session and thus use such
identifier to refer to that LSP.
Example 1: a PCC (e.g. NMS) requesting for a re-optimization of one
or several LSPs can send the request with ''R'' bit set and only
provides the relevant LSP unique identifier(s).
Zhang Expires April 2013 [Page 6]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
In order to support these, the LSP identifier TLV defined in
[Stateful-PCE] can be used in the RP Object to specify the request
LSP ID(s). Upon receiving the PCReq message, PCE should be able to
correlate with one or multiple LSPs with their detailed state
information and carry out optimization accordingly. The handling of
RP object specified in [RFC5440] is stated as following:
''The absence of an RRO in the PCReq message for a non-zero-bandwidth
TE LSP (when the R bit of the RP object is set) MUST trigger the
sending of a PCErr message with Error-Type="Required Object Missing"
and Error-value="RRO Object missing for reoptimization."
If a PCE has stateful capabilities, and such capabilities have been
negotiated and advertised, specific rules given in [RFC5440] may
need to be relaxed. In particular, the re-optimization case: if the
re-optimization request refers to a given LSP state, and the RRO
information is available, the PCE can proceed.
Example 2: in order to set up a LSP which has a constraint that its
route should not use resources used by one or more existing LSPs, a
PCC can send a PCReq with the identifier(s) of these LSPs. A
stateful PCE should be able to find the corresponding route and
resource information so as to meet the constraints set by the
requesting PCC. Hence, the LSP identifier TLV defined in [Stateful-
PCE] can be used in XRO object for this purpose.
2.6. Application-specific PCEP extensions for stateful PCE
[Editor's Note: this is not a complete list of application-specific
PCEP extensions. Suggestions are welcome on expansion on this
section.]
2.6.1. Time-based Scheduling
[Editor's note: synchronization is complex and we cannot assume that
the PCE and PCC clocks are equal and issues such as whether it
should be kept centralized or not will be reflected in the later
version.]
To support time-based scheduling, network operators need to reserve
resources in advance according to customers' requests with specified
starting time and duration. A simple utilization example of this
service is to support scheduled data transmission between data
centers or any generic scheduled based services.
Traditionally, this can be supported by NMS operation through path
pre-establishment and activation on the agreed starting time.
However, this does not provide efficient network usage since the
Zhang Expires April 2013 [Page 7]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
established paths exclude the possibility of being used by other
services even when they are not used for undertaking any service due
to the lack of a time-based mechanism. It can also be accomplished
through GMPLS protocol extensions by carrying the related request
information (e.g., starting time and duration) across the network.
Nevertheless, this method inevitably increases the complexity of
signaling and routing process.
Since a stateful PCE needs to collect LSP related information for
the whole network, it can naturally support this service with
resource usage flexibility (i.e., only excluding the time slot(s)
reserved for time-based scheduling requests). Moreover, it can avoid
the need to add complexity on network elements in this regard. A
stateful PCE should also maintain a database that stores all the
reserved information with time reference. This can be achieved
either by maintaining a separate database or having all the reserved
information with time reference incorporated into LSP-DB. The
details of organizing time-based scheduling related information are
subject to network provider's policy and administrative
consideration and thus outside of the scope of this document.
2.6.1.1. PCEP Extension
For a PCC to request a path computation for scheduled service, it
MUST be able to specify the time-related information, including the
starting time and LSP holding time, in PCEP request.
A SERVICE-TIME object is presented as follows to provide the
required information (i.e. service starting time and holding time).
The Object-Class is TBD and the Object-Type is 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Year | Month | Day |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hour | Minute | Second | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration (in seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
field Length range
----- ------ --------
Zhang Expires April 2013 [Page 8]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
Start-Year 16 bit 0..65536
Month 8 bit 1..12
Day 8 bit 1..31
Hour 8 bit 0..23
Minute 8 bit 0..59
Second 8 bit 0..59
The SERVICE-TIME object can be included in a PCEP request as
specified in the following manner:
<PCReq Message>::=<Common Header>
[<SVEC-list>]
<request-list>
Where:
[<svec-list>]::= <SVEC> [<svec-list>]
<request-list>::=<request>[<request-list>]
<request >::=<RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<SERVICE-TIME>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
WHERE:
<metric-list>::=<METRIC>[<metric-list>]
Zhang Expires April 2013 [Page 9]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
Upon receiving the PCReq message, PCE should compute the path taking
into consideration the constraints of the TED, LSP-DB as well as
other scheduled service information and return the computed route
back to the requesting PCC. If no path can be found, PCE should
return an error message specifying the reason.
2.6.2. RWA in Impairment-aware Wavelength-switched Optical Networks
(WSON)
In impairment-ware WSON networks, the routing and wavelength
assignment process needs to consider the constraints incurred by the
physical impairments. As described in [Stateful-APP], stateful PCE
can effectively reduce the control plane overhead by centrally
maintaining the impairment-information related to each LSP.
In order to establish an impairment-aware LSP, a path computation
request may need to specify the desired values and/or constraints
for one or more of the following parameters:
o Power
o OSNR
o PMD
o T.B.D.
Upon receiving the path computation request, a stateful PCE should
take into consideration the explicitly defined constraints as well
as those of the existing LSPs, stored in LSP-DB. Furthermore, a PCE
may need to reply in PCRep with the actual values of the one or more
of the above-mentioned parameters to the requesting PCC as well as
the adjustment needed. After receiving the reply message, the PCC
can take appropriate actions along the to-be-established paths in
tuning its power or changing other impairment-related parameters so
as to achieve the desired signal quality.
To support the above-mentioned requirements, the METRIC object
defined in [RFC5440] can be exploited with proper extension. A new
type value should be added.
T=T.B.D.: Impairment-aware information
Furthermore, as described in [PCE-IA-WSON], there are two types of
parameters that can be specified, i.e. path level or link level. If
a stateful PCE needs to reply with adjustment needed for path level
parameters. Then further extension to the METRIC object is desirable
and this will be considered in the future.
Zhang Expires April 2013 [Page 10]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
3. IANA Considerations
IANA is requested to allocate new Types for the TLV/Object defined
in this document.
3.1. LayerCapability TLV
3.2. SERVICE-TIME Object
3.3. Extension to METRIC Object
4. Manageability Considerations
TBD.
5. Security Considerations
TBD.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5088] Le Roux, JL., Vasseur, J.-P., Ikejiri, Y., Zhang, R.,
''OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery'', RFC 5088, April 2008.
6.2. Informative References
[Stateful-APP] Zhang, F., Zhang, X., Lee, Y., Casellas, R., Gonzalez
de Dios, O., "Applicability of Stateful Path Computation
Element (PCE) ", draft-zhang-pce-stateful-pce-app, work in
progress.
Zhang Expires April 2013 [Page 11]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
[Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., ''PCEP
Extensions for Stateful PCE'', draft-ietf-pce-stateful-pce,
work in progress.
[PCE-IA-WSON] Lee, Y., Bernstein G., Takeda, T., Tsuritani, T.,
''PCEP Extensions for WSON Impairments'', draft-lee-pce-
wson-impairments, work in progress.
[PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., ''PCEP
extensions for GMPLS'', draft-ietf-pce-gmpls-pcep-
extensions, work in progress.
7. Contributors' Address
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruvd@huawei.com
Zhang Expires April 2013 [Page 12]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
Authors' Addresses
Xian Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972913
Email: zhang.xian@huawei.com
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: ylee@huawei.com
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Phone:
Email: ramon.casellas@cttc.es
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.es
Intellectual Property
Zhang Expires April 2013 [Page 13]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions
of these Legal Provisions that are published by third parties,
including those that are translated into other languages, should
not be considered to be definitive versions of these Legal
Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect
and shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
Zhang Expires April 2013 [Page 14]
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt October 2012
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2012 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
(http://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.
Zhang Expires April 2013 [Page 15]