Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks
draft-zhang-pce-pcep-stateful-pce-gmpls-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Xian Zhang , Young Lee , Ramon Casellas , Oscar Gonzalez de Dios | ||
| Last updated | 2012-07-08 | ||
| Replaced by | draft-ietf-pce-pcep-stateful-pce-gmpls, draft-ietf-pce-pcep-stateful-pce-gmpls, RFC 9504 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-pce-pcep-stateful-pce-gmpls-00
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: January 07, 2013 July 07, 2012
Path Computation Element (PCE) Protocol Extension for Stateful PCE
Usage in GMPLS Networks
draft-zhang-pce-pcep-stateful-pce-gmpls-00.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 January 07, 2013.
Abstract
Zhang Expires January 2013 [Page 1]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 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 exhibits
superiority in facilitating 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, with regard to stateful PCE usage in GMPLS networks.
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. PCEP Simplification .....................................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) .......................................... 9
3. IANA Considerations ........................................ 10
3.1. LayerCapability TLV.................................... 10
3.2. SERVICE-TIME Object.................................... 10
3.3. Extension to METRIC Object............................. 10
4. Manageability Considerations................................ 10
5. Security Considerations..................................... 11
6. References ................................................. 11
6.1. Normative References................................... 11
6.2. Informative References................................. 11
Zhang Expires January 2013 [Page 2]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
7. Contributors' Address....................................... 12
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 there are common aspects for stateful PCE PCEP
extension in GMPLS networks with that in 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 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 January 2013 [Page 3]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
2. PCEP Extensions
2.1. Overview
According to the description in [Stateful-APP], a summary of PCEP
extensions required for stateful PCE in GMPLS networks is provided
as follows:
o Advertisement and negotiation of stateful PCE capability;
o LSP synchronization;
These two are fundamental extension requirements needed in order to
make a stateful PCE functional. 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].
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 Simplification of the existing PCEP protocol [RFC5440];
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.
o Application-specific extensions desired;
A list of examples is provided in [Stateful-APP] and they may
require additional extensions or modification of the PCEP protocol.
In this draft, we present the PCEP extensions for some typical
application examples.
2.2. PCEP Extension for Stateful PCE Capability Advertisement and
Negotiation
Whether a PCE has the 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 January 2013 [Page 4]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 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
If a LSP span across multiple domains and the delegation features
presented in [Stateful-PCE] is supported, it adds complexity to LSP
state synchronization/update. For instance, in a multi-domain
networks where one PCE per domain is adopted, a contiguous LSP is
setup which spans across multiple domains. Then, each PCE is
responsible for synchronizing/updating or is able to modify only
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 of 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(?).
Zhang Expires January 2013 [Page 5]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
[Editor Note: this needs clarification and further discussion. The
scenario with mixed stateful/stateless PCE might also cause
potential issues for LSP delegation ability.]
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. PCEP Simplification
One of the merits mentioned in [Stateful-APP] is its ability to
simplify the information exchange between PCC and PCE. To be more
specific, with a stateful PCE, it is possible for PCCs to carry only
LSP ID information, instead of giving detailed LSP information (such
as route), whenever necessary.
Example 1: a PCC (e.g. NMS) requesting for a re-optimization of
several LSPs, it can send the request with relevant LSP IDs.
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
Zhang Expires January 2013 [Page 6]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
correlate with one or multiple LSPs with their detailed state
information and carry out optimization accordingly.
Example 2: in order to set up a LSP which is diversified with one or
more specific LSPs, a PCC can send a PCReq with the ID 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.
In order to support this, a new subobject type should be supported,
i.e. LSP ID(s). 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
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
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
Zhang Expires January 2013 [Page 7]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
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
----- ------ --------
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>]
Zhang Expires January 2013 [Page 8]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
<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>]
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.
Zhang Expires January 2013 [Page 9]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
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.
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.
Zhang Expires January 2013 [Page 10]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
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, January 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.
[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.
Zhang Expires January 2013 [Page 11]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012
7. Contributors' Address
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruvd@huawei.com
Zhang Expires January 2013 [Page 12]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 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 January 2013 [Page 13]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 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 January 2013 [Page 14]
draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 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 January 2013 [Page 15]