idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-05.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 1026. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1016. ** 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 6555 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-05.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 . . . . . . . . . . . . . . . . 10 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 rate limiting, no promiscuous listening). 442 The PCC-PCE communication protocol MUST include provisions to ensure 443 the security of the exchanges between the entities. In particular, 444 it MUST support mechanisms to prevent spoofing (e.g., 445 authentication), snooping (e.g., encryption) and DOS attacks (e.g., 446 packet filtering, rate limiting, no promiscuous listening). Where 447 the PCE-PCC communication takes place entirely within one limited 448 domain, the use of a private address space which is not available to 449 customer systems MAY be used to help protect the information 450 exchange, but other mechanisms MUST also be available. 452 This function may be provided by the transport protocol or directly 453 by the PCECP. 455 See Section 7 for further discussion of security considerations. 457 6.1.10 Request Prioritization 459 The PCECP MUST allow a PCC to specify the priority of a computation 460 request. 462 Implementation of priority-based activity within a PCE is subject to 463 implementation and local policy. This application processing is out 464 of scope of the PCECP. 466 6.1.11 Unsolicited Notifications 468 The normal operational mode is for the PCC to make path computation 469 requests to the PCE, and for the PCE to respond. 471 The PCECP MUST support unsolicited notifications from PCE to PCC, or 472 PCC to PCE. This requirement facilitates the unsolicited 473 communication of information and alerts between PCCs and PCEs. 475 6.1.12 Asynchronous Communication 477 The PCC-PCE protocol MUST allow for asynchronous communication. A 478 PCC MUST NOT have to wait for a response to one request before it can 479 make another request. 481 It MUST also be possible to have the order of responses differ from 482 the order of the corresponding requests. This may occur, for 483 instance, when path request messages have different priorities (see 484 Requirement 6.1.10). A consequent requirement is that path 485 computation responses MUST include a direct correlation to the 486 associated request. 488 6.1.13 Communication Overhead Minimization 490 The request and response messages SHOULD be designed so that the 491 communication overhead is minimized. In particular, the overhead per 492 message SHOULD be minimized, and the number of bytes exchanged to 493 arrive at a computation answer SHOULD be minimized. Other 494 considerations in overhead minimization include the following: 496 - the number of background messages used by the protocol or its 497 transport protocol to keep alive any session or association 498 between the PCE and PCC 499 - the processing cost at the PCE (or PCC) associated with 500 request/response messages (as distinct from processing the 501 computation requests themselves). 503 6.1.14 Extensibility 505 The PCECP MUST provide a way for the introduction of new path 506 computation constraints, diversity types, objective functions, 507 optimization methods and parameters, etc., without requiring 508 major modifications in the protocol. 510 The PCECP MUST be easily extensible to support various PCE based 511 applications that have been currently identified including: 513 - intra-area path computation [PCECP-INTER-AREA] 514 - inter-area path computation 515 - inter-AS intra provider and inter-AS inter-provider path 516 computation 517 - inter-layer path computation [PCECP-INTER-LAYER] 519 The PCECP MUST support the requirements specified in the 520 application-specific requirements documents. The PCECP MUST also 521 allow extensions as more PCE applications will be introduced in the 522 future. 524 The PCECP SHOULD also be extensible to support future applications 525 not currently in the scope of the PCE working group, such as, for 526 instance, point-to-multipoint path computations, multi-hop pseudowire 527 path computation, etc. 529 Note that application specific requirements are out of the scope of 530 this document and will be addressed in separate requirements 531 documents. 533 6.1.15 Scalability 535 The PCECP MUST scale well, at least as good as linearly, with an 536 increase of any of the following parameters (note, minimum order of 537 magnitude estimates of what the PCECP should support are given in 538 parenthesis): 540 - number of PCCs (1000/domain) 541 - number of PCEs (100/domain) 542 - number of PCCs communicating with a single PCE (1000) 543 - number of PCEs communicated to by a single PCC (100) 544 - number of domains (20) 545 - number of path request messages (average of 10/second/PCE) 546 - handling bursts of requests (burst of 100/second/PCE within a 10- 547 second interval). 549 Note that path requests can be bundled in path request messages, for 550 example, 10 PCECP request messages/second may correspond to 100 path 551 requests/second. 553 Bursts of requests may arise, for example, after a network outage 554 when multiple recomputations are requested. The PCECP MUST handle 555 the congestion in a graceful way so that it does not unduly impact 556 the rest of the network, and so that it does not gate the ability of 557 the PCE to perform computation. 559 6.1.16 Constraints 561 This section provides a list of generic constraints that MUST be 562 supported by the PCECP. Other constraints may be added to service 563 specific applications as identified by separate application-specific 564 requirements documents. 566 Note that the absence of a constraint in this list does not mean that 567 the constraint must not be supported. Note also that the provisions 568 of Section 6.1.14 mean that new constraints can be added to this list 569 without impacting the protocol to a level that requires major 570 protocol changes. 572 Here is the list of generic constraints that MUST be supported: 574 o MPLS-TE and GMPLS generic constraints: 575 - Bandwidth 576 - Affinities inclusion/exclusion 577 - Link, Node, SRLG inclusion/exclusion 578 - Maximum end-to-end IGP metric 579 - Maximum Hop Count 580 - Maximum end-to-end TE metric 581 - Degree of paths disjointess (Link, Node, SRLG) 583 o MPLS-TE specific constraints 584 - Class-type 585 - Local protection 586 - Node protection 587 - Bandwidth protection 589 o GMPLS specific constraints 590 - Switching type, encoding type 591 - Link protection type 593 6.1.17 Objective Functions Supported 595 This section provides a list of generic objective functions that MUST 596 be supported by the PCECP. Other objectives functions MAY be added 597 to service specific applications as identified by separate 598 application-specific requirements documents. 600 Note that the absence of an objective function in this list does not 601 mean that the objective function may not be supported. Note also 602 that the provisions of Section 6.1.14 mean that new objective 603 functions MAY be added to this list without impacting the protocol. 605 The PCECP MUST support the following "unsynchronized" objective 606 functions: 608 - Minimum cost path with respect to a specified metric(shortest path) 609 - Least loaded path 610 - Maximum available bandwidth path 612 Also the PCECP MUST support the following "synchronized" objective 613 functions: 615 - Minimize aggregate bandwidth consumption on all links 616 - Maximize the residual bandwidth on the most loaded link 617 - Minimize the cumulative cost of a set of diverse paths. 619 6.2 Deployment Support Requirements 621 6.2.1 Support for Different Service Provider Environments 623 The PCECP MUST operate in various different service provider network 624 environments that utilize an IP-based control plane, including 626 - MPLS-TE and GMPLS networks 627 - packet and non-packet networks 628 - centralized and distributed PCE path computation 629 - single and multiple PCE path computation 631 Definitions of centralized, distributed, single, and multiple PCE 632 path computation can be found in [PCE-ARCH]. 634 6.2.2 Policy Support 636 The PCECP MUST allow for the use of policies to accept/reject 637 requests, and include the ability for a PCE to supply sufficient 638 detail when it rejects a request for policy reasons to allow the PCC 639 to determine the reason for rejection or failure. For example, 640 filtering could be required for a PCE that serves one domain (perhaps 641 an AS) such that all requests that come from another domain (AS) are 642 rejected. However, specific policy details are left to 643 application-specific PCECP requirements. Actual policies, 644 configuration of policies, and applicability of policies are out of 645 scope. 647 Note that work on supported policy models and the corresponding 648 requirements/implications is being undertaken as a separate work item 649 in the PCE working group. 651 PCECP messages MUST be able to carry transparent policy information. 653 6.3 Aliveness Detection & Recovery Requirements 655 6.3.1 Aliveness Detection 657 The PCECP MUST allow a PCC to 659 - check the liveliness of the PCC-PCE communication 660 - rapidly detect PCC-PCE communication failure (indifferently to 661 partner failure or connectivity failure), 662 - distinguish PCC/PCE node failures from PCC-PCE connectivity 663 failures, after the PCC-PCE communication is recovered. 665 The aliveness detection mechanism MUST ensure reciprocal knowledge of 666 PCE and PCC liveness. 668 6.3.2 Protocol Recovery 670 In the event of the failure of a sender or of the communication 671 channel, the PCECP, upon recovery, MUST support resynchronization of 672 information and requests between the sender and the receiver, and 673 this SHOULD be arranged so as to minimize repeat data transfer. 675 6.3.3 LSP Rerouting & Reoptimization 677 If an LSP fails owing to the failure of a link or node that it 678 traverses, a new computation request may be made to a PCE in order to 679 repair the LSP. Since the PCC cannot know that the PCE's TED has been 680 updated to reflect the failure network information, it is useful to 681 include this information in the new path computation request. Also, 682 in order to re-use the resources used by the old LSP, it may be 683 advantageous to indicate the route of the old LSP as part of the new 684 path computation request. 686 Hence the path computation request message MUST allow an indication 687 of whether the computation is for LSP restoration, and MUST support 688 the inclusion of the previously computed path as well as the identity 689 of the failed element. Note that the old path might only be useful 690 if the old LSP has not yet been torn down. 692 Note that a network failure may impact a large number of LSPs. In 693 this case, a potentially large number of PCCs is going to 694 simultaneously send requests to the PCE. The PCECP MUST properly 695 handle such overload situations, such as for instance through 696 throttling of requests as set forth in section 6.1.8. 698 The path computation request message MUST support TE LSP path 699 reoptimization and the inclusion of a previously computed path. This 700 will help ensure optimal routing of a reoptimized path, since it will 701 allow the PCE to avoid double bandwidth accounting and help reduce 702 blocking issues. 704 6.4 Requirements Summary 706 The following is a summary of the requirements in Section 6: 708 Requirement Necessity Ref. 709 ------------------------------------------------------------------ 710 Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1 711 Client-server communication MUST 6.1.2 712 Support PCC/PCE request message to request path 713 computation MUST 6.1.2 714 Support PCE response message with computed path MUST 6.1.2 715 Support unsolicited communication PCE-PCC SHOULD 6.1.2 716 Maintain PCC-PCE session NON-RQMT 6.1.2 717 Use of existing transport protocol MAY 6.1.3 718 Transport protocol satisfy reliability & security 719 requirements MAY 6.1.3 720 Transport protocol limits size of message MUST NOT 6.1.3 721 Support path computation requests MUST 6.1.4 722 Path computation request includes source & 723 destination MUST 6.1.4 724 Support path constraints (e.g., bandwidth, hops, 725 affinities) to include/exclude MUST 6.1.4 726 Allow to select/prefer from advertised list of 727 standard objective functions/options MUST 6.1.4 728 Allow to customize objective function/options MUST 6.1.4 729 Allow indicating the metric type (IGP or TE) to 730 be used for shortest path selection MUST 6.1.4 731 Allow indicating the set of path attributes 732 required in response message MUST 6.1.4 733 Allow indicating if load-balancing is allowed MUST 6.1.4 734 Support path computation responses MUST 6.1.5 735 Negative response support reasons for failure, 736 constraints to relax to achieve positive result SHOULD 6.1.5 737 Support inclusion of set of path attributes MUST 6.1.5 738 Support inclusion of set of computed paths of a 739 load-balancing path group, as well as their 740 respective bandwidth MUST 6.1.5 741 Cancellation of pending requests MUST 6.1.6 742 Multiple requests and responses MUST 6.1.7 743 Limit by configuration number of requests within 744 a message MUST 6.1.7 745 Support multiple computed paths in response MUST 6.1.7 746 Support "continuation correlation" where related 747 requests or computed paths cannot fit within 748 one message MUST 6.1.7 749 Maximum message size & maximum number of requests 750 per message exchanged through PCE messages to 751 PCC, or indicated in request message MAY 6.1.7 752 Reliable message exchange (achieved by PCECP 753 itself or transport protocol) MUST 6.1.8 754 Allow detection & recovery of lost messages to 755 occur quickly & not impede operation of PCECP MUST 6.1.8 756 Handle overload situations without significant 757 decrease in performance, e.g., through 758 throttling of requests MUST 6.1.8 759 Detect/report lost/corrupted messages, retransmit 760 lost messages, handle out-of-order messages & 761 duplicate messages, provide flow control/ 762 back-pressure to throttle messages, detect 763 PCECP communication failure detection MUST 6.1.8 764 Functionality added to PCECP if transport 765 protocol provides it SHOULD NOT 6.1.8 766 Secure message exchange (provided by PCECP or 767 transport protocol MUST 6.1.9 768 Support mechanisms to prevent spoofing (e.g., 769 authentication), snooping (e.g., encryption), 770 DOS attacks MUST 6.1.9 771 Request prioritization MUST 6.1.10 772 Unsolicited notifications SHOULD 6.1.11 773 Allow asynchronous communication MUST 6.1.12 774 PCC has to wait for response before making 775 another request MUST NOT 6.1.12 776 Allow order of responses differ from order of 777 requests MUST 6.1.12 778 Communication overhead minimization SHOULD 6.1.13 779 Give particular attention to message size SHOULD 6.1.13 780 Extensibility without requiring modifications to 781 protocol MUST 6.1.14 782 Easily extensible to support intra-area, 783 inter-area, inter-AS intra provider, inter-AS 784 inter-provider, multi-layer path & virtual 785 network topology path computation MUST 6.1.14 786 Easily extensible to support future applications 787 not in scope (e.g., point-to-multipoint path 788 computations) SHOULD 6.1.14 789 Scale at least linearly with number of PCCs, 790 PCEs, PCCs communicating with single PCE, PCEs 791 communicated to by single PCC, domains, path 792 requests, handling bursts of requests MUST 6.1.15 793 Support path computation constraints MUST 6.1.16 794 Support "unsynchronized" & "synchronized" 795 objective functions MUST 6.1.17 796 Support different service provider environments 797 (e.g., MPLS-TE and GMPLS networks, centralized 798 & distributed PCE path computation, single & 799 multiple PCE path computation) MUST 6.2.1 800 Policy support for policies to accept/reject 801 requests, PCC to determine reason for 802 rejection, notification of policy violation MUST 6.2.2 803 Aliveness detection of PCCs/PCEs, PCECP failure 804 detection MUST 6.3.1 805 Protocol recovery support resynchronization of 806 information & requests between sender & 807 receiver MUST 6.3.2 808 Minimize repeat data transfer, allow PCE to 809 respond to computation requests issued before 810 failure without requests being re-issued SHOULD 6.3.2 811 Stateful PCE able to resynchronize/recover 812 states (e.g., LSP status, paths) after restart SHOULD 6.3.2 813 Allow indicating if computation is for LSP 814 restoration (support inclusion of previously 815 computed path & failed element) MUST 6.3.3 816 Support path reoptimization & inclusion of a 817 previously computed path MUST 6.3.3 819 7. Security Considerations 821 The impact of the use of a PCECP MUST be considered in the light of 822 the impact that it has on the security of the existing routing and 823 signaling protocols and techniques in use within the network. 824 Intra-domain security is impacted since there is a new interface, 825 protocol and element in the network. Any host in the network could 826 impersonate a PCC, and receive detailed information on network paths. 827 Any host could also impersonate a PCE, both gathering information 828 about the network before passing the request on to a real PCE, and 829 spoofing responses. Some protection here depends on the security of 830 the PCE discovery process (see [PCE-DISC-REQ]). An increase in 831 inter-domain information flows may increase the vulnerability to 832 security attacks, and the facilitation of inter-domain paths may 833 increase the impact of these security attacks. 835 Of particular relevance are the implications for confidentiality 836 inherent in a PCECP for multi-domain networks. It is not necessarily 837 the case that a multi-domain PCE solution will compromise security, 838 but solutions MUST examine their impacts in this area. 840 Applicability statements for particular combinations of signaling, 841 routing and path computation techniques are expected to contain 842 detailed security sections. 844 It should be observed that the use of an external PCE introduces 845 additional security issues. Most notable amongst these are: 847 - interception of PCE requests or responses 848 - impersonation of PCE or PCC 849 - DoS attacks on PCEs or PCCs 851 The PCECP MUST address these issues in detail using authentication, 852 encryption and DoS protection techniques. See also Section 6.1.9. 854 8. Manageability Considerations 856 Manageability of the PCECP MUST address the following considerations: 858 - the need for a MIB module for control and monitoring of PCECP 859 - the need for built-in diagnostic tools to test the operation of the 860 protocol (e.g., partner failure detection, OAM, etc.) 861 - configuration implications for the protocol 863 PCECP operations MUST be modeled and controlled through appropriate 864 MIB modules. Statistics gathering will form an important part of the 865 operation of the PCECP. The operator MUST be able to determine PCECP 866 historical interactions and the success rate of requests using data 867 from MIB modules. Similarly, it is important for an operator to be 868 able to determine PCECP and PCE load and whether an individual PCC is 869 responsible for a disproportionate amount of the load. It MUST be 870 possible, through use of MIB modules, to record and inspect 871 statistics about the PCECP communications, including issues such as 872 malformed messages, unauthorized messages and messages discarded 873 owing to congestion. 875 The new MIB modules should also be used to provide notifications 876 (traps) when thresholds are crossed or when important events occur. 878 PCECP techniques must enable a PCC to determine the liveness of a PCE 879 both before it sends a request and in the period between sending a 880 request and receiving a response. 882 It is also important for a PCE to know about the liveness of PCCs to 883 gain a predictive view of the likely loading of a PCE in the future, 884 and to allow a PCE to abandon processing of a received request. 886 The PCECP MUST support indication of congestion state and rate 887 limitation state, and MAY allow the operator to control such a 888 function. 890 9. IANA Considerations 892 This document makes no requests for IANA action. 894 10. Acknowledgements 896 The authors would like to extend their warmest thanks to (in 897 alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas 898 Morin, Dimitri Papadimitriou, and JP Vasseur for their review and 899 suggestions. 901 11. Normative References 903 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 904 Element (PCE) Architecture", work in progress. 906 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 907 Requirement Levels", BCP 14, RFC 2119, March 1997. 909 12. Informational References 911 [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol 912 (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 913 87, RFC 3785, May 2004. 915 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 916 Computation Element (PCE) Discovery," work in progress. 918 [PCECP-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol 919 (PCECP) specific requirements for Inter-Area (G)MPLS Traffic 920 Engineering," work in progress. 922 [PCECP-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication 923 Requirements for Inter-Layer Traffic Engineering," work in progress. 925 13. Authors' & Contributors' Addresses 927 Jerry Ash (Editor) 928 AT&T 929 Room MT D5-2A01 930 200 Laurel Avenue 931 Middletown, NJ 07748, USA 932 Phone: (732)-420-4578 933 Email: gash@att.com 935 Jean-Louis Le Roux (Editor) 936 France Telecom 937 2, avenue Pierre-Marzin 938 22307 Lannion Cedex, FRANCE 939 Email: jeanlouis.leroux@francetelecom.com 941 Alia K. Atlas 942 Google Inc. 943 1600 Amphitheatre Parkway 944 Mountain View, CA 94043 945 Email: akatlas@alum.mit.edu 947 Arthi Ayyangar 948 Juniper Networks, Inc. 949 1194 N.Mathilda Ave 950 Sunnyvale, CA 94089 USA 951 Email: arthi@juniper.net 953 Nabil Bitar 954 Verizon 955 40 Sylvan Road 956 Waltham, MA 02145 957 Email: nabil.bitar@verizon.com 959 Igor Bryskin 960 Independent Consultant 961 Email: i_bryskin@yahoo.com 963 Dean Cheng 964 Cisco Systems Inc. 965 3700 Cisco Way 966 San Jose CA 95134 USA 967 Phone: 408 527 0677 968 Email: dcheng@cisco.com 970 Durga Gangisetti 971 MCI 972 Email: durga.gangisetti@mci.com 974 Kenji Kumaki 975 KDDI Corporation 976 Garden Air Tower 977 Iidabashi, Chiyoda-ku, 978 Tokyo 102-8460, JAPAN 979 Phone: 3-6678-3103 980 Email: ke-kumaki@kddi.com 982 Eiji Oki 983 NTT 984 Midori-cho 3-9-11 985 Musashino-shi, Tokyo 180-8585, JAPAN 986 Email: oki.eiji@lab.ntt.co.jp 988 Raymond Zhang 989 BT INFONET Services Corporation 990 2160 E. Grand Ave. 991 El Segundo, CA 90245 USA 992 Email: Raymond_zhang@bt.infonet.com 994 Intellectual Property Statement 996 The IETF takes no position regarding the validity or scope of any 997 Intellectual Property Rights or other rights that might be claimed to 998 pertain to the implementation or use of the technology described in 999 this document or the extent to which any license under such rights 1000 might or might not be available; nor does it represent that it has 1001 made any independent effort to identify any such rights. Information 1002 on the procedures with respect to rights in RFC documents can be 1003 found in BCP 78 and BCP 79. 1005 Copies of IPR disclosures made to the IETF Secretariat and any 1006 assurances of licenses to be made available, or the result of an 1007 attempt made to obtain a general license or permission for the use of 1008 such proprietary rights by implementers or users of this 1009 specification can be obtained from the IETF on-line IPR repository at 1010 http://www.ietf.org/ipr. 1012 The IETF invites any interested party to bring to its attention any 1013 copyrights, patents or patent applications, or other proprietary 1014 rights that may cover technology that may be required to implement 1015 this standard. Please address the information to the IETF at 1016 ietf-ipr@ietf.org. 1018 Disclaimer of Validity 1020 This document and the information contained herein are provided on an 1021 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1022 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1023 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1024 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1025 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1026 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1028 Copyright Statement 1030 Copyright (C) The Internet Society (2006). This document is subject 1031 to the rights, licenses and restrictions contained in BCP 78, and 1032 except as set forth therein, the authors retain all their rights.