idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-03.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 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1045. ** 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 (December 2005) is 6706 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 699, but not defined == Missing Reference: 'EXCLUDE-ROUTE' is mentioned on line 701, but not defined == Unused Reference: 'RFC3667' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 951, 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: June 2006 J.L. Le Roux (France Telecom) 5 Editor 7 December 2005 9 draft-ietf-pce-comm-protocol-gen-reqs-03.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 June 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) . . . . . . . . . 5 59 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6 60 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8 61 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8 62 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8 63 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 65 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 66 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10 67 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10 68 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11 69 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 70 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 12 71 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12 72 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12 73 6.1.13 Communication Overhead Minimization . . . . . . . . . 12 74 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 13 75 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 76 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 14 77 6.1.17 Objective Functions Supported . . . . . . . . . . . . 15 78 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 15 79 6.2.1 Support for Different Service Provider Environments . . 15 80 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 15 81 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 16 82 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 16 83 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 16 84 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 16 85 6.3.4 LSP Rerouting & Reoptimization . . . . . . . . . . . . 17 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 18 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 19 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 90 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 19 91 12. Informational References . . . . . . . . . . . . . . . . . . . . 19 92 13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 20 93 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 21 94 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21 95 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Contributors 98 This document is the result of the PCE Working Group PCE 99 Communication Protocol (PCECP) requirements design team joint effort. 100 The following are the design team member authors that contributed to 101 the present document: 103 Jerry Ash (AT&T) 104 Alia Atlas (Google, Inc.) 105 Arthi Ayyangar (Juniper) 106 Nabil Bitar (Verizon) 107 Igor Bryskin (Independent Consultant) 108 Dean Cheng (Cisco) 109 Durga Gangisetti (MCI) 110 Kenji Kumaki (KDDI) 111 Jean-Louis Le Roux (France Telecom) 112 Eiji Oki (NTT) 113 Raymond Zhang (BT Infonet) 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 3. Introduction 123 A Path Computation Element (PCE) [PCE-ARCH] supports requests for 124 path computation issued by a Path Computation Client (PCC), which may 125 be 'composite' (co-located) or 'external' (remote) from a PCE. When 126 the PCC is external from the PCE, a request/response communication 127 protocol is required to carry the path computation request and return 128 the response. In order for the PCC and PCE to communicate, the PCC 129 must know the location of the PCE: PCE discovery is described in 130 [PCE-DISC-REQ]. The PCE operates on a network graph in order to 131 compute paths based on the path computation request issued by the 132 PCC. The path computation request will normally include the source 133 and destination of the paths to be computed, and a set of constraints 134 to be applied during the computation. The PCE response includes the 135 computed paths or the reason for a failed computation. 137 This document lists a set of generic requirements for the PCE 138 Communication Protocol (PCECP). Application-specific requirements 139 are beyond the scope of this document, and will be addressed in 140 separate documents. 142 4. Terminology 144 Domain: any collection of network elements within a common sphere of 145 address management or path computational responsibility. Examples of 146 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 147 within a service provider network, or multiple ASs across multiple 148 service provider networks. 150 GMPLS: Generalized Multi-Protocol Label Switching 152 LSP: MPLS Label Switched Path. 154 MPLS: Multi-Protocol Label Switching 156 PCC: Path Computation Client: any client application requesting a 157 Path computation to be performed by the PCE. 159 PCE: Path Computation Element: an entity (component, application or 160 network node) that is capable of computing a network path or route 161 based on a network graph and applying computational constraints (see 162 further description in [PCE-ARCH]). 164 TED: Traffic Engineering Database, which contains the topology and 165 resource information of the network or network segment used by a PCE. 167 TE LSP: Traffic Engineering MPLS Label Switched Path. 169 See [PCE-ARCH] for further definitions of terms. 171 5. Overview of PCE Communication Protocol (PCECP) 173 In the PCE model, path computation requests are issued by a PCC 174 to a PCE that may be composite (co-located) or external (remote). 175 If the PCC and PCE are not composite, a request/response 176 communication protocol is required to carry the request and return 177 the response. If the PCC and PCE are composite, a communication 178 protocol is not required, but implementations may choose to utilize 179 a protocol for exchanges between the components. 181 In order that a PCC and PCE can communicate, the PCC must know the 182 location of the PCE. This can be configured or discovered. The PCE 183 discovery mechanism is out of scope of this document, but 184 requirements are documented in [PCE-DISC-REQ]. 186 The PCE operates on a network graph built from the TED in order to 187 compute paths. The mechanism by which the TED is populated is out of 188 scope for the PCECP. 190 A path computation request issued by the PCC includes a specification 191 of the path(s) needed. The information supplied includes, at a 192 minimum, the source and destination for the paths, but may also 193 include a set of further requirements (known as constraints) as 194 described in Section 6. 196 The response from the PCE may be positive in which case it will 197 include the paths that have been computed. If the computation fails 198 or cannot be performed, a negative response is required with an 199 indication of the type of failure. 201 A request/response protocol is also required for a PCE to communicate 202 path computation requests to another PCE and for that PCE to return 203 the path computation response. As described in [PCE-ARCH], there is 204 no reason to assume that two different protocols are needed, and this 205 document assumes that a single protocol will satisfy all requirements 206 for PCC-PCE and PCE-PCE communication. 208 [PCE-ARCH] describes four models of PCE: composite, external, 209 multiple PCE path computation, and multiple PCE path computation with 210 inter-PCE communication. In all cases except the composite PCE model, 211 a PCECP is required. The requirements defined in this document are 212 applicable to all models described in the [PCE-ARCH]. 214 6. PCE Communication Protocol Generic Requirements 216 The following is a summary of the requirements in Section 6: 218 Requirement Necessity Ref. 219 ------------------------------------------------------------------ 220 Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1 221 Client-server communication MUST 6.1.2 222 Support PCC/PCE request message to request path 223 computation MUST 6.1.2 224 Support PCE response message with computed path MUST 6.1.2 225 Support unsolicited communication PCE-PCC SHOULD 6.1.2 226 Maintain PCC-PCE session NON-RQMT 6.1.2 227 Use of existing transport protocol MAY 6.1.3 228 Transport protocol satisfy reliability & security 229 requirements MAY 6.1.3 230 Transport protocol limits size of message MUST NOT 6.1.3 231 Support path computation requests MUST 6.1.4 232 include source & destination 233 support path constraints (e.g., bandwidth, hops, 234 affinities) to include/exclude 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 Allow indicating the metric type (IGP or TE) to 239 be used for shortest path selection MUST 6.1.4 240 Allow indicating the set of aggregate path 241 attributes required in response message MUST 6.1.4 242 Allow indicating if load-balancing is allowed MUST 6.1.4 243 Support path computation responses MUST 6.1.5 244 Negative response support reasons for failure, 245 constraints to relax to achieve positive result SHOULD 6.1.5 246 Support inclusion of set of aggregate path 247 attributes MUST 6.1.5 248 Support inclusion of set of computed paths of a 249 load-balancing path group, as well as their 250 respective bandwidth MUST 6.1.5 251 Cancellation of pending requests MUST 6.1.6 252 Multiple requests and responses MUST 6.1.7 253 Limit by configuration number of requests within 254 a message MUST 6.1.7 255 Support multiple computed paths in response MUST 6.1.7 256 Support "continuation correlation" where related 257 requests or computed paths cannot fit within one 258 message MUST 6.1.7 259 Maximum message size & maximum number of requests 260 per message exchanged through PCE messages to PCC, 261 or indicated in request message MAY 6.1.7 262 Reliable message exchange (achieved by PCECP 263 itself or transport protocol MUST 6.1.8 264 Allow detection & recovery of lost messages to 265 occur quickly & not impede operation of PCECP MUST 6.1.8 266 Handle overload situations without significant 267 decrease in performance, e.g., through throttling 268 of requests MUST 6.1.8 269 Provide acknowledged message delivery with 270 retransmission, in order message delivery or 271 facility to restore order, message corruption 272 detection, flow control & back-pressure to 273 throttle requests, rapid partner failure 274 detection, informed rapidly of failure of PCE-PCC 275 connection MUST 6.1.8 276 Functionality added to PCECP if transport protocol 277 provides it SHOULD NOT 6.1.8 278 Secure message exchange (provided by PCECP or 279 transport protocol MUST 6.1.9 280 Support mechanisms to prevent spoofing (e.g., 281 authentication), snooping (e.g., encryption), 282 DOS attacks MUST 6.1.9 283 Request prioritization MUST 6.1.10 284 Unsolicited notifications SHOULD 6.1.11 285 Allow asynchronous communication MUST 6.1.12 286 PCC has to wait for response before making 287 another request MUST NOT 6.1.12 288 Allow order of responses differ from order of 289 requests MUST 6.1.12 290 Communication overhead minimization SHOULD 6.1.13 291 Give particular attention to message size SHOULD 6.1.13 292 Extensibility without requiring modifications to 293 the protocol MUST 6.1.14 294 Easily extensible to support intra-area, 295 inter-area, inter-AS intra provider, inter-AS 296 inter-provider, multi-layer path & virtual network 297 topology path computation MUST 6.1.14 298 Easily extensible to support future applications 299 not in scope (e.g., P2MP path computations) SHOULD 6.1.14 300 Scalability at least linearly with increase in 301 number of PCCs, PCEs, PCCs communicating with a 302 single PCE, PCEs communicated to by a single PCC, 303 PCEs communicated to by another PCE, domains, path 304 requests, handling bursts of requests MUST 6.1.15 305 Support path computation constraints MUST 6.1.16 306 Support "unsynchronized" & "synchronized" 307 objective functions MUST 6.1.17 308 Support different service provider environments 309 (e.g., MPLS-TE and GMPLS networks, centralized & 310 distributed PCE path computation, single & 311 multiple PCE path computation) MUST 6.2.1 312 Policy support for policies to accept/reject 313 requests, PCC to determine reason for rejection, 314 notification of policy violation MUST 6.2.2 315 Aliveness detection of PCCs/PCEs, partner failure 316 detection MUST 6.3.1 317 PCC/PCE failure response procedures defined for 318 PCE/PCC failures, PCC able to clear pending 319 request must 6.3.2 320 PCC select another PCE upon detection of PCE 321 failure MUST 6.3.2 322 PCE able to clear pending requests from a PCC 323 (e.g. when it detects PCC failure or request 324 buffer full) must 6.3.2 325 Protocol recovery support resynchronization of 326 information & requests between sender & receiver MUST 6.3.3 327 Minimize repeat data transfer, allow PCE to 328 respond to computation requests issued before 329 failure without requests being re-issued SHOULD 6.3.3 330 Stateful PCE able to resynchronize/recover 331 states (e.g., LSP status, paths) after restart SHOULD 6.3.3 332 Allow indicating if computation is for LSP 333 restoration (support inclusion of previously 334 computed path & failed element) MUST 6.3.4 335 Support inclusion in response message of upper 336 bound of a random waiting time for further 337 requests MAY 6.3.4 338 Support path reoptimization & inclusion of a 339 previously computed path MUST 6.3.4 341 6.1 Basic Protocol Requirements 343 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 345 A single protocol MUST be defined for PCC-PCE and PCE-PCE 346 communication. A PCE requesting a path from another PCE can be 347 considered as a PCC. 349 6.1.2 Client-Server Communication 351 PCC-PCE and PCE-PCE communication is by nature client-server based. 352 The PCECP MUST allow for a PCC or a PCE to send a request message to 353 a PCE to request path computation, and for a PCE to reply with a 354 response message to the requesting PCC or PCE, once the path has been 355 computed. 357 In addition to this request-response mode, there may be cases where 358 there is unsolicited communication from the PCE to PCC (see 359 Requirement 6.1.6). 361 6.1.3 Transport 363 The PCECP may utilize an existing transport protocol or operate 364 directly over IP. 366 If a transport protocol is used, it may be used to satisfy some 367 requirements stated in other sections of this document (for example, 368 reliability and security). 370 If a transport protocol is used, it MUST NOT limit the size of the 371 message used by the PCECP. 373 Where requirements expressed in this document match the function of 374 existing transport protocols, consideration MUST be given to the use 375 of those protocols. 377 6.1.4 Path Computation Requests 379 The request message MUST include, at least, a source and a 380 destination. However, there is no assumption that the receiving PCE 381 has the complete source/destination domain topology, particularly in 382 the multiple PCE path computation model [PCE-ARCH]. In the latter 383 case, the PCE may have incomplete topological information for 384 multiple domains. 386 The message MUST support the inclusion of a set of one or more path 387 constraints, including the requested bandwidth or resources (hops, 388 affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to 389 exclude points of failure in the computation of the new path if an 390 LSP setup fails). The actual inclusion of constraints is a choice 391 for the PCC issuing the request. A list of core constraints that 392 MUST be supported by the PCECP is supplied in Section 6.1.16. 393 Specification of constraints must be future-proofed as described in 394 Section 6.1.14. 396 The requester MUST be allowed to select or prefer from an advertised 397 list or minimal subset of standard objective functions and functional 398 options. An objective function is used by the PCE to compute a path 399 metric in order to select the best candidate paths (e.g., minimum hop 400 path), and corresponds to the optimization criteria used for the 401 computation of one path, or the synchronized computation of a set of 402 paths. In case of unsynchronized path computation, this can be, for 403 example, the path cost or the residual bandwidth on the most loaded 404 path link. In case of synchronized path computation, this can be, 405 for example, the global bandwidth consumption or the residual 406 bandwidth on the most loaded network link. 408 A list of core objective functions that MUST be supported by the 409 PCECP is supplied in Section 6.1.17. Specification of objective 410 functions MUST be future-proofed as described in Section 6.1.14. 412 The shortest path selection may rely either on the TE metric or on 413 the IGP metric [METRIC]. Hence the PCECP request message MUST allow 414 indicating the metric type (IGP or TE) to be used for shortest path 415 selection. It MUST also allow indicating the set of aggregate path 416 attributes (hop-count, cumulated TE-metric, cumulated IGP-Metric) 417 that are required in the PCECP response message. 419 The request message MUST allow indicating if load-balancing is 420 allowed or not. It MUST also include the maximum number of paths in 421 a load-balancing path group, and the minimum path bandwidth in a 422 load-balancing path group. 424 The requester SHOULD also be able to select a vendor-specific or 425 experimental objective function or functional option. Furthermore, 426 the requester MUST be allowed to customize the function/options in 427 use. That is, individual objective functions will often have 428 parameters to be set in the request from PCC to PCE. Specification 429 of objective functions and objective parameters is required in the 430 protocol extensibility specified in Section 6.1.14. 432 Note that a PCC MAY send a request that is based on the set of TE 433 parameters carried by the MPLS/GMPLS LSP setup signaling protocol, 434 and as long as those parameters are satisfied, the PCC MAY not care 435 about which objective function is used. Also, the PCE MAY execute 436 additional objective functions not explicitly requested by the PCC. 437 This might include policy based routing path computation for load 438 balancing instructed by the management plane. The PCC MUST NOT be 439 allowed to request or cause a computation to fail because it does not 440 wish the PCE to apply a specific objective function. Allowing such 441 behavior would constitute a security risk. 443 6.1.5 Path Computation Responses 445 The response message MUST allow returning various elements including, 446 at least, the computed path(s). 448 The protocol MUST be capable of returning any explicit path that 449 would be acceptable for use for MPLS and GMPLS LSPs once converted to 450 an Explicit Route Object for use in RSVP-TE signaling. In addition, 451 anything that can be expressed in an Explicit Route Object MUST be 452 capable of being returned in the computed path. Note that the 453 resultant path(s) may be made up of a set of strict or loose hops, or 454 any combination of strict and loose hops. Moreover, a hop may have 455 the form of a non-simple abstract node. See RFC 3209 for the 456 definition of strict hop, loose hop, and abstract node. 458 A positive response from the PCE will include the paths that have 459 been computed. When a path satisfying the constraints cannot be 460 found, or if the computation fails or cannot be performed, a 461 negative response MUST be sent. This response MAY include further 462 details of the reason(s) for the failure, and potentially advice 463 about which constraints might be relaxed to be more likely to achieve 464 a positive result. 466 The PCECP response message MUST support the inclusion of a set of 467 aggregate path attributes. 469 The PCECP response message MUST support the inclusion of the set of 470 computed paths of a load-balancing path group, as well as their 471 respective bandwidth. 473 6.1.6 Cancellation of Pending Requests 475 A PCC or PCE MUST be able to cancel a pending request, using an 476 appropriate notification between PCECP peers. A PCC that has sent a 477 request to a PCE and no longer needs a response, for instance, 478 because it received a satisfactory answer from another PCE, MUST be 479 able to notify the PCE that it must clear the request (i.e. stop the 480 computation, if already started, and clear the context). Similarly, 481 a PCE that received a request from a PCC that it cannot serve, for 482 example, due to congestion, MUST be able to notify the PCC, that the 483 request will not be served. 485 6.1.7 Multiple Requests and Responses 487 It MUST be possible to send multiple path computation requests, 488 correlated or not, within the same request message. There are 489 various motivations for doing so (optimality, path diversity, etc.). 490 It MUST be possible to limit by configuration of both PCCs and PCEs 491 the number of requests that can be carried within a single message. 493 Similarly, it MUST be possible to return multiple computed paths 494 within the same response message, corresponding either to the same 495 request (e.g. load balancing) or to distinct requests, correlated or 496 not, of the same request message or distinct request messages. 498 It MUST be possible to provide "continuation correlation" where all 499 related requests or computed paths cannot fit within one message. 501 Maximum acceptable message sizes and the maximum number of requests 502 per message supported by a PCE MAY form part of PCE capabilities 503 advertisement [PCE-DISC-REQ], or MAY be exchanged through information 504 messages from the PCE as part of the protocol described here. 506 Maximum acceptable message sizes and the maximum number of computed 507 paths per message supported by a PCC MAY be indicated in the request 508 message. 510 An implementation MAY choose to limit message size to avoid a big 511 message from unduly delaying a small message. 513 6.1.8 Reliable Message Exchange 515 The PCECP MUST include reliability. This may form part of the 516 protocol itself or may be achieved by the selection of a suitable 517 transport protocol (see Section 6.1.3). 519 In particular, it MUST allow for the detection and recovery of lost 520 messages to occur quickly and not impede the operation of the PCECP. 522 In some cases (e.g. after link failure), a large number of PCCs may 523 simultaneously send requests to a PCE, leading to a potential 524 saturation of the PCEs. The PCECP or the transport protocol it uses 525 MUST properly handle such overload situations, such as through 526 throttling of requests. For example, a PCE MUST be able to limit the 527 rate of incoming request messages to a manageable rate by notifying 528 PCCs and/or peering PCEs. 530 The PCECP or the transport protocol it uses MUST provide: 532 - Acknowledged message delivery with retransmission. 533 - In order message delivery or the facility (such as message 534 numbering) to restore the order of received messages. 535 - Message corruption detection. 536 - Flow control and back-pressure, as specified above with the 537 throttling of requests. 538 - Rapid partner failure detection. 539 - Rapid PCE/PCC or PCC-PCE connection failure detection after 540 failure happens. 542 If it is necessary to add functions to PCECP to overcome shortcomings 543 in the chosen transport mechanisms, these functions SHOULD be based 544 on and re-use where possible techniques developed in other protocols 545 to overcome the same shortcomings. Functionality SHOULD NOT be added 546 to the PCECP where the chosen transport protocol already provides it. 548 6.1.9 Secure Message Exchange 550 The PCC-PCE and PCE-PCE communication protocol MUST include 551 provisions to improve the security of the exchanges between the 552 entities. In particular, it MUST support mechanisms to prevent 553 spoofing (e.g., authentication), snooping (e.g., encryption) and DOS 554 attacks (e.g., rate limiting, no promiscuous listening). 556 This function may be provided by the transport protocol or directly 557 by the PCECP. 559 See Section 7 for further discussion of security considerations. 561 6.1.10 Request Prioritization 563 The PCECP MUST allow a PCC to specify the priority of a computation 564 request. This priority MAY be used by a PCE to service high priority 565 requests before lower priority requests considering all requests 566 received and queued by a single PCE from all PCCs. 568 Implementation of priority-based activity within a PCE is subject to 569 implementation and local policy. This application processing is out 570 of scope of the PCECP. 572 6.1.11 Unsolicited Notifications 574 The normal operational mode is for the PCC to make path computation 575 requests to the PCE, and for the PCE to respond. 577 The PCECP SHOULD support unsolicited notifications from PCE to PCC, 578 PCE to PCE, or PCC to PCE. This requirement facilitates the 579 unsolicited communication of information and alerts between PCCs and 580 PCEs and between PCEs. 582 6.1.12 Asynchronous Communication 584 The PCC-PCE protocol MUST allow for asynchronous communication. A 585 PCC MUST NOT have to wait for a response before it can make another 586 request. 588 It MUST also be possible to have the order of responses differ from 589 the order of the corresponding requests. This may occur, for 590 instance, when path request messages have different priorities (see 591 Requirement 6.1.10). 593 6.1.13 Communication Overhead Minimization 595 The request and response messages SHOULD be designed so that the 596 communication overhead is minimized. In particular, the overhead per 597 message should be minimized, and the number of bytes exchanged to 598 arrive at a computation answer should be minimized. Note that 599 compression techniques are not required. Other considerations in 600 overhead minimization include the following: 602 - the amount of background messages used by the protocol or its 603 transport protocol to keep alive any session or association 604 between the PCE and PCC 605 - the processing cost at the PCE (or PCC) associated with 606 request/response messages (as distinct from processing the 607 computation requests themselves). 609 6.1.14 Extensibility 611 The PCECP MUST provide a way for the introduction of new path 612 computation constraints, diversity types, objective functions, 613 optimization methods and parameters, etc., without requiring 614 modifications in the protocol. 616 The PCECP MUST be easily extensible to support various PCE based 617 applications that have been currently identified including: 619 - intra-area path computation 620 - inter-area path computation 621 - inter-AS intra provider and inter-AS inter-provider path 622 computation 624 The PCECP MUST also allow extensions as more PCE applications will be 625 introduced in the future. For example, the protocol may be extended 626 to support PCE-based multi-layer path computation and virtual network 627 topology computation/reconfiguration. 629 The PCECP SHOULD also be easily extensible to support future 630 applications not currently in the scope of the PCE working group, 631 such as, for instance, P2MP path computations, multi-hop pseudowire 632 path computation, etc. 634 Note that application specific requirements are out of the scope of 635 this document and will be addressed in separate requirements 636 documents. 638 6.1.15 Scalability 640 The PCECP MUST scale well, at least as good as linearly, with an 641 increase of any of the following parameters (note, minimum order of 642 magnitude estimates of what the PCECP should support are given in 643 parenthesis): 645 - number of PCCs (1000/domain) 646 - number of PCEs (100/domain) 647 - number of PCCs communicating with a single PCE (1000) 648 - number of PCEs communicated to by a single PCC (100) 649 - number of PCEs communicated to by another PCE (100) 650 - number of domains (20) 651 - number of path request messages (average of 10/second/PCE) 652 - handling bursts of requests (burst of 100/second/PCE within a 10- 653 second interval). 655 Note that path requests can be bundled in path request messages, for 656 example, 10 path request messages/second may correspond to 100 path 657 requests/second. 659 Bursts of requests may arise, for example, after a network outage 660 when multiple recomputations are requested. It is RECOMMENDED that 661 the protocol handle the congestion in a graceful way so that it does 662 not unduly impact the rest of the network, and so that it does not 663 gate the ability of the PCE to perform computation. 665 6.1.16 Constraints 667 This section provides a list of generic constraints that MUST be 668 supported by the PCECP. Other constraints may be added to service 669 specific applications as identified by separate application-specific 670 requirements documents. 672 Note that the absence of a constraint in this list does not mean that 673 that constraint must not be supported. Note also that the provisions 674 of Section 6.1.14 mean that new constraints can be added to this list 675 without impacting the protocol. 677 Here is the list of generic constraints that MUST be supported: 679 o MPLS-TE and GMPLS generic constraints: 680 - Bandwidth 681 - Affinities inclusion/exclusion 682 - Link, Node, SRLG inclusion/exclusion 683 - Maximum end-to-end IGP metric 684 - Hop Count 685 - Maximum end-to-end TE metric 686 - Multiple disjoint path computation to allow path protection 688 o MPLS-TE specific constraints 689 - Class-type 690 - Local protection 691 - Node protection 692 - Bandwidth protection 694 o GMPLS specific constraints 695 - Switching type, encoding type 696 - Link protection type 698 Regarding affinities inclusion/exclusion, note the three categories 699 used in [RSVP-TE]: exclude-any, include-any, include-all. Regarding 700 link, node, SRLG inclusion/exclusion, note the mandatory and desired 701 exclusion approach in [EXCLUDE-ROUTE]. 703 6.1.17 Objective Functions Supported 705 This section provides a list of generic objective functions that MUST 706 be supported by the PCECP. Other objectives functions MAY be added 707 to service specific applications as identified by separate 708 application-specific requirements documents. 710 Note that the absence of an objective function in this list does not 711 mean that the objective function may not be supported. Note also 712 that the provisions of Section 6.1.14 mean that new objective 713 functions MAY be added to this list without impacting the protocol. 715 The PCECP MUST support the following "unsynchronized" objective 716 functions: 718 o Minimum cost path (shortest path) 719 o Least loaded path (widest path) 720 o To be determined 722 Also the PCECP MUST support the following "synchronized" objective 723 functions: 725 o Minimize aggregate bandwidth consumption on all links 726 o Maximize the residual bandwidth on the most loaded link. 727 O Minimize the cumulative cost of a set of diverse paths. 729 6.2 Deployment Support Requirements 731 6.2.1 Support for Different Service Provider Environments 733 The PCECP MUST operate in various different service provider network 734 environments that utilize an IP-based control plane, including 736 - MPLS-TE and GMPLS networks 737 - packet and non-packet networks 739 - centralized and distributed PCE path computation 740 - single and multiple PCE path computation 742 Definitions of centralized, distributed, single, and multiple PCE 743 path computation can be found in [PCE-ARCH]. 745 6.2.2 Policy Support 747 The PCECP MUST allow for policies to accept/reject requests, and 748 include the ability for a PCE to reject requests with sufficient 749 detail to allow the PCC to determine the reason for rejection or 750 failure. For example, filtering could be required for intra-AS PCE 751 path computation such that all requests are rejected that come from 752 another AS. However, specific policy details are left to 753 application-specific PCECP requirements. Furthermore, the PCECP MUST 754 allow for the notification of a policy violation. Actual policies, 755 configuration of policies, and applicability of policies are out of 756 scope. 758 Note that work on supported policy models and the corresponding 759 requirements/implications is being undertaken as a separate work item 760 in the PCE working group. 762 6.3 Detection & Recovery Requirements 764 6.3.1 Aliveness Detection 766 The PCECP MUST allow a PCC to check the liveliness of PCEs it is 767 using for path computation, and a PCE to check the liveliness of 768 PCCs it is serving. This includes detection of PCE liveness before a 769 PCE is used for computation. i.e. during PCE selection. A PCC should 770 be aware of PCE liveness at all times. The PCECP MUST provide 771 partner failure detection. 773 The aliveness detection mechanism MUST ensure reciprocal knowledge of 774 PCE and PCC liveness. 776 Note that the PCE or PCC software component can be lost without 777 losing the connection or the transport end-point, when a transport 778 protocol is used. 780 6.3.2 PCC/PCE Failure Response 782 Appropriate PCC and PCE procedures MUST be defined to deal with PCE 783 and PCC failures. A PCC must be able to clear any pending request to 784 a PCE so that it is no longer waiting for a response. Clearing a 785 pending request does not imply any message exchange; this differs 786 from pending request cancellation (Section 6.1.6), which requires 787 message exchange. It is RECOMMENDED that a PCC select another PCE 788 upon detection of PCE failure or unreachability of a PCE but note 789 that PCE selection procedure are out of the scope of this document. 791 Similarly, a PCE must be able to clear pending requests from a PCC, 792 for instance, when it detects the failure of the requesting PCC or 793 when its buffer of requests is full. Clearing a pending request does 794 not imply any message exchange. 796 6.3.3 Protocol Recovery 798 Information distributed in asynchronous/unsolicited messages MAY 799 persist at the recipient in the event of the failure of the sender or 800 of the communication channel. Upon recovery, the Communication 801 Protocol MUST support resynchronization of information and requests 802 between the sender and the receiver, and this SHOULD be arranged so 803 as to minimize repeat data transfer. 805 The response to a computation request issued before the PCC is 806 restarted will not be helpful and could be a waste of effort. Thus 807 it is better to allow the request to be re-issued in shorthand (e.g. 808 by request number) if the PCC remembers that it had previously issued 809 it and is still interested in the response. 811 The PCECP SHOULD allow a PCE to respond to computation requests 812 issued before the failure without the requests being re-issued. 814 6.3.4 LSP Rerouting & Reoptimization 816 Upon LSP failure, due to link, node or SRLG failure, a head-end LSR 817 may send a request to the PCE so as to reroute the LSP over an 818 alternate path. So as to ease the computation such request should 819 include the previous path and the failed element (if it can be 820 identified). 822 Hence the request message MUST allow indicating if the computation is 823 for an LSP restoration, and MUST support the inclusion of the 824 previously computed path as well as the failed element. Note that 825 the old path is actually useful only if the old LSP is not torn down 826 yet. This is up to the PCC to decide if it includes the old path or 827 not. 829 Note that a network failure may impact a large number of LSPs. A 830 potentially large number of PCCs, are going to simultaneously send a 831 request to the PCE. Some jittering may be used on PCCs so as to delay 832 a request to the PCE, under network failure condition. 834 The PCECP MAY support the inclusion, in a response message to a PCC, 835 of an upper bound of a random waiting time to be used for further 836 requests to the PCE (e.g. the PCC will wait for a random value 837 between 0 and the upper bound before sending another request). This 838 upper bound would depend on the level of congestion of the PCE. 840 The path computation request message MUST support TE LSP path 841 reoptimization and the inclusion of a previously computed path. This 842 will help ensure optimal routing of a reoptimized path, since it will 843 allow the PCE to avoid double bandwidth accounting and help reduce 844 blocking issues. 846 7. Security Considerations 848 The impact of the use of a PCECP MUST be considered in the light of 849 the impact that it has on the security of the existing routing and 850 signaling protocols and techniques in use within the network. 851 Intra-domain security is impacted since there is a new interface, 852 protocol and element in the network. Any host in the network could 853 impersonate a PCC, and receive detailed information on network paths. 854 Any host could also impersonate a PCE, both gathering information 855 about the network before passing the request on to a real PCE, and 856 spoofing responses. Some protection here depends on the PCE 857 discovery process (if it uses the IGP it relies on IGP security). An 858 increase in inter-domain information flows may increase the 859 vulnerability to security attacks, and the facilitation of 860 inter-domain path may increase the impact of these security attacks. 862 Of particular relevance are the implications for confidentiality 863 inherent in a PCECP for multi-domain networks. It is not necessarily 864 the case that a multi-domain PCE solution will compromise security, 865 but solutions MUST examine their impacts in this area. 867 Applicability statements for particular combinations of signaling, 868 routing and path computation techniques are expected to contain 869 detailed security sections. 871 It should be observed that the use of an external PCE does introduce 872 additional security issues. Most notable amongst these are: 874 - interception of PCE requests or responses 875 - impersonation of PCE or PCC 876 - denial of service attacks on PCE or PCE communication mechanisms 878 It is expected that the PCECP will address these issues in detail 879 using authentication, encryption and DoS protection techniques. See 880 also Section 6.1.9. 882 8. Manageability Considerations 884 Manageability of the PCECP MUST address the following considerations: 886 - need for a MIB module for control and monitoring 887 - need for built-in diagnostic tools (e.g., partner failure 888 detection, OAM, etc.) 889 - configuration implications for the protocol 891 It is expected that PCECP operations will be modeled and controlled 892 through appropriate MIB modules. Statistics gathering will form an 893 important part of the operation of the PCECP. The operator must be 894 able to determine PCECP historical interactions and success rate of 895 requests. Similarly, it is important for an operator to be able to 896 determine PCECP load and whether an individual PCC is responsible for 897 a disproportionate amount of the load. It will also be important to 898 be able to record and inspect statistics about the PCECP 899 communications, including issues such as malformed messages, 900 unauthorized messages and messages discarded owing to congestion. 902 The new MIB modules should also be used to provide notifications 903 (traps) when thresholds are crossed or when important events occur. 905 PCECP techniques must enable a PCC to determine the liveness of a PCE 906 both before it sends a request and in the period between sending a 907 request and receiving a response. 909 It is also important for a PCE to know about the liveness of PCCs to 910 gain a predictive view of the likely loading of a PCE in the future, 911 and to allow a PCE to abandon processing of a received request. 913 It should be possible for an operator to rate limit the requests that 914 a PCC sends to a PCE, and a PCE should be able to report impending 915 congestion (according to a configured threshold) both to the operator 916 and to its PCCs. 918 9. IANA Considerations 920 This document makes no requests for IANA action. 922 10. Acknowledgements 924 The authors would like to extend their warmest thanks to (in 925 alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri 926 Papadimitriou, and JP Vasseur for their review and suggestions. 928 11. Normative References 930 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 931 Element (PCE) Architecture", work in progress. 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, March 1997. 936 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 937 3667, February 2004. 939 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 940 Technology", BCP 79, RFC 3668, February 2004. 942 12. Informational References 944 [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol 945 (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 946 87, RFC 3785, May 2004. 948 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 949 Computation Element (PCE) Discovery," work in progress. 951 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 952 Tunnels," RFC 3209, December 2001. 954 13. Authors' & Contributors' Addresses 956 Jerry Ash (Editor) 957 AT&T 958 Room MT D5-2A01 959 200 Laurel Avenue 960 Middletown, NJ 07748, USA 961 Phone: +1-(732)-420-4578 962 Email: gash@att.com 964 Jean-Louis Le Roux (Editor) 965 France Telecom 966 2, avenue Pierre-Marzin 967 22307 Lannion Cedex, FRANCE 968 Email: jeanlouis.leroux@francetelecom.com 970 Alia K. Atlas 971 Google Inc. 972 1600 Amphitheatre Parkway 973 Mountain View, CA 94043 974 Email: akatlas@alum.mit.edu 976 Arthi Ayyangar 977 Juniper Networks, Inc. 978 1194 N.Mathilda Ave 979 Sunnyvale, CA 94089 USA 980 Email: arthi@juniper.net 982 Nabil Bitar 983 Verizon 984 40 Sylvan Road 985 Waltham, MA 02145 986 Email: nabil.bitar@verizon.com 988 Igor Bryskin 989 Independent Consultant 990 Email: i_bryskin@yahoo.com 992 Dean Cheng 993 Cisco Systems Inc. 994 3700 Cisco Way 995 San Jose CA 95134 USA 996 Phone: +1 408 527 0677 997 Email: dcheng@cisco.com 999 Durga Gangisetti 1000 MCI 1001 Email: durga.gangisetti@mci.com 1003 Kenji Kumaki 1004 KDDI Corporation 1005 Garden Air Tower 1006 Iidabashi, Chiyoda-ku, 1007 Tokyo 102-8460, JAPAN 1008 Phone: +81-3-6678-3103 1009 Email: ke-kumaki@kddi.com 1011 Eiji Oki 1012 NTT 1013 Midori-cho 3-9-11 1014 Musashino-shi, Tokyo 180-8585, JAPAN 1015 Email: oki.eiji@lab.ntt.co.jp 1017 Raymond Zhang 1018 BT INFONET Services Corporation 1019 2160 E. Grand Ave. 1020 El Segundo, CA 90245 USA 1021 Email: Raymond_zhang@bt.infonet.com 1023 Intellectual Property Statement 1025 The IETF takes no position regarding the validity or scope of any 1026 Intellectual Property Rights or other rights that might be claimed to 1027 pertain to the implementation or use of the technology described in 1028 this document or the extent to which any license under such rights 1029 might or might not be available; nor does it represent that it has 1030 made any independent effort to identify any such rights. Information 1031 on the procedures with respect to rights in RFC documents can be 1032 found in BCP 78 and BCP 79. 1034 Copies of IPR disclosures made to the IETF Secretariat and any 1035 assurances of licenses to be made available, or the result of an 1036 attempt made to obtain a general license or permission for the use of 1037 such proprietary rights by implementers or users of this 1038 specification can be obtained from the IETF on-line IPR repository at 1039 http://www.ietf.org/ipr. 1041 The IETF invites any interested party to bring to its attention any 1042 copyrights, patents or patent applications, or other proprietary 1043 rights that may cover technology that may be required to implement 1044 this standard. Please address the information to the IETF at 1045 ietf-ipr@ietf.org. 1047 Disclaimer of Validity 1049 This document and the information contained herein are provided on an 1050 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1051 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1052 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1053 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1054 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1055 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1057 Copyright Statement 1059 Copyright (C) The Internet Society (2005). This document is subject 1060 to the rights, licenses and restrictions contained in BCP 78, and 1061 except as set forth therein, the authors retain all their rights.