idnits 2.17.1 draft-ietf-pce-discovery-reqs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 840. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: On the PCC it MUST be possible for an operator to activate/deactivate automatic PCE discovery. The activation of automatic discovery MUST not prevent static configuration of PCE information that may supplement discovered information. -- 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 6524 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 759, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 5 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: December 2006 7 June 2006 9 Requirements for Path Computation Element (PCE) Discovery 11 draft-ietf-pce-discovery-reqs-05.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 6.10.1. Configuration of PCE Discovery parameters.................13 79 6.10.2. PCE Discovery MIB modules.................................14 80 6.10.2.1. PCC MIB module..........................................14 81 6.10.2.2. PCE MIB module..........................................14 82 6.10.3. Monitoring Protocol Operations............................15 83 6.10.4. Impact on network operations..............................15 84 7. Security Considerations....................................15 85 8. Acknowledgments............................................16 86 9. References.................................................16 87 9.1. Normative references.......................................16 88 9.2. Informative references.....................................16 89 10. Editor Address.............................................16 90 11. Contributors' Addresses....................................16 91 12. Intellectual Property Statement............................17 93 1. Contributors 95 The following are the authors that contributed to the present 96 document: 98 Jean-Louis Le Roux (France Telecom) 99 Paul Mabey (Qwest Communications) 100 Eiji Oki (NTT) 101 Richard Rabbat (Fujitsu) 102 Ting Wo Chung (Bell Canada) 103 Raymond Zhang (BT Infonet) 105 2. Terminology 107 Terminology used in this document 109 LSR: Label Switch Router 111 TE-LSP: Traffic Engineered Label Switched Path 113 PCE: Path Computation Element: an entity (component, application, or 114 network node) that is capable of computing a network path or route 115 based on a network graph, and applying computational constraints. 117 PCC: Path Computation Client: any client application requesting a 118 path computation to be performed by a Path Computation Element. 120 IGP Area: OSPF Area or ISIS level/area 122 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router) 124 AS: Autonomous System 126 ASBR: AS Border Router 128 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 129 boundaries. 131 Inter-area TE LSP: A TE LSP whose path transits through two or more 132 IGP areas. 134 Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or 135 more ASs or sub-ASs (BGP confederations). 137 Domain: any collection of network elements within a common sphere of 138 address management or path computational responsibility. Examples of 139 domains include IGP areas and Autonomous Systems. 141 3. Introduction 143 The PCE-based network Architecture [PCE-ARCH] defines a Path 144 Computation Element (PCE) as an entity capable of computing TE-LSP 145 paths based on a network graph, and applying computational 146 constraints. A PCE serves path computation requests sent by Path 147 Computation Clients (PCC). 148 A PCC is a client application requesting a path computation to be 149 performed by a PCE. This can be, for instance, an LSR requesting a 150 path for a TE-LSP for which it is the head-end, or a PCE requesting a 151 path computation of another PCE (inter-PCE communication). The 152 communication between a PCC and a PCE requires a client-server 153 protocol whose generic requirements are listed in [PCE-COM-REQ]. 155 The PCE based architecture requires, that a PCC be aware of the 156 location of one or more PCEs in its domain, and also potentially of 157 some PCEs in other domains, e.g. in case of inter-domain path 158 computation. 160 In that context it would be highly desirable to define a mechanism 161 for automatic and dynamic PCE discovery, which would allow PCCs to 162 automatically discover a set of PCEs, to determine additional 163 information required for PCE selection, and to dynamically detect new 164 PCEs or any modification of the PCEs' information. This includes the 165 discovery by a PCC of a set of one or more PCEs in its domain, and 166 potentially in some other domains. The latter is a desirable function 167 in the case of inter-domain path computation, for example. 169 This document lists a set of functional requirements for such an 170 automatic and dynamic PCE discovery mechanism. Section 4 points out 171 the problem statement. Section 5 illustrates an application scenario. 172 Finally, section 6 addresses detailed requirements. 174 It is intended that solutions that specify procedures and protocols 175 or protocol extensions for PCE discovery satisfy these requirements. 176 There is no intent either to specify solution-specific requirements 177 or to make any assumption on the protocols that could be used for the 178 discovery. 180 Note that requirements listed in this document apply equally to PCEs 181 that are capable of computing paths in MPLS-TE-enabled networks and 182 PCEs that are capable of computing paths in GMPLS-enabled networks 183 (and PCEs capable of both). 185 It is also important to note that the notion of a PCC encompasses a 186 PCE acting as PCC when requesting a path computation of another PCE 187 (inter-PCE communication). Hence, this document does not make the 188 distinction between PCE discovery by PCCs and PCE discovery by PCEs. 190 4. Problem Statement and Requirements Overview 192 4.1. Problem Statement 194 A routing domain may, in practice, contain multiple PCEs: 195 - The path computation load may be balanced among a set of PCEs 196 to improve scalability; 197 - For the purpose of redundancy, primary and backup PCEs may be 198 used; 199 - PCEs may have distinct path computation capabilities (multi- 200 constrained path computation, backup path computation, etc.); 201 - In an inter-domain context there can be several PCEs with 202 distinct inter-domain functions (inter-area, inter-AS, inter- 203 layer), each PCE being responsible for path computation in one or 204 more domains. 206 In order to allow for effective PCE selection by PCCs, that is to 207 select the appropriate PCE based on its capabilities and perform 208 efficient load balancing of requests, a PCC needs to know the 209 location of PCEs in its domain, along with some information relevant 210 to PCE selection, and also potentially needs to know the location of 211 some PCEs in other domains, for inter-domain path computation 212 purpose. 213 Such PCE information could be learnt through manual configuration, on 214 each PCC, of the set of PCEs along with their capabilities. Such a 215 manual configuration approach may be sufficient, and even desired in 216 some particular situations, (e.g. inter-AS PCE discovery, where 217 manual configuration of neighbor PCEs may be preferred for security 218 reasons), but it obviously faces several limitations: 219 - This may imply a substantial configuration overhead; 220 - This would not allow a PCC to dynamically detect that a new PCE is 221 available, that an existing PCE is no longer available, or that 222 there is a change in the PCE's information. 224 Furthermore, as with any manual configuration approach, there is a 225 risk of configuration errors. 227 As an example, in a multi-area network made up of one backbone area 228 and N peripheral areas, and where inter-area MPLS-TE path computation 229 relies on multiple-PCE path computation with ABRs acting as PCEs, the 230 backbone area would comprise at least N PCEs, and the configuration 231 of PCC would be too cumbersome (e.g. in existing multi-area networks, 232 N can be beyond fifty). 234 Hence, an automated PCE discovery mechanism allowing a PCC to 235 dynamically discover a set of PCEs is highly desirable. 237 4.2. Requirements overview 239 A PCE discovery mechanism that satisfies the requirements set forth 240 in this document MUST allow a PCC to automatically discover the 241 location of one or more of the PCEs in its domain. 242 Where inter-domain path computation is required and policy permits, 243 the PCE discovery method MUST allow a PCC to automatically discover 244 the location of PCEs in other domains that can assist with inter- 245 domain path computation. 247 A PCE discovery mechanism MUST allow a PCC to discover the set of one 248 or more domains where a PCE has TE topology visibility and can 249 compute paths. It MUST also allow the discovery of the potential 250 inter-domain path computation functions of a PCE (inter-area, inter- 251 AS, inter-layer, etc.). 253 A PCE discovery mechanism MUST allow the control of the discovery 254 scope, that is the set of one or more domains (areas, ASs) where 255 information related to a given PCE has to be disclosed. 257 A PCE discovery mechanism MUST allow PCCs in a given discovery scope 258 to dynamically discover that a new PCE has appeared or that there is 259 a change in PCE's information. 261 A PCE discovery mechanism MUST allow PCCs to dynamically discover 262 that a PCE is no longer available. 264 A PCE discovery MUST support security procedures. In particular, key 265 consideration MUST be given in terms of how to establish a trust 266 model for PCE discovery. 268 OPTIONALLY a PCE discovery mechanism MAY be used so as to disclose a 269 set of detailed PCE capabilities so that the PCC may make advanced 270 and informed choices about which PCE to use. 272 5. Example of application scenario 274 <----------------AS1--------------------> <----AS2--- 275 Area 1 Area 0 Area 2 276 R1---------R3-----R5-------R6-----------R9----------R11----R13 277 | | | | | 278 | | | | | 279 R2---------R4-----R7-------R8-----------R10---------R12----R14 280 | 281 | 282 -- 283 |S1| 284 -- 286 Figure 1 288 Figure 1 illustrates a multi-area/AS network with several PCEs: 289 - The ABR R3 is a PCE that can take part in inter area path 290 computation. It can compute paths in area 1 and area 0; 291 - The ABR R6 is a PCE that can take part in inter-area path 292 computation. It can compute paths in area 0 and area2; 293 - The ASBR R9 is a PCE that can take part in inter-AS path 294 computation. It is responsible for path computation in AS1 towards 295 AS2; 296 - The ASBR R12 is a PCE that can take part in inter-AS path 297 computation. It is responsible for path computation in AS2 towards 298 AS1; 299 - The server S1 is a PCE that can be used to compute diverse paths 300 and backup paths in area 1. 302 By meeting the requirements set out in this document, the PCE 303 discovery mechanism will allow: 304 - each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for 305 inter-area path computation, and that R3 can compute paths in area0 306 and area1; 307 - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for 308 inter-area path computation, and that R6 can compute paths in area2 309 and area0; 310 - each PCC in AS1 and one or more PCCs in AS2 to dynamically discover 311 R9 as a PCE for inter-AS path computation in AS1 towards AS2; 312 - each PCC in AS2 and one or more PCCs in AS1 to dynamically discover 313 R12 as a PCE for inter-AS path computation in AS2 towards AS1; 314 - each PCC in area 1 to dynamically discover S1, as a PCE for intra- 315 area path computation in area1, and optionally to discover its path 316 computation capabilities (diverse path computation and backup path 317 computation). 319 6. Detailed Requirements 321 6.1. PCE Information to be disclosed 323 We distinguish two levels of PCE information to be disclosed by a PCE 324 discovery mechanism: 325 - General information. Disclosure MUST be supported by the 326 PCE discovery mechanism. 327 - Detailed information. Disclosure MAY be supported by the 328 PCE discovery mechanism. 330 The PCE discovery mechanism MUST allow disclosure of general PCE 331 information that will allow PCCs to select appropriate PCEs. This 332 comprises discovery of PCE location, PCE domains supported by the 333 PCEs, and PCE inter-domain functions. 335 The PCE discovery mechanism MAY also allow disclosure of detailed PCE 336 information. This comprises any or all information about PCE path 337 computation capabilities and alternate PCEs. This information is not 338 part of PCE discovery; this is additional information that can 339 facilitate the selection of a PCE by a PCC. Support of the exchange 340 of this information is optional in the context of the PCE discovery 341 mechanism itself. This does not mean that the availability of this 342 information is optional in the PCE-based architecture, but such 343 information could also be obtained by other mechanisms, such as the 344 PCC-PCE communication protocol. 346 6.1.1. General PCE Information (Mandatory support) 348 6.1.1.1. Discovery of PCE Location 350 The PCE discovery mechanism MUST allow the discovery, for a given 351 PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE. 352 This address will typically be an address that is always reachable, 353 if there is any connectivity to the PCE. 355 This address will be used by PCCs to communicate with a PCE, through 356 a PCC-PCE communication protocol. 358 6.1.1.2. Discovery of PCE Domains and Inter-domain Functions 360 Inter-domain path computation is a key application of the PCE 361 architecture. This can rely on a multiple-PCE path computation, where 362 PCEs in each domain compute a part of the end-to-end path and 363 collaborate with each other to find the end-to-end-path. Inter-domain 364 path computation can also rely on a single-PCE path computation where 365 a PCE has visibility inside multiple domains and can compute an 366 entire end-to-end inter-domain path (that is a path from the inter- 367 domain TE-LSP head-end to the inter-domain TE-LSP tail end). 369 Hence the PCE discovery mechanism MUST allow the discovery of the set 370 of one or more domains where a PCE has visibility and can compute 371 paths. These domains could be identified using a domain identifier: 372 For instance, an IGP area can be identified by the Area ID (OSPF or 373 ISIS), and an AS can be identified by the AS number. 375 Also the PCE discovery mechanism MUST allow discovery of the inter- 376 domain functions of a PCE, i.e. whether a PCE can be used to compute 377 or to take part in the computation of end-to-end paths across domain 378 borders. The inter-domain functions include non exhaustively: inter- 379 area, inter-AS and inter-layer path computation. Note that these 380 functions are not mutually exclusive. 382 Note that the inter-domain functions are not necessarily inferred 383 from the set of domains where a PCE has visibility. For instance a 384 PCE may have visibility limited to a single domain, but may be able 385 to take part into the computation of inter-domain paths, by 386 collaborating with PCEs in other domains. Conversely, a PCE may have 387 visibility in multiple domains but the operator may not want that the 388 PCE be used for inter-domain path computations. 390 The PCE discovery mechanisms MUST also allow discovery of the set of 391 one or more domains toward which a PCE can compute paths. For 392 instance in an inter-AS path computation context, there may be 393 several PCEs in an AS, each one responsible for taking part in the 394 computation of inter-AS paths toward a set of one or more destination 395 ASs, and a PCC may have to discover the destination ASs each PCE is 396 responsible for. 398 6.1.2. Detailed PCE Information (Optional support) 400 6.1.2.1. Discovery of PCE Capabilities 402 In the case where there are several PCEs with distinct capabilities 403 available, a PCC has to select one or more appropriate PCEs. 405 For that purpose the PCE discovery mechanism MAY support the 406 disclosure of some detailed PCE capabilities. 408 For the sake of illustration this could include the following path 409 computation related PCE capabilities: 410 - The link constraints supported: e.g. bandwidth, affinities. 411 - The path constraints supported: maximum IGP/TE cost, maximum hop 412 count; 413 - The objective functions supported: e.g. shortest path, widest path; 414 - The capability to compute multiple correlated paths: e.g. diverse 415 paths, load balanced paths; 416 - The capability to compute bidirectional paths; 417 - The GMPLS technology specific constraints supported: e.g. the 418 supported interface switching capabilities, encoding types. 420 And this could also include some specific PCE capabilities: 421 - The capability to handle request prioritization; 422 - The maximum size of a request message; 423 - The maximum number of path requests in a request message; 424 - The PCE computation power (static parameters to be used for 425 weighted load balancing of requests). 427 Such information regarding PCE capabilities could then be used by a 428 PCC to select an appropriate PCE from a list of candidate PCEs. 430 Note that the exact definition and description of PCE capabilities is 431 out of the scope of this document. It is expected that this will be 432 described in one or more separate documents which may be application 433 specific. 435 6.1.2.2. Discovery of Alternate PCEs 437 In the case of a PCE failure, a PCC has to select another PCE, if one 438 is available. It could be useful in various situations, for a PCE to 439 indicate a set of one or more alternate PCEs that can be selected in 440 case the given PCE fails. 442 Hence the PCE Discovery mechanism MAY allow the discovery, for a 443 given PCE, of the location of one or more assigned alternate PCEs. 445 The PCE Discovery mechanism MAY also allow the discovery, for a given 446 PCE, of the set of one or more PCEs for which it acts as alternate 447 PCE. 449 6.2. Scope of PCE Discovery 451 The PCE Discovery mechanism MUST allow control of the scope of the 452 PCE information disclosure on a per PCE basis. In other words it MUST 453 allow control of to which PCC or group of PCCs the information 454 related to a PCE may be disclosed. 456 The choice for the discovery scope of a given PCE MUST include at 457 least the followings settings: 459 - All PCCs in a single IGP area 461 - All PCCs in a set of adjacent IGP areas 463 - All PCCs in a single AS 465 - All PCCs in a set of ASs 467 - A set of one or more PCCs in a set of one or more ASs 469 In particular, this also implies that the PCE Discovery mechanism 470 MUST allow for the discovery of PCE information across IGP areas and 471 across AS boundaries. 473 The discovery scope MUST be configurable on a per PCE basis. 475 It MUST be possible to deactivate PCE discovery on a per PCE basis. 477 6.2.1. Inter-AS specific requirements 479 When using a PCE-based approach for inter-AS path computation, a PCC 480 in one AS may need to learn information related to inter-AS capable 481 PCEs located in other ASs. For that purpose, and as pointed out in 482 the previous section, the PCE discovery mechanism MUST allow 483 disclosure of information related to inter-AS capable PCEs across AS 484 boundaries. 486 Such inter-AS PCE discovery must be carefully controlled. For 487 security and confidentiality reasons, particularly in an inter- 488 provider context, the discovery mechanism MUST allow the discovery 489 scope to be limited to a set of ASs and MUST also provide control of 490 the PCE information to be disclosed across ASs. This is achieved by 491 applying policies (See also section 6.4). This implies the capability 492 to contain a PCE advertisement to a restricted set of one or more 493 ASs, and to filter and translate any PCE parameter (PCE domains, PCE 494 inter-domain functions, PCE capabilities, etc.) in disclosures that 495 cross AS borders. For the sake of illustration, it may be useful to 496 disclose detailed PCE information (such as detailed capabilities) 497 locally in the PCE's AS but only general information (such as 498 location and supported domains) in other ASs. 500 6.3. PCE Information Synchronization 502 The PCE discovery mechanism MUST allow a PCC to discover any change 503 in the information related to a PCE that it has previously 504 discovered. This includes changes to both general information (e.g. 505 a change in the PCE domains supported), and detailed information if 506 supported (e.g. a modification of the PCE's capabilities). 508 In addition, the PCE discovery mechanism MUST allow to dynamically 509 discover new PCEs in a given discovery scope. 511 Note that there is no requirement for real-time detection of these 512 changes, the PCE Discovery Mechanism SHOULD rather allow discovery of 513 these changes in an order of magnitude of 60 seconds, and the 514 operator should have the ability to configure the Discovery delay. 516 Note that PCE information is relatively static, and is expected to be 517 fairly stable and to not change frequently. 519 6.4. Discovery of PCE deactivation 521 The PCE discovery mechanism MUST allow a PCC to discover when a PCE 522 that it has previously discovered is no longer alive or is 523 deactivated. This may help reducing or avoiding path computation 524 service disruption. 526 Note that there is no requirement for real-time detection of PCE 527 failure/deactivation, the PCE Discovery Mechanism SHOULD rather allow 528 such discovery in an order of magnitude of 60 seconds, and the 529 operator should have the ability to configure the Discovery delay. 531 6.5. Policy Support 533 The PCE Discovery mechanism MUST allow for policies to restrict the 534 discovery scope to a set of authorized domains, to control and 535 restrict the type and nature of the information to be disclosed, and 536 also to filter and translate some information at domains borders. It 537 MUST be possible to apply these policies on a per PCE basis. 539 Note that the Discovery mechanisms MUST allow disclosing policy 540 information so as to control the disclosure policies at domain 541 boundaries. 543 Also, it MUST be possible to apply different policies when disclosing 544 PCE information to different domains. 546 6.6. Security Requirements 548 The five major threats related to PCE discovery mechanisms are: 549 - Impersonation of PCE; 550 - Interception of PCE discovery information (sniffing); 551 - Falsification of PCE discovery information; 552 - Information disclosure to non-authorized PCCs (PCC spoofing). 553 - DoS Attacks 555 Note that security of the PCE Discovery procedures is of particular 556 importance in an inter-AS context, where PCE discovery may increase 557 the vulnerability to attacks and the consequences of these attacks. 559 Hence mechanisms MUST be defined to ensure authenticity, integrity, 560 confidentiality, and containment of PCE discovery information: 561 - There MUST be a mechanism to authenticate discovery information; 562 - There MUST be a mechanism to verify discovery information 563 integrity; 564 - There MUST be a mechanism to encrypt discovery information; 565 - There MUST be a mechanism to restrict the scope of discovery to a 566 set of authorized PCCs and to filter PCE information disclosed 567 at domain boundaries (as per defined in 6.5). 569 A PCE and PCC MUST be identified by a globally unique ID, which may 570 be for instance a combination of AS number an IP address. 572 Mechanisms MUST be defined in order to limit the impact of a 573 DoS attack on the PCE discovery procedure (e.g. filter out excessive 574 PCE information change and flapping PCEs). Note also that DOS 575 attacks may be either accidental (caused by a mis-behaving 576 PCE system) or intentional. As discussed in [PCE-COM-REQ] such 577 mechanisms may include packet filtering, rate limiting, no 578 promiscuous listening, and where applicable use of private addresses 579 spaces. 581 Also, key consideration MUST be given in terms of how to establish a 582 trust model for PCE discovery. The PCE discovery mechanism MUST 583 explicitly support a specific set of one or more trust models. 585 6.7. Extensibility 587 The PCE discovery mechanism MUST be flexible and extensible so as to 588 easily allow for the inclusion of additional PCE information that 589 could be defined in the future. 591 6.8. Scalability 593 The PCE discovery mechanism MUST be designed to scale well with an 594 increase of any of the following parameters: 595 - Number of PCCs discovering a given PCE; 596 - Number of PCEs to be discovered by a given PCC; 597 - Number of domains in the discovery scope. 599 The PCE discovery mechanism MUST NOT have an adverse effect in the 600 performance of other protocols (especially routing and signaling) 601 already operating in the network. 603 Note that there is no scalability requirement with regards to the 604 amount of information to be exchanged. 605 Information disclosed in the PCE discovery mechanism is relatively 606 static. Changes in PCE information may occur as result of PCE 607 configuration updates, PCE deployment/activation or PCE 608 deactivation/suppression, and should not occur as a result of the PCE 609 activity itself. Hence, this information is quite stable and will not 610 change frequently. 612 6.9. Operational orders of magnitudes 614 This section gives minimum order of magnitude estimates of what the 615 PCE discovery mechanism should support. 617 - Number of PCCs discovering a given PCE: 1000 618 - Number of PCEs to be discovered by a given PCC: 100 620 6.10. Manageability considerations 622 Mechanisms are REQUIRED to manage PCE discovery operations. This 623 includes the configuration of PCE Discovery functions and policies, 624 as well as, the monitoring of the discovery protocol activity. 626 6.10.1. Configuration of PCE Discovery parameters 628 It MUST be possible to enable and disable the PCE discovery function 629 at a PCC and at a PCE. 631 On the PCC it MUST be possible for an operator to activate/deactivate 632 automatic PCE discovery. The activation of automatic discovery MUST 633 not prevent static configuration of PCE information that may 634 supplement discovered information. 636 On the PCE it MUST be possible for an operator to control the 637 application of discovery policies by which the specific PCE is 638 discovered. As described in Section 6.5, this control MUST include 639 the ability to: 640 - restrict the discovery scope to a set of authorized domains; 641 - define the type and nature of the information disclosed; 642 - specify the filtering and translation to be applied to the PCE 643 information disclosed at domain borders. 645 These configuration options MAY be supported through an 646 implementation-specific local configuration interface, or MAY be 647 supported via a standardised interface (such as a MIB module, as 648 below). 650 6.10.2. PCE Discovery MIB modules 652 PCE Discovery MIB modules MUST be specified for the control of the 653 function on PCCs and PCEs. 655 6.10.2.1. PCC MIB module 657 The MIB module that will run on PCCs MUST include at least: 658 - A control to disable automatic discovery by the PCC; 659 - The set of known PCEs; 660 - The number of known PCEs, and the number of discovered PCEs. 662 For each PCE reported in the MIB module, the following information 663 MUST be available: 664 - Information advertised by the PCE (i.e., discovered information); 665 - Information locally configured about the PCE; 666 - The time since the PCE was discovered; 667 - The time since any change to the discovered information for the PCE; 669 Note that when a PCE is no longer alive (see section 6.4), it SHOULD 670 no longer be reported in the PCC MIB module. 672 The MIB module SHOULD also provide the average and maximum rates of 673 arrival, departure and modification of PCE discovery to enable 674 effective analysis of the operation of the protocols. Further, the 675 MIB module SHOULD report on the operation of the discovery protocol 676 by counting the number of unacceptable and incomprehensible 677 information exchanges. 679 The PCC MIB module SHOULD also be used to provide notifications 680 when thresholds (e.g. on the maximum rate of change, on the number of 681 unacceptable messages) are crossed, or when important events occur 682 (e.g. the number of discovered PCEs decreases to zero). 684 6.10.2.2. PCE MIB module 686 The MIB module that will run on PCEs MUST include at least: 687 - A control to disable automatic discovery announcements by the PCE; 688 - Information to be advertised by the PCE, although this information 689 MAY be present as read-only; 690 - The discovery policies active on the PCE, although this information 691 MAY be present as read-only. 693 The MIB module SHOULD also include: 694 - The time since the last change to the advertised PCE information; 695 - The time since the last change to the advertisement policies; 696 - Control of on which interfaces the PCE issues advertisements where 697 this is applicable to the protocol solution selected. 699 Note that a PCE MAY also be configured to discover other PCEs. In 700 this case it SHOULD operate the MIB module described in section 701 6.10.2.1 as well as the module described here. 703 6.10.3. Monitoring Protocol Operations 705 It MUST be possible to monitor the operation of any PCE discovery 706 protocol. Where an existing protocol is used to support the PCE 707 discovery function, this monitoring SHOULD be achieved using the 708 techniques already defined for that protocol, enhanced by the MIB 709 modules described above. Where, those techniques are inadequate, new 710 techniques MUST be developed. 712 Monitoring of the protocol operation demands support for at least the 713 following functions: 714 - Correlation of information advertised against information received; 715 - Counts of dropped, corrupt, and rejected information elements; 716 - Detection of 'segmented' networks. That is, the ability to detect 717 and diagnose the failure of a PCE advertisement to reach a PCC. 719 6.10.4. Impact on network operations 721 Frequent changes in PCE information may have a significant impact on 722 PCCs that receive the advertisements, might destabilise the operation 723 of the network by causing the PCCs to swap between PCEs, and might 724 harm the network through excessive advertisement traffic. Hence it 725 MUST be possible to apply at least the following controls: 727 - Configurable limit on the rate of announcement of changed 728 parameters at a PCE; 729 - Control of the impact on PCCs such as through discovery messages 730 rate-limiting; 731 - Configurable control of triggers that cause a PCC to swap to 732 another PCE. 734 7. Security Considerations 736 This document is a requirement document and hence does not raise by 737 itself any particular security issue. 739 A set of security requirements that MUST be addressed when 740 considering the design and deployment of a PCE Discovery mechanism 741 have been identified in section 6.6. 743 8. Acknowledgments 745 We would like to thank, in chronological order, Benoit Fondeviole, 746 Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng, 747 Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor 748 Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou 749 Berger, Nabil Bitar, and Kenji Kumaki. 751 Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley 752 and Sam Hartman for their review and constructive discussions during 753 the final stages of publication. 755 9. References 757 9.1. Normative references 759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 760 Requirement Levels", BCP 14, RFC 2119, March 1997. 762 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 763 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 764 progress. 766 9.2. Informative references 768 [PCE-COM-REQ] Ash, J., Le Roux, J.L., "PCE Communication Protocol 769 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in 770 progress. 772 10. Editor Address 774 Jean-Louis Le Roux (Editor) 775 France Telecom 776 2, avenue Pierre-Marzin 777 22307 Lannion Cedex 778 FRANCE 779 Email: jeanlouis.leroux@francetelecom.com 781 11. Contributors' Addresses 783 Paul Mabey 784 Qwest Communications 785 950 17th Street, 786 Denver, CO 80202, 787 USA 788 Email: pmabey@qwest.com 790 Eiji Oki 791 NTT 792 Midori-cho 3-9-11 793 Musashino-shi, Tokyo 180-8585, 794 JAPAN 795 Email: oki.eiji@lab.ntt.co.jp 797 Richard Rabbat 798 Fujitsu Laboratories of America 799 1240 East Arques Ave, MS 345 800 Sunnyvale, CA 94085 801 USA 802 Email: richard@us.fujitsu.com 804 Ting Wo Chung 805 Bell Canada 806 181 Bay Street, Suite 350 807 Toronto, Ontario, M5J 2T3 808 CANADA, 809 Email: ting_wo.chung@bell.ca 811 Raymond Zhang 812 BT Infonet 813 2160 E. Grand Ave. 814 El Segundo, CA 90025 815 USA 816 Email: raymond_zhang@infonet.com 818 12. Intellectual Property Statement 820 The IETF takes no position regarding the validity or scope of any 821 Intellectual Property Rights or other rights that might be claimed to 822 pertain to the implementation or use of the technology described in 823 this document or the extent to which any license under such rights 824 might or might not be available; nor does it represent that it has 825 made any independent effort to identify any such rights. Information 826 on the procedures with respect to rights in RFC documents can be 827 found in BCP 78 and BCP 79. 829 Copies of IPR disclosures made to the IETF Secretariat and any 830 assurances of licenses to be made available, or the result of an 831 attempt made to obtain a general license or permission for the use of 832 such proprietary rights by implementers or users of this 833 specification can be obtained from the IETF on-line IPR repository at 834 http://www.ietf.org/ipr. 836 The IETF invites any interested party to bring to its attention any 837 copyrights, patents or patent applications, or other proprietary 838 rights that may cover technology that may be required to implement 839 this standard. Please address the information to the IETF at 840 ietf-ipr@ietf.org. 842 Disclaimer of Validity 844 This document and the information contained herein are provided on an 845 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 846 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 847 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 848 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 849 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 850 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 852 Copyright Statement 854 Copyright (C) The Internet Society (2006). This document is subject 855 to the rights, licenses and restrictions contained in BCP 78, and 856 except as set forth therein, the authors retain all their rights.