idnits 2.17.1 draft-ietf-pce-comm-protocol-gen-reqs-07.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 918. ** 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 (June 2006) is 6517 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-ARCH' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft PCE Working Group Jerry Ash (AT&T) 3 Proposed Status: Informational Editor 4 Expires: December 2006 J.L. Le Roux (France Telecom) 5 Editor 7 June 2006 9 draft-ietf-pce-comm-protocol-gen-reqs-07.txt 11 Path Computation Element (PCE) Communication Protocol 12 Generic Requirements 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 23, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The PCE model is described in the "PCE Architecture" document and 46 facilitates path computation requests from Path Computation Clients 47 (PCCs) to Path Computation Elements (PCEs). This document specifies 48 generic requirements for a communication protocol between PCCs and 49 PCEs, and also between PCEs where cooperation between PCEs is 50 desirable. Subsequent documents will specify application-specific 51 requirements for the PCE communication protocol. 53 Table of Contents 55 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . . . 4 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 5 60 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6 61 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 6 62 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 6 63 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 6 64 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 6 66 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 8 67 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 8 68 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 8 69 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 9 70 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 10 71 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 10 72 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 11 73 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 11 74 6.1.13 Communication Overhead Minimization . . . . . . . . . 11 75 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 11 76 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 12 77 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13 78 6.1.17 Objective Functions Supported . . . . . . . . . . . . 13 79 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14 80 6.2.1 Support for Different Service Provider Environments . . 14 81 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14 82 6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . 14 83 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 14 84 6.3.2 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15 85 6.3.3 LSP Rerouting & Reoptimization . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 17 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 17 91 12. Informational References . . . . . . . . . . . . . . . . . . . . 17 92 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 18 94 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 19 95 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Contributors 99 This document is the result of the PCE Working Group PCE 100 Communication Protocol (PCECP) requirements design team joint effort. 101 In addition to the authors/editors listed in Section 13, the 102 following are the design team members who contributed to the 103 document: 105 Alia K. Atlas 106 Google Inc. 107 1600 Amphitheatre Parkway 108 Mountain View, CA 94043 109 Email: akatlas@alum.mit.edu 111 Arthi Ayyangar 112 Juniper Networks, Inc. 113 1194 N.Mathilda Ave 114 Sunnyvale, CA 94089 USA 115 Email: arthi@juniper.net 117 Nabil Bitar 118 Verizon 119 40 Sylvan Road 120 Waltham, MA 02145 121 Email: nabil.bitar@verizon.com 123 Igor Bryskin 124 Independent Consultant 125 Email: i_bryskin@yahoo.com 127 Dean Cheng 128 Cisco Systems Inc. 129 3700 Cisco Way 130 San Jose CA 95134 USA 131 Phone: 408 527 0677 132 Email: dcheng@cisco.com 134 Durga Gangisetti 135 MCI 136 Email: durga.gangisetti@mci.com 138 Kenji Kumaki 139 KDDI Corporation 140 Garden Air Tower 141 Iidabashi, Chiyoda-ku, 142 Tokyo 102-8460, JAPAN 143 Phone: 3-6678-3103 144 Email: ke-kumaki@kddi.com 146 Eiji Oki 147 NTT 148 Midori-cho 3-9-11 149 Musashino-shi, Tokyo 180-8585, JAPAN 150 Email: oki.eiji@lab.ntt.co.jp 152 Raymond Zhang 153 BT INFONET Services Corporation 154 2160 E. Grand Ave. 155 El Segundo, CA 90245 USA 156 Email: Raymond_zhang@bt.infonet.com 158 2. Conventions used in this document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 3. Introduction 166 A Path Computation Element (PCE) [PCE-ARCH] supports requests for 167 path computation issued by a Path Computation Client (PCC), which may 168 be 'composite' (co-located) or 'external' (remote) from a PCE. When 169 the PCC is external from the PCE, a request/response communication 170 protocol is required to carry the path computation request and return 171 the response. In order for the PCC and PCE to communicate, the PCC 172 must know the location of the PCE: PCE discovery is described in 173 [PCE-DISC-REQ]. 175 The PCE operates on a network graph in order to compute paths based 176 on the path computation request(s) issued by the PCC(s). The path 177 computation request will include the source and destination of the 178 paths to be computed, a set of constraints to be applied during the 179 computation, and may also include an objective function. The PCE 180 response includes the computed paths or the reason for a failed 181 computation. 183 This document lists a set of generic requirements for the PCECP. 184 Application-specific requirements are beyond the scope of this 185 document, and will be addressed in separate documents. For example, 186 application-specific communication protocol requirements are given in 187 [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] for inter-area and 188 inter-layer PCE applications, respectively. 190 4. Terminology 192 Domain: any collection of network elements within a common sphere of 193 address management or path computational responsibility. Examples of 194 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 195 within a service provider network, or multiple ASs across multiple 196 service provider networks. 198 GMPLS: Generalized Multi-Protocol Label Switching 200 LSP: MPLS/GMPLS Label Switched Path 202 LSR: Label Switch Router 204 MPLS: Multi-Protocol Label Switching 205 PCC: Path Computation Client: any client application requesting a 206 path computation to be performed by the PCE. 208 PCE: Path Computation Element: an entity (component, application or 209 network node) that is capable of computing a network path or route 210 based on a network graph and applying computational constraints (see 211 further description in [PCE-ARCH]). 213 TED: Traffic Engineering Database, which contains the topology and 214 resource information of the network or network segment used by a PCE. 216 TE LSP: Traffic Engineering (G)MPLS Label Switched Path. 218 See [PCE-ARCH] for further definitions of terms. 220 5. Overview of PCE Communication Protocol (PCECP) 222 In the PCE model, path computation requests are issued by a PCC 223 to a PCE that may be composite (co-located) or external (remote). If 224 the PCC and PCE are not co-located, a request/response communication 225 protocol is required to carry the request and return the response. 226 If the PCC and PCE are co-located, a communication protocol is not 227 required, but implementations may choose to utilize a protocol for 228 exchanges between the components. 230 In order that a PCC and PCE can communicate, the PCC must know the 231 location of the PCE. This can be configured or discovered. The PCE 232 discovery mechanism is out of scope of this document, but 233 requirements are documented in [PCE-DISC-REQ]. 235 The PCE operates on a network graph built from the TED in order to 236 compute paths. The mechanism by which the TED is populated is out of 237 scope for the PCECP. 239 A path computation request issued by the PCC includes a specification 240 of the path(s) needed. The information supplied includes, at a 241 minimum, the source and destination for the paths, but may also 242 include a set of further requirements (known as constraints) as 243 described in Section 6. 245 The response from the PCE may be positive in which case it will 246 include the paths that have been computed. If the computation fails 247 or cannot be performed, a negative response is required with an 248 indication of the type of failure. 250 A request/response protocol is also required for a PCE to communicate 251 path computation requests to another PCE and for that PCE to return 252 the path computation response. As described in [PCE-ARCH], there is 253 no reason to assume that two different protocols are needed, and this 254 document assumes that a single protocol will satisfy all requirements 255 for PCC-PCE and PCE-PCE communication. 257 [PCE-ARCH] describes four models of PCE: composite, external, 258 multiple PCE path computation, and multiple PCE path computation with 259 inter-PCE communication. In all cases except the composite PCE model, 260 a PCECP is required. The requirements defined in this document are 261 applicable to all models described in the [PCE-ARCH]. 263 6. PCE Communication Protocol Generic Requirements 265 6.1 Basic Protocol Requirements 267 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 269 A single protocol MUST be defined for PCC-PCE and PCE-PCE 270 communication. A PCE requesting a path from another PCE can be 271 considered as a PCC, and in the remainder of this document we refer 272 to all communications as PCC-PCE regardless of whether they are 273 PCC-PCE or PCE-PCE. 275 6.1.2 Client-Server Communication 277 PCC-PCE communication is by nature client-server based. The PCECP 278 MUST allow a PCC to send a request message to a PCE to request path 279 computation, and for a PCE to reply with a response message to the 280 requesting PCC once the path has been computed. 282 In addition to this request-response mode, there are cases where 283 there is unsolicited communication from the PCE to the PCC (see 284 Section 6.1.11). 286 6.1.3 Transport 288 The PCECP SHOULD utilize an existing transport protocol that supports 289 congestion control. This transport protocol may also be used to 290 satisfy some requirements in other sections of this document, such as 291 reliability. The PCECP SHOULD be defined for one transport protocol 292 only in order to ensure interoperability. The transport protocol 293 MUST NOT limit the size of the message used by the PCECP. 295 6.1.4 Path Computation Requests 297 The path computation request message MUST include at least the source 298 and destination. Note that the path computation request is for an 299 LSP or LSP segment, and the source and destination supplied are the 300 start and end of the computation being requested (i.e. of the LSP 301 segment). 303 The path computation request message MUST support the inclusion of a 304 set of one or more path constraints, including but not limited to the 305 requested bandwidth or resources (hops, affinities, etc.) to 306 include/exclude. For example, a PCC may request the PCE to exclude 307 points of failure in the computation of a new path if an LSP setup 308 fails. The actual inclusion of constraints is a choice for the PCC 309 issuing the request. A list of core constraints that must be 310 supported by the PCECP is supplied in Section 6.1.16. Specification 311 of constraints MUST be future-proofed as described in Section 6.1.14. 313 The requester MUST be allowed to select or prefer from an advertised 314 list or minimal subset of standard objective functions and functional 315 options. An objective function is used by the PCE to process 316 constraints to a path computation request when it computes a path in 317 order to select the "best" candidate paths (e.g., minimum hop path), 318 and corresponds to the optimization criteria used for the computation 319 of one path, or the synchronized computation of a set of paths. In 320 the case of unsynchronized path computation, this can be, for 321 example, the path cost or the residual bandwidth on the most loaded 322 path link. In the case of synchronized path computation, this can 323 be, for example, the global bandwidth consumption or the residual 324 bandwidth on the most loaded network link. 326 A list of core objective functions that MUST be supported by the 327 PCECP is supplied in Section 6.1.17. Specification of objective 328 functions MUST be future-proofed as described in Section 6.1.14. 330 The requester SHOULD also be able to select a vendor-specific or 331 experimental objective function or functional option. Furthermore, 332 the requester MUST be allowed to customize the function/options in 333 use. That is, individual objective functions will often have 334 parameters to be set in the request from PCC to PCE. Support for the 335 specification of objective functions and objective parameters is 336 required in the protocol extensibility specified in Section 6.1.14. 338 A request message MAY include TE parameters carried by the MPLS/GMPLS 339 LSP setup signaling protocol. Also, it MUST be possible for the PCE 340 to apply additional objective functions. This might include policy 341 based routing path computation for load balancing instructed by the 342 management plane. 344 Shortest path selection may rely either on the TE metric or on the 345 IGP metric [METRIC]. Hence the PCECP request message MUST allow the 346 PCC to indicate the metric type (IGP or TE) to be used for shortest 347 path selection. Note that other metric types may be specified in the 348 future. 350 There may be cases where a single path cannot fit a given bandwidth 351 request, while a set of paths could be combined to fit the request. 352 Such path combination to serve a given request is called 353 load-balancing. The request message MUST allow the PCC to indicate if 354 load-balancing is allowed or not. It MUST also include the maximum 355 number of paths in a load-balancing path group, and the minimum path 356 bandwidth in a load-balancing path group. The request message MUST 357 allow specification of the degree of disjointness of the members of 358 the load-balancing group. 360 6.1.5 Path Computation Responses 362 The path computation response message MUST allow the PCE to return 363 various elements including, at least, the computed path(s). 365 The protocol MUST be capable of returning any explicit path that 366 would be acceptable for use for MPLS and GMPLS LSPs once converted to 367 an Explicit Route Object for use in RSVP-TE signaling. In addition, 368 anything that can be expressed in an Explicit Route Object MUST be 369 capable of being returned in the computed path. Note that the 370 resultant path(s) may be made up of a set of strict or loose hops, or 371 any combination of strict and loose hops. Moreover, a hop may have 372 the form of a non-simple abstract node. See [RFC3209] for the 373 definition of strict hop, loose hop, and abstract node. 375 A positive response from the PCE MUST include the paths that have 376 been computed. A positive PCECP computation response MUST support 377 the inclusion of a set of attributes of the computed path, such as 378 the path costs (e.g., cumulative link TE metrics and cumulative link 379 IGP metrics) and the computed bandwidth. The latter is useful when a 380 single path cannot serve the requested bandwidth and load balancing 381 is applied. 383 When a path satisfying the constraints cannot be found, or if the 384 computation fails or cannot be performed, a negative response MUST be 385 sent. This response MAY include further details of the reason(s) for 386 the failure, and MAY include advice about which constraints might be 387 relaxed to be more likely to achieve a positive result. 389 The PCECP response message MUST support the inclusion of the set of 390 computed paths of a load-balancing path group, as well as their 391 respective bandwidths. 393 6.1.6 Cancellation of Pending Requests 395 A PCC MUST be able to cancel a pending request using an appropriate 396 message. A PCC that has sent a request to a PCE and no longer needs 397 a response, for instance because it no longer wants to set up the 398 associated service, MUST be able to notify the PCE that it can clear 399 the request (i.e. stop the computation if already started, and clear 400 the context). The PCE may also wish to cancel a pending request 401 because of some congested state. 403 6.1.7 Multiple Requests and Responses 405 It MUST be possible to send multiple path computation requests 406 within the same request message. Such requests may be correlated (for 407 example, requesting disjoint paths) or uncorrelated (requesting paths 408 for unrelated services). It MUST be possible to limit by 409 configuration of both PCCs and PCEs the number of requests that can 410 be carried within a single message. 412 Similarly, it MUST be possible to return multiple computed paths 413 within the same response message, corresponding either to the same 414 request (e.g. multiple suited paths, paths of a load balancing path 415 group) or to distinct requests, correlated or not, of the same 416 request message or distinct request messages. 418 It MUST be possible to provide "continuation correlation" where all 419 related requests or computed paths cannot fit within one message, and 420 are carried in a sequence of correlated messages. 422 The PCE MUST inform the PCC of its capabilities. Maximum acceptable 423 message sizes and the maximum number of requests per message 424 supported by a PCE MAY form part of PCE capabilities advertisement 425 [PCE-DISC-REQ], or MAY be exchanged through information messages from 426 the PCE as part of the protocol described here. 428 It MUST be possible for a PCC to specify, in the request message, the 429 maximum acceptable response message sizes and the maximum number of 430 computed paths per response message it can support. 432 It MUST be possible to limit the message size by configuration on 433 PCCs and PCEs. 435 6.1.8 Reliable Message Exchange 437 The PCECP MUST support reliable transmission of PCECP packets. This 438 may form part of the protocol itself or may be achieved by the 439 selection of a suitable transport protocol (see Section 6.1.3). 441 In particular, it MUST allow for the detection and recovery of lost 442 messages to occur quickly and not impede the operation of the PCECP. 444 In some cases (e.g. after link failure), a large number of PCCs may 445 simultaneously send requests to a PCE, leading to a potential 446 saturation of the PCEs. The PCECP MUST support indication of 447 congestion state and rate limitation state. This should enable, for 448 example, a PCE to limit the rate of incoming request messages if the 449 request rate is too high. 451 The PCECP or its transport protocol MUST provide: 453 - Detection and report of lost or corrupted messages 454 - Automatic attempts to retransmit lost messages without reference to 455 the application 456 - Handling of out-of-order messages 457 - Handling of duplicate messages 458 - Flow control and back-pressure to enable throttling of requests and 459 responses 460 - Rapid PCECP communication failure detection 461 - Distinction between partner failure and communication channel 462 failure after the PCECP communication is recovered 464 If it is necessary to add functions to PCECP to overcome shortcomings 465 in the chosen transport mechanisms, these functions SHOULD be based 466 on and re-use where possible techniques developed in other protocols 467 to overcome the same shortcomings. Functionality MUST NOT be added 468 to the PCECP where the chosen transport protocol already provides it. 470 6.1.9 Secure Message Exchange 472 The PCC-PCE communication protocol MUST include provisions to ensure 473 the security of the exchanges between the entities. In particular, 474 it MUST support mechanisms to prevent spoofing (e.g., 475 authentication), snooping (e.g., preservation of confidentiality of 476 information through techniques such as encryption) and DOS attacks 477 (e.g., packet filtering, rate limiting, no promiscuous listening). 478 Once a PCC is identified and authenticated, it has the same 479 privileges as all other PCCs. 481 To ensure confidentiality, the PCECP SHOULD allow local policy to be 482 configured on the PCE to not provide explicit path(s). If a PCC 483 requests an explicit path when this is not allowed, the PCE MUST 484 return an error message to the requesting PCC and the pending path 485 computation request MUST be discarded. 487 Authorization requirements [RFC3127] include reject capability, 488 reauthorization on demand, support for access rules and filters, and 489 unsolicited disconnect. 491 Where the PCE-PCC communication takes place entirely within one 492 limited domain, the use of a private address space which is not 493 available to customer systems MAY be used to help protect the 494 information exchange, but other mechanisms MUST also be available. 496 These functions may be provided by the transport protocol or directly 497 by the PCECP. See Section 7 for further discussion of security 498 considerations. 500 6.1.10 Request Prioritization 502 The PCECP MUST allow a PCC to specify the priority of a computation 503 request. 505 Implementation of priority-based activity within a PCE is subject to 506 implementation and local policy. This application processing is out 507 of scope of the PCECP. 509 6.1.11 Unsolicited Notifications 511 The normal operational mode is for the PCC to make path computation 512 requests to the PCE, and for the PCE to respond. 514 The PCECP MUST support unsolicited notifications from PCE to PCC, or 515 PCC to PCE. This requirement facilitates the unsolicited 516 communication of information and alerts between PCCs and PCEs. As 517 specified in Section 6.1.8, these notification messages must be 518 supported by a reliable transmission protocol. The PCECP MAY also 519 support response messages to the unsolicited notification messages. 521 6.1.12 Asynchronous Communication 523 The PCC-PCE protocol MUST allow for asynchronous communication. A 524 PCC MUST NOT have to wait for a response to one request before it can 525 make another request. 527 It MUST also be possible to have the order of responses differ from 528 the order of the corresponding requests. This may occur, for 529 instance, when path request messages have different priorities (see 530 Requirement 6.1.10). A consequent requirement is that path 531 computation responses MUST include a direct correlation to the 532 associated request. 534 6.1.13 Communication Overhead Minimization 536 The request and response messages SHOULD be designed so that the 537 communication overhead is minimized. In particular, the overhead per 538 message SHOULD be minimized, and the number of bytes exchanged to 539 arrive at a computation answer SHOULD be minimized. Other 540 considerations in overhead minimization include the following: 542 - the number of background messages used by the protocol or its 543 transport protocol to keep alive any session or association 544 between the PCE and PCC 545 - the processing cost at the PCE (or PCC) associated with 546 request/response messages (as distinct from processing the 547 computation requests themselves). 549 6.1.14 Extensibility 551 The PCECP MUST provide a way for the introduction of new path 552 computation constraints, diversity types, objective functions, 553 optimization methods and parameters, etc., without requiring 554 major modifications in the protocol. 556 For example, the PCECP MUST be extensible to support various PCE 557 based applications, such as the following: 559 - intra-area path computation 560 - inter-area path computation [PCECP-INTER-AREA] 561 - inter-AS intra provider and inter-AS inter-provider path 562 computation 563 - inter-layer path computation [PCECP-INTER-LAYER] 565 The PCECP MUST support the requirements specified in the 566 application-specific requirements documents. The PCECP MUST also 567 allow extensions as more PCE applications will be introduced in the 568 future. 570 The PCECP SHOULD also be extensible to support future applications 571 not currently in the scope of the PCE working group, such as, for 572 instance, point-to-multipoint path computations, multi-hop pseudowire 573 path computation, etc. 575 Note that application specific requirements are out of the scope of 576 this document and will be addressed in separate requirements 577 documents. 579 6.1.15 Scalability 581 The PCECP MUST scale well, at least as good as linearly, with an 582 increase of any of the following parameters. Minimum order of 583 magnitude estimates of what the PCECP should support are given in 584 parenthesis (note: these are requirements on the PCECP, not a PCE): 586 - number of PCCs (1000/domain) 587 - number of PCEs (100/domain) 588 - number of PCCs communicating with a single PCE (1000) 589 - number of PCEs communicated to by a single PCC (100) 590 - number of domains (20) 591 - number of path request messages (average of 10/second/PCE) 592 - handling bursts of requests (burst of 100/second/PCE within a 10- 593 second interval). 595 Note that path requests can be bundled in path request messages, for 596 example, 10 PCECP request messages/second may correspond to 100 path 597 requests/second. 599 Bursts of requests may arise, for example, after a network outage 600 when multiple recomputations are requested. The PCECP MUST handle 601 the congestion in a graceful way so that it does not unduly impact 602 the rest of the network, and so that it does not gate the ability of 603 the PCE to perform computation. 605 6.1.16 Constraints 607 This section provides a list of generic constraints that MUST be 608 supported by the PCECP. Other constraints may be added to service 609 specific applications as identified by separate application-specific 610 requirements documents. Note that the provisions of Section 6.1.14 611 mean that new constraints can be added to this list without impacting 612 the protocol to a level that requires major protocol changes. 614 The set of supported generic constraints MUST include at the least 615 The following: 617 o MPLS-TE and GMPLS generic constraints: 618 - Bandwidth 619 - Affinities inclusion/exclusion 620 - Link, Node, SRLG inclusion/exclusion 621 - Maximum end-to-end IGP metric 622 - Maximum Hop Count 623 - Maximum end-to-end TE metric 624 - Degree of paths disjointness (Link, Node, SRLG) 626 o MPLS-TE specific constraints 627 - Class-type 628 - Local protection 629 - Node protection 630 - Bandwidth protection 632 o GMPLS specific constraints 633 - Switching type, encoding type 634 - Link protection type 636 6.1.17 Objective Functions Supported 638 This section provides a list of generic objective functions that MUST 639 be supported by the PCECP. Other objectives functions MAY be added 640 to service specific applications as identified by separate 641 application-specific requirements documents. Note that the 642 provisions of Section 6.1.14 mean that new objective functions MAY be 643 added to this list without impacting the protocol. 645 The PCECP MUST support at least the following "unsynchronized" 646 functions: 648 - Minimum cost path with respect to a specified metric(shortest path) 649 - Least loaded path 650 - Maximum available bandwidth path 652 Also the PCECP MUST support at least the following "synchronized" 653 objective functions: 655 - Minimize aggregate bandwidth consumption on all links 656 - Maximize the residual bandwidth on the most loaded link 657 - Minimize the cumulative cost of a set of diverse paths. 659 6.2 Deployment Support Requirements 661 6.2.1 Support for Different Service Provider Environments 663 The PCECP must at least support the following environments: 665 - MPLS-TE and GMPLS networks 666 - packet and non-packet networks 667 - centralized and distributed PCE path computation 668 - single and multiple PCE path computation 670 For example, PCECP is possibly applicable to packet networks (e.g., 671 IP networks), non-packet networks (e.g., TDM transport), and perhaps 672 to multi-layer GMPLS control plane environments. Definitions of 673 centralized, distributed, single, and multiple PCE path computation 674 can be found in [PCE-ARCH]. 676 6.2.2 Policy Support 678 The PCECP MUST allow for the use of policies to accept/reject 679 requests. It MUST include the ability for a PCE to supply sufficient 680 detail when it rejects a request for policy reasons to allow the PCC 681 to determine the reason for rejection or failure. For example, 682 filtering could be required for a PCE that serves one domain (perhaps 683 an AS) such that all requests that come from another domain (AS) are 684 rejected. However, specific policy details are left to 685 application-specific PCECP requirements. Actual policies, 686 configuration of policies, and applicability of policies are out of 687 scope. 689 Note that work on supported policy models and the corresponding 690 requirements/implications is being undertaken as a separate work item 691 in the PCE working group. 693 PCECP messages MUST be able to carry transparent policy information. 695 6.3 Aliveness Detection & Recovery Requirements 697 6.3.1 Aliveness Detection 699 The PCECP MUST allow a PCC to 701 - check the liveliness of the PCC-PCE communication 702 - rapidly detect PCC-PCE communication failure (indifferently to 703 partner failure or connectivity failure), 704 - distinguish PCC/PCE node failures from PCC-PCE connectivity 705 failures, after the PCC-PCE communication is recovered. 707 The aliveness detection mechanism MUST ensure reciprocal knowledge of 708 PCE and PCC liveness. 710 6.3.2 Protocol Recovery 712 In the event of the failure of a sender or of the communication 713 channel, the PCECP, upon recovery, MUST support resynchronization of 714 information (e.g. PCE congestion status) and requests between the 715 sender and the receiver, and this SHOULD be arranged so as to 716 minimize repeat data transfer. 718 6.3.3 LSP Rerouting & Reoptimization 720 If an LSP fails owing to the failure of a link or node that it 721 traverses, a new computation request may be made to a PCE in order to 722 repair the LSP. Since the PCC cannot know that the PCE's TED has been 723 updated to reflect the failure network information, it is useful to 724 include this information in the new path computation request. Also, 725 in order to re-use the resources used by the old LSP, it may be 726 advantageous to indicate the route of the old LSP as part of the new 727 path computation request. 729 Hence the path computation request message MUST allow an indication 730 of whether the computation is for LSP restoration, and MUST support 731 the inclusion of the previously computed path as well as the identity 732 of the failed element. Note that the old path might only be useful 733 if the old LSP has not yet been torn down. The PCE MAY or MAY not 734 take into account failure indication carried in a given request when 735 handling subsequent requests. This should be driven by local policy 736 decision. 738 IP addresses are used to identify PCCs and PCEs. However, as noted 739 in Section 6.1.9, a private address space MAY be used if the PCE-PCC 740 communication takes place entirely within one limited domain. 742 Note that a network failure may impact a large number of LSPs. In 743 this case, a potentially large number of PCCs will simultaneously 744 send requests to the PCE. The PCECP MUST properly handle such 745 overload situations, such as for instance through throttling of 746 requests as set forth in section 6.1.8. 748 The path computation request message MUST support TE LSP path 749 reoptimization and the inclusion of a previously computed path. This 750 will help ensure optimal routing of a reoptimized path, since it will 751 allow the PCE to avoid double bandwidth accounting and help reduce 752 blocking issues. 754 7. Security Considerations 756 Key management MUST be provided by the PCECP to provide for the 757 authenticity and integrity of PCECP messages. This will allow 758 protecting against PCE or PCC impersonation and also against message 759 content falsification. 761 The impact of the use of a PCECP MUST be considered in the light of 762 the impact that it has on the security of the existing routing and 763 signaling protocols and techniques in use within the network. 764 Intra-domain security is impacted since there is a new interface, 765 protocol and element in the network. Any host in the network could 766 impersonate a PCC, and receive detailed information on network paths. 767 Any host could also impersonate a PCE, both gathering information 768 about the network before passing the request on to a real PCE, and 769 spoofing responses. Some protection here depends on the security of 770 the PCE discovery process (see [PCE-DISC-REQ]). An increase in 771 inter-domain information flows may increase the vulnerability to 772 security attacks, and the facilitation of inter-domain paths may 773 increase the impact of these security attacks. 775 Of particular relevance are the implications for confidentiality 776 inherent in a PCECP for multi-domain networks. It is not necessarily 777 the case that a multi-domain PCE solution will compromise security, 778 but solutions MUST examine their impacts in this area. 780 Applicability statements for particular combinations of signaling, 781 routing and path computation techniques are expected to contain 782 detailed security sections. 784 It should be observed that the use of an external PCE introduces 785 additional security issues. Most notable amongst these are: 787 - interception of PCE requests or responses 788 - impersonation of PCE or PCC 789 - DoS attacks on PCEs or PCCs 791 The PCECP MUST address these issues in detail using authentication, 792 encryption and DoS protection techniques. See also Section 6.1.9. 794 There are security implications of allowing arbitrary objective 795 functions, as discussed in Section 6.1.17, and the PCECP MUST allow 796 mitigating the risk of, for example, a PCC using complex objectives 797 to intentionally drive a PCE into resource exhaustion. 799 8. Manageability Considerations 801 Manageability of the PCECP MUST address the following considerations: 803 - the need for a MIB module for control and monitoring of PCECP 804 - the need for built-in diagnostic tools to test the operation of the 805 protocol (e.g., partner failure detection, OAM, etc.) 806 - configuration implications for the protocol 808 PCECP operations MUST be modeled and controlled through appropriate 809 MIB modules. There are enough specific differences between PCCs and 810 PCEs to lead to the need of defining separate MIB modules. 811 Statistics gathering will form an important part of the operation of 812 the PCECP. The MIB modules MUST provide information that will allow 813 an operator to determine PCECP historical interactions and the 814 success rate of requests. Similarly, it is important for an operator 815 to be able to determine PCECP and PCE load and whether an individual 816 PCC is responsible for a disproportionate amount of the load. It 817 MUST be possible, through use of MIB modules, to record and inspect 818 statistics about the PCECP communications, including issues such as 819 malformed messages, unauthorized messages and messages discarded 820 owing to congestion. 822 The new MIB modules should also be used to provide notifications 823 (traps) when thresholds are crossed or when important events occur. 824 For example, the MIB module may support indication of exceeding the 825 congestion state threshold or rate limitation state. 827 PCECP techniques must enable a PCC to determine the liveness of a PCE 828 both before it sends a request and in the period between sending a 829 request and receiving a response. 831 It is also important for a PCE to know about the liveness of PCCs to 832 gain a predictive view of the likely loading of a PCE in the future, 833 and to allow a PCE to abandon processing of a received request. 835 The PCECP MUST support indication of congestion state and rate 836 limitation state, and MAY allow the operator to control such a 837 function. 839 9. IANA Considerations 841 This document makes no requests for IANA action. 843 10. Acknowledgements 845 The authors would like to extend their warmest thanks to (in 846 alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas 847 Morin, Dimitri Papadimitriou, Robert Sparks, and JP Vasseur for their 848 review and suggestions. 850 11. Normative References 852 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 853 Element (PCE) Architecture", work in progress. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 12. Informational References 860 [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol 861 (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 862 87, RFC 3785, May 2004. 864 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 865 Computation Element (PCE) Discovery," work in progress. 867 [PCECP-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol 868 (PCECP) specific requirements for Inter-Area (G)MPLS Traffic 869 Engineering," work in progress. 871 [PCECP-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication 872 Requirements for Inter-Layer Traffic Engineering," work in progress. 874 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 875 Tunnels," RFC 3209, December 2001. 877 [RFC3127] Mitton, D., et. al., "Authentication, Authorization, and 878 Accounting: Protocol Evaluation," RFC 3127, June 2001. 880 13. Authors' Addresses 882 Jerry Ash (Editor) 883 AT&T 884 Room MT D5-2A01 885 200 Laurel Avenue 886 Middletown, NJ 07748, USA 887 Phone: (732)-420-4578 888 Email: gash@att.com 890 Jean-Louis Le Roux (Editor) 891 France Telecom 892 2, avenue Pierre-Marzin 893 22307 Lannion Cedex, FRANCE 894 Email: jeanlouis.leroux@francetelecom.com 896 Intellectual Property Statement 898 The IETF takes no position regarding the validity or scope of any 899 Intellectual Property Rights or other rights that might be claimed to 900 pertain to the implementation or use of the technology described in 901 this document or the extent to which any license under such rights 902 might or might not be available; nor does it represent that it has 903 made any independent effort to identify any such rights. Information 904 on the procedures with respect to rights in RFC documents can be 905 found in BCP 78 and BCP 79. 907 Copies of IPR disclosures made to the IETF Secretariat and any 908 assurances of licenses to be made available, or the result of an 909 attempt made to obtain a general license or permission for the use of 910 such proprietary rights by implementers or users of this 911 specification can be obtained from the IETF on-line IPR repository at 912 http://www.ietf.org/ipr. 914 The IETF invites any interested party to bring to its attention any 915 copyrights, patents or patent applications, or other proprietary 916 rights that may cover technology that may be required to implement 917 this standard. Please address the information to the IETF at 918 ietf-ipr@ietf.org. 920 Disclaimer of Validity 922 This document and the information contained herein are provided on an 923 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 924 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 925 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 926 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 927 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 928 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 930 Copyright Statement 932 Copyright (C) The Internet Society (2006). This document is subject 933 to the rights, licenses and restrictions contained in BCP 78, and 934 except as set forth therein, the authors retain all their rights.