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]