idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 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 (May 2006) is 6556 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: 'RFC 3209' is mentioned on line 337, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-ARCH' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft PCE Working Group Jerry Ash (AT&T) 2 Proposed Status: Informational Editor 3 Expires: December 2006 J.L. Le Roux (France Telecom) 4 Editor 6 May 2006 8 draft-ietf-pce-comm-protocol-gen-reqs-06.txt 10 PCE Communication Protocol Generic Requirements 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 18, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The PCE model is described in the "PCE Architecture" document and 44 facilitates path computation requests from Path Computation Clients 45 (PCCs) to Path Computation Elements (PCEs). This document specifies 46 generic requirements for a communication protocol between PCCs and 47 PCEs, and also between PCEs where cooperation between PCEs is 48 desirable. Subsequent documents will specify application-specific 49 requirements for the PCE communication protocol. 51 Table of Contents 53 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 55 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 4 58 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 59 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5 60 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 5 61 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 5 62 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 6 64 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 7 65 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 8 66 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 8 67 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 8 68 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 9 69 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 9 70 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 10 71 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 10 72 6.1.13 Communication Overhead Minimization . . . . . . . . . 10 73 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 10 74 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 11 75 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 12 76 6.1.17 Objective Functions Supported . . . . . . . . . . . . 12 77 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 13 78 6.2.1 Support for Different Service Provider Environments . . 13 79 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 13 80 6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . 13 81 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 13 82 6.3.2 Protocol Recovery . . . . . . . . . . . . . . . . . . . 14 83 6.3.3 LSP Rerouting & Reoptimization . . . . . . . . . . . . 14 84 6.4 Requirements Summary . . . . . . . . . . . . . . . . . . . . 14 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 17 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 18 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 89 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 18 90 12. Informational References . . . . . . . . . . . . . . . . . . . . 18 91 13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 19 92 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 20 93 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21 94 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 21 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]. 132 The PCE operates on a network graph in order to compute paths based 133 on the path computation request(s) issued by the PCC(s). The path 134 computation request will include the source and destination of the 135 paths to be computed, a set of constraints to be applied during the 136 computation, and may also include an objective function. The PCE 137 response includes the computed paths or the reason for a failed 138 computation. 140 This document lists a set of generic requirements for the PCECP. 141 Application-specific requirements are beyond the scope of this 142 document, and will be addressed in separate documents. For example, 143 application-specific communication protocol requirements are given in 144 [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] for inter-area and 145 inter-layer PCE applications, respectively. 147 4. Terminology 149 Domain: any collection of network elements within a common sphere of 150 address management or path computational responsibility. Examples of 151 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 152 within a service provider network, or multiple ASs across multiple 153 service provider networks. 155 GMPLS: Generalized Multi-Protocol Label Switching 157 LSP: MPLS/GMPLS Label Switched Path 159 LSR: Label Switch Router 161 MPLS: Multi-Protocol Label Switching 163 PCC: Path Computation Client: any client application requesting a 164 path computation to be performed by the PCE. 166 PCE: Path Computation Element: an entity (component, application or 167 network node) that is capable of computing a network path or route 168 based on a network graph and applying computational constraints (see 169 further description in [PCE-ARCH]). 171 TED: Traffic Engineering Database, which contains the topology and 172 resource information of the network or network segment used by a PCE. 174 TE LSP: Traffic Engineering (G)MPLS Label Switched Path. 176 See [PCE-ARCH] for further definitions of terms. 178 5. Overview of PCE Communication Protocol (PCECP) 180 In the PCE model, path computation requests are issued by a PCC 181 to a PCE that may be composite (co-located) or external (remote). If 182 the PCC and PCE are not co-located, a request/response communication 183 protocol is required to carry the request and return the response. 184 If the PCC and PCE are co-located, a communication protocol is not 185 required, but implementations may choose to utilize a protocol for 186 exchanges between the components. 188 In order that a PCC and PCE can communicate, the PCC must know the 189 location of the PCE. This can be configured or discovered. The PCE 190 discovery mechanism is out of scope of this document, but 191 requirements are documented in [PCE-DISC-REQ]. 193 The PCE operates on a network graph built from the TED in order to 194 compute paths. The mechanism by which the TED is populated is out of 195 scope for the PCECP. 197 A path computation request issued by the PCC includes a specification 198 of the path(s) needed. The information supplied includes, at a 199 minimum, the source and destination for the paths, but may also 200 include a set of further requirements (known as constraints) as 201 described in Section 6. 203 The response from the PCE may be positive in which case it will 204 include the paths that have been computed. If the computation fails 205 or cannot be performed, a negative response is required with an 206 indication of the type of failure. 208 A request/response protocol is also required for a PCE to communicate 209 path computation requests to another PCE and for that PCE to return 210 the path computation response. As described in [PCE-ARCH], there is 211 no reason to assume that two different protocols are needed, and this 212 document assumes that a single protocol will satisfy all requirements 213 for PCC-PCE and PCE-PCE communication. 215 [PCE-ARCH] describes four models of PCE: composite, external, 216 multiple PCE path computation, and multiple PCE path computation with 217 inter-PCE communication. In all cases except the composite PCE model, 218 a PCECP is required. The requirements defined in this document are 219 applicable to all models described in the [PCE-ARCH]. 221 6. PCE Communication Protocol Generic Requirements 223 Section 6.4 contains a summary of the requirements in this section. 225 6.1 Basic Protocol Requirements 227 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 229 A single protocol MUST be defined for PCC-PCE and PCE-PCE 230 communication. A PCE requesting a path from another PCE can be 231 considered as a PCC, and in the remainder of this document we refer 232 to all communications as PCC-PCE regardless of whether they are 233 PCC-PCE or PCE-PCE. 235 6.1.2 Client-Server Communication 237 PCC-PCE communication is by nature client-server based. The PCECP 238 MUST allow a PCC to send a request message to a PCE to request path 239 computation, and for a PCE to reply with a response message to the 240 requesting PCC once the path has been computed. 242 In addition to this request-response mode, there are cases where 243 there is unsolicited communication from the PCE to the PCC (see 244 Section 6.1.11). 246 6.1.3 Transport 248 The PCECP may utilize an existing transport protocol or operate 249 directly over IP. 251 If a transport protocol is used, it MAY be used to satisfy some 252 requirements stated in other sections of this document (for example, 253 reliability and security). Where requirements expressed in this 254 document match the function of existing transport protocols, 255 consideration MUST be given to the use of those protocols. 257 If a transport protocol is used, it MUST NOT limit the size of the 258 message used by the PCECP. 260 6.1.4 Path Computation Requests 262 The path computation request message MUST include at least the source 263 and destination. Note that the path computation request is for an 264 LSP or LSP segment, and the source and destination supplied are the 265 start and end of the computation being requested (i.e. of the LSP 266 segment). 268 The path computation request message MUST support the inclusion of a 269 set of one or more path constraints, including but not limited to the 270 requested bandwidth or resources (hops, affinities, etc.) to 271 include/exclude. For example, a PCC may request the PCE to exclude 272 points of failure in the computation of a new path if an LSP setup 273 fails. The actual inclusion of constraints is a choice for the PCC 274 issuing the request. A list of core constraints that must be 275 supported by the PCECP is supplied in Section 6.1.16. Specification 276 of constraints MUST be future-proofed as described in Section 6.1.14. 278 The requester MUST be allowed to select or prefer from an advertised 279 list or minimal subset of standard objective functions and functional 280 options. An objective function is used by the PCE to process 281 constraints to a path computation request when it computes a path in 282 order to select the "best" candidate paths (e.g., minimum hop path), 283 and corresponds to the optimization criteria used for the computation 284 of one path, or the synchronized computation of a set of paths. In 285 the case of unsynchronized path computation, this can be, for 286 example, the path cost or the residual bandwidth on the most loaded 287 path link. In the case of synchronized path computation, this can 288 be, for example, the global bandwidth consumption or the residual 289 bandwidth on the most loaded network link. 291 A list of core objective functions that MUST be supported by the 292 PCECP is supplied in Section 6.1.17. Specification of objective 293 functions MUST be future-proofed as described in Section 6.1.14. 295 The requester SHOULD also be able to select a vendor-specific or 296 experimental objective function or functional option. Furthermore, 297 the requester MUST be allowed to customize the function/options in 298 use. That is, individual objective functions will often have 299 parameters to be set in the request from PCC to PCE. Support for the 300 specification of objective functions and objective parameters is 301 required in the protocol extensibility specified in Section 6.1.14. 303 A request message MAY include TE parameters carried by the MPLS/GMPLS 304 LSP setup signaling protocol. Also, it MUST be possible for the PCE 305 to apply additional objective functions. This might include policy 306 based routing path computation for load balancing instructed by the 307 management plane. 309 Shortest path selection may rely either on the TE metric or on the 310 IGP metric [METRIC]. Hence the PCECP request message MUST allow the 311 PCC to indicate the metric type (IGP or TE) to be used for shortest 312 path selection. Note that other metric types may be specified in the 313 future. 315 There may be cases where a single path cannot fit a given bandwidth 316 request, while a set of paths could be combined to fit the request. 317 Such path combination to serve a given request is called 318 load-balancing. The request message MUST allow the PCC to indicate if 319 load-balancing is allowed or not. It MUST also include the maximum 320 number of paths in a load-balancing path group, and the minimum path 321 bandwidth in a load-balancing path group. The request message MUST 322 allow specification of the degree of disjointness of the members of 323 the load-balancing group. 325 6.1.5 Path Computation Responses 327 The path computation response message MUST allow the PCE to return 328 various elements including, at least, the computed path(s). 330 The protocol MUST be capable of returning any explicit path that 331 would be acceptable for use for MPLS and GMPLS LSPs once converted to 332 an Explicit Route Object for use in RSVP-TE signaling. In addition, 333 anything that can be expressed in an Explicit Route Object MUST be 334 capable of being returned in the computed path. Note that the 335 resultant path(s) may be made up of a set of strict or loose hops, or 336 any combination of strict and loose hops. Moreover, a hop may have 337 the form of a non-simple abstract node. See [RFC 3209] for the 338 definition of strict hop, loose hop, and abstract node. 340 A positive response from the PCE MUST include the paths that have 341 been computed. A positive PCECP computation response MUST support 342 the inclusion of a set of attributes of the computed path, such as 343 the path costs (e.g., cumulative link TE metrics and cumulative link 344 IGP metrics) and the computed bandwidth. The latter is useful when a 345 single path cannot serve the requested bandwidth and load balancing 346 is applied. 348 When a path satisfying the constraints cannot be found, or if the 349 computation fails or cannot be performed, a negative response MUST be 350 sent. This response MAY include further details of the reason(s) for 351 the failure, and MAY include advice about which constraints might be 352 relaxed to be more likely to achieve a positive result. 354 The PCECP response message MUST support the inclusion of the set of 355 computed paths of a load-balancing path group, as well as their 356 respective bandwidths. 358 6.1.6 Cancellation of Pending Requests 360 A PCC MUST be able to cancel a pending request using a notification 361 message. A PCC that has sent a request to a PCE and no longer needs 362 a response, for instance because it no longer wants to set up the 363 associated service, MUST be able to notify the PCE that it can clear 364 the request (i.e. stop the computation if already started, and clear 365 the context). The PCE may also wish to cancel a pending request 366 because of some congested state. 368 6.1.7 Multiple Requests and Responses 370 It MUST be possible to send multiple path computation requests 371 within the same request message. Such requests may be correlated (for 372 example, requesting disjoint paths) or uncorrelated (requesting paths 373 for unrelated services). It MUST be possible to limit by 374 configuration of both PCCs and PCEs the number of requests that can 375 be carried within a single message. 377 Similarly, it MUST be possible to return multiple computed paths 378 within the same response message, corresponding either to the same 379 request (e.g. multiple suited paths, paths of a load balancing path 380 group) or to distinct requests, correlated or not, of the same 381 request message or distinct request messages. 383 It MUST be possible to provide "continuation correlation" where all 384 related requests or computed paths cannot fit within one message, and 385 are carried in a sequence of correlated messages. 387 The PCE MUST inform the PCC of its capabilities. Maximum acceptable 388 message sizes and the maximum number of requests per message 389 supported by a PCE MAY form part of PCE capabilities advertisement 390 [PCE-DISC-REQ], or MAY be exchanged through information messages from 391 the PCE as part of the protocol described here. 393 It MUST be possible for a PCC to specify, in the request message, the 394 maximum acceptable response message sizes and the maximum number of 395 computed paths per response message it can support. 397 It MUST be possible to limit the message size by configuration on 398 PCCs and PCEs. 400 6.1.8 Reliable Message Exchange 402 The PCECP MUST support reliable transmission of PCECP packets. This 403 may form part of the protocol itself or may be achieved by the 404 selection of a suitable transport protocol (see Section 6.1.3). 406 In particular, it MUST allow for the detection and recovery of lost 407 messages to occur quickly and not impede the operation of the PCECP. 409 In some cases (e.g. after link failure), a large number of PCCs may 410 simultaneously send requests to a PCE, leading to a potential 411 saturation of the PCEs. The PCECP MUST support indication of 412 congestion state and rate limitation state. This should enable, for 413 example, a PCE to limit the rate of incoming request messages if the 414 request rate is too high. 416 The PCECP MUST provide: 418 - Detection and report of lost or corrupted messages 419 - Automatic attempts to retransmit lost messages without reference to 420 the application 421 - Handling of out-of-order messages 422 - Handling of duplicate messages 423 - Flow control and back-pressure to enable throttling of requests and 424 responses 425 - Rapid PCECP communication failure detection 426 - Distinction between partner failure and communication channel 427 failure after the PCECP communication is recovered 429 If it is necessary to add functions to PCECP to overcome shortcomings 430 in the chosen transport mechanisms, these functions SHOULD be based 431 on and re-use where possible techniques developed in other protocols 432 to overcome the same shortcomings. Functionality MUST NOT be added 433 to the PCECP where the chosen transport protocol already provides it. 435 6.1.9 Secure Message Exchange 437 The PCC-PCE communication protocol MUST include provisions to ensure 438 the security of the exchanges between the entities. In particular, 439 it MUST support mechanisms to prevent spoofing (e.g., 440 authentication), snooping (e.g., encryption) and DOS attacks (e.g., 441 packet filtering, rate limiting, no promiscuous listening). Where 442 the PCE-PCC communication takes place entirely within one limited 443 domain, the use of a private address space which is not available to 444 customer systems MAY be used to help protect the information 445 exchange, but other mechanisms MUST also be available. 447 This function may be provided by the transport protocol or directly 448 by the PCECP. 450 See Section 7 for further discussion of security considerations. 452 6.1.10 Request Prioritization 454 The PCECP MUST allow a PCC to specify the priority of a computation 455 request. 457 Implementation of priority-based activity within a PCE is subject to 458 implementation and local policy. This application processing is out 459 of scope of the PCECP. 461 6.1.11 Unsolicited Notifications 463 The normal operational mode is for the PCC to make path computation 464 requests to the PCE, and for the PCE to respond. 466 The PCECP MUST support unsolicited notifications from PCE to PCC, or 467 PCC to PCE. This requirement facilitates the unsolicited 468 communication of information and alerts between PCCs and PCEs. 470 6.1.12 Asynchronous Communication 472 The PCC-PCE protocol MUST allow for asynchronous communication. A 473 PCC MUST NOT have to wait for a response to one request before it can 474 make another request. 476 It MUST also be possible to have the order of responses differ from 477 the order of the corresponding requests. This may occur, for 478 instance, when path request messages have different priorities (see 479 Requirement 6.1.10). A consequent requirement is that path 480 computation responses MUST include a direct correlation to the 481 associated request. 483 6.1.13 Communication Overhead Minimization 485 The request and response messages SHOULD be designed so that the 486 communication overhead is minimized. In particular, the overhead per 487 message SHOULD be minimized, and the number of bytes exchanged to 488 arrive at a computation answer SHOULD be minimized. Other 489 considerations in overhead minimization include the following: 491 - the number of background messages used by the protocol or its 492 transport protocol to keep alive any session or association 493 between the PCE and PCC 494 - the processing cost at the PCE (or PCC) associated with 495 request/response messages (as distinct from processing the 496 computation requests themselves). 498 6.1.14 Extensibility 500 The PCECP MUST provide a way for the introduction of new path 501 computation constraints, diversity types, objective functions, 502 optimization methods and parameters, etc., without requiring 503 major modifications in the protocol. 505 The PCECP MUST be easily extensible to support various PCE based 506 applications that have been currently identified including: 508 - intra-area path computation [PCECP-INTER-AREA] 509 - inter-area path computation 510 - inter-AS intra provider and inter-AS inter-provider path 511 computation 512 - inter-layer path computation [PCECP-INTER-LAYER] 514 The PCECP MUST support the requirements specified in the 515 application-specific requirements documents. The PCECP MUST also 516 allow extensions as more PCE applications will be introduced in the 517 future. 519 The PCECP SHOULD also be extensible to support future applications 520 not currently in the scope of the PCE working group, such as, for 521 instance, point-to-multipoint path computations, multi-hop pseudowire 522 path computation, etc. 524 Note that application specific requirements are out of the scope of 525 this document and will be addressed in separate requirements 526 documents. 528 6.1.15 Scalability 530 The PCECP MUST scale well, at least as good as linearly, with an 531 increase of any of the following parameters (note, minimum order of 532 magnitude estimates of what the PCECP should support are given in 533 parenthesis): 535 - number of PCCs (1000/domain) 536 - number of PCEs (100/domain) 537 - number of PCCs communicating with a single PCE (1000) 538 - number of PCEs communicated to by a single PCC (100) 539 - number of domains (20) 540 - number of path request messages (average of 10/second/PCE) 541 - handling bursts of requests (burst of 100/second/PCE within a 10- 542 second interval). 544 Note that path requests can be bundled in path request messages, for 545 example, 10 PCECP request messages/second may correspond to 100 path 546 requests/second. 548 Bursts of requests may arise, for example, after a network outage 549 when multiple recomputations are requested. The PCECP MUST handle 550 the congestion in a graceful way so that it does not unduly impact 551 the rest of the network, and so that it does not gate the ability of 552 the PCE to perform computation. 554 6.1.16 Constraints 556 This section provides a list of generic constraints that MUST be 557 supported by the PCECP. Other constraints may be added to service 558 specific applications as identified by separate application-specific 559 requirements documents. 561 Note that the absence of a constraint in this list does not mean that 562 the constraint must not be supported. Note also that the provisions 563 of Section 6.1.14 mean that new constraints can be added to this list 564 without impacting the protocol to a level that requires major 565 protocol changes. 567 Here is the list of generic constraints that MUST be supported: 569 o MPLS-TE and GMPLS generic constraints: 570 - Bandwidth 571 - Affinities inclusion/exclusion 572 - Link, Node, SRLG inclusion/exclusion 573 - Maximum end-to-end IGP metric 574 - Maximum Hop Count 575 - Maximum end-to-end TE metric 576 - Degree of paths disjointess (Link, Node, SRLG) 578 o MPLS-TE specific constraints 579 - Class-type 580 - Local protection 581 - Node protection 582 - Bandwidth protection 584 o GMPLS specific constraints 585 - Switching type, encoding type 586 - Link protection type 588 6.1.17 Objective Functions Supported 590 This section provides a list of generic objective functions that MUST 591 be supported by the PCECP. Other objectives functions MAY be added 592 to service specific applications as identified by separate 593 application-specific requirements documents. 595 Note that the absence of an objective function in this list does not 596 mean that the objective function may not be supported. Note also 597 that the provisions of Section 6.1.14 mean that new objective 598 functions MAY be added to this list without impacting the protocol. 600 The PCECP MUST support the following "unsynchronized" objective 601 functions: 603 - Minimum cost path with respect to a specified metric(shortest path) 604 - Least loaded path 605 - Maximum available bandwidth path 607 Also the PCECP MUST support the following "synchronized" objective 608 functions: 610 - Minimize aggregate bandwidth consumption on all links 611 - Maximize the residual bandwidth on the most loaded link 612 - Minimize the cumulative cost of a set of diverse paths. 614 6.2 Deployment Support Requirements 616 6.2.1 Support for Different Service Provider Environments 618 The PCECP MUST operate in various different service provider network 619 environments that utilize an IP-based control plane, including 621 - MPLS-TE and GMPLS networks 622 - packet and non-packet networks 623 - centralized and distributed PCE path computation 624 - single and multiple PCE path computation 626 Definitions of centralized, distributed, single, and multiple PCE 627 path computation can be found in [PCE-ARCH]. 629 6.2.2 Policy Support 631 The PCECP MUST allow for the use of policies to accept/reject 632 requests, and include the ability for a PCE to supply sufficient 633 detail when it rejects a request for policy reasons to allow the PCC 634 to determine the reason for rejection or failure. For example, 635 filtering could be required for a PCE that serves one domain (perhaps 636 an AS) such that all requests that come from another domain (AS) are 637 rejected. However, specific policy details are left to 638 application-specific PCECP requirements. Actual policies, 639 configuration of policies, and applicability of policies are out of 640 scope. 642 Note that work on supported policy models and the corresponding 643 requirements/implications is being undertaken as a separate work item 644 in the PCE working group. 646 PCECP messages MUST be able to carry transparent policy information. 648 6.3 Aliveness Detection & Recovery Requirements 650 6.3.1 Aliveness Detection 652 The PCECP MUST allow a PCC to 654 - check the liveliness of the PCC-PCE communication 655 - rapidly detect PCC-PCE communication failure (indifferently to 656 partner failure or connectivity failure), 657 - distinguish PCC/PCE node failures from PCC-PCE connectivity 658 failures, after the PCC-PCE communication is recovered. 660 The aliveness detection mechanism MUST ensure reciprocal knowledge of 661 PCE and PCC liveness. 663 6.3.2 Protocol Recovery 665 In the event of the failure of a sender or of the communication 666 channel, the PCECP, upon recovery, MUST support resynchronization of 667 information and requests between the sender and the receiver, and 668 this SHOULD be arranged so as to minimize repeat data transfer. 670 6.3.3 LSP Rerouting & Reoptimization 672 If an LSP fails owing to the failure of a link or node that it 673 traverses, a new computation request may be made to a PCE in order to 674 repair the LSP. Since the PCC cannot know that the PCE's TED has been 675 updated to reflect the failure network information, it is useful to 676 include this information in the new path computation request. Also, 677 in order to re-use the resources used by the old LSP, it may be 678 advantageous to indicate the route of the old LSP as part of the new 679 path computation request. 681 Hence the path computation request message MUST allow an indication 682 of whether the computation is for LSP restoration, and MUST support 683 the inclusion of the previously computed path as well as the identity 684 of the failed element. Note that the old path might only be useful 685 if the old LSP has not yet been torn down. 687 Note that a network failure may impact a large number of LSPs. In 688 this case, a potentially large number of PCCs is going to 689 simultaneously send requests to the PCE. The PCECP MUST properly 690 handle such overload situations, such as for instance through 691 throttling of requests as set forth in section 6.1.8. 693 The path computation request message MUST support TE LSP path 694 reoptimization and the inclusion of a previously computed path. This 695 will help ensure optimal routing of a reoptimized path, since it will 696 allow the PCE to avoid double bandwidth accounting and help reduce 697 blocking issues. 699 6.4 Requirements Summary 701 The following is a summary of the requirements in Section 6: 703 Requirement Necessity Ref. 704 ------------------------------------------------------------------ 705 Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1 706 Client-server communication MUST 6.1.2 707 Support PCC/PCE request message to request path 708 computation MUST 6.1.2 709 Support PCE response message with computed path MUST 6.1.2 710 Support unsolicited communication PCE-PCC SHOULD 6.1.2 711 Maintain PCC-PCE session NON-RQMT 6.1.2 712 Use of existing transport protocol MAY 6.1.3 713 Transport protocol satisfy reliability & security 714 requirements MAY 6.1.3 715 Transport protocol limits size of message MUST NOT 6.1.3 716 Support path computation requests MUST 6.1.4 717 Path computation request includes source & 718 destination MUST 6.1.4 719 Support path constraints (e.g., bandwidth, hops, 720 affinities) to include/exclude MUST 6.1.4 721 Allow to select/prefer from advertised list of 722 standard objective functions/options MUST 6.1.4 723 Allow to customize objective function/options MUST 6.1.4 724 Allow indicating the metric type (IGP or TE) to 725 be used for shortest path selection MUST 6.1.4 726 Allow indicating the set of path attributes 727 required in response message MUST 6.1.4 728 Allow indicating if load-balancing is allowed MUST 6.1.4 729 Support path computation responses MUST 6.1.5 730 Negative response support reasons for failure, 731 constraints to relax to achieve positive result SHOULD 6.1.5 732 Support inclusion of set of path attributes MUST 6.1.5 733 Support inclusion of set of computed paths of a 734 load-balancing path group, as well as their 735 respective bandwidth MUST 6.1.5 736 Cancellation of pending requests MUST 6.1.6 737 Multiple requests and responses MUST 6.1.7 738 Limit by configuration number of requests within 739 a message MUST 6.1.7 740 Support multiple computed paths in response MUST 6.1.7 741 Support "continuation correlation" where related 742 requests or computed paths cannot fit within 743 one message MUST 6.1.7 744 Maximum message size & maximum number of requests 745 per message exchanged through PCE messages to 746 PCC, or indicated in request message MAY 6.1.7 747 Reliable message exchange (achieved by PCECP 748 itself or transport protocol) MUST 6.1.8 749 Allow detection & recovery of lost messages to 750 occur quickly & not impede operation of PCECP MUST 6.1.8 751 Handle overload situations without significant 752 decrease in performance, e.g., through 753 throttling of requests MUST 6.1.8 754 Detect/report lost/corrupted messages, retransmit 755 lost messages, handle out-of-order messages & 756 duplicate messages, provide flow control/ 757 back-pressure to throttle messages, detect 758 PCECP communication failure detection MUST 6.1.8 759 Functionality added to PCECP if transport 760 protocol provides it SHOULD NOT 6.1.8 761 Secure message exchange (provided by PCECP or 762 transport protocol MUST 6.1.9 763 Support mechanisms to prevent spoofing (e.g., 764 authentication), snooping (e.g., encryption), 765 DOS attacks MUST 6.1.9 766 Request prioritization MUST 6.1.10 767 Unsolicited notifications SHOULD 6.1.11 768 Allow asynchronous communication MUST 6.1.12 769 PCC has to wait for response before making 770 another request MUST NOT 6.1.12 771 Allow order of responses differ from order of 772 requests MUST 6.1.12 773 Communication overhead minimization SHOULD 6.1.13 774 Give particular attention to message size SHOULD 6.1.13 775 Extensibility without requiring modifications to 776 protocol MUST 6.1.14 777 Easily extensible to support intra-area, 778 inter-area, inter-AS intra provider, inter-AS 779 inter-provider, multi-layer path & virtual 780 network topology path computation MUST 6.1.14 781 Easily extensible to support future applications 782 not in scope (e.g., point-to-multipoint path 783 computations) SHOULD 6.1.14 784 Scale at least linearly with number of PCCs, 785 PCEs, PCCs communicating with single PCE, PCEs 786 communicated to by single PCC, domains, path 787 requests, handling bursts of requests MUST 6.1.15 788 Support path computation constraints MUST 6.1.16 789 Support "unsynchronized" & "synchronized" 790 objective functions MUST 6.1.17 791 Support different service provider environments 792 (e.g., MPLS-TE and GMPLS networks, centralized 793 & distributed PCE path computation, single & 794 multiple PCE path computation) MUST 6.2.1 795 Policy support for policies to accept/reject 796 requests, PCC to determine reason for 797 rejection, notification of policy violation MUST 6.2.2 798 Aliveness detection of PCCs/PCEs, PCECP failure 799 detection MUST 6.3.1 800 Protocol recovery support resynchronization of 801 information & requests between sender & 802 receiver MUST 6.3.2 803 Minimize repeat data transfer, allow PCE to 804 respond to computation requests issued before 805 failure without requests being re-issued SHOULD 6.3.2 806 Stateful PCE able to resynchronize/recover 807 states (e.g., LSP status, paths) after restart SHOULD 6.3.2 808 Allow indicating if computation is for LSP 809 restoration (support inclusion of previously 810 computed path & failed element) MUST 6.3.3 811 Support path reoptimization & inclusion of a 812 previously computed path MUST 6.3.3 814 7. Security Considerations 816 The impact of the use of a PCECP MUST be considered in the light of 817 the impact that it has on the security of the existing routing and 818 signaling protocols and techniques in use within the network. 819 Intra-domain security is impacted since there is a new interface, 820 protocol and element in the network. Any host in the network could 821 impersonate a PCC, and receive detailed information on network paths. 822 Any host could also impersonate a PCE, both gathering information 823 about the network before passing the request on to a real PCE, and 824 spoofing responses. Some protection here depends on the security of 825 the PCE discovery process (see [PCE-DISC-REQ]). An increase in 826 inter-domain information flows may increase the vulnerability to 827 security attacks, and the facilitation of inter-domain paths may 828 increase the impact of these security attacks. 830 Of particular relevance are the implications for confidentiality 831 inherent in a PCECP for multi-domain networks. It is not necessarily 832 the case that a multi-domain PCE solution will compromise security, 833 but solutions MUST examine their impacts in this area. 835 Applicability statements for particular combinations of signaling, 836 routing and path computation techniques are expected to contain 837 detailed security sections. 839 It should be observed that the use of an external PCE introduces 840 additional security issues. Most notable amongst these are: 842 - interception of PCE requests or responses 843 - impersonation of PCE or PCC 844 - DoS attacks on PCEs or PCCs 846 The PCECP MUST address these issues in detail using authentication, 847 encryption and DoS protection techniques. See also Section 6.1.9. 849 8. Manageability Considerations 851 Manageability of the PCECP MUST address the following considerations: 853 - the need for a MIB module for control and monitoring of PCECP 854 - the need for built-in diagnostic tools to test the operation of the 855 protocol (e.g., partner failure detection, OAM, etc.) 856 - configuration implications for the protocol 858 PCECP operations MUST be modeled and controlled through appropriate 859 MIB modules. Statistics gathering will form an important part of the 860 operation of the PCECP. The operator MUST be able to determine PCECP 861 historical interactions and the success rate of requests using data 862 from MIB modules. Similarly, it is important for an operator to be 863 able to determine PCECP and PCE load and whether an individual PCC is 864 responsible for a disproportionate amount of the load. It MUST be 865 possible, through use of MIB modules, to record and inspect 866 statistics about the PCECP communications, including issues such as 867 malformed messages, unauthorized messages and messages discarded 868 owing to congestion. 870 The new MIB modules should also be used to provide notifications 871 (traps) when thresholds are crossed or when important events occur. 873 PCECP techniques must enable a PCC to determine the liveness of a PCE 874 both before it sends a request and in the period between sending a 875 request and receiving a response. 877 It is also important for a PCE to know about the liveness of PCCs to 878 gain a predictive view of the likely loading of a PCE in the future, 879 and to allow a PCE to abandon processing of a received request. 881 The PCECP MUST support indication of congestion state and rate 882 limitation state, and MAY allow the operator to control such a 883 function. 885 9. IANA Considerations 887 This document makes no requests for IANA action. 889 10. Acknowledgements 891 The authors would like to extend their warmest thanks to (in 892 alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas 893 Morin, Dimitri Papadimitriou, and JP Vasseur for their review and 894 suggestions. 896 11. Normative References 898 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 899 Element (PCE) Architecture", work in progress. 901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, March 1997. 904 12. Informational References 906 [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol 907 (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 908 87, RFC 3785, May 2004. 910 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 911 Computation Element (PCE) Discovery," work in progress. 913 [PCECP-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol 914 (PCECP) specific requirements for Inter-Area (G)MPLS Traffic 915 Engineering," work in progress. 917 [PCECP-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication 918 Requirements for Inter-Layer Traffic Engineering," work in progress. 920 13. Authors' & Contributors' Addresses 922 Jerry Ash (Editor) 923 AT&T 924 Room MT D5-2A01 925 200 Laurel Avenue 926 Middletown, NJ 07748, USA 927 Phone: (732)-420-4578 928 Email: gash@att.com 930 Jean-Louis Le Roux (Editor) 931 France Telecom 932 2, avenue Pierre-Marzin 933 22307 Lannion Cedex, FRANCE 934 Email: jeanlouis.leroux@francetelecom.com 936 Alia K. Atlas 937 Google Inc. 938 1600 Amphitheatre Parkway 939 Mountain View, CA 94043 940 Email: akatlas@alum.mit.edu 942 Arthi Ayyangar 943 Juniper Networks, Inc. 944 1194 N.Mathilda Ave 945 Sunnyvale, CA 94089 USA 946 Email: arthi@juniper.net 948 Nabil Bitar 949 Verizon 950 40 Sylvan Road 951 Waltham, MA 02145 952 Email: nabil.bitar@verizon.com 954 Igor Bryskin 955 Independent Consultant 956 Email: i_bryskin@yahoo.com 958 Dean Cheng 959 Cisco Systems Inc. 960 3700 Cisco Way 961 San Jose CA 95134 USA 962 Phone: 408 527 0677 963 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.