idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-04.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 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1011. ** 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 (February 2006) is 6639 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: 'PCECP-INTER-AREA' is mentioned on line 505, but not defined == Missing Reference: 'PCECP-INTER-LAYER' is mentioned on line 145, but not defined == Missing Reference: 'RFC 3209' is mentioned on line 338, but not defined == Missing Reference: 'PCECP-MULTI-LAYER' is mentioned on line 510, but not defined == Unused Reference: 'RFC3209' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'PCE-INTER-AREA' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'PCE-INTER-LAYER' is defined on line 918, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-ARCH' Summary: 4 errors (**), 0 flaws (~~), 9 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: August 2006 J.L. Le Roux (France Telecom) 5 Editor 7 February 2006 9 draft-ietf-pce-comm-protocol-gen-reqs-04.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 August 1, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 3 59 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 4 60 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5 61 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 5 62 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 5 63 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 6 65 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 7 66 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 8 67 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 8 68 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 8 69 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 9 70 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 9 71 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 10 72 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 10 73 6.1.13 Communication Overhead Minimization . . . . . . . . . 10 74 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 10 75 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 11 76 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 11 77 6.1.17 Objective Functions Supported . . . . . . . . . . . . 12 78 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 13 79 6.2.1 Support for Different Service Provider Environments . . 13 80 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 13 81 6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . 13 82 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 13 83 6.3.2 Protocol Recovery . . . . . . . . . . . . . . . . . . . 14 84 6.3.3 LSP Rerouting & Reoptimization . . . . . . . . . . . . 14 85 6.4 Requirements Summary . . . . . . . . . . . . . . . . . . . . 14 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 17 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 18 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 90 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 18 91 12. Informational References . . . . . . . . . . . . . . . . . . . . 18 92 13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 19 93 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 20 94 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21 95 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Contributors 99 This document is the result of the PCE Working Group PCE 100 Communication Protocol (PCECP) requirements design team joint effort. 101 The following are the design team member authors that contributed to 102 the present document: 104 Jerry Ash (AT&T) 105 Alia Atlas (Google, Inc.) 106 Arthi Ayyangar (Juniper) 107 Nabil Bitar (Verizon) 108 Igor Bryskin (Independent Consultant) 109 Dean Cheng (Cisco) 110 Durga Gangisetti (MCI) 111 Kenji Kumaki (KDDI) 112 Jean-Louis Le Roux (France Telecom) 113 Eiji Oki (NTT) 114 Raymond Zhang (BT Infonet) 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. Introduction 124 A Path Computation Element (PCE) [PCE-ARCH] supports requests for 125 path computation issued by a Path Computation Client (PCC), which may 126 be 'composite' (co-located) or 'external' (remote) from a PCE. When 127 the PCC is external from the PCE, a request/response communication 128 protocol is required to carry the path computation request and return 129 the response. In order for the PCC and PCE to communicate, the PCC 130 must know the location of the PCE: PCE discovery is described in 131 [PCE-DISC-REQ]. 133 The PCE operates on a network graph in order to compute paths based 134 on the path computation request(s) issued by the PCC(s). The path 135 computation request will include the source and destination of the 136 paths to be computed, a set of constraints to be applied during the 137 computation, and may also include an objective function. The PCE 138 response includes the computed paths or the reason for a failed 139 computation. 141 This document lists a set of generic requirements for the PCECP. 142 Application-specific requirements are beyond the scope of this 143 document, and will be addressed in separate documents. For example, 144 application-specific communication protocol requirements are given in 145 [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] for inter-area and 146 inter-layer PCE applications, respectively. 148 4. Terminology 150 Domain: any collection of network elements within a common sphere of 151 address management or path computational responsibility. Examples of 152 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 153 within a service provider network, or multiple ASs across multiple 154 service provider networks. 156 GMPLS: Generalized Multi-Protocol Label Switching 158 LSP: MPLS/GMPLS Label Switched Path 160 LSR: Label Switch Router 162 MPLS: Multi-Protocol Label Switching 164 PCC: Path Computation Client: any client application requesting a 165 path computation to be performed by the PCE. 167 PCE: Path Computation Element: an entity (component, application or 168 network node) that is capable of computing a network path or route 169 based on a network graph and applying computational constraints (see 170 further description in [PCE-ARCH]). 172 TED: Traffic Engineering Database, which contains the topology and 173 resource information of the network or network segment used by a PCE. 175 TE LSP: Traffic Engineering (G)MPLS Label Switched Path. 177 See [PCE-ARCH] for further definitions of terms. 179 5. Overview of PCE Communication Protocol (PCECP) 181 In the PCE model, path computation requests are issued by a PCC 182 to a PCE that may be composite (co-located) or external (remote). If 183 the PCC and PCE are not co-located, a request/response communication 184 protocol is required to carry the request and return the response. 185 If the PCC and PCE are co-located, a communication protocol is not 186 required, but implementations may choose to utilize a protocol for 187 exchanges between the components. 189 In order that a PCC and PCE can communicate, the PCC must know the 190 location of the PCE. This can be configured or discovered. The PCE 191 discovery mechanism is out of scope of this document, but 192 requirements are documented in [PCE-DISC-REQ]. 194 The PCE operates on a network graph built from the TED in order to 195 compute paths. The mechanism by which the TED is populated is out of 196 scope for the PCECP. 198 A path computation request issued by the PCC includes a specification 199 of the path(s) needed. The information supplied includes, at a 200 minimum, the source and destination for the paths, but may also 201 include a set of further requirements (known as constraints) as 202 described in Section 6. 204 The response from the PCE may be positive in which case it will 205 include the paths that have been computed. If the computation fails 206 or cannot be performed, a negative response is required with an 207 indication of the type of failure. 209 A request/response protocol is also required for a PCE to communicate 210 path computation requests to another PCE and for that PCE to return 211 the path computation response. As described in [PCE-ARCH], there is 212 no reason to assume that two different protocols are needed, and this 213 document assumes that a single protocol will satisfy all requirements 214 for PCC-PCE and PCE-PCE communication. 216 [PCE-ARCH] describes four models of PCE: composite, external, 217 multiple PCE path computation, and multiple PCE path computation with 218 inter-PCE communication. In all cases except the composite PCE model, 219 a PCECP is required. The requirements defined in this document are 220 applicable to all models described in the [PCE-ARCH]. 222 6. PCE Communication Protocol Generic Requirements 224 Section 6.4 contains a summary of the requirements in this section. 226 6.1 Basic Protocol Requirements 228 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 230 A single protocol MUST be defined for PCC-PCE and PCE-PCE 231 communication. A PCE requesting a path from another PCE can be 232 considered as a PCC, and in the remainder of this document we refer 233 to all communications as PCC-PCE regardless of whether they are 234 PCC-PCE or PCE-PCE. 236 6.1.2 Client-Server Communication 238 PCC-PCE communication is by nature client-server based. The PCECP 239 MUST allow a PCC to send a request message to a PCE to request path 240 computation, and for a PCE to reply with a response message to the 241 requesting PCC once the path has been computed. 243 In addition to this request-response mode, there are cases where 244 there is unsolicited communication from the PCE to the PCC (see 245 Section 6.1.11). 247 6.1.3 Transport 249 The PCECP may utilize an existing transport protocol or operate 250 directly over IP. 252 If a transport protocol is used, it MAY be used to satisfy some 253 requirements stated in other sections of this document (for example, 254 reliability and security). Where requirements expressed in this 255 document match the function of existing transport protocols, 256 consideration MUST be given to the use of those protocols. 258 If a transport protocol is used, it MUST NOT limit the size of the 259 message used by the PCECP. 261 6.1.4 Path Computation Requests 263 The path computation request message MUST include at least the source 264 and destination. Note that the path computation request is for an 265 LSP or LSP segment, and the source and destination supplied are the 266 start and end of the computation being requested (i.e. of the LSP 267 segment). 269 The path computation request message MUST support the inclusion of a 270 set of one or more path constraints, including but not limited to the 271 requested bandwidth or resources (hops, affinities, etc.) to 272 include/exclude. For example, a PCC may request the PCE to exclude 273 points of failure in the computation of a new path if an LSP setup 274 fails. The actual inclusion of constraints is a choice for the PCC 275 issuing the request. A list of core constraints that must be 276 supported by the PCECP is supplied in Section 6.1.16. Specification 277 of constraints MUST be future-proofed as described in Section 6.1.14. 279 The requester MUST be allowed to select or prefer from an advertised 280 list or minimal subset of standard objective functions and functional 281 options. An objective function is used by the PCE to process 282 constraints to a path computation request when it computes a path in 283 order to select the "best" candidate paths (e.g., minimum hop path), 284 and corresponds to the optimization criteria used for the computation 285 of one path, or the synchronized computation of a set of paths. In 286 the case of unsynchronized path computation, this can be, for 287 example, the path cost or the residual bandwidth on the most loaded 288 path link. In the case of synchronized path computation, this can 289 be, for example, the global bandwidth consumption or the residual 290 bandwidth on the most loaded network link. 292 A list of core objective functions that MUST be supported by the 293 PCECP is supplied in Section 6.1.17. Specification of objective 294 functions MUST be future-proofed as described in Section 6.1.14. 296 The requester SHOULD also be able to select a vendor-specific or 297 experimental objective function or functional option. Furthermore, 298 the requester MUST be allowed to customize the function/options in 299 use. That is, individual objective functions will often have 300 parameters to be set in the request from PCC to PCE. Support for the 301 specification of objective functions and objective parameters is 302 required in the protocol extensibility specified in Section 6.1.14. 304 A request message MAY include TE parameters carried by the MPLS/GMPLS 305 LSP setup signaling protocol. Also, it MUST be possible for the PCE 306 to apply additional objective functions. This might include policy 307 based routing path computation for load balancing instructed by the 308 management plane. 310 Shortest path selection may rely either on the TE metric or on the 311 IGP metric [METRIC]. Hence the PCECP request message MUST allow the 312 PCC to indicate the metric type (IGP or TE) to be used for shortest 313 path selection. Note that other metric types may be specified in the 314 future. 316 There may be cases where a single path cannot fit a given bandwidth 317 request, while a set of paths could be combined to fit the request. 318 Such path combination to serve a given request is called 319 load-balancing. The request message MUST allow the PCC to indicate if 320 load-balancing is allowed or not. It MUST also include the maximum 321 number of paths in a load-balancing path group, and the minimum path 322 bandwidth in a load-balancing path group. The request message MUST 323 allow specification of the degree of disjointness of the members of 324 the load-balancing group. 326 6.1.5 Path Computation Responses 328 The path computation response message MUST allow the PCE to return 329 various elements including, at least, the computed path(s). 331 The protocol MUST be capable of returning any explicit path that 332 would be acceptable for use for MPLS and GMPLS LSPs once converted to 333 an Explicit Route Object for use in RSVP-TE signaling. In addition, 334 anything that can be expressed in an Explicit Route Object MUST be 335 capable of being returned in the computed path. Note that the 336 resultant path(s) may be made up of a set of strict or loose hops, or 337 any combination of strict and loose hops. Moreover, a hop may have 338 the form of a non-simple abstract node. See [RFC 3209] for the 339 definition of strict hop, loose hop, and abstract node. 341 A positive response from the PCE MUST include the paths that have 342 been computed. A positive PCECP computation response MUST support 343 the inclusion of a set of attributes of the computed path, such as 344 the path costs (e.g., cumulative link TE metrics and cumulative link 345 IGP metrics) and the computed bandwidth. The latter is useful when a 346 single path cannot serve the requested bandwidth and load balancing 347 is applied. 349 When a path satisfying the constraints cannot be found, or if the 350 computation fails or cannot be performed, a negative response MUST be 351 sent. This response MAY include further details of the reason(s) for 352 the failure, and MAY include advice about which constraints might be 353 relaxed to be more likely to achieve a positive result. 355 The PCECP response message MUST support the inclusion of the set of 356 computed paths of a load-balancing path group, as well as their 357 respective bandwidths. 359 6.1.6 Cancellation of Pending Requests 361 A PCC MUST be able to cancel a pending request using a notification 362 message. A PCC that has sent a request to a PCE and no longer needs 363 a response, for instance because it no longer wants to set up the 364 associated service, MUST be able to notify the PCE that it can clear 365 the request (i.e. stop the computation if already started, and clear 366 the context). The PCE may also wish to cancel a pending request 367 because of some congested state. 369 6.1.7 Multiple Requests and Responses 371 It MUST be possible to send multiple path computation requests 372 within the same request message. Such requests may be correlated (for 373 example, requesting disjoint paths) or uncorrelated (requesting paths 374 for unrelated services). It MUST be possible to limit by 375 configuration of both PCCs and PCEs the number of requests that can 376 be carried within a single message. 378 Similarly, it MUST be possible to return multiple computed paths 379 within the same response message, corresponding either to the same 380 request (e.g. multiple suited paths, paths of a load balancing path 381 group) or to distinct requests, correlated or not, of the same 382 request message or distinct request messages. 384 It MUST be possible to provide "continuation correlation" where all 385 related requests or computed paths cannot fit within one message, and 386 are carried in a sequence of correlated messages. 388 The PCE MUST inform the PCC of its capabilities. Maximum acceptable 389 message sizes and the maximum number of requests per message 390 supported by a PCE MAY form part of PCE capabilities advertisement 391 [PCE-DISC-REQ], or MAY be exchanged through information messages from 392 the PCE as part of the protocol described here. 394 It MUST be possible for a PCC to specify, in the request message, the 395 maximum acceptable response message sizes and the maximum number of 396 computed paths per response message it can support. 398 It MUST be possible to limit the message size by configuration on 399 PCCs and PCEs. 401 6.1.8 Reliable Message Exchange 403 The PCECP MUST include reliability. This may form part of the 404 protocol itself or may be achieved by the selection of a suitable 405 transport protocol (see Section 6.1.3). 407 In particular, it MUST allow for the detection and recovery of lost 408 messages to occur quickly and not impede the operation of the PCECP. 410 In some cases (e.g. after link failure), a large number of PCCs may 411 simultaneously send requests to a PCE, leading to a potential 412 saturation of the PCEs. The PCECP MUST support indication of 413 congestion state and rate limitation state. This should enable, for 414 example, a PCE to limit the rate of incoming request messages if the 415 request rate is too high. 417 The PCECP MUST provide: 419 - Detection and report of lost or corrupted messages 420 - Automatic attempts to retransmit lost messages without reference to 421 the application 422 - Handling of out-of-order messages 423 - Handling of duplicate messages 424 - Flow control and back-pressure to enable throttling of requests and 425 responses 426 - Rapid PCECP communication failure detection 427 - Distinction between partner failure and communication channel 428 failure after the PCECP communication is recovered 430 If it is necessary to add functions to PCECP to overcome shortcomings 431 in the chosen transport mechanisms, these functions SHOULD be based 432 on and re-use where possible techniques developed in other protocols 433 to overcome the same shortcomings. Functionality MUST NOT be added 434 to the PCECP where the chosen transport protocol already provides it. 436 6.1.9 Secure Message Exchange 438 The PCC-PCE communication protocol MUST include provisions to insure 439 the security of the exchanges between the entities. In particular, 440 it MUST support mechanisms to prevent spoofing (e.g., 441 authentication), snooping (e.g., encryption) and DOS attacks (e.g., 442 rate limiting, no promiscuous listening). 444 This function may be provided by the transport protocol or directly 445 by the PCECP. 447 See Section 7 for further discussion of security considerations. 449 6.1.10 Request Prioritization 451 The PCECP MUST allow a PCC to specify the priority of a computation 452 request. 454 Implementation of priority-based activity within a PCE is subject to 455 implementation and local policy. This application processing is out 456 of scope of the PCECP. 458 6.1.11 Unsolicited Notifications 460 The normal operational mode is for the PCC to make path computation 461 requests to the PCE, and for the PCE to respond. 463 The PCECP MUST support unsolicited notifications from PCE to PCC, or 464 PCC to PCE. This requirement facilitates the unsolicited 465 communication of information and alerts between PCCs and PCEs. 467 6.1.12 Asynchronous Communication 469 The PCC-PCE protocol MUST allow for asynchronous communication. A 470 PCC MUST NOT have to wait for a response to one request before it can 471 make another request. 473 It MUST also be possible to have the order of responses differ from 474 the order of the corresponding requests. This may occur, for 475 instance, when path request messages have different priorities (see 476 Requirement 6.1.10). A consequent requirement is that path 477 computation responses MUST include a direct correlation to the 478 associated request. 480 6.1.13 Communication Overhead Minimization 482 The request and response messages SHOULD be designed so that the 483 communication overhead is minimized. In particular, the overhead per 484 message SHOULD be minimized, and the number of bytes exchanged to 485 arrive at a computation answer SHOULD be minimized. Other 486 considerations in overhead minimization include the following: 488 - the number of background messages used by the protocol or its 489 transport protocol to keep alive any session or association 490 between the PCE and PCC 491 - the processing cost at the PCE (or PCC) associated with 492 request/response messages (as distinct from processing the 493 computation requests themselves). 495 6.1.14 Extensibility 497 The PCECP MUST provide a way for the introduction of new path 498 computation constraints, diversity types, objective functions, 499 optimization methods and parameters, etc., without requiring 500 major modifications in the protocol. 502 The PCECP MUST be easily extensible to support various PCE based 503 applications that have been currently identified including: 505 - intra-area path computation [PCECP-INTER-AREA] 506 - inter-area path computation 507 - inter-AS intra provider and inter-AS inter-provider path 508 computation 510 - inter-layer path computation [PCECP-MULTI-LAYER] 512 The PCECP MUST support the requirements specified in the 513 application-specific requirements documents. The PCECP MUST also 514 allow extensions as more PCE applications will be introduced in the 515 future. 517 The PCECP SHOULD also be extensible to support future applications 518 not currently in the scope of the PCE working group, such as, for 519 instance, point-to-multipoint path computations, multi-hop pseudowire 520 path computation, etc. 522 Note that application specific requirements are out of the scope of 523 this document and will be addressed in separate requirements 524 documents. 526 6.1.15 Scalability 528 The PCECP MUST scale well, at least as good as linearly, with an 529 increase of any of the following parameters (note, minimum order of 530 magnitude estimates of what the PCECP should support are given in 531 parenthesis): 533 - number of PCCs (1000/domain) 534 - number of PCEs (100/domain) 535 - number of PCCs communicating with a single PCE (1000) 536 - number of PCEs communicated to by a single PCC (100) 537 - number of domains (20) 538 - number of path request messages (average of 10/second/PCE) 539 - handling bursts of requests (burst of 100/second/PCE within a 10- 540 second interval). 542 Note that path requests can be bundled in path request messages, for 543 example, 10 PCECP request messages/second may correspond to 100 path 544 requests/second. 546 Bursts of requests may arise, for example, after a network outage 547 when multiple recomputations are requested. The PCECP MUST handle 548 the congestion in a graceful way so that it does not unduly impact 549 the rest of the network, and so that it does not gate the ability of 550 the PCE to perform computation. 552 6.1.16 Constraints 554 This section provides a list of generic constraints that MUST be 555 supported by the PCECP. Other constraints may be added to service 556 specific applications as identified by separate application-specific 557 requirements documents. 559 Note that the absence of a constraint in this list does not mean that 560 the constraint must not be supported. Note also that the provisions 561 of Section 6.1.14 mean that new constraints can be added to this list 562 without impacting the protocol to a level that requires major 563 protocol changes. 565 Here is the list of generic constraints that MUST be supported: 567 o MPLS-TE and GMPLS generic constraints: 568 - Bandwidth 569 - Affinities inclusion/exclusion 570 - Link, Node, SRLG inclusion/exclusion 571 - Maximum end-to-end IGP metric 572 - Maximum Hop Count 573 - Maximum end-to-end TE metric 574 - Degree of paths disjointess (Link, Node, SRLG) 576 o MPLS-TE specific constraints 577 - Class-type 578 - Local protection 579 - Node protection 580 - Bandwidth protection 582 o GMPLS specific constraints 583 - Switching type, encoding type 584 - Link protection type 586 6.1.17 Objective Functions Supported 588 This section provides a list of generic objective functions that MUST 589 be supported by the PCECP. Other objectives functions MAY be added 590 to service specific applications as identified by separate 591 application-specific requirements documents. 593 Note that the absence of an objective function in this list does not 594 mean that the objective function may not be supported. Note also 595 that the provisions of Section 6.1.14 mean that new objective 596 functions MAY be added to this list without impacting the protocol. 598 The PCECP MUST support the following "unsynchronized" objective 599 functions: 601 - Minimum cost path with respect to a specified metric(shortest path) 602 - Least loaded path 603 - Maximum available bandwidth path 605 Also the PCECP MUST support the following "synchronized" objective 606 functions: 608 - Minimize aggregate bandwidth consumption on all links 609 - Maximize the residual bandwidth on the most loaded link 610 - Minimize the cumulative cost of a set of diverse paths. 612 6.2 Deployment Support Requirements 614 6.2.1 Support for Different Service Provider Environments 616 The PCECP MUST operate in various different service provider network 617 environments that utilize an IP-based control plane, including 619 - MPLS-TE and GMPLS networks 620 - packet and non-packet networks 621 - centralized and distributed PCE path computation 622 - single and multiple PCE path computation 624 Definitions of centralized, distributed, single, and multiple PCE 625 path computation can be found in [PCE-ARCH]. 627 6.2.2 Policy Support 629 The PCECP MUST allow for the use of policies to accept/reject 630 requests, and include the ability for a PCE to supply sufficient 631 detail when it rejects a request for policy reasons to allow the PCC 632 to determine the reason for rejection or failure. For example, 633 filtering could be required for a PCE that serves one domain (perhaps 634 an AS) such that all requests that come from another domain (AS) are 635 rejected. However, specific policy details are left to 636 application-specific PCECP requirements. Actual policies, 637 configuration of policies, and applicability of policies are out of 638 scope. 640 Note that work on supported policy models and the corresponding 641 requirements/implications is being undertaken as a separate work item 642 in the PCE working group. 644 PCECP messages MUST be able to carry transparent policy information. 646 6.3 Aliveness Detection & Recovery Requirements 648 6.3.1 Aliveness Detection 650 The PCECP MUST allow a PCC to 652 - check the liveliness of the PCC-PCE communication 653 - rapidly detect PCC-PCE communication failure (indifferently to 654 partner failure or connectivity failure), 655 - distinguish PCC/PCE node failures from PCC-PCE connectivity 656 failures, after the PCC-PCE communication is recovered. 658 The aliveness detection mechanism MUST ensure reciprocal knowledge of 659 PCE and PCC liveness. 661 6.3.2 Protocol Recovery 663 In the event of the failure of a sender or of the communication 664 channel, the PCECP, upon recovery, MUST support resynchronization of 665 information and requests between the sender and the receiver, and 666 this SHOULD be arranged so as to minimize repeat data transfer. 668 6.3.3 LSP Rerouting & Reoptimization 670 If an LSP fails owing to the failure of a link or node that it 671 traverses, a new computation request may be made to a PCE in order to 672 repair the LSP. Since the PCC cannot know that the PCE's TED has been 673 updated to reflect the failure network information, it is useful to 674 include this information in the new path computation request. Also, 675 in order to re-use the resources used by the old LSP, it may be 676 advantageous to indicate the route of the old LSP as part of the new 677 path computation request. 679 Hence the path computation request message MUST allow an indication 680 of whether the computation is for LSP restoration, and MUST support 681 the inclusion of the previously computed path as well as the identity 682 of the failed element. Note that the old path might only be useful 683 if the old LSP has not yet been torn down. 685 Note that a network failure may impact a large number of LSPs. In 686 this case, a potentially large number of PCCs is going to 687 simultaneously send requests to the PCE. The PCECP MUST properly 688 handle such overload situations, such as for instance through 689 throttling of requests as set forth in section 6.1.8. 691 The path computation request message MUST support TE LSP path 692 reoptimization and the inclusion of a previously computed path. This 693 will help ensure optimal routing of a reoptimized path, since it will 694 allow the PCE to avoid double bandwidth accounting and help reduce 695 blocking issues. 697 6.4 Requirements Summary 699 The following is a summary of the requirements in Section 6: 701 Requirement Necessity Ref. 702 ------------------------------------------------------------------ 703 Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1 704 Client-server communication MUST 6.1.2 705 Support PCC/PCE request message to request path 706 computation MUST 6.1.2 707 Support PCE response message with computed path MUST 6.1.2 708 Support unsolicited communication PCE-PCC SHOULD 6.1.2 709 Maintain PCC-PCE session NON-RQMT 6.1.2 710 Use of existing transport protocol MAY 6.1.3 711 Transport protocol satisfy reliability & security 712 requirements MAY 6.1.3 713 Transport protocol limits size of message MUST NOT 6.1.3 714 Support path computation requests MUST 6.1.4 715 Path computation request includes source & 716 destination MUST 6.1.4 717 Support path constraints (e.g., bandwidth, hops, 718 affinities) to include/exclude MUST 6.1.4 719 Allow to select/prefer from advertised list of 720 standard objective functions/options MUST 6.1.4 721 Allow to customize objective function/options MUST 6.1.4 722 Allow indicating the metric type (IGP or TE) to 723 be used for shortest path selection MUST 6.1.4 724 Allow indicating the set of path attributes 725 required in response message MUST 6.1.4 726 Allow indicating if load-balancing is allowed MUST 6.1.4 727 Support path computation responses MUST 6.1.5 728 Negative response support reasons for failure, 729 constraints to relax to achieve positive result SHOULD 6.1.5 730 Support inclusion of set of path attributes MUST 6.1.5 731 Support inclusion of set of computed paths of a 732 load-balancing path group, as well as their 733 respective bandwidth MUST 6.1.5 734 Cancellation of pending requests MUST 6.1.6 735 Multiple requests and responses MUST 6.1.7 736 Limit by configuration number of requests within 737 a message MUST 6.1.7 738 Support multiple computed paths in response MUST 6.1.7 739 Support "continuation correlation" where related 740 requests or computed paths cannot fit within 741 one message MUST 6.1.7 742 Maximum message size & maximum number of requests 743 per message exchanged through PCE messages to 744 PCC, or indicated in request message MAY 6.1.7 745 Reliable message exchange (achieved by PCECP 746 itself or transport protocol) MUST 6.1.8 747 Allow detection & recovery of lost messages to 748 occur quickly & not impede operation of PCECP MUST 6.1.8 749 Handle overload situations without significant 750 decrease in performance, e.g., through 751 throttling of requests MUST 6.1.8 752 Detect/report lost/corrupted messages, retransmit 753 lost messages, handle out-of-order messages & 754 duplicate messages, provide flow control/ 755 back-pressure to throttle messages, detect 756 PCECP communication failure detection MUST 6.1.8 757 Functionality added to PCECP if transport 758 protocol provides it SHOULD NOT 6.1.8 759 Secure message exchange (provided by PCECP or 760 transport protocol MUST 6.1.9 762 Support mechanisms to prevent spoofing (e.g., 763 authentication), snooping (e.g., encryption), 764 DOS attacks MUST 6.1.9 765 Request prioritization MUST 6.1.10 766 Unsolicited notifications SHOULD 6.1.11 767 Allow asynchronous communication MUST 6.1.12 768 PCC has to wait for response before making 769 another request MUST NOT 6.1.12 770 Allow order of responses differ from order of 771 requests MUST 6.1.12 772 Communication overhead minimization SHOULD 6.1.13 773 Give particular attention to message size SHOULD 6.1.13 774 Extensibility without requiring modifications to 775 protocol MUST 6.1.14 776 Easily extensible to support intra-area, 777 inter-area, inter-AS intra provider, inter-AS 778 inter-provider, multi-layer path & virtual 779 network topology path computation MUST 6.1.14 780 Easily extensible to support future applications 781 not in scope (e.g., point-to-multipoint path 782 computations) SHOULD 6.1.14 783 Scale at least linearly with number of PCCs, 784 PCEs, PCCs communicating with single PCE, PCEs 785 communicated to by single PCC, domains, path 786 requests, handling bursts of requests MUST 6.1.15 787 Support path computation constraints MUST 6.1.16 788 Support "unsynchronized" & "synchronized" 789 objective functions MUST 6.1.17 790 Support different service provider environments 791 (e.g., MPLS-TE and GMPLS networks, centralized 792 & distributed PCE path computation, single & 793 multiple PCE path computation) MUST 6.2.1 794 Policy support for policies to accept/reject 795 requests, PCC to determine reason for 796 rejection, notification of policy violation MUST 6.2.2 797 Aliveness detection of PCCs/PCEs, PCECP failure 798 detection MUST 6.3.1 799 Protocol recovery support resynchronization of 800 information & requests between sender & 801 receiver MUST 6.3.2 802 Minimize repeat data transfer, allow PCE to 803 respond to computation requests issued before 804 failure without requests being re-issued SHOULD 6.3.2 805 Stateful PCE able to resynchronize/recover 806 states (e.g., LSP status, paths) after restart SHOULD 6.3.2 807 Allow indicating if computation is for LSP 808 restoration (support inclusion of previously 809 computed path & failed element) MUST 6.3.3 810 Support path reoptimization & inclusion of a 811 previously computed path MUST 6.3.3 813 7. Security Considerations 815 The impact of the use of a PCECP MUST be considered in the light of 816 the impact that it has on the security of the existing routing and 817 signaling protocols and techniques in use within the network. 818 Intra-domain security is impacted since there is a new interface, 819 protocol and element in the network. Any host in the network could 820 impersonate a PCC, and receive detailed information on network paths. 821 Any host could also impersonate a PCE, both gathering information 822 about the network before passing the request on to a real PCE, and 823 spoofing responses. Some protection here depends on the security of 824 the PCE discovery process (see [PCE-DISC-REQ]). An increase in 825 inter-domain information flows may increase the vulnerability to 826 security attacks, and the facilitation of inter-domain paths may 827 increase the impact of these security attacks. 829 Of particular relevance are the implications for confidentiality 830 inherent in a PCECP for multi-domain networks. It is not necessarily 831 the case that a multi-domain PCE solution will compromise security, 832 but solutions MUST examine their impacts in this area. 834 Applicability statements for particular combinations of signaling, 835 routing and path computation techniques are expected to contain 836 detailed security sections. 838 It should be observed that the use of an external PCE introduces 839 additional security issues. Most notable amongst these are: 841 - interception of PCE requests or responses 842 - impersonation of PCE or PCC 843 - DoS attacks on PCEs or PCCs 845 The PCECP MUST address these issues in detail using authentication, 846 encryption and DoS protection techniques. See also Section 6.1.9. 848 8. Manageability Considerations 850 Manageability of the PCECP MUST address the following considerations: 852 - the need for a MIB module for control and monitoring of PCECP 853 - the need for built-in diagnostic tools to test the operation of the 854 protocol (e.g., partner failure detection, OAM, etc.) 855 - configuration implications for the protocol 857 PCECP operations MUST be modeled and controlled through appropriate 858 MIB modules. Statistics gathering will form an important part of the 859 operation of the PCECP. The operator MUST be able to determine PCECP 860 historical interactions and the success rate of requests using data 861 from MIB modules. Similarly, it is important for an operator to be 862 able to determine PCECP and PCE load and whether an individual PCC is 863 responsible for a disproportionate amount of the load. It MUST be 864 possible, through use of MIB modules, to record and inspect 865 statistics about the PCECP communications, including issues such as 866 malformed messages, unauthorized messages and messages discarded 867 owing to congestion. 869 The new MIB modules should also be used to provide notifications 870 (traps) when thresholds are crossed or when important events occur. 872 PCECP techniques must enable a PCC to determine the liveness of a PCE 873 both before it sends a request and in the period between sending a 874 request and receiving a response. 876 It is also important for a PCE to know about the liveness of PCCs to 877 gain a predictive view of the likely loading of a PCE in the future, 878 and to allow a PCE to abandon processing of a received request. 880 The PCECP MUST support indication of congestion state and rate 881 limitation state, and MAY allow the operator to control such a 882 function. 884 9. IANA Considerations 886 This document makes no requests for IANA action. 888 10. Acknowledgements 890 The authors would like to extend their warmest thanks to (in 891 alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri 892 Papadimitriou, and JP Vasseur for their review and suggestions. 894 11. Normative References 896 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 897 Element (PCE) Architecture", work in progress. 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, March 1997. 902 12. Informational References 904 [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol 905 (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 906 87, RFC 3785, May 2004. 908 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 909 Computation Element (PCE) Discovery," work in progress. 911 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 912 Tunnels," RFC 3209, December 2001. 914 [PCE-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol 915 (PCECP) specific requirements for Inter-Area (G)MPLS Traffic 916 Engineering," work in progress. 918 [PCE-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication 919 Requirements for Inter-Layer Traffic Engineering," work in progress. 921 13. Authors' & Contributors' Addresses 923 Jerry Ash (Editor) 924 AT&T 925 Room MT D5-2A01 926 200 Laurel Avenue 927 Middletown, NJ 07748, USA 928 Phone: (732)-420-4578 929 Email: gash@att.com 931 Jean-Louis Le Roux (Editor) 932 France Telecom 933 2, avenue Pierre-Marzin 934 22307 Lannion Cedex, FRANCE 935 Email: jeanlouis.leroux@francetelecom.com 937 Alia K. Atlas 938 Google Inc. 939 1600 Amphitheatre Parkway 940 Mountain View, CA 94043 941 Email: akatlas@alum.mit.edu 943 Arthi Ayyangar 944 Juniper Networks, Inc. 945 1194 N.Mathilda Ave 946 Sunnyvale, CA 94089 USA 947 Email: arthi@juniper.net 949 Nabil Bitar 950 Verizon 951 40 Sylvan Road 952 Waltham, MA 02145 953 Email: nabil.bitar@verizon.com 955 Igor Bryskin 956 Independent Consultant 957 Email: i_bryskin@yahoo.com 959 Dean Cheng 960 Cisco Systems Inc. 961 3700 Cisco Way 962 San Jose CA 95134 USA 963 Phone: 408 527 0677 964 Email: dcheng@cisco.com 965 Durga Gangisetti 966 MCI 967 Email: durga.gangisetti@mci.com 969 Kenji Kumaki 970 KDDI Corporation 971 Garden Air Tower 972 Iidabashi, Chiyoda-ku, 973 Tokyo 102-8460, JAPAN 974 Phone: 3-6678-3103 975 Email: ke-kumaki@kddi.com 977 Eiji Oki 978 NTT 979 Midori-cho 3-9-11 980 Musashino-shi, Tokyo 180-8585, JAPAN 981 Email: oki.eiji@lab.ntt.co.jp 983 Raymond Zhang 984 BT INFONET Services Corporation 985 2160 E. Grand Ave. 986 El Segundo, CA 90245 USA 987 Email: Raymond_zhang@bt.infonet.com 989 Intellectual Property Statement 991 The IETF takes no position regarding the validity or scope of any 992 Intellectual Property Rights or other rights that might be claimed to 993 pertain to the implementation or use of the technology described in 994 this document or the extent to which any license under such rights 995 might or might not be available; nor does it represent that it has 996 made any independent effort to identify any such rights. Information 997 on the procedures with respect to rights in RFC documents can be 998 found in BCP 78 and BCP 79. 1000 Copies of IPR disclosures made to the IETF Secretariat and any 1001 assurances of licenses to be made available, or the result of an 1002 attempt made to obtain a general license or permission for the use of 1003 such proprietary rights by implementers or users of this 1004 specification can be obtained from the IETF on-line IPR repository at 1005 http://www.ietf.org/ipr. 1007 The IETF invites any interested party to bring to its attention any 1008 copyrights, patents or patent applications, or other proprietary 1009 rights that may cover technology that may be required to implement 1010 this standard. Please address the information to the IETF at 1011 ietf-ipr@ietf.org. 1013 Disclaimer of Validity 1015 This document and the information contained herein are provided on an 1016 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1017 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1018 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1019 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1020 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1021 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1023 Copyright Statement 1025 Copyright (C) The Internet Society (2006). This document is subject 1026 to the rights, licenses and restrictions contained in BCP 78, and 1027 except as set forth therein, the authors retain all their rights.