idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 887. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2005) is 6859 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: 'RFC3667' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 793, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-ARCH' ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft PCE Working Group Jerry Ash (AT&T) 2 Proposed Status: Informational Editor 3 Expires: January 2006 J.L. Le Roux (France Telecom) 4 Editor 6 July 2005 8 draft-ietf-pce-comm-protocol-gen-reqs-01.txt 10 PCE Communication Protocol Generic Requirements 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 26, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The PCE model is described in the "PCE Architecture" document and 44 facilitates path computation requests from Path Computation Clients 45 (PCCs) to Path Computation Elements (PCEs). This document specifies 46 generic requirements for a communication protocol between PCCs and 47 PCEs, and also between PCEs where cooperation between PCEs is 48 desirable. Subsequent documents will specify application-specific 49 requirements for the PCE communication protocol. 51 Table of Contents 53 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 55 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Overview of PCE Communication Protocol (PCEP) . . . . . . . . . . 4 58 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 59 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8 60 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8 61 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8 62 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 64 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 65 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10 66 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10 67 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11 68 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 69 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 11 70 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12 71 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12 72 6.1.13 Communication Overhead Minimization . . . . . . . . . 12 73 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 12 74 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 75 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13 76 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14 77 6.2.1 Support for Different Service Provider Environments . . 14 78 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14 79 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 14 80 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 14 81 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 15 82 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 16 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 16 88 12. Informational References . . . . . . . . . . . . . . . . . . . . 17 89 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 18 91 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 18 92 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Contributors 95 This document is the result of the PCE Working Group PCE 96 communication protocol (PCEP) requirements design team joint effort. 97 The following are the design team member authors that contributed to 98 the present document: 100 Jerry Ash (AT&T) 101 Alia Atlas (Avici) 102 Arthi Ayyangar (Juniper) 103 Nabil Bitar (Verizon) 104 Igor Bryskin (Independent Consultant) 105 Dean Cheng (Cisco) 106 Durga Gangisetti (MCI) 107 Kenji Kumaki (KDDI) 108 Jean-Louis Le Roux (France Telecom) 109 Eiji Oki (NTT) 110 Raymond Zhang (BT Infonet) 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Introduction 120 The path computation element (PCE) [PCE-ARCH] supports requests for 121 path computation issued by a path computation client (PCC), which may 122 be 'composite' (co-located) or 'external' (remote) from a PCE. When 123 the PCC is external from the PCE, a request/response communication 124 protocol is required to carry the path computation request and return 125 the response. In order for the PCC and PCE to communicate, the PCC 126 must know the location of the PCE: PCE discovery is described in 127 [PCE-DISC-REQ]. The PCE operates on a network graph in order to 128 compute paths based on the path computation request issued by the 129 PCC. The path computation request will normally include the source 130 and destination of the paths to be computed, and a set of constraints 131 to be applied during the computation. The PCE response includes the 132 computed paths or the reason for a failed computation. 134 This document lists a set of generic requirements for the PCEP. 135 Application-specific requirements are beyond the scope of this 136 document, and will be addressed in separate documents. 138 4. Terminology 140 Domain: any collection of network elements within a common sphere of 141 address management or path computational responsibility. Examples of 142 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 143 within a service provider network, or multiple ASs across multiple 144 service provider networks. 146 GMPLS: Generalized Multiprotocol Label Switching 148 LSP: MPLS Label Switched Path. 150 MPLS: multiprotocol label switching 152 PCC: Path Computation Client: any client application requesting a 153 Path computation to be performed by the PCE. 155 PCE: Path Computation Element: an entity (component, application or 156 network node) that is capable of computing a network path or route 157 based on a network graph and applying computational constraints (see 158 further description in [PCE-ARCH]). 160 TED: Traffic Engineering Database, which contains the topology and 161 resource information of the network or network segment used by a PCE. 163 TE LSP: Traffic Engineering MPLS Label Switched Path. 165 See [PCE-ARCH] for further definitions of terms. 167 5. Overview of PCE Communication Protocol (PCEP) 169 In the PCE model, path computation requests are issued by a PCC 170 to a PCE that may be composite (co-located) or external (remote). 171 If the PCC and PCE are not composite, a request/response 172 communication protocol is required to carry the request and return 173 the response. If the PCC and PCE are composite, a communication 174 protocol is not required, but implementations may choose to utilize 175 a protocol for exchanges between the components. 177 In order that a PCC and PCE can communicate, the PCC must know the 178 location of the PCE. This can be configured or discovered. The PCE 179 discovery mechanism is out of scope of this document, but 180 requirements are documented in [PCE-DISC-REQ]. 182 The PCE operates on a network graph built from the TED in order to 183 compute paths. The mechanism by which the TED is populated is out of 184 scope for the PCEP. 186 A path computation request issued by the PCC includes a specification 187 of the path(s) needed. The information supplied includes, at a 188 minimum, the source and destination for the paths, but may also 189 include a set of further requirements (known as constraints) as 190 described in Section 6. 192 The response from the PCE may be positive in which case it will 193 include the paths that have been computed. If the computation fails 194 or cannot be performed, a negative response is required with an 195 indication of the type of failure. 197 A request/response protocol is also required for a PCE to communicate 198 path computation requests to another PCE and for that PCE to return 199 the path computation response. As described in [PCE-ARCH], there is 200 no reason to assume that two different protocols are needed, and this 201 document assumes that a single protocol will satisfy all requirements 202 for PCC-PCE and PCE-PCE communication. 204 [PCE-ARCH] describes four models of PCE: composite, external, 205 multiple PCE path computation, and multiple PCE path computation with 206 inter-PCE communication. In all cases except the composite PCE model, 207 a PCEP is required. The requirements defined in this document are 208 applicable to all models described in the [PCE-ARCH] except the 209 composite PCE model. 211 6. PCE Communication Protocol Generic Requirements 213 [This paragraph to be deleted after successful completion and before 214 publication as an RFC.] 216 The designers of a PCEP MUST take the requirements set out in this 217 document and discuss them widely within the IETF and particularly 218 within the Applications Area to determine whether a suitable protocol 219 already exists. The results of this investigation MUST be published 220 on the PCE mailing list. 222 The following is a summary of the requirements in Section 6: 224 Requirement Necessity Ref. 225 ------------------------------------------------------------------ 226 Commonality of PCC-PCE and PCE-PCE Communication MUST 6.1.1 227 Client-Server Communication MUST 6.1.2 228 Support PCC/PCE request message to request path 229 computation MUST 6.1.2 230 Support PCE response message with computed path MUST 6.1.2 231 Support unsolicited communication PCE-PCC SHOULD 6.1.2 232 Maintain PCC-PCE session NON-RQMT 6.1.2 233 Use of Existing Transport Protocol MAY 6.1.3 234 Transport protocol satisfy reliability & security 235 requirements MAY 6.1.3 236 Transport Protocol Limits Size of Message MUST NOT 6.1.3 237 Support Path Computation Requests MUST 6.1.4 238 Include source & destination 239 Support path constraints (e.g., bandwidth, hops, 240 affinities) to include/exclude MUST 6.1.4 241 Support path reoptimization & inclusion of a 242 previously computed path MUST 6.1.4 243 Allow to select/prefer from advertised list of 244 standard objective functions/options MUST 6.1.4 245 Allow to customize objective function/options MUST 6.1.4 246 Request a less-constrained path MAY 6.1.4 247 Support request for less-constrained path, 248 including constraint-relaxation policy's SHOULD 6.1.4 249 Support Path Computation Responses MUST 6.1.5 250 Negative response support reasons for failure, 251 constraints to relax to achieve positive result, 252 less-constrained path reflecting 253 constraint-relaxation policy's SHOULD 6.1.5 254 Cancellation of Pending Requests MUST 6.1.6 255 Multiple Requests and Responses MUST 6.1.7 256 Limit by configuration number of requests within 257 a message MUST 6.1.7 258 Support multiple computed paths in response MUST 6.1.7 259 Support "continuation correlation" where related 260 requests or computed paths cannot fit within one 261 message MUST 6.1.7 262 Maximum message size & maximum number of requests 263 per message exchanged through PCE messages to PCC, 264 or indicated in request message MAY 6.1.7 265 Reliable Message Exchange (achieved by PCEP 266 itself or transport protocol MUST 6.1.8 267 Allow detection & recovery of lost messages to 268 occur quickly & not impede operation of PCEP MUST 6.1.8 269 Handle overload situations without significant 270 decrease in performance, e.g., through throttling 271 of requests MUST 6.1.8 272 Provide acknowledged message delivery with 273 retransmission, in order message delivery or 274 facility to restore order, message corruption 275 detection, flow control & back-pressure to 276 throttle requests, rapid partner failure 277 detection, informed rapidly of failure of PCE-PCC 278 connection MUST 6.1.8 279 Functionality added to PCEP if transport protocol 280 provides it SHOULD NOT 6.1.8 281 Secure Message Exchange (provided by PCEP or 282 transport protocol MUST 6.1.9 283 Support mechanisms to prevent spoofing (e.g., 284 authentication), snooping (e.g., encryption), 285 DOS attacks MUST 6.1.9 286 Request Prioritization MUST 6.1.10 287 Unsolicited Notifications SHOULD 6.1.11 288 Allow Asynchronous Communication MUST 6.1.12 289 PCC Has to Wait for Response Before Making 290 Another Request MUST NOT 6.1.12 291 Allow order of responses differ from order of 292 Requests MUST 6.1.12 293 Communication Overhead Minimization SHOULD 6.1.13 294 Give particular attention to message size SHOULD 6.1.13 295 Extensibility without requiring modifications to 296 the protocol MUST 6.1.14 297 Easily extensible to support intra-area, 298 inter-area, inter-AS intra provider, inter-AS 299 inter-provider, multi-layer path & virtual network 300 topology path computation MUST 6.1.14 301 Easily extensible to support future applications 302 not in scope (e.g., P2MP path computations) SHOULD 6.1.14 303 Scalability at least linearly with increase in 304 number of PCCs, PCEs, PCCs communicating with a 305 single PCE, PCEs communicated to by a single PCC, 306 PCEs communicated to by another PCE, domains, path 307 requests, handling bursts of requests MUST 6.1.15 308 Support Path Computation Constraints MUST 6.1.16 309 Support Different Service Provider Environments 310 (e.g., MPLS-TE and GMPLS networks, centralized & 311 distributed PCE path computation, single & 312 multiple PCE path computation) MUST 6.2.1 313 Policy Support for policies to accept/reject 314 requests, PCC to determine reason for rejection, 315 notification of policy violation MUST 6.2.2 316 Aliveness Detection of PCCs/PCEs, partner failure 317 Detection MUST 6.3.1 318 PCC/PCE Failure Response procedures defined for 319 PCE/PCC failures, PCC able to clear pending 320 Request MUST 6.3.2 321 PCC select another PCE upon detection of PCE 322 failure MUST 6.3.2 323 PCE able to clear pending requests from a PCC 324 (e.g. when it detects PCC failure or request 325 buffer full) MUST 6.3.2 326 Protocol Recovery support resynchronization of 327 information & requests between sender & receiver MUST 6.3.3 328 Minimize repeat data transfer, allow PCE to 329 respond to computation requests issued before 330 failure without requests being re-issued SHOULD 6.3.3 331 Stateful PCE able to resynchronize/recover 332 states (e.g., LSP status, paths) after restart SHOULD 6.3.3 334 6.1 Basic Protocol Requirements 336 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 338 A single protocol MUST be defined for PCC-PCE and PCE-PCE 339 communication. A PCE requesting a path from another PCE can be 340 considered as a PCC. 342 6.1.2 Client-Server Communication 344 PCC-PCE and PCE-PCE communication is by nature client-server based. 345 The PCEP MUST allow for a PCC or a PCE to send a request message to a 346 PCE to request path computation, and for a PCE to reply with a 347 response message to the requesting PCC or PCE, once the path has been 348 computed. 350 In addition to this request-response mode, there may be cases where 351 there is unsolicited communication from the PCE to PCC (see 352 Requirement 6.1.6). 354 There is no requirement to maintain a session or association between 355 communicating PCC and PCE, nor between communicating PCEs. The 356 request/response exchange defines a limited association between 357 requester and responder. 359 6.1.3 Transport 361 The PCEP may utilize an existing transport protocol or operate 362 directly over IP. 364 If a transport protocol is used, it may be used to satisfy some 365 requirements stated in other sections of this document (for example, 366 reliability and security). 368 If a transport protocol is used, it MUST NOT limit the size of the 369 message used by the PCEP. 371 Where requirements expressed in this document match the function of 372 existing transport protocols, consideration MUST be given to the use 373 of those protocols. 375 6.1.4 Path Computation Requests 377 The request message MUST include, at least, a source and a 378 destination. The message MUST support the inclusion of a set of one 379 or more path constraints, such as the requested bandwidth or 380 resources (hops, affinities, etc.) to include/exclude (e.g., a PCC 381 requests the PCE to exclude points of failure in the computation of 382 the new path if an LSP setup fails). The actual inclusion of 383 constraints is a choice for the PCC issuing the request. 384 A list of core constraints that MUST be supported by the PCEP is 385 supplied in Section 6.1.16. Specification of constraints must be 386 future-proofed as described in Section 6.1.14. 388 The path computation request message MUST support TE LSP path 389 reoptimization and the inclusion of a previously computed path. This 390 will help ensure optimal routing of a reoptimized path, since it will 391 allow the PCE to avoid double bandwidth accounting and help reduce 392 blocking issues. 394 The requester MUST be allowed to select or prefer from an advertised 395 list or minimal subset of standard objective functions and functional 396 options. The requester SHOULD also be able to select a 397 vendor-specific or experimental objective function or functional 398 option. Furthermore, the requester MUST be allowed to customize the 399 objective function/options in use. That is, individual objective 400 functions will often have parameters to be set in the request from 401 PCC to PCE. Specification of objective functions and objective 402 function parameters is required in the protocol extensibility 403 specified in Section 6.1.14. 405 If a PCC selects an objective function that the PCE does not support, 406 the PCE response MUST be negative. 408 Note that a PCC MAY send a request that is based on the set of TE 409 parameters carried by the MPLS/GMPLS LSP setup signaling protocol, 410 and as long as those parameters are satisfied, the PCC MAY not care 411 about which objective function is used. Also, the PCE MAY execute 412 objective functions not advertised to the PCC, for example, policy 413 based routing path computation for load balancing instructed by the 414 management plane. 416 As also discussed in Section 6.1.5 (Path Computation Responses), a 417 PCC MAY request a less-constrained TE LSP path, and the path 418 computation request MAY include one or more constraint-relaxation 419 policy's. The Request message SHOULD support the inclusion of a 420 request for a less-constrained path, including one or more 421 constraint-relaxation policy's. 423 6.1.5 Path Computation Responses 425 The response message MUST allow returning various elements including, 426 at least, the computed path(s). 428 The protocol MUST be capable of returning any explicit path that 429 would be acceptable for use for MPLS and GMPLS LSPs once converted to 430 an Explicit Route Object for use in RSVP-TE signaling. Note that the 431 resultant path(s) may be made up of a set of strict or loose hops, or 432 any combination of strict and loose hops. Moreover, a hop may have 433 the form of a non-simple abstract node. See RFC 3209 for the 434 definition of strict hop, loose hop, and abstract node. 436 A positive response from the PCE will include the paths that have 437 been computed. When a Path satisfying the constraints cannot be 438 found, or if the computation fails or cannot be performed, a 439 negative response MUST be sent. This response MAY include further 440 details of the reason(s) for the failure, and potentially advice 441 about which constraints might be relaxed to be more likely to achieve 442 a positive result. Optionally the PCE MAY provide a 443 less-constrained path taking into account one or more relaxation 444 policy's that could potentially be provided by the PCC in the 445 request. As discussed in Section 6.1.4, a PCC MAY optionally 446 request a less-constrained TE LSP path, and the path computation 447 request MAY also include one or more constraint-relaxation policy's. 449 Hence the Response message SHOULD support the inclusion of the 450 reasons for a failure, and the inclusion of less-constrained path. 451 The Request message SHOULD support the inclusion of a request for a 452 less-constrained path, including one or more constraint-relaxation 453 policy's. 455 6.1.6 Cancellation of Pending Requests 457 A PCC or PCE MUST be able to cancel a pending request. 459 6.1.7 Multiple Requests and Responses 461 It MUST be possible to send multiple path computation requests, 462 correlated or not, within the same request message. There are 463 various motivations for doing so (optimality, path diversity, etc.). 464 It MUST be possible to limit by configuration the number of requests 465 that can be carried within a single message. 467 Similarly, it MUST be possible to return multiple computed paths 468 within the same response message, corresponding either to the same 469 request (e.g. load balancing) or to distinct requests, correlated or 470 not, of the same request message or distinct request messages. 472 It MUST be possible to provide "continuation correlation" where all 473 related requests or computed paths cannot fit within one message. 475 Maximum acceptable message sizes and the maximum number of requests 476 per message supported by a PCE MAY form part of PCE capabilities 477 advertisement [PCE-DISC-REQ], or MAY be exchanged through information 478 messages from the PCE as part of the protocol described here. 480 Maximum acceptable message sizes and the maximum number of computed 481 paths per message supported by a PCC MAY be indicated in the request 482 message. 484 An implementation MAY choose to limit message size to avoid a big 485 message from unduly delaying a small message. 487 6.1.8 Reliable Message Exchange 489 The PCEP MUST include reliability. This may form part of the 490 protocol itself or may be achieved by the selection of a suitable 491 transport protocol (see Section 6.1.3). 493 In particular, it MUST allow for the detection and recovery of lost 494 messages to occur quickly and not impede the operation of the PCEP. 496 In some cases (e.g. after link failure), a large number of PCCs may 497 simultaneously send requests to a PCE, leading to a potential 498 saturation of the PCEs. The PCEP or the transport protocol it uses 499 MUST properly handle such overload situations without a significant 500 decrease in performance, such as through throttling of such requests. 502 The PCEP or the transport protocol it uses MUST provide: 504 - Acknowledged message delivery with retransmission. 505 - In order message delivery or the facility (such as message 506 numbering) to restore the order of received messages. 507 - Message corruption detection. 508 - Flow control and back-pressure, as specified above with the 509 throttling of requests. 510 - Rapid partner failure detection. The PCC/PCE MUST be informed of 511 the failure of any PCE/PCC or PCC-PCE connection rapidly after 512 the failure happens. 514 Functionality SHOULD NOT be added to the PCEP where the chosen 515 transport protocol already provides it. 517 6.1.9 Secure Message Exchange 519 The PCC-PCE and PCE-PCE communication MUST be secure. In particular, 520 it MUST support mechanisms to prevent spoofing (e.g., 521 authentication), snooping (e.g., encryption) and DOS attacks. 523 This function may be provided by the transport protocol or directly 524 by the PCEP. 526 6.1.10 Request Prioritization 528 The PCEP MUST allow a PCC to specify the priority of a computation 529 request. This priority is used by a PCE to service high priority 530 requests before lower priority requests considering all requests 531 received and queued by a single PCE from all PCCs. 533 Implementation of priority-based activity within a PCE is subject to 534 implementation and local policy. This application processing is out 535 of scope of the PCEP. 537 6.1.11 Unsolicited Notifications 539 The normal operational mode is for the PCC to make path computation 540 requests to the PCE, and for the PCE to respond. 542 The PCEP SHOULD support unsolicited notifications from PCE to PCC, 543 PCE to PCE, or PCC to PCE. This requirement facilitates the 544 unsolicited communication of information, updated paths, and alerts 545 between PCCs and PCEs and between PCEs. 547 6.1.12 Asynchronous Communication 549 The PCC-PCE protocol MUST allow for asynchronous communication. A 550 PCC MUST NOT have to wait for a response before it can make another 551 request. 553 It MUST also be possible to have the order of responses differ from 554 the order of the corresponding requests. This may occur, for 555 instance, when path request messages have different priorities (see 556 Requirement 6.1.10). 558 6.1.13 Communication Overhead Minimization 560 The request and response messages SHOULD be designed so that the 561 communication overhead is minimized. Particular attention SHOULD be 562 given to the message size. Other considerations in overhead 563 minimization include the following: 565 - the number of messages exchanged to arrive at a computation answer 566 - the amount of background messages used by the protocol or its 567 transport protocol to keep alive any session or association 568 between the PCE and PCC 569 - the processing cost at the PCE (or PCC) associated with 570 request/response messages (as distinct from processing the 571 computation requests themselves). 573 6.1.14 Extensibility 575 The PCEP MUST provide a way for the introduction of new path 576 computation constraints, diversity types, objective functions, 577 optimization methods and parameters, etc., without requiring 578 modifications in the protocol. 580 The PCEP MUST be easily extensible to support various PCE based 581 applications that have been currently identified including: 583 - intra-area path computation 584 - inter-area path computation 585 - inter-AS intra provider and inter-AS inter-provider path 586 computation 588 The PCEP MUST also allow extensions as more PCE applications will be 589 introduced in the future. For example, the protocol may be extended 590 to support PCE-based multi-layer path computation and virtual network 591 topology computation/reconfiguration. 593 The PCEP SHOULD also be easily extensible to support future 594 applications not currently in the scope of the PCE working group, 595 such as, for instance, P2MP path computations, etc. 597 Note that application specific requirements are out of the scope of 598 this document and will be addressed in separate requirements 599 documents. 601 6.1.15 Scalability 603 The PCEP MUST scale well, at least as good as linearly, with an 604 increase of any of the following parameters: 606 - number of PCCs 607 - number of PCEs 608 - number of PCCs communicating with a single PCE 609 - number of PCEs communicated to by a single PCC 610 - number of PCEs communicated to by another PCE 611 - number of domains 612 - number of path requests 613 - handling bursts of requests. 615 Bursts of requests may arise, for example, after a network outage 616 when multiple recomputations are requested. It is RECOMMENDED that 617 the protocol handle the congestion in a graceful way so that it does 618 not unduly impact the rest of the network, and so that it does not 619 gate the ability of the PCE to perform computation. 621 6.1.16 Constraints 623 This section provides a list of generic constraints that MUST be 624 supported by the PCEP. Other constraints may be added to service 625 specific applications as identified by separate application-specific 626 requirements documents. 628 Note that the absence of a constraint in this list does not mean that 629 that constraint must not be supported. Note also that the provisions 630 of Section 6.1.14 mean that new constraints can be added to this list 631 without impacting the protocol. 633 Here is the list of generic constraints that MUST be supported: 635 o MPLS-TE and GMPLS generic constraints: 636 - Bandwidth 637 - Affinities inclusion/exclusion 638 - Link, Node, SRLG inclusion/exclusion 639 - Maximum end-to-end delay metrics 640 - Hop Count 642 o MPLS-TE specific constraints 643 - Class-Type 645 o GMPLS specific constraints 646 - Switching Type, Encoding Type 647 - Protection type 649 o TBD 651 6.2 Deployment Support Requirements 653 6.2.1 Support for Different Service Provider Environments 655 The PCEP MUST operate in various different service provider network 656 environments that utilize an IP-based control plane, such as 658 - MPLS-TE and GMPLS networks 659 - centralized and distributed PCE path computation 660 - single and multiple PCE path computation 662 Definitions of centralized, distributed, single, and multiple PCE 663 path computation can be found in [PCE-ARCH]. 665 6.2.2 Policy Support 667 The PCEP MUST allow for policies to accept/reject requests, and 668 include the ability for a PCE to reject requests with sufficient 669 detail to allow the PCC to determine the reason for rejection or 670 failure. For example, filtering could be required for intra-AS PCE 671 path computation such that all requests are rejected that come from 672 another AS. However, specific policy details are left to 673 application-specific PCEP requirements. Furthermore, the PCEP MUST 674 allow for the notification of a policy violation. Actual policies, 675 configuration of policies, and applicability of policies are out of 676 scope. 678 6.3 Detection & Recovery Requirements 680 6.3.1 Aliveness Detection 682 The PCEP MUST allow a PCC to check the liveliness of PCEs it is using 683 for path computation, and a PCE to check the liveliness of PCCs it is 684 serving. The PCEP MUST provide partner failure detection. 686 Depending on the solution, this requirement MAY be met by the PCEP 687 design or the transport protocol design. 689 6.3.2 PCC/PCE Failure Response 691 Appropriate PCC and PCE procedures MUST be defined to deal with PCE 692 and PCC failures. A PCC must be able to clear any pending request to 693 a PCE so that it is no longer waiting for a response. Clearing a 694 pending request does not imply any message exchange; this differs 695 from pending request cancellation (Section 6.1.6), which requires 696 message exchange. It is RECOMMENDED that a PCC select another PCE 697 upon detection of PCE failure or unreachability of a PCE but note 698 that PCE selection procedure are out of the scope of this document. 700 Similarly, a PCE must be able to clear pending requests from a PCC, 701 for instance, when it detects the failure of the requesting PCC or 702 when its buffer of requests is full. Clearing a pending request does 703 not imply any message exchange. 705 It is assumed that the aliveness detection mechanism (see Section 706 6.3.1) ensures reciprocal knowledge of PCE and PCC liveness. 708 6.3.3 Protocol Recovery 710 Information distributed in asynchronous/unsolicited messages MAY 711 persist at the recipient in the event of the failure of the sender or 712 of the communication channel. Upon recovery, the Communication 713 Protocol MUST support resynchronization of information and requests 714 between the sender and the receiver, and this SHOULD be arranged so 715 as to minimize repeat data transfer. 717 For example, the PCEP SHOULD allow a PCE to respond to computation 718 requests issued before the failure without the requests being 719 re-issued. 721 Similarly, a stateful PCE SHOULD be able to resynchronize and recover 722 states (e.g., LSP status, paths, etc.) after a restart. 724 7. Security Considerations 726 The impact of the use of a PCEP MUST be considered in the light of 727 the impact that it has on the security of the existing routing and 728 signaling protocols and techniques in use within the network. There 729 is unlikely to be any impact on intra-domain security, but an 730 increase in inter-domain information flows and the facilitation of 731 inter-domain path establishment may increase the vulnerability to 732 security attacks. 734 Of particular relevance are the implications for confidentiality 735 inherent in a PCEP for multi-domain networks. It is not necessarily 736 the case that a multi-domain PCE solution will compromise security, 737 but solutions MUST examine their impacts in this area. 739 Applicability statements for particular combinations of signaling, 740 routing and path computation techniques are expected to contain 741 detailed security sections. 743 It should be observed that the use of an external PCE does introduce 744 additional security issues. Most notable amongst these are: 746 - interception of PCE requests or responses 747 - impersonation of PCE 748 - falsification of TE information 749 - denial of service attacks on PCE or PCE communication mechanisms 751 It is expected that the PCEP will address these issues in detail 752 using authentication and security techniques. See also Section 753 6.1.9. 755 8. Manageability Considerations 757 Manageability of the PCEP MUST address the following considerations: 759 - need for a MIB module for control and monitoring 760 - need for built-in diagnostic tools (e.g., partner failure 761 detection, OAM, etc.) 762 - configuration implications for the protocol 764 9. IANA Considerations 766 This document makes no requests for IANA action. 768 10. Acknowledgements 770 The authors would like to extend their warmest thanks to (in 771 alphabetical order) Adrian Farrel, Thomas Morin, and JP Vasseur for 772 their review and suggestions. 774 11. Normative References 776 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 777 Element (PCE) Architecture", work in progress. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 783 3667, February 2004. 785 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 786 Technology", BCP 79, RFC 3668, February 2004. 788 12. Informational References 790 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 791 Computation Element (PCE) Discovery," work in progress. 793 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 794 Tunnels," RFC 3209, December 2001. 796 13. Authors' Addresses 798 Jerry Ash 799 AT&T 800 Room MT D5-2A01 801 200 Laurel Avenue 802 Middletown, NJ 07748, USA 803 Phone: +1-(732)-420-4578 804 Email: gash@att.com 806 Alia K. Atlas 807 Avici Systems, Inc. 808 101 Billerica Avenue 809 N. Billerica, MA 01862, USA 810 Phone: +1 978 964 2070 811 Email: aatlas@avici.com 813 Arthi Ayyangar 814 Juniper Networks, Inc. 815 1194 N.Mathilda Ave 816 Sunnyvale, CA 94089 USA 817 Email: arthi@juniper.net 819 Nabil Bitar 820 Verizon 821 40 Sylvan Road 822 Waltham, MA 02145 823 Email: nabil.bitar@verizon.com 825 Igor Bryskin 826 Independent Consultant 827 Email: i_bryskin@yahoo.com 829 Dean Cheng 830 Cisco Systems Inc. 831 3700 Cisco Way 832 San Jose CA 95134 USA 833 Phone: +1 408 527 0677 834 Email: dcheng@cisco.com 836 Durga Gangisetti 837 MCI 838 Email: durga.gangisetti@mci.com 839 Kenji Kumaki 840 KDDI Corporation 841 Garden Air Tower 842 Iidabashi, Chiyoda-ku, 843 Tokyo 102-8460, JAPAN 844 Phone: +81-3-6678-3103 845 Email: ke-kumaki@kddi.com 847 Jean-Louis Le Roux 848 France Telecom 849 2, avenue Pierre-Marzin 850 22307 Lannion Cedex, FRANCE 851 Email: jeanlouis.leroux@francetelecom.com 853 Eiji Oki 854 NTT 855 Midori-cho 3-9-11 856 Musashino-shi, Tokyo 180-8585, JAPAN 857 Email: oki.eiji@lab.ntt.co.jp 859 Raymond Zhang 860 BT INFONET Services Corporation 861 2160 E. Grand Ave. 862 El Segundo, CA 90245 USA 863 Email: Raymond_zhang@bt.infonet.com 865 Intellectual Property Statement 867 The IETF takes no position regarding the validity or scope of any 868 Intellectual Property Rights or other rights that might be claimed to 869 pertain to the implementation or use of the technology described in 870 this document or the extent to which any license under such rights 871 might or might not be available; nor does it represent that it has 872 made any independent effort to identify any such rights. Information 873 on the procedures with respect to rights in RFC documents can be 874 found in BCP 78 and BCP 79. 876 Copies of IPR disclosures made to the IETF Secretariat and any 877 assurances of licenses to be made available, or the result of an 878 attempt made to obtain a general license or permission for the use of 879 such proprietary rights by implementers or users of this 880 specification can be obtained from the IETF on-line IPR repository at 881 http://www.ietf.org/ipr. 883 The IETF invites any interested party to bring to its attention any 884 copyrights, patents or patent applications, or other proprietary 885 rights that may cover technology that may be required to implement 886 this standard. Please address the information to the IETF at 887 ietf-ipr@ietf.org. 889 Disclaimer of Validity 891 This document and the information contained herein are provided on an 892 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 893 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 894 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 895 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 896 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 897 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 899 Copyright Statement 901 Copyright (C) The Internet Society (2005). This document is subject 902 to the rights, licenses and restrictions contained in BCP 78, and 903 except as set forth therein, the authors retain all their rights.