idnits 2.17.00 (12 Aug 2021) /tmp/idnits33909/draft-zhang-pce-udp-for-pcecp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2010) is 4496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5226' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC768' is defined on line 597, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Suresh B R 3 Category: Standards Track SenthilKumarS 4 Jun Sun 5 Huawei 6 Expires: July 21, 2010 January 21, 2010 8 UDP as Transport Protocol for PCECP 10 draft-zhang-pce-udp-for-pcecp-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Copyright (c) <2010> IETF Trust and the persons identified as the 18 document authors. All rights reserved. 20 This document is subject to BCP 78 and the IETF Trust's Legal 21 Provisions Relating to IETF Documents 22 (http://trustee.ietf.org/license-info) in effect on the date of 23 publication of this document. Please review these documents carefully, 24 as they describe your rights and restrictions with respect to this 25 document. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on July 20, 2010. 45 Abstract 47 The Path Computation Element Communication Protocol defines a 48 request/response protocol used for the communication between a Path 49 Computation Client (PCC) and a Path Computation Element (PCE), or 50 between two PCEs. PCEP employs Transmission Control Protocol (TCP) as 51 the transport layer protocol by using a registered TCP port. 53 This document proposes the possibility of employing UDP as the 54 transport layer protocol instead of TCP. 56 UDP is a connectionless protocol within TCP/IP protocol suite that 57 corresponds to the transport layer in the ISO/OSI reference model. 58 UDP converts data messages generated by an application into packets 59 to be sent through IP. The reliability is not guaranteed by UDP and 60 should be ensured by the application that generates the data message. 62 The PCECP application is flexible to ensure the reliability of PCECP 63 messages. This document explains on how the reliability of the PCECP 64 messages can be achieved by means of PCECP, while operating PCECP 65 over UDP. 67 Table of Contents 69 1. Introduction..................................................3 70 1.1. Requirements Language....................................3 71 2. Terminology...................................................3 72 3. Requirements..................................................4 73 3.1. Motivations for Using UDP as the transport protocol for 74 PCECP........................................................5 75 3.2. Benefits from PCECP over UDP.............................6 76 4. Proposing UDP for PCECP Transport Protocol....................6 77 4.1. Reliability of PCECP Messages............................7 78 4.1.1. Fast Request Retransmission with Exponential or 79 Linear Back-off Mechanism..................................7 80 4.1.2. Retransmission Parameters...........................8 81 4.2. Handling Duplication.....................................8 82 4.3. Congestion Control.......................................9 83 4.4. PCECP Messages and Object Formats........................9 84 5. UDP Port.....................................................10 85 6. Security Considerations......................................10 86 6.1. Authentication of PCECP Messages........................10 87 6.1.1. RDM Monotonic Counter TLV (64-bits)................11 88 6.1.2. HMAC-MD5 TLV.......................................11 89 6.1.3. Message Validation.................................12 90 6.1.4. Key Utilization....................................13 91 7. Conclusion...................................................13 92 8. IANA Considerations..........................................13 93 8.1. UDP Port................................................13 94 8.2. PCECP Objects...........................................13 95 8.3. PCECP TLV Type Indicators...............................13 96 9. Acknowledgments..............................................14 97 10. References..................................................14 98 10.1. Normative References...................................14 99 10.2. Informative References.................................14 100 11. Authors' Addresses..........................................14 102 1. Introduction 104 [RFC4655] describes the motivation and architecture for a Path 105 Computation Element (PCE) based model for the computation of Multi- 106 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 107 Engineering Label Switched Paths (TE LSPs). The PCE is an entity 108 (component, application or network node) that is capable of computing 109 a network path or route based on a network graph and applying 110 computational constraints. The Path Computation Client (PCC) is any 111 client application requesting a path computation to be performed by a 112 PCE. [RFC5440] specifies the Path Computation Element communication 113 Protocol (PCEP) used for communication between a PCC and PCE in 114 compliance with [RFC4657]. The PCECP(PCE Communication Protocol) is 115 an application layer communication protocol employed between PCC and 116 PCE, as well between PCE and PCE (In this document, we refer to all 117 communications as PCC-PCE regardless of whether they are PCC-PCE or 118 PCE-PCE.). The purpose of PCECP is to carry TE-LSP computation 119 requests, responses and other notifications between PCC and PCE or 120 between PCE and PCE. The PCECP operates over a transport layer 121 protocol for transmitting the PCECP messages between the PCECP peers. 123 [RFC5440] has defined TCP as the transport protocol for PCECP. This 124 document explains how to operate PCECP over UDP instead of TCP, and 125 defines the necessary changes and extensions to PCEP. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC2119 [RFC2119]. 133 2. Terminology 135 The following terminology is used in this document. 137 GMPLS: Generalized Multi-Protocol Label Switching 139 IP: Internet Protocol. IP governs the break up of data messages 140 into packets, the routing of the packets from sender to destination 141 network and station, and the reassembly of the packets into the 142 original data messages at the destination. 144 PCC: Path Computation Client. Any client application requesting a 145 path computation to be performed by the Path Computation Element. 147 PCE: Path Computation Element. An entity (component, application, 148 or network node) that is capable of computing a network path or route 149 based on a network graph and applying computational constraints. 151 PCECP: Path Computation Element Communication Protocol, which is a 152 request/response protocol used for the communication between a PCC 153 and a PCE, or between two PCEs 155 PCEP: A kind of specific protocol defined in [RFC5440] for PCECP. 157 PCECP Peer: An element involved in a PCECP session (For example, a 158 PCC or a PCE). 160 PCECP Session: The PCECP session is a logical connection established 161 automatically between the PCECP peers. 163 TE LSP: Traffic Engineering MPLS Label Switched Path. 165 TCP: Transmission Control Protocol. TCP is a connection-oriented, 166 end-to-end reliable protocol that governs the break up of data 167 messages into packets to be sent through IP (Internet Protocol), and 168 the reassembly and verification of the complete messages from packets 169 received by IP. 171 UDP: User Datagram Protocol. UDP is a connectionless protocol that 172 converts data messages generated by an application into packets to be 173 sent through IP. 175 3. Requirements 177 In GMPLS networks, the service has to be restored within the minimum 178 restoring time to avoid service interruption in the event of fiber or 179 node failure. In such scenarios, establishing a PCECP session, 180 controlling request retransmission, message/packet overhead over the 181 bandwidth constrained in-band signaling channels becomes critical. 183 3.1. Motivations for Using UDP as the transport protocol for PCECP 185 The following are the motivations for using UDP as the transport 186 protocol: 188 Absence of Initial Connection Establishment: TCP employs three-way 189 handshake mechanism before sending the PCEP messages. Unlike TCP, 190 UDP does not establish end-to-end connection between PCECP peers. UDP 191 communication consequently does not incur connection establishment 192 and teardown overheads. 194 Absence of Connection State: TCP maintains the connection state in 195 the transport layer of PCECP peers. This includes the connection 196 state, receive and send buffers, congestion control parameters, and 197 sequence numbers. This information is used to realize the reliable 198 data transfer of TCP and the congestion control that leads to high 199 memory and CPU usage. 201 UDP does not maintain any such connection state and does not track 202 the congestion parameters or the sequence numbers. As a result, a 203 PCE can typically support more number of PCCs when the PCECP runs 204 over UDP rather than TCP. 206 Minimum Segment Overhead: The TCP segment has 20 bytes of header 207 overhead in each segment to guarantee the reliable transfer of 208 messages. The UDP only has 8 bytes of overhead. 210 Absence of Inherent Data Rate: TCP has a congestion control 211 mechanism that restricts the PCECP peer when one or more links 212 between sender and receiver becomes excessively congested. This 213 restriction can have a severe impact for path request/response when a 214 TE-LSP is rerouted. On the other hand, using UDP the application can 215 send data that is constrained by the rate at which the application 216 generates data and the process capabilities of the source. 218 Application Flexibility for Reliability: The built-in reliability 219 mechanism in TCP leads to additional overhead and resource usage in 220 the network. The PCECP can realize its own reliable mechanism to 221 ensure the reliability of messages. For example, the PCC can realize 222 appropriate retransmission strategy to guarantee the reliable 223 delivery of PCECP messages. The PCC can decide to retransmit the 224 request to the same PCE or to a different PCE (based on the 225 availability) in case if no response is received. 227 Absence of Message Boundary: TCP is a stream oriented protocol and a 228 read from the socket does not guarantee the complete message. To 229 receive a complete message, the state oriented message assembler is 230 required. Unlike TCP, the message assembler is not required for UDP. 231 A single UDP datagram consists of complete message and the message 232 boundaries are guaranteed irrespective of link/path MTU. 234 3.2. Benefits from PCECP over UDP 236 The following are the advantages of UDP: 238 o No time is spent in establishing a TCP connection to the PCE 239 server. Directly PCECP session establishment can be initiated 240 using UDP. 242 o Complexity of PCECP message parser is reduced as complete PCECP 243 message is carried by one UDP datagram. This will enhance the 244 PCECP parser performance. 246 o PCC has the complete control about the retransmission and can 247 choose a different PCE upon retransmission failure. Custom 248 retransmission algorithm and policy can be implemented based on 249 the network. 251 o If the number of PCC is huge, then number of sessions to be 252 handled is also huge. Using TCP needs more memory and more 253 processing. Using UDP this problem can be solved. 255 By operating PCECP over UDP, the above mentioned requirements are 256 satisfied. 258 4. Proposing UDP for PCECP Transport Protocol 260 UDP is a connectionless protocol that provides a minimal, best-effort, 261 message-passing transport with minimum protocol mechanism. The 262 service provided by UDP is unreliable that provides no guarantee for 263 delivery. The simplicity of UDP reduces the overhead from using the 264 protocol and the services may be adequate in many cases. 266 When PCECP uses UDP as transport protocol, an UDP datagram must 267 contain exactly one PCECP message. So while using UDP, the 268 application has to realize its own mechanisms to guarantee the 269 reliable delivery of messages, handle duplication, and congestion of 270 messages. 272 The following sections explain on how PCECP can handle the reliable 273 delivery of PCECP messages avoiding duplication and congestion on a 274 UDP based PCECP session. 276 4.1. Reliability of PCECP Messages 278 The PCC or PCE originating the PCECP message is responsible for the 279 reliable delivery of PCECP messages. For example, when a PCC is 280 sending a TE-LSP path request to PCE, PCC is responsible to keep 281 track of the request. The PCC must retransmit its PCECP message, if 282 it fails to receive the response message, either the path response or 283 error response from the PCE. [draft-ietf-pce-monitoring] 285 4.1.1. Fast Request Retransmission with Exponential or Linear Back- 286 off Mechanism 288 The PCC will transmit a request message to the selected PCE. The 289 message exchange terminates when either the PCC receives the 290 appropriate PCECP response successfully, or when the message exchange 291 has failed as per the retransmission mechanism. 293 The retransmission behaviour is controlled and described by the 294 following variables: 296 RT: Retransmission timeout 298 IRT: Initial retransmission time 300 MRT: Maximum retransmission time 302 MRC: Maximum retransmission count 304 MRD: Maximum retransmission duration 306 RAND: Randomization factor. The RAND is a random number chosen 307 with a uniform distribution between -0.3 and +0.3. 309 The PCC controls the retransmission behaviour using exponential back- 310 off mechanism as explained below. 312 o With each request transmission or retransmission, the PCC sets RT. 313 The RT for the first message retransmission is based on IRT. 315 RT =(1 + RAND)*IRT 317 o On the expiry of RT, if the PCC has not received a response to the 318 PCReq, the PCC recomputes RT and retransmits the message. Each of 319 the computations of a new RT includes a RAND. The RAND is 320 included to minimize synchronization of messages transmitted by 321 PCCs. The RT for each subsequent message transmission is based on 322 the previous value of RT. 324 RT = (Back-off * RTprev) + (RAND * RTprev), where Back-off = 1 for 325 Linear and 2 for Exponential. 327 o The MRT specifies a boundary value for RT (disregarding the 328 randomization added by the use of RAND). If MRT is 0, then there 329 is no upper limit on the value of RT. Otherwise, when RT > MRT, 330 RT is recalculated using, RT = (1 + RAND)*MRT. 332 o The MRC specifies a boundary value on the number of times a PCC 333 may retransmit a message. Unless MRC is zero, the message 334 exchange fails once the PCC has retransmitted the message MRC 335 times. 337 o MRD specifies a boundary value on the length of time a PCC may 338 retransmit a message. Unless MRD is zero, the message exchange 339 fails once MRD seconds have elapsed since the PCC first 340 transmitted the message. 342 o When MRC and MRD are non-zero, the message exchange fails whenever 343 either of the conditions specified in the previous points is met. 344 If both MRC and MRD are zero, the PCC continues to transmit the 345 message until it receives a response, but setting both MRC and MRD 346 to zero is not recommended. 348 The same retransmission mechanism either exponential back-off or 349 linear mechanism is followed during PCE switching. 351 4.1.2. Retransmission Parameters 353 This section presents the default values used to describe the message 354 transmission behaviour. 356 Parameter Default Value Range 357 IRT 1 sec 0.1 sec to 8 secs 358 MRC 3 0 to 8 359 MRT 2 secs 0.5 sec to 16 secs 360 MRD 8 secs 1.0 sec to 64 secs 361 MPC 2 0 to 16 363 4.2. Handling Duplication 365 UDP does not protect against any message duplication, but PCECP can 366 follow the below mentioned mechanism to gracefully handle duplication. 367 A duplicate PCECP message is identified by a repeated PCECP request- 368 ID received from the same PCC. 370 o When a PCE receives a duplicate request message, and if it is 371 still processing the original message (path computation is still 372 in progress or queued, and the path response is not sent), the 373 newly received request message is dropped. 375 o When a PCE receives a duplicate request message for which the path 376 response is already sent, PCE accepts the request and process it. 377 This is because the PCE may not be able to identify that the 378 received request is duplicate unless otherwise it maintains the 379 history. 381 o When a PCC receives a duplicate response message, it discards it 382 as it will not be able to locate the original request message that 383 was processed earlier. 385 4.3. Congestion Control 387 UDP does not provide any means to handle congestion. Moreover, when 388 UDP is used as the transport layer protocol, the rate at which the 389 message is generated and transmitted is based on the application 390 capabilities. This may lead to congestion at PCE when multiple PCCs 391 are sending large number of requests. In such case, the PCE MAY drop 392 the additional requests that are governed by the load attributes such 393 as memory, CPU, etc. The PCE MAY not send any notification to the 394 PCC that the request message is dropped. When the request is dropped, 395 PCC will retransmit the PCECP message based on its retransmission 396 strategies. 398 However, based on a hysteresis, PCE can notify the corresponding PCC 399 before dropping the received response message during overload. At 400 once PCE is recovered from the high load condition it can continue to 401 provide the path computation service. 403 In the event of congestion in the network, UDP datagrams (carrying 404 PCECP messages) can be dropped and PCC or PCE may be unaware of this. 405 Handling of such messages is not required and is out of scope from 406 this document. However, this results in PCC retransmitting the 407 corresponding request message. 409 4.4. PCECP Messages and Object Formats 411 No new messages and objects are introduced in this document. The 412 PCECP messages and objects are the same as defined in [RFC5440]. 414 5. UDP Port 416 The PCECP operates over UDP using a registered UDP port (4189). All 417 PCECP messages MUST be sent using the registered UDP port. 419 6. Security Considerations 421 The PCECP messages could be the target of the following security 422 issues: 424 o Spoofing (PCC or PCE impersonation) 426 o Snooping (message interception) 428 o Falsification 430 o Denial of Service 432 When UDP is used, the application MUST address these security issues. 433 This can be achieved using authenticated message exchange along with 434 an appropriate replay detection scheme. At once authentication is 435 enabled; PCECP peers can verify the integrity of message before 436 processing it. PCECP peer drops the received message in the event of 437 authentication failure. 439 6.1. Authentication of PCECP Messages 441 The authentication of PCECP messages plays a vital role in resolving 442 the falsification of messages, integrality, and denial of service 443 attacks. PCECP peers can be preconfigured with authentication keys to 444 be used during the message exchange. The authentication keys can be 445 configured manually or by employing an appropriate key-exchange 446 protocol which is out of scope from this document. 448 The authentication of PCECP message can be achieved by carrying the 449 authentication information in the Authentication object to reliably 450 identify the source of a PCECP message and to confirm that the 451 contents of the PCECP message have not been tampered with. 453 The Authentication object carries authentication information to 454 authenticate the identity and contents of PCECP messages. The format 455 of the Authentication object is as follows: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |Object-Class=27| OT=1 |Res|P|I| Object Length (bytes) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 // TLVs // 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 The following are the TLVs: 469 TLV type Length Name 470 1 64 bits RDM Monotonic Counter TLV 471 2 128 bits HMAC-MD5 TLV 473 6.1.1. RDM Monotonic Counter TLV (64-bits) 475 The RDM Monotonic Counter TLV specifies the type of replay detection 476 to be used. The replay detection field MUST be set to the value of a 477 monotonically increasing counter. Using a counter value, such as the 478 current time of day (for example, an NTP-format timestamp), can 479 reduce the danger of replay attacks. Hence, the replay detection 480 scheme can detect the replayed message and can drop the message even 481 when the intruder has captured the valid message (say path request 482 message) and is playing it back. If Replay is not detected, this may 483 lead to denial of service where PCE will be overloaded (PCE will 484 perform repeated path computation for the path request it has 485 received from the intruder as PCE is assuming that the valid PCC has 486 submitted the path request) 488 6.1.2. HMAC-MD5 TLV 490 The use of a particular technique based on the HMAC protocol [RFC2104] 491 using the MD5 hash [RFC1321] is defined here, however, mechanism like 492 SHA can also be used. The format of the HMAC-MD5 TLV is as follows: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | PCECP realm | 498 | (variable length) | 499 . . 500 . . 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | key ID | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | | 505 | HMAC-MD5 | 506 | (128 bits) | 507 | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 PCECP realm: The PCECP realm identifies the administrative domain 511 under which PCC and PCE are deployed. 513 key ID: The key identifier that identifies the key used to generate 514 the HMAC-MD5 value. 516 HMAC-MD5: The message authentication code generated by applying MD5 517 to the PCECP message using the key identified by the PCECP realm, PCC 518 IP address, and key ID. 520 The sender computes the MAC using the HMAC generation algorithm and 521 the MD5 hash function. The entire PCECP message (setting the MAC 522 field of the authentication option to zero), including the PCECP 523 message header and the options field, is used as input to the HMAC- 524 MD5 computation function. 526 6.1.3. Message Validation 528 To validate an incoming message, the receiver computes the MAC. The 529 entire PCECP message (setting the MAC field of the authentication 530 option to 0) is used as input to the HMAC-MD5 computation function. 531 If the MAC computed by the receiver does not match the MAC contained 532 in the authentication option, the receiver MUST discard the PCECP 533 message. 535 6.1.4. Key Utilization 537 Each PCC and PCE is assigned with a set of key. Each key is uniquely 538 identified by the IP address of the peer. 540 The PCC and PCE use the assigned keys to authenticate PCECP messages 541 during a session. 543 7. Conclusion 545 UDP can be used as the transport layer protocol for PCECP instead of 546 TCP. The application will become responsible for the reliable 547 delivery of the messages and also monitors the congestion. The PCECP 548 session holds good even when UDP being the transport layer protocol. 550 8. IANA Considerations 552 8.1. UDP Port 554 PCECP will use a registered UDP port to be assigned by IANA (4189). 556 8.2. PCECP Objects 558 The PCECP Objects registry contains a sub registry, PCECP Objects. 560 IANA is requested to make some allocations for the Authentication 561 object. 563 Object-Class Value Name Reference 564 27 Authentication This document 565 Object-Type-1 567 8.3. PCECP TLV Type Indicators 569 IANA is requested to create a registry for the following TLVs that 570 appear in the Authentication object. 572 Value Meaning Reference 573 1 RDM Monotonic Counter TLV This document 574 2 HMAC-MD5 TLV This document 576 9. Acknowledgments 578 The authors would like to thank Adrian Farrel, Pradeep Shastry, 579 Thiyagarajan Manickam, Hemalatha G for their suggestions during the 580 development of this draft. 582 10. References 584 10.1. Normative References 586 [RFC1321] Rivet, R., "The MD5 Message-Digest Algorithm", April 1992. 588 [RFC2104] Canetti, R., Bellare, M., and H. Krawczyk, "HMAC: Keyed- 589 Hashing for Message Authentication", February 1997. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", March 1997. 594 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 595 IANA Considerations Section in RFCs", May 2008. 597 [RFC768] Postel, J., "User Datagram Protocol", August 1980. 599 10.2. Informative References 601 [RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element (PCE)- 602 Based Architecture", August 2006. 604 [RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE) 605 Communication Protocol Generic Requirements", September 2006. 607 [RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE) 608 communication Protocol (PCEP)", March 2009. 610 11. Authors' Addresses 612 Fatai Zhang 613 Huawei Technologies 614 F3-5-B R&D Center, Huawei Base 615 Bantian, Longgang District 616 Shenzhen 518129 P.R.China 618 Phone: +86-755-28972912 619 Email: zhangfatai@huawei.com 621 Suresh BR 622 Huawei Technologies 623 Shenzhen 624 China 626 Email: sureshbr@huawei.com 628 SenthilKumar S 629 Huawei Technologies 630 Shenzhen 631 China 633 Email: ssenthilkumar@huawei.com 635 Jun Sun 636 Huawei Technologies 637 Shenzhen 638 China 640 Phone: +86-755-28977297 641 Email: johnsun@huawei.com 643 Intellectual Property 645 The IETF Trust takes no position regarding the validity or scope of 646 any Intellectual Property Rights or other rights that might be 647 claimed to pertain to the implementation or use of the technology 648 described in any IETF Document or the extent to which any license 649 under such rights might or might not be available; nor does it 650 represent that it has made any independent effort to identify any 651 such rights. 653 Copies of Intellectual Property disclosures made to the IETF 654 Secretariat and any assurances of licenses to be made available, or 655 the result of an attempt made to obtain a general license or 656 permission for the use of such proprietary rights by implementers or 657 users of this specification can be obtained from the IETF on-line IPR 658 repository at http://www.ietf.org/ipr 659 The IETF invites any interested party to bring to its attention any 660 copyrights, patents or patent applications, or other proprietary 661 rights that may cover technology that may be required to implement 662 any standard or specification contained in an IETF Document. Please 663 address the information to the IETF at ietf-ipr@ietf.org. 665 The definitive version of an IETF Document is that published by, or 666 under the auspices of, the IETF. Versions of IETF Documents that are 667 published by third parties, including those that are translated into 668 other languages, should not be considered to be definitive versions 669 of IETF Documents. The definitive version of these Legal Provisions 670 is that published by, or under the auspices of, the IETF. Versions of 671 these Legal Provisions that are published by third parties, including 672 those that are translated into other languages, should not be 673 considered to be definitive versions of these Legal Provisions. 675 For the avoidance of doubt, each Contributor to the IETF Standards 676 Process licenses each Contribution that he or she makes as part of 677 the IETF Standards Process to the IETF Trust pursuant to the 678 provisions of RFC 5378. No language to the contrary, or terms, 679 conditions or rights that differ from or are inconsistent with the 680 rights and licenses granted under RFC 5378, shall have any effect and 681 shall be null and void, whether published or posted by such 682 Contributor, or included with or in such Contribution. 684 Disclaimer of Validity 686 All IETF Documents and the information contained therein are provided 687 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 688 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 689 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 690 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 691 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 692 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 693 FOR A PARTICULAR PURPOSE. 695 Full Copyright Statement 697 Copyright (c) 2009 IETF Trust and the persons identified as the 698 document authors. All rights reserved. 700 This document is subject to BCP 78 and the IETF Trust's Legal 701 Provisions Relating to IETF Documents in effect on the date of 702 publication of this document (http://trustee.ietf.org/license-info). 703 Please review these documents carefully, as they describe your rights 704 and restrictions with respect to this document.