Network Working Group Fatai Zhang
Internet Draft Suresh B R
Category: Standards Track SenthilKumarS
Jun Sun
Huawei
Expires: July 21, 2010 January 21, 2010
UDP as Transport Protocol for PCECP
draft-zhang-pce-udp-for-pcecp-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.
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.
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 July 20, 2010.
zhang Expires July 2010 [Page 1]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
Abstract
The Path Computation Element Communication Protocol defines a
request/response protocol used for the communication between a Path
Computation Client (PCC) and a Path Computation Element (PCE), or
between two PCEs. PCEP employs Transmission Control Protocol (TCP) as
the transport layer protocol by using a registered TCP port.
This document proposes the possibility of employing UDP as the
transport layer protocol instead of TCP.
UDP is a connectionless protocol within TCP/IP protocol suite that
corresponds to the transport layer in the ISO/OSI reference model.
UDP converts data messages generated by an application into packets
to be sent through IP. The reliability is not guaranteed by UDP and
should be ensured by the application that generates the data message.
The PCECP application is flexible to ensure the reliability of PCECP
messages. This document explains on how the reliability of the PCECP
messages can be achieved by means of PCECP, while operating PCECP
over UDP.
Table of Contents
1. Introduction..................................................3
1.1. Requirements Language....................................3
2. Terminology...................................................3
3. Requirements..................................................4
3.1. Motivations for Using UDP as the transport protocol for
PCECP........................................................5
3.2. Benefits from PCECP over UDP.............................6
4. Proposing UDP for PCECP Transport Protocol....................6
4.1. Reliability of PCECP Messages............................7
4.1.1. Fast Request Retransmission with Exponential or
Linear Back-off Mechanism..................................7
4.1.2. Retransmission Parameters...........................8
4.2. Handling Duplication.....................................8
4.3. Congestion Control.......................................9
4.4. PCECP Messages and Object Formats........................9
5. UDP Port.....................................................10
6. Security Considerations......................................10
6.1. Authentication of PCECP Messages........................10
6.1.1. RDM Monotonic Counter TLV (64-bits)................11
6.1.2. HMAC-MD5 TLV.......................................11
6.1.3. Message Validation.................................12
zhang Expires July 2010 [Page 2]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
6.1.4. Key Utilization....................................13
7. Conclusion...................................................13
8. IANA Considerations..........................................13
8.1. UDP Port................................................13
8.2. PCECP Objects...........................................13
8.3. PCECP TLV Type Indicators...............................13
9. Acknowledgments..............................................14
10. References..................................................14
10.1. Normative References...................................14
10.2. Informative References.................................14
11. Authors' Addresses..........................................14
1. Introduction
[RFC4655] describes the motivation and architecture for a Path
Computation Element (PCE) based model for the computation of Multi-
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering Label Switched Paths (TE LSPs). The PCE is 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. The Path Computation Client (PCC) is any
client application requesting a path computation to be performed by a
PCE. [RFC5440] specifies the Path Computation Element communication
Protocol (PCEP) used for communication between a PCC and PCE in
compliance with [RFC4657]. The PCECP(PCE Communication Protocol) is
an application layer communication protocol employed between PCC and
PCE, as well between PCE and PCE (In this document, we refer to all
communications as PCC-PCE regardless of whether they are PCC-PCE or
PCE-PCE.). The purpose of PCECP is to carry TE-LSP computation
requests, responses and other notifications between PCC and PCE or
between PCE and PCE. The PCECP operates over a transport layer
protocol for transmitting the PCECP messages between the PCECP peers.
[RFC5440] has defined TCP as the transport protocol for PCECP. This
document explains how to operate PCECP over UDP instead of TCP, and
defines the necessary changes and extensions to PCEP.
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 [RFC2119].
2. Terminology
The following terminology is used in this document.
zhang Expires July 2010 [Page 3]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
GMPLS: Generalized Multi-Protocol Label Switching
IP: Internet Protocol. IP governs the break up of data messages
into packets, the routing of the packets from sender to destination
network and station, and the reassembly of the packets into the
original data messages at the destination.
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.
PCECP: Path Computation Element Communication Protocol, which is a
request/response protocol used for the communication between a PCC
and a PCE, or between two PCEs
PCEP: A kind of specific protocol defined in [RFC5440] for PCECP.
PCECP Peer: An element involved in a PCECP session (For example, a
PCC or a PCE).
PCECP Session: The PCECP session is a logical connection established
automatically between the PCECP peers.
TE LSP: Traffic Engineering MPLS Label Switched Path.
TCP: Transmission Control Protocol. TCP is a connection-oriented,
end-to-end reliable protocol that governs the break up of data
messages into packets to be sent through IP (Internet Protocol), and
the reassembly and verification of the complete messages from packets
received by IP.
UDP: User Datagram Protocol. UDP is a connectionless protocol that
converts data messages generated by an application into packets to be
sent through IP.
3. Requirements
In GMPLS networks, the service has to be restored within the minimum
restoring time to avoid service interruption in the event of fiber or
node failure. In such scenarios, establishing a PCECP session,
controlling request retransmission, message/packet overhead over the
bandwidth constrained in-band signaling channels becomes critical.
zhang Expires July 2010 [Page 4]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
3.1. Motivations for Using UDP as the transport protocol for PCECP
The following are the motivations for using UDP as the transport
protocol:
Absence of Initial Connection Establishment: TCP employs three-way
handshake mechanism before sending the PCEP messages. Unlike TCP,
UDP does not establish end-to-end connection between PCECP peers. UDP
communication consequently does not incur connection establishment
and teardown overheads.
Absence of Connection State: TCP maintains the connection state in
the transport layer of PCECP peers. This includes the connection
state, receive and send buffers, congestion control parameters, and
sequence numbers. This information is used to realize the reliable
data transfer of TCP and the congestion control that leads to high
memory and CPU usage.
UDP does not maintain any such connection state and does not track
the congestion parameters or the sequence numbers. As a result, a
PCE can typically support more number of PCCs when the PCECP runs
over UDP rather than TCP.
Minimum Segment Overhead: The TCP segment has 20 bytes of header
overhead in each segment to guarantee the reliable transfer of
messages. The UDP only has 8 bytes of overhead.
Absence of Inherent Data Rate: TCP has a congestion control
mechanism that restricts the PCECP peer when one or more links
between sender and receiver becomes excessively congested. This
restriction can have a severe impact for path request/response when a
TE-LSP is rerouted. On the other hand, using UDP the application can
send data that is constrained by the rate at which the application
generates data and the process capabilities of the source.
Application Flexibility for Reliability: The built-in reliability
mechanism in TCP leads to additional overhead and resource usage in
the network. The PCECP can realize its own reliable mechanism to
ensure the reliability of messages. For example, the PCC can realize
appropriate retransmission strategy to guarantee the reliable
delivery of PCECP messages. The PCC can decide to retransmit the
request to the same PCE or to a different PCE (based on the
availability) in case if no response is received.
Absence of Message Boundary: TCP is a stream oriented protocol and a
read from the socket does not guarantee the complete message. To
receive a complete message, the state oriented message assembler is
zhang Expires July 2010 [Page 5]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
required. Unlike TCP, the message assembler is not required for UDP.
A single UDP datagram consists of complete message and the message
boundaries are guaranteed irrespective of link/path MTU.
3.2. Benefits from PCECP over UDP
The following are the advantages of UDP:
o No time is spent in establishing a TCP connection to the PCE
server. Directly PCECP session establishment can be initiated
using UDP.
o Complexity of PCECP message parser is reduced as complete PCECP
message is carried by one UDP datagram. This will enhance the
PCECP parser performance.
o PCC has the complete control about the retransmission and can
choose a different PCE upon retransmission failure. Custom
retransmission algorithm and policy can be implemented based on
the network.
o If the number of PCC is huge, then number of sessions to be
handled is also huge. Using TCP needs more memory and more
processing. Using UDP this problem can be solved.
By operating PCECP over UDP, the above mentioned requirements are
satisfied.
4. Proposing UDP for PCECP Transport Protocol
UDP is a connectionless protocol that provides a minimal, best-effort,
message-passing transport with minimum protocol mechanism. The
service provided by UDP is unreliable that provides no guarantee for
delivery. The simplicity of UDP reduces the overhead from using the
protocol and the services may be adequate in many cases.
When PCECP uses UDP as transport protocol, an UDP datagram must
contain exactly one PCECP message. So while using UDP, the
application has to realize its own mechanisms to guarantee the
reliable delivery of messages, handle duplication, and congestion of
messages.
The following sections explain on how PCECP can handle the reliable
delivery of PCECP messages avoiding duplication and congestion on a
UDP based PCECP session.
zhang Expires July 2010 [Page 6]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
4.1. Reliability of PCECP Messages
The PCC or PCE originating the PCECP message is responsible for the
reliable delivery of PCECP messages. For example, when a PCC is
sending a TE-LSP path request to PCE, PCC is responsible to keep
track of the request. The PCC must retransmit its PCECP message, if
it fails to receive the response message, either the path response or
error response from the PCE. [draft-ietf-pce-monitoring]
4.1.1. Fast Request Retransmission with Exponential or Linear Back-
off Mechanism
The PCC will transmit a request message to the selected PCE. The
message exchange terminates when either the PCC receives the
appropriate PCECP response successfully, or when the message exchange
has failed as per the retransmission mechanism.
The retransmission behaviour is controlled and described by the
following variables:
RT: Retransmission timeout
IRT: Initial retransmission time
MRT: Maximum retransmission time
MRC: Maximum retransmission count
MRD: Maximum retransmission duration
RAND: Randomization factor. The RAND is a random number chosen
with a uniform distribution between -0.3 and +0.3.
The PCC controls the retransmission behaviour using exponential back-
off mechanism as explained below.
o With each request transmission or retransmission, the PCC sets RT.
The RT for the first message retransmission is based on IRT.
RT =(1 + RAND)*IRT
o On the expiry of RT, if the PCC has not received a response to the
PCReq, the PCC recomputes RT and retransmits the message. Each of
the computations of a new RT includes a RAND. The RAND is
included to minimize synchronization of messages transmitted by
PCCs. The RT for each subsequent message transmission is based on
the previous value of RT.
zhang Expires July 2010 [Page 7]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
RT = (Back-off * RTprev) + (RAND * RTprev), where Back-off = 1 for
Linear and 2 for Exponential.
o The MRT specifies a boundary value for RT (disregarding the
randomization added by the use of RAND). If MRT is 0, then there
is no upper limit on the value of RT. Otherwise, when RT > MRT,
RT is recalculated using, RT = (1 + RAND)*MRT.
o The MRC specifies a boundary value on the number of times a PCC
may retransmit a message. Unless MRC is zero, the message
exchange fails once the PCC has retransmitted the message MRC
times.
o MRD specifies a boundary value on the length of time a PCC may
retransmit a message. Unless MRD is zero, the message exchange
fails once MRD seconds have elapsed since the PCC first
transmitted the message.
o When MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous points is met.
If both MRC and MRD are zero, the PCC continues to transmit the
message until it receives a response, but setting both MRC and MRD
to zero is not recommended.
The same retransmission mechanism either exponential back-off or
linear mechanism is followed during PCE switching.
4.1.2. Retransmission Parameters
This section presents the default values used to describe the message
transmission behaviour.
Parameter Default Value Range
IRT 1 sec 0.1 sec to 8 secs
MRC 3 0 to 8
MRT 2 secs 0.5 sec to 16 secs
MRD 8 secs 1.0 sec to 64 secs
MPC 2 0 to 16
4.2. Handling Duplication
UDP does not protect against any message duplication, but PCECP can
follow the below mentioned mechanism to gracefully handle duplication.
A duplicate PCECP message is identified by a repeated PCECP request-
ID received from the same PCC.
zhang Expires July 2010 [Page 8]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
o When a PCE receives a duplicate request message, and if it is
still processing the original message (path computation is still
in progress or queued, and the path response is not sent), the
newly received request message is dropped.
o When a PCE receives a duplicate request message for which the path
response is already sent, PCE accepts the request and process it.
This is because the PCE may not be able to identify that the
received request is duplicate unless otherwise it maintains the
history.
o When a PCC receives a duplicate response message, it discards it
as it will not be able to locate the original request message that
was processed earlier.
4.3. Congestion Control
UDP does not provide any means to handle congestion. Moreover, when
UDP is used as the transport layer protocol, the rate at which the
message is generated and transmitted is based on the application
capabilities. This may lead to congestion at PCE when multiple PCCs
are sending large number of requests. In such case, the PCE MAY drop
the additional requests that are governed by the load attributes such
as memory, CPU, etc. The PCE MAY not send any notification to the
PCC that the request message is dropped. When the request is dropped,
PCC will retransmit the PCECP message based on its retransmission
strategies.
However, based on a hysteresis, PCE can notify the corresponding PCC
before dropping the received response message during overload. At
once PCE is recovered from the high load condition it can continue to
provide the path computation service.
In the event of congestion in the network, UDP datagrams (carrying
PCECP messages) can be dropped and PCC or PCE may be unaware of this.
Handling of such messages is not required and is out of scope from
this document. However, this results in PCC retransmitting the
corresponding request message.
4.4. PCECP Messages and Object Formats
No new messages and objects are introduced in this document. The
PCECP messages and objects are the same as defined in [RFC5440].
zhang Expires July 2010 [Page 9]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
5. UDP Port
The PCECP operates over UDP using a registered UDP port (4189). All
PCECP messages MUST be sent using the registered UDP port.
6. Security Considerations
The PCECP messages could be the target of the following security
issues:
o Spoofing (PCC or PCE impersonation)
o Snooping (message interception)
o Falsification
o Denial of Service
When UDP is used, the application MUST address these security issues.
This can be achieved using authenticated message exchange along with
an appropriate replay detection scheme. At once authentication is
enabled; PCECP peers can verify the integrity of message before
processing it. PCECP peer drops the received message in the event of
authentication failure.
6.1. Authentication of PCECP Messages
The authentication of PCECP messages plays a vital role in resolving
the falsification of messages, integrality, and denial of service
attacks. PCECP peers can be preconfigured with authentication keys to
be used during the message exchange. The authentication keys can be
configured manually or by employing an appropriate key-exchange
protocol which is out of scope from this document.
The authentication of PCECP message can be achieved by carrying the
authentication information in the Authentication object to reliably
identify the source of a PCECP message and to confirm that the
contents of the PCECP message have not been tampered with.
The Authentication object carries authentication information to
authenticate the identity and contents of PCECP messages. The format
of the Authentication object is as follows:
zhang Expires July 2010 [Page 10]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
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=27| OT=1 |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following are the TLVs:
TLV type Length Name
1 64 bits RDM Monotonic Counter TLV
2 128 bits HMAC-MD5 TLV
6.1.1. RDM Monotonic Counter TLV (64-bits)
The RDM Monotonic Counter TLV specifies the type of replay detection
to be used. The replay detection field MUST be set to the value of a
monotonically increasing counter. Using a counter value, such as the
current time of day (for example, an NTP-format timestamp), can
reduce the danger of replay attacks. Hence, the replay detection
scheme can detect the replayed message and can drop the message even
when the intruder has captured the valid message (say path request
message) and is playing it back. If Replay is not detected, this may
lead to denial of service where PCE will be overloaded (PCE will
perform repeated path computation for the path request it has
received from the intruder as PCE is assuming that the valid PCC has
submitted the path request)
6.1.2. HMAC-MD5 TLV
The use of a particular technique based on the HMAC protocol [RFC2104]
using the MD5 hash [RFC1321] is defined here, however, mechanism like
SHA can also be used. The format of the HMAC-MD5 TLV is as follows:
zhang Expires July 2010 [Page 11]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCECP realm |
| (variable length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCECP realm: The PCECP realm identifies the administrative domain
under which PCC and PCE are deployed.
key ID: The key identifier that identifies the key used to generate
the HMAC-MD5 value.
HMAC-MD5: The message authentication code generated by applying MD5
to the PCECP message using the key identified by the PCECP realm, PCC
IP address, and key ID.
The sender computes the MAC using the HMAC generation algorithm and
the MD5 hash function. The entire PCECP message (setting the MAC
field of the authentication option to zero), including the PCECP
message header and the options field, is used as input to the HMAC-
MD5 computation function.
6.1.3. Message Validation
To validate an incoming message, the receiver computes the MAC. The
entire PCECP message (setting the MAC field of the authentication
option to 0) is used as input to the HMAC-MD5 computation function.
If the MAC computed by the receiver does not match the MAC contained
in the authentication option, the receiver MUST discard the PCECP
message.
zhang Expires July 2010 [Page 12]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
6.1.4. Key Utilization
Each PCC and PCE is assigned with a set of key. Each key is uniquely
identified by the IP address of the peer.
The PCC and PCE use the assigned keys to authenticate PCECP messages
during a session.
7. Conclusion
UDP can be used as the transport layer protocol for PCECP instead of
TCP. The application will become responsible for the reliable
delivery of the messages and also monitors the congestion. The PCECP
session holds good even when UDP being the transport layer protocol.
8. IANA Considerations
8.1. UDP Port
PCECP will use a registered UDP port to be assigned by IANA (4189).
8.2. PCECP Objects
The PCECP Objects registry contains a sub registry, PCECP Objects.
IANA is requested to make some allocations for the Authentication
object.
Object-Class Value Name Reference
27 Authentication This document
Object-Type-1
8.3. PCECP TLV Type Indicators
IANA is requested to create a registry for the following TLVs that
appear in the Authentication object.
Value Meaning Reference
1 RDM Monotonic Counter TLV This document
2 HMAC-MD5 TLV This document
zhang Expires July 2010 [Page 13]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
9. Acknowledgments
The authors would like to thank Adrian Farrel, Pradeep Shastry,
Thiyagarajan Manickam, Hemalatha G for their suggestions during the
development of this draft.
10. References
10.1. Normative References
[RFC1321] Rivet, R., "The MD5 Message-Digest Algorithm", April 1992.
[RFC2104] Canetti, R., Bellare, M., and H. Krawczyk, "HMAC: Keyed-
Hashing for Message Authentication", February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", May 2008.
[RFC768] Postel, J., "User Datagram Protocol", August 1980.
10.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.
[RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE)
communication Protocol (PCEP)", March 2009.
11. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
zhang Expires July 2010 [Page 14]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
Email: zhangfatai@huawei.com
Suresh BR
Huawei Technologies
Shenzhen
China
Email: sureshbr@huawei.com
SenthilKumar S
Huawei Technologies
Shenzhen
China
Email: ssenthilkumar@huawei.com
Jun Sun
Huawei Technologies
Shenzhen
China
Phone: +86-755-28977297
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
zhang Expires July 2010 [Page 15]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
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 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) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
zhang Expires July 2010 [Page 16]
draft-zhang-pce-udp-for-pcecp-00.txt January 2010
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
zhang Expires July 2010 [Page 17]