Network Working Group Fatai Zhang
Internet Draft Suresh B R
Young Lee
SenthilKumarS
Category: Standards Track Jun Sun
Huawei
Expires: August 20, 2010 February 21 2010
Extensions to the Path Computation Element Communication Protocol for
Traffic Engineering Label Switched Paths in GMPLS Networks
draft-zhang-pce-pcep-extensions-for-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 August 20, 2010.
Abstract
This document defines the extensions for the Path Computation Element
Communication Protocol (PCEP) to support the establishment of TE LSPs
in GMPLS networks.
zhang Expires August 2010 [Page 1]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
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 [RFC2119].
Table of Contents
1. Introduction.................................................2
1.1. Requirements Language...................................3
2. Terminology..................................................3
3. PCEP Requirements............................................3
4. Protocol Procedure and Extensions............................4
4.1. SWITCH-LAYER Object.....................................4
4.2. END-POINTS Object Extension.............................4
4.2.1. Destination Prefix Information TLV.................4
4.3. New Object - QoS........................................5
4.3.1. Traffic Parameters TLV.............................6
4.3.2. LSP Protection Information TLV.....................7
4.3.3. SWITCH-LAYER and QoS Object in PCReq and PCRep.....7
4.4. NO-PATH Object Extension................................8
4.4.1. Extensions to NO-PATH-VECTOR TLV...................9
4.5. Additional Error Type and Error Values Defined..........9
5. Liveness Detection and Monitoring...........................10
6. IANA Considerations.........................................10
6.1. New PCEP Object........................................10
6.2. New PCEP TLVs..........................................11
6.3. PCEP NO-PATH-VECTOR TLV Flag Field.....................11
6.4. New PCEP Error Codes...................................12
7. Security Considerations.....................................12
8. Acknowledgements............................................12
9. References..................................................12
9.1. Normative References...................................12
9.2. Informative References.................................14
10. Authors' Addresses.........................................14
1. Introduction
RFC4655 defines the PCE based architecture and explains how a PCE may
compute LSPs in MPLS Traffic Engineering (TE) and GMPLS) networks at
the request of Path Computation Clients (PCCs).
zhang Expires August 2010 [Page 2]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
RFC5440 specifies the PCEP for communication between a PCC and a PCE,
or between two PCEs, in compliance with RFC4657. However, that it
does not provide a mechanism to request path computation for
establishing TE LSPs in GMPLS networks such as SDH network. [GMPLS-
REQ] addresses the functional requirements for GMPLS in PCE
application.
This document describes the protocol extensions to PCEP to support
path computation for TE LSP in GMPLS networks.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
2. Terminology
The following terminology is used in this document.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation
Element.
PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
PCEP: Path Computation Element Communication Protocol. PCEP is a
request/response protocol used for the communication between a
PCC and a PCE, or between two PCEs.
PCEP Peer: An element involved in a PCEP session (For example, a PCC
or a PCE).
PCEP Session: The PCEP session is a logical connection established
automatically between the PCEP peers.
This document also uses the terminology defined in RFC4655, and
RFC5440.
3. PCEP Requirements
This section summarizes the PCEP extensions for GMPLS. This document
introduces no new messages for PCEP. However, extensions have been
introduced to the existing PCEP objects, sub-objects and TLVs. Also,
zhang Expires August 2010 [Page 3]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
a few new objects and TLVs have been introduced to support network
type and QoS. The details on the PCEP objects and TLVs are mentioned
below:
Enhanced Objects
o PCEP End Point (IPv4/Node ID) Object
o PCEP NO-PATH Object
Newly Introduced Object
o PCEP QoS Object
Newly Introduced TLVs
o Destination Prefix Information
o Traffic Parameters
o LSP Protection Information
4. Protocol Procedure and Extensions
4.1. SWITCH-LAYER Object
The PCE architecture can be extended to support various network types
such as SDH, WDM, OTN, and PTN and so on. PCE MAY select the
appropriate policy profile depending on the current path request
which is applicable to a particular network type.
The SWITCH-LAYER object is an OPTIONAL object and MUST be carried
only in PCReq and PCRep message specifying the encoding and switching
type of the network, to which the path request belongs to. This
object is defined in [INTER-LAYER] (Section 3.2).
4.2. END-POINTS Object Extension
The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the path for
which a path computation is requested. New OPTIONAL TLV is defined
that is to be carried in the END-POINTS object for the path that
depends on destination prefix information.
4.2.1. Destination Prefix Information TLV
The Destination Prefix Information TLV is a new OPTIONAL TLV. It MUST
only appear inside END-POINTS (IPv4/Node ID) object. The receiver
SHOULD ignore the Destination Prefix Information TLV if it appears in
zhang Expires August 2010 [Page 4]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
any other object other than END-POINTS object. This TLV contains the
prefix length for the destination IPv4 address and will appear when
prefix length is in the range between 0 and 32 (inclusive).
The format of the Destination Prefix Information TLV is as follows:
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 = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination | Flags |E| Reserved |
| Prefix Length | Field |M| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Prefix Length (8-bits) - Specifies the prefix length of
the destination IPv4 address.
Flags Field (7-bits) - Reserved for future to define new flags. It
MUST be filled with zeros and SHOULD be ignored by the receiver.
EM- Exact Prefix Match (1-bit) - Specifies whether exact prefix match
is required for the destination IPv4 address.
Bit EM Type
0 Exact prefix match is not required
1 Exact prefix match is required
Reserved (16-bits) - Reserved. MUST be set to zero and SHOULD be
ignored by the receiver.
4.3. New Object - QoS
When a PCC requests a PCE for a route, and if PCE provides the
response to the request, it MAY be useful for the PCC and the PCE to
include the traffic parameters. These traffic parameters specify a
base set of capabilities for GMPLS networks such as Service Level
Agreement (SLA), protection scheme, segment recovery, concatenation,
transparency, and so on. The QoS object handles the quality of
service parameters for TE-LSPs in GMPLS networks.
The QoS object can be included in the PCReq and PCRep messages by the
PCC and PCE respectively. It represents the parameters that become
necessary to manage bandwidth in the networks. When a PCE cannot find
a path by satisfying a set of constraints requested by the PCC, the
zhang Expires August 2010 [Page 5]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
PCE may also include the original constraint so as to indicate the
reason for an unsuccessful computation in the NO-PATH object. Based
on the available service parameters proposed by a PCE, the PCC MAY
decide to resend the path requests. These parameters ensure that the
applications are guaranteed the network resources they need, despite
varying traffic load.
The format of the QoS object is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Class | OT |Res|P|I| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Traffic Parameters TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// LSP Protection Information TLV //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class (8-bits) - Specifies the class of the object (Value =
25).
OT - Object Type (4-bits) - Specifies the type of the object (Value =
1).
4.3.1. Traffic Parameters TLV
For different networks, different traffic parameters should be
embedded in the Traffic Parameters TLV, which is a new OPTIONAL TLV.
The following types are defined currently:
Object Type Name Remarks
34 SDH-Traffic SDH/Sonet networks
35 G.709-Traffic OTN digital wrapper
36 WSON-Traffic WSON
37 Ethernet-Traffic Ethernet
38 PTN TBD
For SDH-Traffic, the contents of this object are identical in
encoding to the contents of the Resource Reservation Protocol Traffic
zhang Expires August 2010 [Page 6]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
Engineering Extensions (RSVP-TE)SONET and SDH Parameters defined in
RFC4606 (section 2.1).
For G.709-Traffic, the contents of this object are identical with the
Traffic Parameters defined in [OTN-SIG].
For WSON-Traffic and Ethernet-Traffic, we can refer to [WSON-SIG] and
[Eth-Traffic].
4.3.2. LSP Protection Information TLV
The LSP Protection Information TLV is a new OPTIONAL TLV and MUST
only appear inside QoS object. This TLV contains the LSP recovery
attributes, LSP association and protection constraints that are
required during signaling to support end-to-end LSP recovery.
The information of end-to-end LSP recovery during GMPLS signaling is
already defined in RFC4872 and RFC4873. Henceforth, the contents of
LSP Protection Information TLV defined in this document is identical
to the Protection Object defined in RFC4873 (section 6.1).
LSP Protection Information TLV type is 40.
4.3.3. SWITCH-LAYER and QoS Object in PCReq and PCRep
As mentioned earlier the SWITCH-LAYER and QoS object MAY be included
in the PCReq message. These objects are OPTIONAL, and if QoS object
is present only one instance of SDH-ASON QoS parameters TLV or LSP
protection TLV must be included. If multiple instances of TLV or some
other TLV is present, then the complete message has to be discarded
without performing any further processing.
The format of the PCReq message including the SWITCH-LAYER and QoS
object is as follows:
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>[<svec-list>]
<request-list> ::= <request>[<request-list>]
<request> ::= <RP>
<SWITCH-LAYER>
zhang Expires August 2010 [Page 7]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<QoS>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
The format of the PCRep message is as follows:
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list> ::= <response>[<response-list>]
<response> ::= <RP>
<SWITCH-LAYER>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path>[<path-list>]
<path> ::= <ERO><attribute-list>
where:
<attribute-list> ::= [<LSPA>]
[<BANDWIDTH>]
[<QoS>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC>[<metric-list>]
4.4. NO-PATH Object Extension
The NO-PATH object is used in PCRep messages in response to an
unsuccessful path computation request (the PCE could not find a path
by satisfying the set of constraints). In this scenario, PCE MUST
include a NO-PATH object in the PCRep message.
zhang Expires August 2010 [Page 8]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
The NO-PATH object carries the NO-PATH-VECTOR TLV that specifies more
information on the reasons that led to a negative reply. In case of
GMPLS networks there could be some more additional constraints that
led to the failure like protection mismatch, lack of resources, and
so on. Few new flags have been introduced in 32-bit flag field of the
NO-PATH-VECTOR TLV and no modifications have been made in the NO-PATH
object.
4.4.1. Extensions to NO-PATH-VECTOR TLV
The modified NO-PATH-VECTOR TLV carrying the additional information
is as follows:
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 = 1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |N|P|U|U|N|
| Field |R|M|S|D|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NP - PCE currently unavailable
UD - Unknown destination
US - Unknown source
New fields PM and NR are defined in the 28th and 27th bit of the
Flags field respectively.
PM - Protection Mismatch (1-bit). Specifies the mismatch of the
protection type in the request.
NR - No Resource (1-bit). Specifies that the resources are not
currently sufficient to provide the path.
4.5. Additional Error Type and Error Values Defined
A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error
type. An additional error type and few error values are defined to
represent some of the errors related to the newly identified objects
related to GMPLS networks.
zhang Expires August 2010 [Page 9]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
For each PCEP error, an Error-Type and an Error-value are defined.
Error-Type 1 to 10 is already defined in RFC5440. Additional Error-
values are defined for Error-Type 10 and a new Error-Type 14 is
introduced.
Error-Type Error-value
10 Reception of an invalid object
Error-value=2: LSP Protection Information TLV missing
in QoS object.
Error-value=3: TLV missing in QoS object.
Error-value=4: Multiple instance of TLV present in
QoS object.
Error-value=5: Unsupported TLV present in QoS object.
Error-value=6: Traffic Parameters TLV missing in QoS
object.
14 Path computation failure
Error-value=1: Unacceptable response message.
Error-value=2: QoS object missing in request message.
5. Liveness Detection and Monitoring
This document makes no change to the basic operation of PCEP and so
there are no changes to the requirements for liveness detection and
monitoring set out in RFC4657 and RFC5440.
6. IANA Considerations
IANA assigns values to the PCEP protocol objects and TLVs. IANA is
requested to make some allocations for the newly defined objects and
TLVs introduced in this document. Also, IANA is requested to manage
the space of flags that are newly added in the TLVs.
6.1. New PCEP Object
IANA is requested to make some allocations for the QoS object:
zhang Expires August 2010 [Page 10]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
Object-Class Value Name Reference
25 QoS Object-Type-1 This document (section 4.5)
6.2. New PCEP TLVs
IANA is requested to create a registry for the following TLVs:
Value Meaning Reference
20 Destination Prefix Information This document (section 4.1.1)
34 SDH-Traffic This document (section 4.2.1)
35 G.709-Traffic This document (section 4.2.1)
36 WSON-Traffic This document (section 4.2.1)
37 Ethernet-Traffic This document (section 4.2.1)
40 LSP Protection Information This document (section 4.2.2)
6.3. PCEP NO-PATH-VECTOR TLV Flag Field
IANA is requested to update the registry that manages the Flag field
of the NO-PATH-VECTOR TLV.
New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Name Flag
o Reference
Code space of the Flag field (NO-PATH-VECTOR TLV).
Bit Number Name Reference
27 No Resource (NR) This document (section 4.2.1)
28 Protection Mismatch (PM) This document (section 4.2.1)
zhang Expires August 2010 [Page 11]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
6.4. New PCEP Error Codes
As descried in Section 4.5, new PCEP Error-Type and Error Values are
defined. IANA is requested to manage the code space of the Error
object.
Error-Type Error-value
10 Reception of an invalid object
Error-value=2: LSP Protection Information TLV missing
in QoS object.
Error-value=3: TLV missing in QoS object.
Error-value=4: Multiple instance of TLV present in
QoS object.
Error-value=5: Unsupported TLV present in QoS object.
Error-value=6: Traffic Parameters TLV missing in QoS
object.
14 Path computation failure
Error-value=1: Unacceptable response message.
Error-value=2: QoS object missing in request message.
7. Security Considerations
The protocol extensions defined in this document do not substantially
change the nature of PCEP. Therefore, the security considerations set
out in RFC5440 apply unchanged.
8. Acknowledgements
The authors would like to thank Cyril Margaria, Pradeep Shastry,
Thiyagarajan Manickam, and Hemalatha G for their suggestions during
the development of this draft.
9. References
9.1. Normative References
[GMPLS-REQ] Otani, Ogaki, Caviglia, and Fatai Zhang, "Requirements
for GMPLS applications of PCE", July 2009.
zhang Expires August 2010 [Page 12]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3209] Bradner, S., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signaling Unnumbered Links
in Resource Reservation Protocol - Traffic Engineering
(RSVP-TE)", January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", May 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", May 2008.
[RFC4872] J.P.Lang,Y.Rekhter, D. Papadimitriou "RSVP-TE Extensions
in Support of End-to-End Generalized Multi-Protocol
Label Switching (GMPLS) Recovery", May 2007.
[RFC4873] J.P.Lang, I. Bryskin, D. Papadimitriou, A. Farrel "GMPLS
Segment Recovery", May 2007.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", February 2003.
[OTN-SIG] Fatai Zhang, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for the evolving
G.709 Optical Transport Networks Control", draft-zhang-
ccamp-gmpls-evolving-g709, in progress.
[WSON-SIG] G. Bernstein, Young Lee, Ed., "Signaling Extensions for
Wavelength Switched Optical Networks", draft-bernstein-
ccamp-wson-signaling, in progress.
[Eth-Traffic] D. Papadimitriou " Ethernet Traffic Parameters ",
draft-ietf-ccamp-ethernet-traffic-parameters", in
progress.
zhang Expires August 2010 [Page 13]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
9.2. Informative References
[RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element
(PCE)-Based Architecture", August 2006.
[RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", September
2006.
[RFC4674] Roux, J., "Requirements for Path Computation Element
(PCE) Discovery", October 2006.
[RFC5088] Roux, J., "OSPF Protocol Extensions for PCE Discovery",
January 2008.
[RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE)
communication Protocol (PCEP)", March 2009.
[INTER-LAYER] E.Oki, Tomorini Takeda, J.Roux, A.Farrel,"Extensions
to the Path Computation Element communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering"
[RFC3471] L.Berger," Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", Jan 2003
10. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Email: zhangfatai@huawei.com
Suresh BR
Huawei Technologies
Shenzhen
China
Email: sureshbr@huawei.com
Young Lee
Huawei Technologies
1700 Alma Drive, Suite 100
zhang Expires August 2010 [Page 14]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
SenthilKumar S
Huawei Technologies
Shenzhen
China
Email: senthilkumars@huawei.com
Jun Sun
Huawei Technologies
Shenzhen
China
Email: johnsun@huawei.com
Intellectual Property
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
zhang Expires August 2010 [Page 15]
draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010
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 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.
Copyright Notice
Copyright (c) 2010 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.
zhang Expires August 2010 [Page 16]