idnits 2.17.1 draft-ietf-pce-discovery-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 721. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 6546 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 642, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Category: Informational 5 Expires: November 2006 7 May 2006 9 Requirements for Path Computation Element (PCE) Discovery 11 draft-ietf-pce-discovery-reqs-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-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 Abstract 37 This document presents a set of requirements for a Path Computation 38 Element (PCE) discovery mechanism that would allow a Path Computation 39 Client (PCC) to discover dynamically and automatically a set of PCEs 40 along with certain information relevant for PCE selection. It is 41 intended that solutions that specify procedures and protocols or 42 extensions to existing protocols for such PCE discovery satisfy these 43 requirements. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119. 51 Table of Contents 53 1. Contributors................................................3 54 2. Terminology.................................................3 55 3. Introduction................................................4 56 4. Problem Statement and Requirements Overview.................5 57 4.1. Problem Statement...........................................5 58 4.2. Requirements overview.......................................6 59 5. Example of application scenario.............................6 60 6. Detailed Requirements.......................................7 61 6.1. PCE Information to be disclosed.............................7 62 6.1.1. General PCE Information (Mandatory support).................8 63 6.1.1.1. Discovery of PCE Location.................................8 64 6.1.1.2. Discovery of PCE Domains and Inter-domain Functions.......8 65 6.1.2. Detailed PCE Information (Optional support).................9 66 6.1.2.1. Discovery of PCE Capabilities.............................9 67 6.1.2.2. Discovery of Alternate PCEs...............................9 68 6.2. Scope of PCE Discovery.....................................10 69 6.2.1. Inter-AS specific requirements.............................10 70 6.3. PCE Information Synchronization............................11 71 6.4. Discovery of PCE deactivation..............................11 72 6.5. Policy Support.............................................11 73 6.6. Security Requirements......................................12 74 6.7. Extensibility..............................................12 75 6.8. Scalability................................................12 76 6.9. Operational orders of magnitudes...........................13 77 6.10. Manageability considerations...............................13 78 7. Security Considerations....................................13 79 8. Acknowledgments............................................13 80 9. References.................................................14 81 9.1. Normative references.......................................14 82 9.2. Informative references.....................................14 83 10. Authors' Addresses:........................................14 84 11. Intellectual Property Statement............................15 86 1. Contributors 88 The following are the authors that contributed to the present 89 document: 91 Jean-Louis Le Roux (France Telecom) 92 Paul Mabey (Qwest Communications) 93 Eiji Oki (NTT) 94 Richard Rabbat (Fujitsu) 95 Ting Wo Chung (Bell Canada) 96 Raymond Zhang (BT Infonet) 98 2. Terminology 100 Terminology used in this document 102 LSR: Label Switch Router 104 TE-LSP: Traffic Engineered Label Switched Path 106 PCE: Path Computation Element: an entity (component, application, or 107 network node) that is capable of computing a network path or route 108 based on a network graph, and applying computational constraints. 110 PCC: Path Computation Client: any client application requesting a 111 path computation to be performed by a Path Computation Element. 113 IGP Area: OSPF Area or ISIS level/area 115 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router) 117 AS: Autonomous System 119 ASBR: AS Border Router 121 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 122 boundaries. 124 Inter-area TE LSP: A TE LSP whose path transits through two or more 125 IGP areas. 127 Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or 128 more ASs or sub-ASs (BGP confederations). 130 Domain: any collection of network elements within a common sphere of 131 address management or path computational responsibility. Examples of 132 domains include IGP areas and Autonomous Systems. 134 3. Introduction 136 The PCE-based network Architecture [PCE-ARCH] defines a Path 137 Computation Element (PCE) as an entity capable of computing TE-LSP 138 paths based on a network graph, and applying computational 139 constraints. A PCE serves path computation requests sent by Path 140 Computation Clients (PCC). 141 A PCC is a client application requesting a path computation to be 142 performed by a PCE. This can be, for instance, an LSR requesting a 143 path for a TE-LSP for which it is the head-end, or a PCE requesting a 144 path computation of another PCE (inter-PCE communication). The 145 communication between a PCC and a PCE requires a client-server 146 protocol whose generic requirements are listed in [PCE-COM-REQ]. 148 The PCE based architecture requires, that a PCC be aware of the 149 location of one or more PCEs in its domain, and also potentially of 150 some PCEs in other domains, e.g. in case of inter-domain path 151 computation. 153 In that context it would be highly desirable to define a mechanism 154 for automatic and dynamic PCE discovery, which would allow PCCs to 155 automatically discover a set of PCEs, to determine additional 156 information required for PCE selection, and to dynamically detect new 157 PCEs or any modification of the PCEs' information. This includes the 158 discovery by a PCC of a set of one or more PCEs in its domain, and 159 potentially in some other domains. The latter is a desirable function 160 in the case of inter-domain path computation, for example. 162 This document lists a set of functional requirements for such an 163 automatic and dynamic PCE discovery mechanism. Section 4 points out 164 the problem statement. Section 5 illustrates an application scenario. 165 Finally, section 6 addresses detailed requirements. 167 It is intended that solutions that specify procedures and protocols 168 or protocol extensions for PCE discovery satisfy these requirements. 169 There is no intent either to specify solution-specific requirements 170 or to make any assumption on the protocols that could be used for the 171 discovery. 173 Note that requirements listed in this document apply equally to PCEs 174 that are capable of computing paths in MPLS-TE-enabled networks and 175 PCEs that are capable of computing paths in GMPLS-enabled networks 176 (and PCEs capable of both). 178 It is also important to note that the notion of a PCC encompasses a 179 PCE acting as PCC when requesting a path computation of another PCE 180 (inter-PCE communication). Hence, this document does not make the 181 distinction between PCE discovery by PCCs and PCE discovery by PCEs. 183 4. Problem Statement and Requirements Overview 185 4.1. Problem Statement 187 A routing domain may, in practice, contain multiple PCEs: 188 - The path computation load may be balanced among a set of PCEs 189 to improve scalability; 190 - For the purpose of redundancy, primary and backup PCEs may be 191 used; 192 - PCEs may have distinct path computation capabilities (multi- 193 constrained path computation, backup path computation, etc.); 194 - In an inter-domain context there can be several PCEs with 195 distinct inter-domain functions (inter-area, inter-AS, inter- 196 layer), each PCE being responsible for path computation in one or 197 more domains. 199 In order to allow for effective PCE selection by PCCs, that is to 200 select the appropriate PCE based on its capabilities and perform 201 efficient load balancing of requests, a PCC needs to know the 202 location of PCEs in its domain, along with some information relevant 203 to PCE selection, and also potentially needs to know the location of 204 some PCEs in other domains, for inter-domain path computation 205 purpose. 206 Such PCE information could be learnt through manual configuration, on 207 each PCC, of the set of PCEs along with their capabilities. Such a 208 manual configuration approach may be sufficient, and even desired in 209 some particular situations, (e.g. inter-AS PCE discovery, where 210 manual configuration of neighbor PCEs may be preferred for security 211 reasons), but it obviously faces several limitations: 212 - This may imply a substantial configuration overhead; 213 - This would not allow a PCC to dynamically detect that a new PCE is 214 available, that an existing PCE is no longer available, or that 215 there is a change in the PCE's information. 217 Furthermore, as with any manual configuration approach, there is a 218 risk of configuration errors. 220 As an example, in a multi-area network made up of one backbone area 221 and N peripheral areas, and where inter-area MPLS-TE path computation 222 relies on multiple-PCE path computation with ABRs acting as PCEs, the 223 backbone area would comprise at least N PCEs, and the configuration 224 of PCC would be too cumbersome (e.g. in existing multi-area networks, 225 N can be beyond fifty). 227 Hence, an automated PCE discovery mechanism allowing a PCC to 228 dynamically discover a set of PCEs is highly desirable. 230 4.2. Requirements overview 232 A PCE discovery mechanism that satisfies the requirements set forth 233 in this document MUST allow a PCC to automatically discover the 234 location of one or more of the PCEs in its domain. 235 Where inter-domain path computation is required, the PCE discovery 236 method MUST allow a PCC to automatically discover the location of 237 PCEs in other domains that can assist with inter-domain path 238 computation. 240 A PCE discovery mechanism MUST allow a PCC to discover the set of one 241 or more domains where a PCE has TE topology visibility and can 242 compute paths. It MUST also allow the discovery of the potential 243 inter-domain path computation functions of a PCE (inter-area, inter- 244 AS, inter-layer, etc.). 246 A PCE discovery mechanism MUST allow the control of the discovery 247 scope, that is the set of one or more domains (areas, ASs) where 248 information related to a given PCE has to be disclosed. 250 A PCE discovery mechanism MUST allow PCCs in a given discovery scope 251 to dynamically discover that a new PCE has appeared or that there is 252 a change in PCE's information. 254 A PCE discovery mechanism MUST allow PCCs to dynamically discover 255 that a PCE is no longer available. 257 A PCE discovery MUST support security procedures. In particular, key 258 consideration MUST be given in terms of how to establish a trust 259 model for PCE discovery. 261 OPTIONALLY a PCE discovery mechanism MAY be used so as to disclose a 262 set of detailed PCE capabilities so that the PCC may make advanced 263 and informed choices about which PCE to use. 265 5. Example of application scenario 267 <----------------AS1--------------------> <----AS2--- 268 Area 1 Area 0 Area 2 269 R1---------R3-----R5-------R6-----------R9----------R11----R13 270 | | | | | 271 | | | | | 272 R2---------R4-----R7-------R8-----------R10---------R12----R14 273 | 274 | 275 -- 276 |S1| 277 -- 279 Figure 1 281 Figure 1 illustrates a multi-area/AS network with several PCEs: 282 - The ABR R3 is a PCE that can take part in inter area path 283 computation. It can compute paths in area 1 and area 0; 284 - The ABR R6 is a PCE that can take part in inter-area path 285 computation. It can compute paths in area 0 and area2; 286 - The ASBR R9 is a PCE that can take part in inter-AS path 287 computation. It is responsible for path computation in AS1 towards 288 AS2; 289 - The ASBR R12 is a PCE that can take part in inter-AS path 290 computation. It is responsible for path computation in AS2 towards 291 AS1; 292 - The server S1 is a PCE that can be used to compute diverse paths 293 and backup paths in area 1. 295 By meeting the requirements set out in this document, the PCE 296 discovery mechanism will allow: 297 - each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for 298 inter-area path computation, and that R3 can compute paths in area0 299 and area1; 300 - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for 301 inter-area path computation, and that R6 can compute paths in area2 302 and area0; 303 - each PCC in AS1 and one or more PCCs in AS2 to dynamically discover 304 R9 as a PCE for inter-AS path computation in AS1 towards AS2; 305 - each PCC in AS2 and one or more PCCs in AS1 to dynamically discover 306 R12 as a PCE for inter-AS path computation in AS2 towards AS1; 307 - each PCC in area 1 to dynamically discover S1, as a PCE for intra- 308 area path computation in area1, and optionally to discover its path 309 computation capabilities (diverse path computation and backup path 310 computation). 312 6. Detailed Requirements 314 6.1. PCE Information to be disclosed 316 We distinguish two levels of PCE information to be disclosed by a PCE 317 discovery mechanism: 318 - General information. Disclosure MUST be supported by the 319 PCE discovery mechanism. 320 - Detailed information. Disclosure MAY be supported by the 321 PCE discovery mechanism. 323 The PCE discovery mechanism MUST allow disclosure of general PCE 324 information that will allow PCCs to select appropriate PCEs. This 325 comprises discovery of PCE location, PCE domains supported by the 326 PCEs, and PCE inter-domain functions. 328 The PCE discovery mechanism MAY also allow disclosure of detailed PCE 329 information. This comprises any or all information about PCE path 330 computation capabilities and alternate PCEs. This information is not 331 part of PCE discovery; this is additional information that can 332 facilitate the selection of a PCE by a PCC. Support of the exchange 333 of this information is optional in the context of the PCE discovery 334 mechanism itself. This does not mean that the availability of this 335 information is optional in the PCE-based architecture, but such 336 information could also be obtained by other mechanisms, such as the 337 PCC-PCE communication protocol. 339 6.1.1. General PCE Information (Mandatory support) 341 6.1.1.1. Discovery of PCE Location 343 The PCE discovery mechanism MUST allow the discovery, for a given 344 PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE. 345 This address will typically be a loop-back address that is always 346 reachable, if there is any connectivity to the PCE. 348 This address will be used by PCCs to communicate with a PCE, through 349 a PCC-PCE communication protocol. 351 6.1.1.2. Discovery of PCE Domains and Inter-domain Functions 353 Inter-domain path computation is a key application of the PCE 354 architecture. This can rely on a multiple-PCE path computation, where 355 PCEs in each domain compute a part of the end-to-end path and 356 collaborate with each other to find the end-to-end-path. Inter-domain 357 path computation can also rely on a single-PCE path computation where 358 a PCE has visibility inside multiple domains and can compute an 359 entire end-to-end inter-domain path (that is a path from the inter- 360 domain TE-LSP head-end to the inter-domain TE-LSP tail end). 362 Hence the PCE discovery mechanism MUST allow the discovery of the set 363 of one or more domains where a PCE has visibility and can compute 364 paths. These domains could be identified using a domain identifier: 365 For instance, an IGP area can be identified by the Area ID (OSPF or 366 ISIS), and an AS can be identified by the AS number. 368 Also the PCE discovery mechanism MUST allow discovery of the inter- 369 domain functions of a PCE, i.e. whether a PCE can be used to compute 370 or to take part in the computation of end-to-end paths across domain 371 borders. The inter-domain functions include non exhaustively: inter- 372 area, inter-AS and inter-layer path computation. Note that these 373 functions are not mutually exclusive. 375 Note that the inter-domain functions are not necessarily inferred 376 from the set of domains where a PCE has visibility. For instance a 377 PCE may have visibility limited to a single domain, but may be able 378 to take part into the computation of inter-domain paths, by 379 collaborating with PCEs in other domains. Conversely, a PCE may have 380 visibility in multiple domains but the operator may not want that the 381 PCE be used for inter-domain path computations. 383 The PCE discovery mechanisms MUST also allow discovery of the set of 384 one or more domains toward which a PCE can compute paths. For 385 instance in an inter-AS path computation context, there may be 386 several PCEs in an AS, each one responsible for taking part in the 387 computation of inter-AS paths toward a set of one or more destination 388 ASs, and a PCC must discover the destination ASs each PCE is 389 responsible for. 391 6.1.2. Detailed PCE Information (Optional support) 393 6.1.2.1. Discovery of PCE Capabilities 395 In the case where there are several PCEs with distinct capabilities 396 available, a PCC has to select one or more appropriate PCEs. 398 For that purpose the PCE discovery mechanism MAY support the 399 disclosure of some detailed PCE capabilities. 401 For the sake of illustration this could include the following path 402 computation related PCE capabilities: 403 - The link constraints supported: e.g. bandwidth, affinities. 404 - The path constraints supported: maximum IGP/TE cost, maximum hop 405 count; 406 - The objective functions supported: e.g. shortest path, widest path; 407 - The capability to compute multiple correlated paths: e.g. diverse 408 paths, load balanced paths; 409 - The capability to compute bidirectional paths; 410 - The GMPLS technology specific constraints supported: e.g. the 411 supported interface switching capabilities, encoding types. 413 And this could also include some specific PCE capabilities: 414 - The capability to handle request prioritization; 415 - The maximum size of a request message; 416 - The maximum number of path requests in a request message; 417 - The PCE computation power (static parameters to be used for 418 weighted load balancing of requests). 420 Such information regarding PCE capabilities could then be used by a 421 PCC to select an appropriate PCE from a list of candidate PCEs. 423 Note that the exact definition and description of PCE capabilities is 424 out of the scope of this document. It is expected that this will be 425 described in one or more separate documents which may be application 426 specific. 428 6.1.2.2. Discovery of Alternate PCEs 430 In the case of a PCE failure, a PCC has to select another PCE, if one 431 is available. It could be useful in various situations, for a PCE to 432 indicate a set of one or more alternate PCEs that can be selected in 433 case the given PCE fails. 435 Hence the PCE Discovery mechanism MAY allow the discovery, for a 436 given PCE, of the location of one or more assigned alternate PCEs. 438 The PCE Discovery mechanism MAY also allow the discovery, for a given 439 PCE, of the set of one or more PCEs for which it acts as alternate 440 PCE. 442 6.2. Scope of PCE Discovery 444 The PCE Discovery mechanism MUST allow control of the scope of the 445 PCE information disclosure on a per PCE basis. In other words it MUST 446 allow control of to which PCC or group of PCCs the information 447 related to a PCE may be disclosed. 449 The choice for the discovery scope of a given PCE MUST include at 450 least the followings settings: 452 - All PCCs in a single IGP area 454 - All PCCs in a set of adjacent IGP areas 456 - All PCCs in a single AS 458 - All PCCs in a set of ASs 460 - A set of one or more PCCs in a set of one or more ASs 462 In particular, this also implies that the PCE Discovery mechanism 463 MUST allow for the discovery of PCE information across IGP areas and 464 across AS boundaries. 466 The discovery scope MUST be configurable on a per PCE basis. 468 It MUST be possible to deactivate PCE discovery on a per PCE basis. 470 6.2.1. Inter-AS specific requirements 472 When using a PCE-based approach for inter-AS path computation, a PCC 473 in one AS may need to learn information related to inter-AS capable 474 PCEs located in other ASs. For that purpose, and as pointed out in 475 the previous section, the PCE discovery mechanism MUST allow 476 disclosure of information related to inter-AS capable PCEs across AS 477 boundaries. 479 Such inter-AS PCE discovery must be carefully controlled. For 480 security and confidentiality reasons, particularly in an inter- 481 provider context, the discovery mechanism MUST allow the discovery 482 scope to be limited to a set of ASs and MUST also provide control of 483 the PCE information to be disclosed across ASs. This is achieved by 484 applying policies (See also section 6.4). This implies the capability 485 to contain a PCE advertisement to a restricted set of one or more 486 ASs, and to filter and translate any PCE parameter (PCE domains, PCE 487 inter-domain functions, PCE capabilities, etc.) in disclosures that 488 cross AS borders. For the sake of illustration, it may be useful to 489 disclose detailed PCE information (such as detailed capabilities) 490 locally in the PCE's AS but only general information (such as 491 location and supported domains) in other ASs. 493 6.3. PCE Information Synchronization 495 The PCE discovery mechanism MUST allow a PCC to discover any change 496 in the information related to a PCE that it has previously 497 discovered. This includes changes to both general information (e.g. 498 a change in the PCE domains supported), and detailed information if 499 supported (e.g. a modification of the PCE's capabilities). 501 In addition, the PCE discovery mechanism MUST allow to dynamically 502 discover new PCEs in a given discovery scope. 504 Note that there is no requirement for real-time detection of these 505 changes, the PCE Discovery Mechanism SHOULD rather allow discovery of 506 these changes in an order of magnitude of 60 seconds, and the 507 operator should have the ability to configure the Discovery delay. 509 Note that PCE information is relatively static, and is expected to be 510 fairly stable and to not change frequently. 512 6.4. Discovery of PCE deactivation 514 The PCE discovery mechanism MUST allow a PCC to discover when a PCE 515 that it has previously discovered is no longer alive or is 516 deactivated. This may help reducing or avoiding path computation 517 service disruption. 519 Note that there is no requirement for real-time detection of PCE 520 failure/deactivation, the PCE Discovery Mechanism SHOULD rather allow 521 such discovery in an order of magnitude of 60 seconds, and the 522 operator should have the ability to configure the Discovery delay. 524 6.5. Policy Support 526 The PCE Discovery mechanism MUST allow for policies to restrict the 527 discovery scope to a set of authorized domains, to control and 528 restrict the type and nature of the information to be disclosed, and 529 also to filter and translate some information at domains borders. It 530 MUST be possible to apply these policies on a per PCE basis. 531 The way these policies could be managed is out of the scope of this 532 document. 534 Note that the Discovery mechanisms MUST allow disclosing policy 535 information so as to control the disclosure policies at domain 536 boundaries. 538 Also, it MUST be possible to apply different policies when disclosing 539 PCE information to different domains. 541 6.6. Security Requirements 543 The five major threats related to PCE discovery mechanisms are: 544 - Impersonation of PCE; 545 - Interception of PCE discovery information (sniffing); 546 - Falsification of PCE discovery information; 547 - Information disclosure to non-authorized PCCs (PCC spoofing). 548 - DoS Attacks 550 Note that security of the PCE Discovery procedures is of particular 551 importance in an inter-AS context, where PCE discovery may increase 552 the vulnerability to attacks and the consequences of these attacks. 554 Hence mechanisms MUST be defined to ensure authenticity, integrity, 555 privacy, and containment of PCE discovery information: 556 - There MUST be a mechanism to authenticate discovery information; 557 - There MUST be a mechanism to verify discovery information 558 integrity; 559 - There MUST be a mechanism to encrypt discovery information; 560 - There MUST be a mechanism to restrict the scope of discovery to a 561 set of authorized PCCs and to filter PCE information disclosed 562 at domain boundaries (as per defined in 6.5). 564 Mechanisms MUST be defined in order to limit the impact of a 565 DoS attack on the PCE discovery procedure (e.g. filter out excessive 566 PCE information change and flapping PCEs). Note also that DOS 567 attacks may be either accidental (caused by a mis-behaving 568 PCE system) or intentional. As discussed in [PCE-COM-REQ] such 569 mechanisms may include packet filtering, rate limiting, no 570 promiscuous listening, and where applicable use of private addresses 571 spaces. 573 Also, key consideration MUST be given in terms of how to establish a 574 trust model for PCE discovery. The PCE discovery mechanism MUST 575 explicitly support a specific set of one or more trust models. 577 6.7. Extensibility 579 The PCE discovery mechanism MUST be flexible and extensible so as to 580 easily allow for the inclusion of additional PCE information that 581 could be defined in the future. 583 6.8. Scalability 585 The PCE discovery mechanism MUST be designed to scale well with an 586 increase of any of the following parameters: 587 - Number of PCCs discovering a given PCE; 588 - Number of PCEs to be discovered by a given PCC; 589 - Number of domains in the discovery scope. 591 The PCE discovery mechanism MUST NOT have an adverse effect in the 592 performance of other protocols (especially routing and signaling) 593 already operating in the network. 595 Note that there is no scalability requirement with regards to the 596 amount of information to be exchanged. 597 Information disclosed in the PCE discovery mechanism is relatively 598 static. Changes in PCE information may occur as result of PCE 599 configuration updates, PCE deployment/activation or PCE 600 deactivation/suppression, and should not occur as a result of the PCE 601 activity itself. Hence, this information is quite stable and will not 602 change frequently. 604 6.9. Operational orders of magnitudes 606 This section gives minimum order of magnitude estimates of what the 607 PCE discovery mechanism should support. 609 - Number of PCCs discovering a given PCE: 1000 610 - Number of PCEs to be discovered by a given PCC: 100 612 6.10. Manageability considerations 614 Manageability of PCE discovery MUST addresses the following 615 considerations: 617 - need for a MIB module for PCE discovery; 618 - configuration implications for the protocol. 620 7. Security Considerations 622 This document is a requirement document and hence does not raise by 623 itself any particular security issue. 625 A set of security requirements that MUST be addressed when 626 considering the design and deployment of a PCE Discovery mechanism 627 have been identified in section 6.6. 629 8. Acknowledgments 631 We would like to thank Benoit Fondeviole, Thomas Morin, Emile 632 Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai 633 Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri 634 Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil 635 Bitar, Kenji Kumaki and Ross Callon for their useful comments and 636 suggestions. 638 9. References 640 9.1. Normative references 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 646 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 647 progress. 649 9.2. Informative references 651 [PCE-COM-REQ] Ash, J., Le Roux, J.L., "PCE Communication Protocol 652 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 653 progress. 655 10. Authors' Addresses: 657 Jean-Louis Le Roux (Editor) 658 France Telecom 659 2, avenue Pierre-Marzin 660 22307 Lannion Cedex 661 FRANCE 662 Email: jeanlouis.leroux@francetelecom.com 664 Paul Mabey 665 Qwest Communications 666 950 17th Street, 667 Denver, CO 80202, 668 USA 669 Email: pmabey@qwest.com 671 Eiji Oki 672 NTT 673 Midori-cho 3-9-11 674 Musashino-shi, Tokyo 180-8585, 675 JAPAN 676 Email: oki.eiji@lab.ntt.co.jp 678 Richard Rabbat 679 Fujitsu Laboratories of America 680 1240 East Arques Ave, MS 345 681 Sunnyvale, CA 94085 682 USA 683 Email: richard@us.fujitsu.com 685 Ting Wo Chung 686 Bell Canada 687 181 Bay Street, Suite 350 688 Toronto, Ontario, M5J 2T3 689 CANADA, 690 Email: ting_wo.chung@bell.ca 692 Raymond Zhang 693 BT Infonet 694 2160 E. Grand Ave. 695 El Segundo, CA 90025 696 USA 697 Email: raymond_zhang@infonet.com 699 11. Intellectual Property Statement 701 The IETF takes no position regarding the validity or scope of any 702 Intellectual Property Rights or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; nor does it represent that it has 706 made any independent effort to identify any such rights. Information 707 on the procedures with respect to rights in RFC documents can be 708 found in BCP 78 and BCP 79. 710 Copies of IPR disclosures made to the IETF Secretariat and any 711 assurances of licenses to be made available, or the result of an 712 attempt made to obtain a general license or permission for the use of 713 such proprietary rights by implementers or users of this 714 specification can be obtained from the IETF on-line IPR repository at 715 http://www.ietf.org/ipr. 717 The IETF invites any interested party to bring to its attention any 718 copyrights, patents or patent applications, or other proprietary 719 rights that may cover technology that may be required to implement 720 this standard. Please address the information to the IETF at 721 ietf-ipr@ietf.org. 723 Disclaimer of Validity 725 This document and the information contained herein are provided on an 726 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 727 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 728 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 729 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 730 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 731 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 733 Copyright Statement 735 Copyright (C) The Internet Society (2006). This document is subject 736 to the rights, licenses and restrictions contained in BCP 78, and 737 except as set forth therein, the authors retain all their rights.