idnits 2.17.1 draft-ash-pce-comm-protocol-gen-reqs-01.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 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 707. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines 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 2005) is 6918 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) == Unused Reference: 'RFC3667' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 613, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-ARCH' ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 6 errors (**), 0 flaws (~~), 6 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: November 2005 J.L. Le Roux (France Telecom) 4 Editor 6 May 2005 8 draft-ash-pce-comm-protocol-gen-reqs-01.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 November 26, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 Constraint-based path computation is a fundamental building block for 44 traffic engineering systems such as multiprotocol label switching 45 (MPLS) and generalized multiprotocol label switching (GMPLS) 46 networks. Path computation in large, multi-domain or multi-layer 47 networks is highly complex and may require special computational 48 components and cooperation between the different network domains. 50 There are multiple components in the Path Computation Element (PCE)- 51 based path computation model, including PCE discovery and the PCE 52 communication protocol. The PCE model is described in the "PCE 53 Architecture" document and facilitates path computation requests from 54 Path Computation Clients (PCCs) to PCEs. This document specifies 55 generic requirements for a communication protocol between PCCs and 56 PCEs, and between PCEs where cooperation between PCEs is desirable. 57 Subsequent documents will specify application-specific requirements 58 for the PCE communication protocol. 60 Table of Contents 62 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 64 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Overview of PCE Communication Protocol . . . . . . . . . . . . . 4 67 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 68 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5 69 6.1.1 Client-Server Communication . . . . . . . . . . . . . . 6 70 6.1.2 PCC-PCE and PCE-PCE Communication . . . . . . . . . . . 7 71 6.1.3 Reliable Message Exchange . . . . . . . . . . . . . . . 7 72 6.1.4 Secure Message Exchange . . . . . . . . . . . . . . . . 8 73 6.1.5 Request Prioritization . . . . . . . . . . . . . . . . 8 74 6.1.6 Unsolicited Notifications . . . . . . . . . . . . . . . 8 75 6.1.7 Asynchronous Communication . . . . . . . . . . . . . . 8 76 6.1.8 Communication Overhead Minimization . . . . . . . . . . 9 77 6.1.9 Extensibility . . . . . . . . . . . . . . . . . . . . . 9 78 6.1.10 Scalability . . . . . . . . . . . . . . . . . . . . . 9 79 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 10 80 6.2.1 Support for Various Service Provider Environments and 81 Applications . . . . . . . . . . . . . . . . . . . . . 10 82 6.2.2 Confidentiality . . . . . . . . . . . . . . . . . . . . 10 83 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 10 84 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 10 85 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 10 86 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 11 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 11 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 91 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 12 92 12. Informational References . . . . . . . . . . . . . . . . . . . . 13 93 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 14. Intellectual Property Considerations . . . . . . . . . . . . . . 14 95 1. Contributors 97 This document is the result of the PCE Working Group PCE 98 communication protocol requirements design team joint effort. The 99 following are the design team member authors that contributed to the 100 present document: 102 Jerry Ash (AT&T) 103 Alia Atlas (Avici) 104 Arthi Ayyangar (Juniper) 105 Nabil Bitar (Verizon) 106 Igor Bryskin (Independent Consultant) 107 Dean Cheng (Cisco) 108 Durga Gangisetti (MCI) 109 Kenji Kumaki (KDDI) 110 Jean-Louis Le Roux (France Telecom) 111 Eiji Oki (NTT) 112 Raymond Zhang (BT Infonet) 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 3. Introduction 122 The path computation element (PCE) capability [PCE-ARCH] supports 123 requests for path computation issued by a path computation client 124 (PCC), which may be co-located or remote from a PCE. When the PCC is 125 remote from the PCE, a request/response communications protocol is 126 required to carry the path computation request and return the 127 response. In order for the PCC and PCE to communicate, the PCC must 128 discover the location of the PCE, as described in [PCE-DISC-REQ]. 129 The PCE operates on a network graph in order to compute paths based 130 on the path computation request issued by the PCC, which will 131 normally include the source, destination, and a set of constraints. 132 The PCE response includes the computed paths or the reason for a 133 failed computation. 135 This document lists a set of generic requirements for the PCE 136 communication protocol, where the PCE communications protocol 137 solution MUST satisfy these requirements. Application-specific 138 requirements are beyond the scope of this document, and will be 139 addressed in separate documents. 141 4. Terminology 143 Domain: any collection of network elements within a common sphere of 144 address management or path computational responsibility. Examples of 145 domains include IGP areas, Autonomous Systems (ASs), multiple ASs 146 within a service provider network, or multiple ASs across multiple 147 service provider networks. 149 GMPLS: generalized multiprotocol label switching 151 LSP: MPLS Label Switched Path. 153 MPLS: multiprotocol label switching 155 PCC: Path Computation Client: any client application requesting a 156 Path computation to be performed by the PCE. 158 PCE: Path Computation Element: an entity (component, application or 159 network node) that is capable of computing a network path or route 160 based on a network graph and applying computational constraints (see 161 further description in [PCE-ARCH]). 163 TED: Traffic Engineering Database, which contains the topology and 164 resource information of the network or network segment used by a PCE. 166 TE LSP: Traffic Engineering MPLS Label Switched Path. 168 See [PCE-ARCH] for further definitions of terms. 170 5. Overview of PCE Communication Protocol 172 In the PCE model, path computation requests are issued by a PCC 173 to a PCE that may be co-located or situated at a remote site. If 174 the PCC and PCE are not co-located a request/response communications 175 protocol is required to carry the request and return the response. If 176 the PCC and PCE are co-located a communications protocol is not 177 required, but implementations may choose to utilize a protocol for 178 exchanges between the components. 180 In order that a PCC and PCE can communicate, the PCC must know the 181 location of the PCE. This can be configured or discovered. The PCE 182 discovery mechanism is out of scope of this document, but 183 requirements are documented in [PCE-DISC-REQ]. 185 The PCE operates on a network graph built from the TED in order to 186 compute paths. The mechanism by which the TED is populated is out of 187 scope for the PCE Communications Protocol. 189 A path computation request issued by the PCC will include a 190 specification of the path(s) needed. The information supplied will 191 include at a minimum the source and destination for the path(s), but 192 may also include a set of further requirements (known as constraints) 193 as described in Section 6. 195 The response from the PCE may be positive in which case it will 196 include the paths that have been computed. If the computation fails 197 or cannot be performed, a negative response is required with an 198 indication of the type of and reason(s) for the failure. A negative 199 response may also include further details of the reason(s) for the 200 failure, and potentially advice about which constraints might be 201 relaxed to be more likely to achieve a positive result. That is, the 202 PCE SHOULD provide sufficient information for the PCC to know whether 203 it has to relax constraints or query another PCE. 205 A request/response protocol is also required for a PCE to communicate 206 path computation requests to another PCE and for the PCE to return 207 the path computation response. As described in [PCE-ARCH], there is 208 no reason to assume that two different protocols are needed, and this 209 document assumes that a single protocol will satisfy all requirements 210 for PCC-PCE and PCE-PCE communications. 212 [PCE-ARCH] describes four models of PCE: composite, external, 213 multiple PCE path computation and multiple PCE path computation with 214 inter-PCE communication. In all cases except the composite PCE 215 model, a communication protocol is required. The requirements 216 defined in this document therefore are applicable to all models 217 described in the [PCE-ARCH] except the composite PCE model. 219 6. PCE Communication Protocol Generic Requirements 221 The designers of a PCE communication protocol MUST take the 222 requirements set out in this document and discuss them widely within 223 the IETF and particularly within the Applications Area to determine 224 whether a suitable protocol already exists. The results of this 225 investigation MUST be published on the PCE mailing list. 227 6.1 Basic Protocol Requirements 229 6.1.1 Client-Server Communication 231 PCC-PCE and PCE-PCE communication is by nature client-server based. 232 The communication protocol MUST allow for a PCC or a PCE to send a 233 path request message to a PCE, and for a PCE to reply with a path 234 response message to the requesting PCC or PCE, once the path has been 235 computed. In addition to this request-response model, there may be 236 cases where there is unsolicited communication from the PCE to PCC 237 (see Requirement 6.1.6). 239 The protocol MUST be capable of returning any explicit path that 240 would be acceptable for use for MPLS and GMPLS LSPs once converted to 241 an Explicit Route Object for use in RSVP-TE signaling. Note that the 242 resultant path(s) may be made up of a set of strict or loose hops, or 243 any combination of strict and loose hops. Moreover, a hop may have 244 the form of a non-explicit abstract node. See RFC 3209 for the 245 definition of strict hop, loose hop, and abstract node. 247 It MUST be possible to send multiple path computation requests, 248 correlated or not, within the same path request message. There are 249 various motivations for doing so (optimality, path diversity, etc.). 251 It MUST be possible to limit by configuration the number of requests 252 that can be carried within a single message. The transport protocol 253 MUST allow sending unlimited size messages, but MUST be able to limit 254 message size, to avoid a big message from unduly delaying a small 255 message. Maximum message size MAY be negotiated at session 256 initialization. If the number of correlated requests exceeds the 257 maximum message size, then separate messages MAY be sent with an 258 indication that they are correlated. 260 The path request message MUST include, at least, a source and a 261 destination, and MAY include a set of one or more path constraints, 262 such as the requested bandwidth or resources (hops, affinities, etc.) 263 to include/exclude (e.g., a PCC requests the PCE to exclude points of 264 failure in the computation of the new path if an LSP setup fails). 266 The path request message MUST support the ability to prefer/customize 267 various path computation objective functions, policies and 268 optimization criteria. For example, a PCC may be aware of and would 269 like to choose from among various objective functions that a PCE may 270 offer, and the PCE communication protocol SHOULD allow this to be 271 specified per path computation request. This capability to prefer 272 certain objective functions depends on the fact that the PCE 273 advertises this to a PCC or that the PCC requests one of a set of 274 objective functions defined as a minimal subset that MUST be 275 supported by any PCE. 277 The requester MUST be allowed to select from the advertised list or 278 minimal subset of standard objective functions and functional 279 options. The requester SHOULD also be able to select a 280 vendor-specific or experimental objective function or functional 281 option. Furthermore, the requester MUST be allowed to customize the 282 objective function/options in use. That is, individual objective 283 functions will often have parameters to be set in the request from 284 PCC to PCE. Specification of objective functions and objective 285 function parameters is required in the protocol extensibility 286 specified in Section 6.1.9. 288 If a PCC selects an objective function that the PCE does not support, 289 the PCE response MUST be negative. 291 Note that a PCC MAY send a request that is based on the set of TE 292 parameters carried by the MPLS/GMPLS LSP setup signaling protocol, 293 and as long as those parameters are satisfied, the PCC MAY not care 294 about which objective function is used. Also, the PCE MAY execute 295 objective functions not advertised to the PCC, for example, policy 296 based routing path computation for load balancing instructed by the 297 management plane. 299 A PCC or PCE MUST be able to cancel a pending request. 301 The path response message MUST allow returning various elements 302 including, at least, the computed path. It MUST be possible to 303 return multiple paths within the same path response message, 304 corresponding either to the same request (e.g. load balancing) or to 305 distinct requests of the same path request message or distinct path 306 request messages. 308 6.1.2 PCC-PCE and PCE-PCE Communication 310 A single protocol MUST be defined for PCC-PCE and PCE-PCE 311 communication. A PCE requesting a path from another PCE can be 312 considered as a PCC. 314 6.1.3 Reliable Message Exchange 316 The PCE communication protocol MUST run on top of a reliable 317 transport protocol. In particular, it MUST allow for the detection 318 and recovery of lost messages to occur quickly and not impede the 319 operation of the communication protocol. Here the PCE communication 320 protocol includes a number of application-specific capabilities, all 321 of which run on top of a common, reliable transport protocol layer. 323 In some particular cases (e.g. link failure), a large number of PCCs 324 may simultaneously send a request to a PCE, leading potentially to a 325 saturation of request buffers on PCEs. The PCE communication 326 protocol MUST properly handle such overload situations without a 327 significant decrease in performance, such as through throttling of 328 such requests. 330 The PCE communication-protocol transport MUST provide: 332 - acknowledged message delivery with retransmission, as discussed in 333 Section 6.1.1 334 - in order message delivery. For the set of requests between a given 335 PCC and a PCE, the ordering is already there relying on the 336 reliable transport layer. For requests between a set of PCCs and a 337 given PCE, the ordering of responses SHOULD be based on the PCE's 338 own handling policy, as well as the priority of the requests. 339 - message corruption detection 340 - flow control and back-pressure, as specified above with the 341 throttling of requests. 343 These requirements SHOULD be satisfied by an existing reliable 344 transport protocol, and functionality SHOULD only be added where the 345 transport protocol does not provide it (e.g., rapid partner failure 346 detection). With regard to the rapid partner failure detection, the 347 PCC MUST be informed of any failed PCE (or PCE connection) when it 348 happens. 350 6.1.4 Secure Message Exchange 352 The PCC-PCE and PCE-PCE communication MUST be secure. In particular, 353 it MUST support mechanisms to prevent spoofing (e.g., 354 authentication), snooping (e.g., encryption) and DOS attacks. 356 6.1.5 Request Prioritization 358 The communication protocol MUST support the notion of request 359 priority, allowing a PCC to specify the degree of urgency of a 360 particular request. This is used to serve some requests before 361 others, and would require global prioritization. That is, a request 362 from one PCC can have a higher priority than a request from another 363 PCC to the same PCE. However, there is no intention or need for a 364 PCE to preempt (i.e., discard) a given request from one PCC if it 365 receives a higher-priority request from another PCC; the PCE just 366 delays the lower-priority request. 368 If, for example, the PCE is processing a low priority request that 369 will take extended computation time (e.g., for full re-optimization 370 of 1000 protected LSPs through a complex algorithm), it is 371 RECOMMENDED that the low priority request to set up a new LSP be 372 suspended/interrupted until the high priority request can be 373 completed. The PCE must consider, however, in addition to the 374 priority of the path computations, the PCE policy based on its system 375 resources, configurations, etc. That is, the handling of priority on 376 the PCE is not entirely in the purview of the PCE communication 377 protocol design. 379 The PCE communication protocol design MUST consider whether request 380 if starvation can occur for particular priorities, whether that is 381 acceptable, and how that is handled. 383 6.1.6 Unsolicited Notifications 385 The PCE communication protocol SHOULD support unsolicited 386 notifications from PCE to PCC or from PCE to PCE. That is, the 387 normal mode is for the PCC to make path computation requests to the 388 PCE. This requirement includes cases of PCEs computing paths without 389 being asked by a PCC, and the PCE sending those unsolicited paths to 390 PCCs. This could also include PCE overload notifications. 392 6.1.7 Asynchronous Communication 394 The PCC-PCE protocol MUST allow for asynchronous communication. A 395 client MUST NOT have to wait for a response to make another request. 396 Also it MUST be possible to have the order of some responses differ 397 from the order of their corresponding requests. This may occur, for 398 instance, when path request messages have distinct priorities (see 399 Requirement 6.1.5). 401 6.1.8 Communication Overhead Minimization 403 The request and response messages SHOULD be designed so that the 404 communication overhead is minimized. Particular attention SHOULD be 405 given to the message size. Other considerations in overhead 406 minimization include the following: 408 - the number of messages exchanged to arrive at a computation answer 409 - the amount of background messages to keep the session up 410 - the processing cost at the PCE (or PCC) associated with 411 requests/responses. 413 6.1.9 Extensibility 415 The PCE communication protocol MUST provide a way for introduction of 416 new path computation constraints, diversity types, objective 417 functions, optimization methods and parameters, etc., without 418 requiring modifications in the protocol. In particular, the PCE 419 communication protocol SHOULD allow supporting future applications 420 not currently in the scope of the PCE working group, such as, for 421 instance, P2MP path computations. 423 The communication protocol MUST allow supporting various PCE based 424 applications that have been currently identified and MAY be 425 identified in the future, such as: 427 - intra-area path computation 428 - inter-area path computation 429 - inter-AS intra provider and inter-AS inter-provider path 430 computation 431 - multi-layer and virtual network topology computation 433 Note that application specific requirements are out of the scope of 434 this document and will be addressed in separate requirements 435 documents. 437 6.1.10 Scalability 439 The PCE communication protocol MUST scale well with an increase of 440 any of the following parameters: 442 - number of PCCs 443 - number of PCEs 444 - number of PCCs communicating with a single PCE 445 - number of PCEs communicated to by a single PCC 446 - number of PCEs communicated to by another PCE. 447 - TED size (number of links/nodes, which may drive up path 448 computation time) 449 - number of domains 450 - number of path requests 451 - handling bursts of requests 452 Bursts of requests may arise, for example, after a network outage 453 when multiple recomputations are requested as a result. It is 454 RECOMMENDED that the protocol handle the congestion in a graceful way 455 so that it does not unduly impact the rest of the network, and so 456 that it does not gate the ability of the PCE to perform computation. 458 6.2 Deployment Support Requirements 460 6.2.1 Support for Various Service Provider Environments and Applications 462 The communication protocol MUST operate in various service provider 463 network environments, where the IP control plane is deployed, such as 465 - MPLS-TE and GMPLS networks 466 - centralized and distributed PCE path computation 467 - single and multiple PCE path computation 469 Definitions of centralized, distributed, single, and multiple PCE 470 path computation can be found in [PCE-ARCH]. 472 6.2.2 Confidentiality 474 The communication protocol MUST allow minimizing the amount of 475 topological information exchanged between a PCC and PCE, and between 476 PCEs. This is of particular importance in inter-PCE communication, 477 where the PCEs are located in distinct service-provider domains. 478 For example, the protocol design SHOULD enable policies to be 479 implemented such that domain-specific topology information is 480 excluded on inter-PCE, inter-domain communication. 482 6.2.3 Policy Support 484 The communication protocol MUST allow for policies to accept/reject 485 requests, and include the ability for a PCE to reject requests with 486 sufficient detail to allow the PCC to determine the reason for 487 rejection or failure. For example, filtering could be required for 488 intra-AS PCE path computation such that all requests are rejected 489 that come from another AS. However, specific policy details 490 are left to application-specific communication protocol requirements. 491 Furthermore, the communication protocol MUST allow for the 492 notification of a policy violation. Actual policies, configuration 493 of policies, and applicability of policies are out of scope. 495 6.3 Detection & Recovery Requirements 497 6.3.1 Aliveness Detection 499 The PCE communication protocol MUST allow a PCC to check the 500 liveliness of PCEs it is using for path computation and a PCE to 501 check the liveliness of PCCs it is serving. The PCE communication 502 protocol MUST provide partner failure detection. 504 Depending on the design, this requirement MAY be met by the PCE 505 communication protocol design or the transport protocol design. 507 6.3.2 PCC/PCE Failure Response 509 Appropriate PCC and PCE procedures MUST be defined to deal with PCE 510 and PCC failures. A PCC MUST be able to clear any pending request to 511 a PCE. That is, the PCC MAY cancel a previously-made path 512 computation request to a PCE. 514 Similarly, a PCE MUST be able to clear pending requests from a PCC, 515 for instance, when it detects the failure of the requesting PCC or 516 when its buffer of requests is full. It is RECOMMENDED that a PCC 517 select another PCE upon detection of PCE failure or unreachability of 518 a PCE but note that PCE selection procedure are out of the scope of 519 this document. 521 It is assumed that the underlying reliable communication mechanism 522 ensures reciprocal knowledge of PCE and PCC liveness. Therefore it 523 NOT possible for the PCC/PCE to believe that the PCE/PCC is 524 unreachable, but not vice versa. 526 6.3.3 Protocol Recovery 528 Information distributed in asynchronous/unsolicited messages SHOULD 529 be allowed to persist at the recipient in the event of the failure of 530 the sender or of the communications channel. Upon recovery, the 531 communications protocol MUST support resynchronization of information 532 between the sender and the receiver, and this SHOULD be arranged so 533 as to minimize repeat data transfer. 535 For example, the communication protocol SHOULD allow a stateful 536 PCE to resynchronize and recover states (e.g., LSP status, paths, 537 etc.) after a restart. Recovery would require the PCE communication 538 protocol to support recovery of state information in the PCE. This 539 would be of particular importance when local PCE recovery is not 540 supported or fails. 542 7. Security Considerations 544 The impact of the use of a PCE-based architecture MUST be considered 545 in the light of the impact that it has on the security of the 546 existing routing and signaling protocols and techniques in use within 547 the network. There is unlikely to be any impact on intra-domain 548 security, but an increase in inter-domain information flows and the 549 facilitation of inter-domain path establishment may increase the 550 vulnerability to security attacks. 552 Of particular relevance are the implications for confidentiality 553 inherent in a PCE-based architecture for multi-domain networks. It 554 is not necessarily the case that a multi-domain PCE solution will 555 compromise security, but solutions MUST examine their impacts in this 556 area. 558 Applicability statements for particular combinations of signaling, 559 routing and path computation techniques are expected to contain 560 detailed security sections. 562 It should be observed that the use of a non-local PCE (that is, not 563 co-resident with the PCC) does introduce additional security issues. 564 Most notable amongst these are: 566 - interception of PCE requests or responses 567 - impersonation of PCE 568 - falsification of TE information 569 - denial of service attacks on PCE or PCE communication mechanisms 571 It is expected that PCE solutions will address these issues in detail 572 using authentication and security techniques. 574 8. Manageability Considerations 576 Manageability of the PCE communication protocol MUST address the 577 following considerations: 579 - need for a MIB module for control and monitoring 580 - need for built-in diagnostic tools (e.g., partner failure 581 detection, OAM, etc.) 582 - configuration implications for the protocol 584 9. IANA Considerations 586 This document makes no requests for IANA action. 588 10. Acknowledgements 590 The authors would like to extend their warmest thanks to (in 591 alphabetical order) Adrian Farrel, Thomas Morin, and JP Vasseur for 592 their review and suggestions. 594 11. Normative References 596 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 597 Element (PCE) Architecture", work in progress. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 603 3667, February 2004. 605 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 606 Technology", BCP 79, RFC 3668, February 2004. 608 12. Informational References 610 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 611 Computation Element (PCE) Discovery," work in progress. 613 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 614 Tunnels," RFC 3209, December 2001. 616 13. Authors' Addresses 618 Jerry Ash 619 AT&T 620 Room MT D5-2A01 621 200 Laurel Avenue 622 Middletown, NJ 07748, USA 623 Phone: +1-(732)-420-4578 624 Email: gash@att.com 626 Alia K. Atlas 627 Avici Systems, Inc. 628 101 Billerica Avenue 629 N. Billerica, MA 01862, USA 630 Phone: +1 978 964 2070 631 Email: aatlas@avici.com 633 Arthi Ayyangar 634 Juniper Networks, Inc. 635 1194 N.Mathilda Ave 636 Sunnyvale, CA 94089 USA 637 Email: arthi@juniper.net 639 Nabil Bitar 640 Verizon 641 40 Sylvan Road 642 Waltham, MA 02145 643 Email: nabil.bitar@verizon.com 645 Igor Bryskin 646 Independent Consultant 647 Email: i_bryskin@yahoo.com 649 Dean Cheng 650 Cisco Systems Inc. 651 3700 Cisco Way 652 San Jose CA 95134 USA 653 Phone: +1 408 527 0677 654 Email: dcheng@cisco.com 655 Durga Gangisetti 656 MCI 657 Email: durga.gangisetti@mci.com 659 Kenji Kumaki 660 KDDI Corporation 661 Garden Air Tower 662 Iidabashi, Chiyoda-ku, 663 Tokyo 102-8460, JAPAN 664 Phone: +81-3-6678-3103 665 Email: ke-kumaki@kddi.com 667 Jean-Louis Le Roux 668 France Telecom 669 2, avenue Pierre-Marzin 670 22307 Lannion Cedex, FRANCE 671 Email: jeanlouis.leroux@francetelecom.com 673 Eiji Oki 674 NTT 675 Midori-cho 3-9-11 676 Musashino-shi, Tokyo 180-8585, JAPAN 677 Email: oki.eiji@lab.ntt.co.jp 679 Raymond Zhang 680 BT INFONET Services Corporation 681 2160 E. Grand Ave. 682 El Segundo, CA 90245 USA 683 Email: Raymond_zhang@bt.infonet.com 685 14. Intellectual Property Statement 687 The IETF takes no position regarding the validity or scope of any 688 Intellectual Property Rights or other rights that might be claimed to 689 pertain to the implementation or use of the technology described in 690 this document or the extent to which any license under such rights 691 might or might not be available; nor does it represent that it has 692 made any independent effort to identify any such rights. Information 693 on the procedures with respect to rights in RFC documents can be 694 found in BCP 78 and BCP 79. 696 Copies of IPR disclosures made to the IETF Secretariat and any 697 assurances of licenses to be made available, or the result of an 698 attempt made to obtain a general license or permission for the use of 699 such proprietary rights by implementers or users of this 700 specification can be obtained from the IETF on-line IPR repository at 701 http://www.ietf.org/ipr. 703 The IETF invites any interested party to bring to its attention any 704 copyrights, patents or patent applications, or other proprietary 705 rights that may cover technology that may be required to implement 706 this standard. Please address the information to the IETF at 707 ietf-ipr@ietf.org. 709 Disclaimer of Validity 711 This document and the information contained herein are provided on an 712 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 713 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 714 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 715 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 716 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 717 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 719 Copyright Statement 721 Copyright (C) The Internet Society (2005). This document is subject 722 to the rights, licenses and restrictions contained in BCP 78, and 723 except as set forth therein, the authors retain all their rights.