idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 946. ** 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 (September 2005) is 6797 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) == Missing Reference: 'RSVP-TE' is mentioned on line 663, but not defined == Missing Reference: 'EXCLUDE-ROUTE' is mentioned on line 665, but not defined == Unused Reference: 'RFC3667' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 853, 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 (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft PCE Working Group Jerry Ash (AT&T) 3 Proposed Status: Informational Editor 4 Expires: March 2006 J.L. Le Roux (France Telecom) 5 Editor 7 September 2005 9 draft-ietf-pce-comm-protocol-gen-reqs-02.txt 11 PCE Communication Protocol Generic Requirements 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 20, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The PCE model is described in the "PCE Architecture" document and 45 facilitates path computation requests from Path Computation Clients 46 (PCCs) to Path Computation Elements (PCEs). This document specifies 47 generic requirements for a communication protocol between PCCs and 48 PCEs, and also between PCEs where cooperation between PCEs is 49 desirable. Subsequent documents will specify application-specific 50 requirements for the PCE communication protocol. 52 Table of Contents 54 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 4 59 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 60 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 7 61 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 7 62 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 7 63 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 65 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 66 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 9 67 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 9 68 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 10 69 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 70 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 11 71 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 11 72 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 11 73 6.1.13 Communication Overhead Minimization . . . . . . . . . 12 74 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 12 75 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 76 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13 77 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14 78 6.2.1 Support for Different Service Provider Environments . . 14 79 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14 80 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 15 81 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 15 82 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 15 83 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 88 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 17 89 12. Informational References . . . . . . . . . . . . . . . . . . . . 17 90 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 19 92 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 19 93 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Contributors 96 This document is the result of the PCE Working Group PCE 97 Communication Protocol (PCECP) requirements design team joint effort. 98 The following are the design team member authors that contributed to 99 the present document: 101 Jerry Ash (AT&T) 102 Alia Atlas (Google, Inc.) 103 Arthi Ayyangar (Juniper) 104 Nabil Bitar (Verizon) 105 Igor Bryskin (Independent Consultant) 106 Dean Cheng (Cisco) 107 Durga Gangisetti (MCI) 108 Kenji Kumaki (KDDI) 109 Jean-Louis Le Roux (France Telecom) 110 Eiji Oki (NTT) 111 Raymond Zhang (BT Infonet) 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 3. Introduction 121 A Path Computation Element (PCE) [PCE-ARCH] supports requests for 122 path computation issued by a Path Computation Client (PCC), which may 123 be 'composite' (co-located) or 'external' (remote) from a PCE. When 124 the PCC is external from the PCE, a request/response communication 125 protocol is required to carry the path computation request and return 126 the response. In order for the PCC and PCE to communicate, the PCC 127 must know the location of the PCE: PCE discovery is described in 128 [PCE-DISC-REQ]. The PCE operates on a network graph in order to 129 compute paths based on the path computation request issued by the 130 PCC. The path computation request will normally include the source 131 and destination of the paths to be computed, and a set of constraints 132 to be applied during the computation. The PCE response includes the 133 computed paths or the reason for a failed computation. 135 This document lists a set of generic requirements for the PCE 136 Communication Protocol (PCECP). Application-specific requirements 137 are beyond the scope of this document, and will be addressed in 138 separate documents. 140 4. Terminology 142 Domain: any collection of network elements within a common sphere of 143 address management or path computational responsibility. Examples of 144 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 145 within a service provider network, or multiple ASs across multiple 146 service provider networks. 148 GMPLS: Generalized Multi-Protocol Label Switching 150 LSP: MPLS Label Switched Path. 152 MPLS: Multi-Protocol Label Switching 154 PCC: Path Computation Client: any client application requesting a 155 Path computation to be performed by the PCE. 157 PCE: Path Computation Element: an entity (component, application or 158 network node) that is capable of computing a network path or route 159 based on a network graph and applying computational constraints (see 160 further description in [PCE-ARCH]). 162 TED: Traffic Engineering Database, which contains the topology and 163 resource information of the network or network segment used by a PCE. 165 TE LSP: Traffic Engineering MPLS Label Switched Path. 167 See [PCE-ARCH] for further definitions of terms. 169 5. Overview of PCE Communication Protocol (PCECP) 171 In the PCE model, path computation requests are issued by a PCC 172 to a PCE that may be composite (co-located) or external (remote). 173 If the PCC and PCE are not composite, a request/response 174 communication protocol is required to carry the request and return 175 the response. If the PCC and PCE are composite, a communication 176 protocol is not required, but implementations may choose to utilize 177 a protocol for exchanges between the components. 179 In order that a PCC and PCE can communicate, the PCC must know the 180 location of the PCE. This can be configured or discovered. The PCE 181 discovery mechanism is out of scope of this document, but 182 requirements are documented in [PCE-DISC-REQ]. 184 The PCE operates on a network graph built from the TED in order to 185 compute paths. The mechanism by which the TED is populated is out of 186 scope for the PCECP. 188 A path computation request issued by the PCC includes a specification 189 of the path(s) needed. The information supplied includes, at a 190 minimum, the source and destination for the paths, but may also 191 include a set of further requirements (known as constraints) as 192 described in Section 6. 194 The response from the PCE may be positive in which case it will 195 include the paths that have been computed. If the computation fails 196 or cannot be performed, a negative response is required with an 197 indication of the type of failure. 199 A request/response protocol is also required for a PCE to communicate 200 path computation requests to another PCE and for that PCE to return 201 the path computation response. As described in [PCE-ARCH], there is 202 no reason to assume that two different protocols are needed, and this 203 document assumes that a single protocol will satisfy all requirements 204 for PCC-PCE and PCE-PCE communication. 206 [PCE-ARCH] describes four models of PCE: composite, external, 207 multiple PCE path computation, and multiple PCE path computation with 208 inter-PCE communication. In all cases except the composite PCE model, 209 a PCECP is required. The requirements defined in this document are 210 applicable to all models described in the [PCE-ARCH]. 212 6. PCE Communication Protocol Generic Requirements 214 The following is a summary of the requirements in Section 6: 216 Requirement Necessity Ref. 217 ------------------------------------------------------------------ 218 Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1 219 Client-server communication MUST 6.1.2 220 Support PCC/PCE request message to request path 221 computation MUST 6.1.2 222 Support PCE response message with computed path MUST 6.1.2 223 Support unsolicited communication PCE-PCC SHOULD 6.1.2 224 Maintain PCC-PCE session NON-RQMT 6.1.2 225 Use of existing transport protocol MAY 6.1.3 226 Transport protocol satisfy reliability & security 227 requirements MAY 6.1.3 228 Transport protocol limits size of message MUST NOT 6.1.3 229 Support path computation requests MUST 6.1.4 230 include source & destination 231 support path constraints (e.g., bandwidth, hops, 232 affinities) to include/exclude MUST 6.1.4 233 Support path reoptimization & inclusion of a 234 previously computed path MUST 6.1.4 235 Allow to select/prefer from advertised list of 236 standard objective functions/options MUST 6.1.4 237 Allow to customize objective function/options MUST 6.1.4 238 Support path computation responses MUST 6.1.5 239 Negative response support reasons for failure, 240 constraints to relax to achieve positive result SHOULD 6.1.5 241 Cancellation of pending requests MUST 6.1.6 242 Multiple requests and responses MUST 6.1.7 243 Limit by configuration number of requests within 244 a message MUST 6.1.7 245 Support multiple computed paths in response MUST 6.1.7 246 Support "continuation correlation" where related 247 requests or computed paths cannot fit within one 248 message MUST 6.1.7 249 Maximum message size & maximum number of requests 250 per message exchanged through PCE messages to PCC, 251 or indicated in request message MAY 6.1.7 252 Reliable message exchange (achieved by PCECP 253 itself or transport protocol MUST 6.1.8 254 Allow detection & recovery of lost messages to 255 occur quickly & not impede operation of PCECP MUST 6.1.8 256 Handle overload situations without significant 257 decrease in performance, e.g., through throttling 258 of requests MUST 6.1.8 259 Provide acknowledged message delivery with 260 retransmission, in order message delivery or 261 facility to restore order, message corruption 262 detection, flow control & back-pressure to 263 throttle requests, rapid partner failure 264 detection, informed rapidly of failure of PCE-PCC 265 connection MUST 6.1.8 266 Functionality added to PCECP if transport protocol 267 provides it SHOULD NOT 6.1.8 268 Secure message exchange (provided by PCECP or 269 transport protocol MUST 6.1.9 270 Support mechanisms to prevent spoofing (e.g., 271 authentication), snooping (e.g., encryption), 272 DOS attacks MUST 6.1.9 273 Request prioritization MUST 6.1.10 274 Unsolicited notifications SHOULD 6.1.11 275 Allow asynchronous communication MUST 6.1.12 276 PCC has to wait for response before making 277 another request MUST NOT 6.1.12 278 Allow order of responses differ from order of 279 requests MUST 6.1.12 280 Communication overhead minimization SHOULD 6.1.13 281 Give particular attention to message size SHOULD 6.1.13 282 Extensibility without requiring modifications to 283 the protocol MUST 6.1.14 284 Easily extensible to support intra-area, 285 inter-area, inter-AS intra provider, inter-AS 286 inter-provider, multi-layer path & virtual network 287 topology path computation MUST 6.1.14 288 Easily extensible to support future applications 289 not in scope (e.g., P2MP path computations) SHOULD 6.1.14 290 Scalability at least linearly with increase in 291 number of PCCs, PCEs, PCCs communicating with a 292 single PCE, PCEs communicated to by a single PCC, 293 PCEs communicated to by another PCE, domains, path 294 requests, handling bursts of requests MUST 6.1.15 295 Support path computation constraints MUST 6.1.16 296 Support different service provider environments 297 (e.g., MPLS-TE and GMPLS networks, centralized & 298 distributed PCE path computation, single & 299 multiple PCE path computation) MUST 6.2.1 300 Policy support for policies to accept/reject 301 requests, PCC to determine reason for rejection, 302 notification of policy violation MUST 6.2.2 303 Aliveness detection of PCCs/PCEs, partner failure 304 detection MUST 6.3.1 305 PCC/PCE failure response procedures defined for 306 PCE/PCC failures, PCC able to clear pending 307 request must 6.3.2 308 PCC select another PCE upon detection of PCE 309 failure MUST 6.3.2 310 PCE able to clear pending requests from a PCC 311 (e.g. when it detects PCC failure or request 312 buffer full) must 6.3.2 313 Protocol recovery support resynchronization of 314 information & requests between sender & receiver MUST 6.3.3 315 Minimize repeat data transfer, allow PCE to 316 respond to computation requests issued before 317 failure without requests being re-issued SHOULD 6.3.3 318 Stateful PCE able to resynchronize/recover 319 states (e.g., LSP status, paths) after restart SHOULD 6.3.3 321 6.1 Basic Protocol Requirements 323 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 325 A single protocol MUST be defined for PCC-PCE and PCE-PCE 326 communication. A PCE requesting a path from another PCE can be 327 considered as a PCC. 329 6.1.2 Client-Server Communication 331 PCC-PCE and PCE-PCE communication is by nature client-server based. 332 The PCECP MUST allow for a PCC or a PCE to send a request message to 333 a PCE to request path computation, and for a PCE to reply with a 334 response message to the requesting PCC or PCE, once the path has been 335 computed. 337 In addition to this request-response mode, there may be cases where 338 there is unsolicited communication from the PCE to PCC (see 339 Requirement 6.1.6). 341 6.1.3 Transport 343 The PCECP may utilize an existing transport protocol or operate 344 directly over IP. 346 If a transport protocol is used, it may be used to satisfy some 347 requirements stated in other sections of this document (for example, 348 reliability and security). 350 If a transport protocol is used, it MUST NOT limit the size of the 351 message used by the PCECP. 353 Where requirements expressed in this document match the function of 354 existing transport protocols, consideration MUST be given to the use 355 of those protocols. 357 6.1.4 Path Computation Requests 359 The request message MUST include, at least, a source and a 360 destination. However, there is no assumption that the receiving PCE 361 has the complete source/destination domain topology, particularly in 362 the multiple PCE path computation model [PCE-ARCH]. In the latter 363 case, the PCE may have incomplete topological information for 364 multiple domains. 366 The message MUST support the inclusion of a set of one or more path 367 constraints, including the requested bandwidth or resources (hops, 368 affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to 369 exclude points of failure in the computation of the new path if an 370 LSP setup fails). The actual inclusion of constraints is a choice 371 for the PCC issuing the request. A list of core constraints that 372 MUST be supported by the PCECP is supplied in Section 6.1.16. 373 Specification of constraints must be future-proofed as described in 374 Section 6.1.14. 376 The path computation request message MUST support TE LSP path 377 reoptimization and the inclusion of a previously computed path. This 378 will help ensure optimal routing of a reoptimized path, since it will 379 allow the PCE to avoid double bandwidth accounting and help reduce 380 blocking issues. 382 The requester MUST be allowed to select or prefer from an advertised 383 list or minimal subset of standard objective functions and functional 384 options. An objective function is used by the PCE to compute a path 385 metric in order to select the best candidate paths (e.g., minimum hop 386 path), and corresponds to the optimization criteria used for the 387 computation of one path, or the synchronized computation of a set of 388 paths. In case of unsynchronized path computation, this can be, for 389 example, the path cost or the residual bandwidth on the most loaded 390 path link. In case of synchronized path computation, this can be, 391 for example, the global bandwidth consumption or the residual 392 bandwidth on the most loaded network link. 394 The requester SHOULD also be able to select a vendor-specific or 395 experimental objective function or functional option. Furthermore, 396 the requester MUST be allowed to customize the function/options in 397 use. That is, individual objective functions will often have 398 parameters to be set in the request from PCC to PCE. Specification 399 of objective functions and objective parameters is required in the 400 protocol extensibility specified in Section 6.1.14. 402 Note that a PCC MAY send a request that is based on the set of TE 403 parameters carried by the MPLS/GMPLS LSP setup signaling protocol, 404 and as long as those parameters are satisfied, the PCC MAY not care 405 about which objective function is used. Also, the PCE MAY execute 406 additional objective functions not explicitly requested by the PCC. 407 This might include policy based routing path computation for load 408 balancing instructed by the management plane. The PCC MUST NOT be 409 allowed to request or cause a computation to fail because it does not 410 wish the PCE to apply a specific objective function. Allowing such 411 behavior would constitute a security risk. 413 6.1.5 Path Computation Responses 415 The response message MUST allow returning various elements including, 416 at least, the computed path(s). 418 The protocol MUST be capable of returning any explicit path that 419 would be acceptable for use for MPLS and GMPLS LSPs once converted to 420 an Explicit Route Object for use in RSVP-TE signaling. In addition, 421 anything that can be expressed in an Explicit Route Object MUST be 422 capable of being returned in the computed path. Note that the 423 resultant path(s) may be made up of a set of strict or loose hops, or 424 any combination of strict and loose hops. Moreover, a hop may have 425 the form of a non-simple abstract node. See RFC 3209 for the 426 definition of strict hop, loose hop, and abstract node. 428 A positive response from the PCE will include the paths that have 429 been computed. When a path satisfying the constraints cannot be 430 found, or if the computation fails or cannot be performed, a 431 negative response MUST be sent. This response MAY include further 432 details of the reason(s) for the failure, and potentially advice 433 about which constraints might be relaxed to be more likely to achieve 434 a positive result. 436 6.1.6 Cancellation of Pending Requests 438 A PCC or PCE MUST be able to cancel a pending request, using an 439 appropriate notification between PCECP peers. A PCC that has sent a 440 request to a PCE and no longer needs a response, for instance, 441 because it received a satisfactory answer from another PCE, MUST be 442 able to notify the PCE that it must clear the request (i.e. stop the 443 computation, if already started, and clear the context). Similarly, 444 a PCE that received a request from a PCC that it cannot serve, for 445 example, due to congestion, MUST be able to notify the PCC, that the 446 request will not be served. 448 6.1.7 Multiple Requests and Responses 450 It MUST be possible to send multiple path computation requests, 451 correlated or not, within the same request message. There are 452 various motivations for doing so (optimality, path diversity, etc.). 453 It MUST be possible to limit by configuration of both PCCs and PCEs 454 the number of requests that can be carried within a single message. 456 Similarly, it MUST be possible to return multiple computed paths 457 within the same response message, corresponding either to the same 458 request (e.g. load balancing) or to distinct requests, correlated or 459 not, of the same request message or distinct request messages. 461 It MUST be possible to provide "continuation correlation" where all 462 related requests or computed paths cannot fit within one message. 464 Maximum acceptable message sizes and the maximum number of requests 465 per message supported by a PCE MAY form part of PCE capabilities 466 advertisement [PCE-DISC-REQ], or MAY be exchanged through information 467 messages from the PCE as part of the protocol described here. 469 Maximum acceptable message sizes and the maximum number of computed 470 paths per message supported by a PCC MAY be indicated in the request 471 message. 473 An implementation MAY choose to limit message size to avoid a big 474 message from unduly delaying a small message. 476 6.1.8 Reliable Message Exchange 478 The PCECP MUST include reliability. This may form part of the 479 protocol itself or may be achieved by the selection of a suitable 480 transport protocol (see Section 6.1.3). 482 In particular, it MUST allow for the detection and recovery of lost 483 messages to occur quickly and not impede the operation of the PCECP. 485 In some cases (e.g. after link failure), a large number of PCCs may 486 simultaneously send requests to a PCE, leading to a potential 487 saturation of the PCEs. The PCECP or the transport protocol it uses 488 MUST properly handle such overload situations, such as through 489 throttling of requests. For example, a PCE MUST be able to limit the 490 rate of incoming request messages to a manageable rate by notifying 491 PCCs and/or peering PCEs. 493 The PCECP or the transport protocol it uses MUST provide: 495 - Acknowledged message delivery with retransmission. 496 - In order message delivery or the facility (such as message 497 numbering) to restore the order of received messages. 498 - Message corruption detection. 499 - Flow control and back-pressure, as specified above with the 500 throttling of requests. 501 - Rapid partner failure detection. 503 - Rapid PCE/PCC or PCC-PCE connection failure detection after 504 failure happens. 506 If it is necessary to add functions to PCECP to overcome shortcomings 507 in the chosen transport mechanisms, these functions SHOULD be based 508 on and re-use where possible techniques developed in other protocols 509 to overcome the same shortcomings. Functionality SHOULD NOT be added 510 to the PCECP where the chosen transport protocol already provides it. 512 6.1.9 Secure Message Exchange 514 The PCC-PCE and PCE-PCE communication protocol MUST include 515 provisions to improve the security of the exchanges between the 516 entities. In particular, it MUST support mechanisms to prevent 517 spoofing (e.g., authentication), snooping (e.g., encryption) and DOS 518 attacks (e.g., rate limiting, no promiscuous listening). 520 This function may be provided by the transport protocol or directly 521 by the PCECP. 523 See Section 7 for further discussion of security considerations. 525 6.1.10 Request Prioritization 527 The PCECP MUST allow a PCC to specify the priority of a computation 528 request. This priority MAY be used by a PCE to service high priority 529 requests before lower priority requests considering all requests 530 received and queued by a single PCE from all PCCs. 532 Implementation of priority-based activity within a PCE is subject to 533 implementation and local policy. This application processing is out 534 of scope of the PCECP. 536 6.1.11 Unsolicited Notifications 538 The normal operational mode is for the PCC to make path computation 539 requests to the PCE, and for the PCE to respond. 541 The PCECP SHOULD support unsolicited notifications from PCE to PCC, 542 PCE to PCE, or PCC to PCE. This requirement facilitates the 543 unsolicited communication of information and alerts between PCCs and 544 PCEs and between PCEs. 546 6.1.12 Asynchronous Communication 548 The PCC-PCE protocol MUST allow for asynchronous communication. A 549 PCC MUST NOT have to wait for a response before it can make another 550 request. 552 It MUST also be possible to have the order of responses differ from 553 the order of the corresponding requests. This may occur, for 554 instance, when path request messages have different priorities (see 555 Requirement 6.1.10). 557 6.1.13 Communication Overhead Minimization 559 The request and response messages SHOULD be designed so that the 560 communication overhead is minimized. In particular, the overhead per 561 message should be minimized, and the number of bytes exchanged to 562 arrive at a computation answer should be minimized. Note that 563 compression techniques are not required. Other considerations in 564 overhead minimization include the following: 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 PCECP 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 PCECP 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 PCECP 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 PCECP 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, multi-hop pseudowire 596 path computation, etc. 598 Note that application specific requirements are out of the scope of 599 this document and will be addressed in separate requirements 600 documents. 602 6.1.15 Scalability 604 The PCECP MUST scale well, at least as good as linearly, with an 605 increase of any of the following parameters (note, minimum order of 606 magnitude estimates of what the PCECP should support are given in 607 parenthesis): 609 - number of PCCs (1000/domain) 610 - number of PCEs (100/domain) 611 - number of PCCs communicating with a single PCE (1000) 612 - number of PCEs communicated to by a single PCC (100) 613 - number of PCEs communicated to by another PCE (100) 614 - number of domains (20) 615 - number of path request messages (average of 10/second/PCE) 616 - handling bursts of requests (burst of 100/second/PCE within a 10- 617 second interval). 619 Note that path requests can be bundled in path request messages, for 620 example, 10 path request messages/second may correspond to 100 path 621 requests/second. 623 Bursts of requests may arise, for example, after a network outage 624 when multiple recomputations are requested. It is RECOMMENDED that 625 the protocol handle the congestion in a graceful way so that it does 626 not unduly impact the rest of the network, and so that it does not 627 gate the ability of the PCE to perform computation. 629 6.1.16 Constraints 631 This section provides a list of generic constraints that MUST be 632 supported by the PCECP. Other constraints may be added to service 633 specific applications as identified by separate application-specific 634 requirements documents. 636 Note that the absence of a constraint in this list does not mean that 637 that constraint must not be supported. Note also that the provisions 638 of Section 6.1.14 mean that new constraints can be added to this list 639 without impacting the protocol. 641 Here is the list of generic constraints that MUST be supported: 643 o MPLS-TE and GMPLS generic constraints: 644 - Bandwidth 645 - Affinities inclusion/exclusion 646 - Link, Node, SRLG inclusion/exclusion 647 - Maximum end-to-end delay metrics 648 - Hop Count 649 - Maximum end-to-end TE metric (cost) 650 - Multiple disjoint path computation to allow path protection 652 o MPLS-TE specific constraints 653 - Class-type 654 - Local protection 655 - Node protection 656 - Bandwidth protection 658 o GMPLS specific constraints 659 - Switching type, encoding type 660 - Link protection type 662 Regarding affinities inclusion/exclusion, note the three categories 663 used in [RSVP-TE]: exclude-any, include-any, include-all. Regarding 664 link, node, SRLG inclusion/exclusion, note the mandatory and desired 665 exclusion approach in [EXCLUDE-ROUTE]. 667 6.2 Deployment Support Requirements 669 6.2.1 Support for Different Service Provider Environments 671 The PCECP MUST operate in various different service provider network 672 environments that utilize an IP-based control plane, including 674 - MPLS-TE and GMPLS networks 675 - packet and non-packet networks 677 - centralized and distributed PCE path computation 678 - single and multiple PCE path computation 680 Definitions of centralized, distributed, single, and multiple PCE 681 path computation can be found in [PCE-ARCH]. 683 6.2.2 Policy Support 685 The PCECP MUST allow for policies to accept/reject requests, and 686 include the ability for a PCE to reject requests with sufficient 687 detail to allow the PCC to determine the reason for rejection or 688 failure. For example, filtering could be required for intra-AS PCE 689 path computation such that all requests are rejected that come from 690 another AS. However, specific policy details are left to 691 application-specific PCECP requirements. Furthermore, the PCECP MUST 692 allow for the notification of a policy violation. Actual policies, 693 configuration of policies, and applicability of policies are out of 694 scope. 696 Note that work on supported policy models and the corresponding 697 requirements/implications is being undertaken as a separate work item 698 in the PCE working group. 700 6.3 Detection & Recovery Requirements 702 6.3.1 Aliveness Detection 704 The PCECP MUST allow a PCC to check the liveliness of PCEs it is 705 using for path computation, and a PCE to check the liveliness of 706 PCCs it is serving. This includes detection of PCE liveness before a 707 PCE is used for computation. i.e. during PCE selection. A PCC should 708 be aware of PCE liveness at all times. The PCECP MUST provide 709 partner failure detection. 711 The aliveness detection mechanism MUST ensure reciprocal knowledge of 712 PCE and PCC liveness. 714 Note that the PCE or PCC software component can be lost without 715 losing the connection or the transport end-point, when a transport 716 protocol is used. 718 6.3.2 PCC/PCE Failure Response 720 Appropriate PCC and PCE procedures MUST be defined to deal with PCE 721 and PCC failures. A PCC must be able to clear any pending request to 722 a PCE so that it is no longer waiting for a response. Clearing a 723 pending request does not imply any message exchange; this differs 724 from pending request cancellation (Section 6.1.6), which requires 725 message exchange. It is RECOMMENDED that a PCC select another PCE 726 upon detection of PCE failure or unreachability of a PCE but note 727 that PCE selection procedure are out of the scope of this document. 729 Similarly, a PCE must be able to clear pending requests from a PCC, 730 for instance, when it detects the failure of the requesting PCC or 731 when its buffer of requests is full. Clearing a pending request does 732 not imply any message exchange. 734 6.3.3 Protocol Recovery 736 Information distributed in asynchronous/unsolicited messages MAY 737 persist at the recipient in the event of the failure of the sender or 738 of the communication channel. Upon recovery, the Communication 739 Protocol MUST support resynchronization of information and requests 740 between the sender and the receiver, and this SHOULD be arranged so 741 as to minimize repeat data transfer. 743 The response to a computation request issued before the PCC is 744 restarted will not be helpful and could be a waste of effort. Thus 745 it is better to allow the request to be re-issued in shorthand (e.g. 746 by request number) if the PCC remembers that it had previously issued 747 it and is still interested in the response. 749 The PCECP SHOULD allow a PCE to respond to computation requests 750 issued before the failure without the requests being re-issued. 752 7. Security Considerations 754 The impact of the use of a PCECP MUST be considered in the light of 755 the impact that it has on the security of the existing routing and 756 signaling protocols and techniques in use within the network. 757 Intra-domain security is impacted since there is a new interface, 758 protocol and element in the network. Any host in the network could 759 impersonate a PCC, and receive detailed information on network paths. 760 Any host could also impersonate a PCE, both gathering information 761 about the network before passing the request on to a real PCE, and 762 spoofing responses. Some protection here depends on the PCE 763 discovery process (if it uses the IGP it relies on IGP security). An 764 increase in inter-domain information flows may increase the 765 vulnerability to security attacks, and the facilitation of 766 inter-domain path may increase the impact of these security attacks. 768 Of particular relevance are the implications for confidentiality 769 inherent in a PCECP for multi-domain networks. It is not necessarily 770 the case that a multi-domain PCE solution will compromise security, 771 but solutions MUST examine their impacts in this area. 773 Applicability statements for particular combinations of signaling, 774 routing and path computation techniques are expected to contain 775 detailed security sections. 777 It should be observed that the use of an external PCE does introduce 778 additional security issues. Most notable amongst these are: 780 - interception of PCE requests or responses 781 - impersonation of PCE or PCC 782 - denial of service attacks on PCE or PCE communication mechanisms 784 It is expected that the PCECP will address these issues in detail 785 using authentication, encryption and DoS protection techniques. See 786 also Section 6.1.9. 788 8. Manageability Considerations 790 Manageability of the PCECP MUST address the following considerations: 792 - need for a MIB module for control and monitoring 793 - need for built-in diagnostic tools (e.g., partner failure 794 detection, OAM, etc.) 795 - configuration implications for the protocol 797 It is expected that PCECP operations will be modeled and controlled 798 through appropriate MIB modules. Statistics gathering will form an 799 important part of the operation of the PCECP. The operator must be 800 able to determine PCECP historical interactions and success rate of 801 requests. Similarly, it is important for an operator to be able to 802 determine PCECP load and whether an individual PCC is responsible for 803 a disproportionate amount of the load. It will also be important to 804 be able to record and inspect statistics about the PCECP 805 communications, including issues such as malformed messages, 806 unauthorized messages and messages discarded owing to congestion. 808 The new MIB modules should also be used to provide notifications 809 (traps) when thresholds are crossed or when important events occur. 811 PCECP techniques must enable a PCC to determine the liveness of a PCE 812 both before it sends a request and in the period between sending a 813 request and receiving a response. 815 It is also important for a PCE to know about the liveness of PCCs to 816 gain a predictive view of the likely loading of a PCE in the future, 817 and to allow a PCE to abandon processing of a received request. 819 It should be possible for an operator to rate limit the requests that 820 a PCC sends to a PCE, and a PCE should be able to report impending 821 congestion (according to a configured threshold) both to the operator 822 and to its PCCs. 824 9. IANA Considerations 826 This document makes no requests for IANA action. 828 10. Acknowledgements 830 The authors would like to extend their warmest thanks to (in 831 alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri 832 Papadimitriou, and JP Vasseur for their review and suggestions. 834 11. Normative References 836 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 837 Element (PCE) Architecture", work in progress. 839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, March 1997. 842 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 843 3667, February 2004. 845 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 846 Technology", BCP 79, RFC 3668, February 2004. 848 12. Informational References 850 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 851 Computation Element (PCE) Discovery," work in progress. 853 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 854 Tunnels," RFC 3209, December 2001. 856 13. Authors' Addresses 858 Jerry Ash 859 AT&T 860 Room MT D5-2A01 861 200 Laurel Avenue 862 Middletown, NJ 07748, USA 863 Phone: +1-(732)-420-4578 864 Email: gash@att.com 865 Alia K. Atlas 866 Google Inc. 867 1600 Amphitheatre Parkway 868 Mountain View, CA 94043 869 Email: akatlas@alum.mit.edu 871 Arthi Ayyangar 872 Juniper Networks, Inc. 873 1194 N.Mathilda Ave 874 Sunnyvale, CA 94089 USA 875 Email: arthi@juniper.net 877 Nabil Bitar 878 Verizon 879 40 Sylvan Road 880 Waltham, MA 02145 881 Email: nabil.bitar@verizon.com 883 Igor Bryskin 884 Independent Consultant 885 Email: i_bryskin@yahoo.com 887 Dean Cheng 888 Cisco Systems Inc. 889 3700 Cisco Way 890 San Jose CA 95134 USA 891 Phone: +1 408 527 0677 892 Email: dcheng@cisco.com 894 Durga Gangisetti 895 MCI 896 Email: durga.gangisetti@mci.com 898 Kenji Kumaki 899 KDDI Corporation 900 Garden Air Tower 901 Iidabashi, Chiyoda-ku, 902 Tokyo 102-8460, JAPAN 903 Phone: +81-3-6678-3103 904 Email: ke-kumaki@kddi.com 906 Jean-Louis Le Roux 907 France Telecom 908 2, avenue Pierre-Marzin 909 22307 Lannion Cedex, FRANCE 910 Email: jeanlouis.leroux@francetelecom.com 912 Eiji Oki 913 NTT 914 Midori-cho 3-9-11 915 Musashino-shi, Tokyo 180-8585, JAPAN 916 Email: oki.eiji@lab.ntt.co.jp 918 Raymond Zhang 919 BT INFONET Services Corporation 920 2160 E. Grand Ave. 921 El Segundo, CA 90245 USA 922 Email: Raymond_zhang@bt.infonet.com 924 Intellectual Property Statement 926 The IETF takes no position regarding the validity or scope of any 927 Intellectual Property Rights or other rights that might be claimed to 928 pertain to the implementation or use of the technology described in 929 this document or the extent to which any license under such rights 930 might or might not be available; nor does it represent that it has 931 made any independent effort to identify any such rights. Information 932 on the procedures with respect to rights in RFC documents can be 933 found in BCP 78 and BCP 79. 935 Copies of IPR disclosures made to the IETF Secretariat and any 936 assurances of licenses to be made available, or the result of an 937 attempt made to obtain a general license or permission for the use of 938 such proprietary rights by implementers or users of this 939 specification can be obtained from the IETF on-line IPR repository at 940 http://www.ietf.org/ipr. 942 The IETF invites any interested party to bring to its attention any 943 copyrights, patents or patent applications, or other proprietary 944 rights that may cover technology that may be required to implement 945 this standard. Please address the information to the IETF at 946 ietf-ipr@ietf.org. 948 Disclaimer of Validity 950 This document and the information contained herein are provided on an 951 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 952 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 953 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 954 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 955 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 958 Copyright Statement 960 Copyright (C) The Internet Society (2005). This document is subject 961 to the rights, licenses and restrictions contained in BCP 78, and 962 except as set forth therein, the authors retain all their rights.