idnits 2.17.1 draft-ietf-pce-vpn-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Yasukawa 2 Internet Draft NTT 3 Category: Informational A. Farrel (Ed.) 4 Created: October 19, 2009 Old Dog Consulting 5 Expires: April 19, 2010 7 PCC-PCE Communication Requirements for VPNs 9 draft-ietf-pce-vpn-req-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Path Computation Element (PCE) provides path computation 35 functions in support of traffic engineering in Multiprotocol Label 36 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 38 An important application of MPLS and GMPLS networks is Virtual 39 Private Networks (VPNs) that may be constructed using Label Switched 40 Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may 41 be applied as a tool to compute the paths of such tunnels in order to 42 achieve better use of the network resources and to provide better 43 levels of service to the VPN customers. 45 Generic requirements for a communication protocol between Path 46 Computation Clients (PCCs) and PCEs are presented in "Path 47 Computation Element (PCE) Communication Protocol Generic 48 Requirements". This document complements the generic requirements and 49 presents a detailed set of PCC-PCE communication protocol 50 requirements that are specific to the application of PCE to VPNs. 52 Contents 54 1. Introduction ................................................... 3 55 2. Terminology .................................................... 4 56 2.1. Conventions used in this document ............................ 4 57 2.2. Specific Terminology ......................................... 4 58 3. Core Network Requirements in Support of VPNs ................... 4 59 3.1. VPN-Specific Behavior ........................................ 5 60 3.1.1. Per-VPN Policy ............................................. 5 61 3.1.2. Per-VPN Constraints and Algorithms ......................... 5 62 3.1.3. Per-VPN Resources .......................................... 5 63 3.1.4. LSP Protection Schemes and Resource Sharing ................ 5 64 3.2. Customer Control of The Core Network ......................... 6 65 3.3. Private Address Spaces ....................................... 6 66 3.4. CE-CE Service Protection Schemes ............................. 6 67 3.5. Aggregation Schemes .......................................... 7 68 3.5.1. Sharing Core Tunnels ....................................... 7 69 3.5.2. Handling Core Scalability .................................. 7 70 3.6. Multicast Considerations ..................................... 8 71 3.6.1. Unicast or Multicast LSPs .................................. 8 72 3.6.2. P2MP Traffic Engineering ................................... 9 73 3.6.3. Aggregation onto P2MP LSPs ................................. 9 74 3.7. VPN Establishment/Addition/Deletion .......................... 9 75 3.8. Interworking Between Multiple VPN Domains ................... 10 76 4. PCECP Requirements for PCE Support of VPNs .................... 10 77 4.1. Identification of VPN ....................................... 10 78 4.2. Identification of Related VPNs .............................. 10 79 4.3. Scoping of Addresses ........................................ 11 80 4.4. Cooperation between Customer PCE and Core PCE ............... 11 81 4.5. Path Diversity .............................................. 11 82 4.6. Point-to-Multipoint ......................................... 11 83 4.7. Incorporating Path Calculation During VPN Membership 84 Discovery ................................................. 11 85 5. Manageability Considerations .... ............................. 12 86 5.1 Control of Function and Policy ............................... 12 87 5.2 Information and Data Models .................................. 12 88 5.3 Liveness Detection and Monitoring ............................ 12 89 5.4 Verifying Correct Operation .................................. 12 90 5.5 Requirements on Other Protocols and Functional Components .... 12 91 5.6 Impact on Network Operation .................................. 13 92 5.7 Other Considerations ......................................... 13 93 6. Security Considerations ....................................... 13 94 7. IANA Considerations ........................................... 14 95 8. Acknowledgments ............................................... 14 96 9. References .................................................... 14 97 9.1. Normative References ........................................ 14 98 9.2. Informative References ...................................... 14 99 10. Author's Address ............................................. 16 101 1. Introduction 103 The Virtual Private Network (VPN) is an important service offered by 104 network providers to their customers. A lot of different VPN 105 technologies such as IP-VPN and VPLS [RFC2764], [RFC4761], [RFC4762] 106 have been developed and are deployed into many service providers' 107 networks to enhance their service capabilities. VPN technologies have 108 also has been extended to support multicast services [RFC4834] and 109 layer 1 servics [RFC4847]. 111 Multiprotocol Label Switching (MPLS) [RFC3031] and Generalized MPLS 112 (GMPLS) [RFC3945] are often used to provide VPN solutions within 113 provider core networks because Label Switched Paths (LSPs) provide 114 traffic trunks that can be used to connect customers' VPN sites. 115 These LSPs can be traffic engineered to help meet service level 116 agreements (SLAs) and to enhance the manageability of providers' 117 networks. 119 To meet customer demands and to realize competitive VPN network 120 infrastructures, one promising possibility for service providers 121 (SPs) is to deploy a common IP/MPLS network infrastructure for 122 several VPN services. To realize this, the core network operator 123 faces the following challenges. 125 - The SP must accommodate multiple VPN services which might have 126 different network policies within a common IP/MPLS core network. 127 This may require sophisticated traffic engineering (TE) mechanisms 128 for the TE-LSPs that support more than one VPN. 130 - The SP must introduce automatic VPN establishment/addition/deletion 131 mechanisms on top of an IP/MPLS core network to reduce their 132 Operational Expenditure (OPEX). This requires some automatic path 133 calculation and setup mechanisms during the VPN establishment/ 134 addition/deletion processes. 136 - The SP must introduce VPN interworking functions that enable 137 interworking between multiple domains of the same VPN service 138 (e.g., Inter-AS operation), and interworking between multiple VPN 139 service networks. 141 Designing TE-LSPs is a key technical component to meet these 142 challenges. The Path Computation Element (PCE) defined in [RFC4655] 143 is an entity that is capable of computing network paths and routes 144 based on a network graph, and applying computational constraints. 145 PCE is applicable of computating traffic engineered paths for MPLS 146 and GMPLS LSPs, and so it is natural to seek to apply the same 147 technology to support VPNs. 149 In the PCE architecture, the Path Computation Element Communication 150 Protocol (PCECP) is used to exchange path computation requests and 151 responses between Path Computation Clients (PCCs) and PCEs, and also 152 between PCEs. Generic requirements for PCECP are presented in 153 [RFC4657]. PCECP is described in [RFC5440]. 155 This document presents a set of requirements for the Path Computation 156 Element Communication Protocol (PCECP) when PCE is used in support of 157 VPNs. 159 Specific requirements for PCECP in support of point-to-multipoint 160 path computation such as might be used in support of multicast VPNs 161 are described in [PCE-P2MP-REQ]. 163 2. Terminology 165 2.1. Conventions used in this document 167 For clarity of specification of requirements, the key words "MUST", 168 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 169 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 170 interpreted as described in RFC 2119 [RFC2119]. 172 2.2. Specific Terminology 174 PCE terminology is defined in [RFC4655]. 176 Applicable MPLS terminology may be found in [RFC3031] and [RFC2702]. 178 GMPLS terminology is defined in [RFC3945] 180 VPN terminology can be found in [RFC4026] with additional terms in 181 [RFC4834] and [RFC4847]. 183 The reader is assumed to be familiar with this terminology. 185 3. Core Network Requirements in Support of VPNs 187 This section is not intended to describe the function of VPNs, nor to 188 provide a full description of how core networks support VPNs. Its 189 purpose is to enumerate the principal features and functions that are 190 used to support VPNs within a core network and with which PCE might 191 be able to assist. This material is only present to give context to 192 Section 4 that lists the specific PCECP requirements in support of 193 VPNs. 195 3.1. VPN-Specific Behavior 197 3.1.1. Per-VPN Policy 199 A core network may apply different policies to the VPN connections 200 established on behalf of different VPNs. Some policy decisions may be 201 made at the time of path computation and could, therefore, be 202 implemented through PCE provided that PCE has access to the correct 203 policy information (perhaps through a policy server [RFC5394]), and 204 is aware of the associated VPN ID. 206 3.1.2. Per-VPN Constraints and Algorithms 208 It is conceivable that different path computation behavior might be 209 applied for the VPN connections belonging to different VPNs. This 210 might, for example, reflect the different SLAs made for the 211 different VPN services/customers. PCE can implement such differences 212 in computational characteristics through specific requests or by 213 being configured to provide different default behaviors according to 214 the VPN ID. 216 3.1.3. Per-VPN Resources 218 In order to make it simpler to guarantee service levels core network 219 resources may be assigned as reserved for use in support of a 220 specific VPN or to be shared amongst only a subset of the total 221 number of VPNs. This division of resources has an obvious impact on 222 path computation and, provided the information can be made available 223 to PCE in its traffic engineering database (TED) and that the VPN ID 224 is supplied along with the path computation request, PCE can provide 225 a path that conforms to the per-VPN resource allocation 226 configuration. 228 3.1.4. LSP Protection Schemes and Resource Sharing 230 The SLA negotiated between network provider and VPN customer will 231 dictate the level of LSP protection required within the network. A 232 PCE can be used to compute protected (i.e., resource disjoint) paths. 234 Some protection schemes (1:n, extra traffic, etc.) allow resources 235 used for protection paths to be shared. It may be a condition of the 236 SLA that protection resources used to support one VPN are not shared 237 outside that VPN, or are shared only with a subset of other VPNs. 238 This might be a condition imposed for security or to improve 239 protection guarantees. PCE can compute protection paths limited to a 240 subset of the network resources. Full support of this function would, 241 however, either require that PCE keep track of the VPNs that use 242 shareable resources by updating its TED, or that PCE is fully 243 stateful. 245 3.2. Customer Control of The Core Network 247 The customer network may wish to exert some control over the path of 248 the VPN connection in the core network using techniques such as those 249 in [RFC4206] and [RFC4208]. Such control may be expressed as 250 inclusion constraints to the computation of the path of the VPN 251 connection LSP, and PCE can compute paths with such constraints. 253 3.3. Private Address Spaces 255 VPNs may operate private address spaces. This has only two 256 consequences for the core network. 258 - In order that a PE-to-PE LSP can be set up across the core network 259 it is necessary to convert the tuple {VPN ID, destination CE 260 address} to the target destination PE address. and this may require 261 access to "reachablity information". That is, it may be necessary 262 to know through which PEs a given CE can be reached in order to 263 perform this mapping. 265 Provided that the PCE is configured with or learns the appropriate 266 mapping tables and knows the VPN ID, it can provide this 267 translation as part of path computation. The target address would 268 need to be flagged as a CE address and not as the destination of 269 the core LSP. 271 - The customer network may exert some control over the path of the 272 VPN connection in the core network as described in Section 3.2. In 273 this case, the core addresses supplied by the customer network to 274 the source PE in an explicit route may be expressed using the 275 customer VPN's private address space. Again, the PCE is capable of 276 providing the required translation as part of the path computation 277 operation. 279 3.4. CE-CE Service Protection Schemes 281 The LSP protection described in Section 3.1.4 applies to PE-PE 282 connections. It is also possible that the VPN will wish to operate 283 CE-CE protection by forming separate CE-CE connections over the core 284 network, usually by connecting each CE to more than one PE. Such 285 CE-CE connections need to use disjoint paths within the core network, 286 but unless the VPN exerts control over these paths (see Section 3.2) 287 the responsibility for ensuring diversity is delegated to the core 288 network. Since the CE-CE connections are established separately, the 289 core network cannot compute a pair of mutually disjoint paths. 290 Instead, the second path must be computed to avoid the resources of 291 the first path. PCE can perform such a computation using the details 292 of the first path as exclusions in the second computation. 294 3.5. Aggregation Schemes 296 Support of VPNs with very many access points may cause significant 297 scaling issues for a core network. Similarly, the support of a large 298 number of VPNs may cause problems. 300 Aggregation solutions may be applied to improve scaling within the 301 core network, for example, by utilizing one PE-PE tunnel to carry the 302 traffic for multiple VPNs. 304 These aggregation schemes require careful analysis of traffic loads 305 to ensure that the VPNs each meet their service requirements and this 306 may necesitate special computations based on aggregate demands. A PCE 307 can perform such computations. 309 3.5.1. Sharing Core Tunnels 311 Where a pair of PEs both provide access to a set of VPNs, there is no 312 requirement for multiple LSP tunnels across the core between the PEs. 313 Traffic between the VPN sites can share a tunnel. 315 A stateful PCE that is requested to compute the path of a new PE-PE 316 LSP might be able to indicate that an existing LSP would be suitable. 317 This function, however, might be more appropriately implemented in a 318 descint "VPN Manager" component. 320 3.5.2. Handling Core Scalability 322 Core network scalability may become an issue when mesh connectivity 323 is required between very many PEs since this may result in 324 exceptionally many LSPs crossing the middle of the network. One 325 mechanism to handle this is to build a mesh of hierarchical LSP 326 tunnels within the core of the core network, and to use these to 327 provide forwarding adjacencies [RFC4206] or to operate a layered 328 (client/server) network [RFC5212]. 330 PCE can compute the paths of PE-PE LSPs that use these core tunnels 331 as forwarding adjacencies. Alternatively, when a multi-layered 332 approach is taken, PCE may be an ideal computation tool where 333 inter-layer or separate layer TE visibility is available 334 [PCE-INTER-LAYER]. 336 3.6. Multicast Considerations 338 VPNs may be required to support multicast traffic [RFC4834]. Various 339 solutions have been proposed including some that use traffic 340 engineered MPLS LSPs within the core network. 342 3.6.1. Unicast or Multicast LSPs 344 VPN connectivity for multicast VPNs may be provided by unicast or 345 multicast LSPs. Data sourced through a CE and passed to a PE must be 346 distributed across the network and delivered through multiple PEs to 347 many CEs that participate in the same VPN. There are three models as 348 follows. 350 a. PE Replication. 352 In this model multicast traffic is replicated by the ingress PE 353 and distributed on unicast (point-to-point) LSPs to the egress 354 PEs. The egress PEs may, themselves, be responsible for further 355 replication if there are multiple attached CEs. 357 This model does not place any different requirements on the 358 traffic engineering model from unicast VPNs, and a PCE can be used 359 to compute the paths of the PE-PE TE-LSPs. 361 b. Rendezvous Point Replication 363 Replication can be placed within the network through the use of a 364 rendezvous point. A unicast LSP carries data from the ingress PE 365 to the rendezvous point where it is replicated and distributed to 366 egress PEs along other unicast LSPs. 368 Rendezvous points may also be used to support multicast VPNs with 369 multiple data sources. Further, a hierarchy of such points of 370 replication could be constructed to achieve better network 371 utilization. 373 Again, the point-to-point LSPs are no different from the TE-LSPs 374 described before, and a PCE can be used to compute their paths. A 375 PCE might also be used to select an appropriate rendezvous point 376 for a traffic flow in a VPN, and where a hierarchy of replication 377 points is used, PCE could coordinate them so that no egress PCE 378 receives duplicate data. These latter functions, however, are more 379 suited to a VPN Manager component leaving PCE to perform path 380 computation operations consistent with its specification in 381 [RFC4655]. 383 c. Multicast LSPs 385 Most efficient use of the core network can be made by establishing 386 multicast LSPs, otherwise known as point-to-multipoint (P2MP) 387 LSPs. These provide a distribution tree from the ingress PE to the 388 egress PEs. Data replication happens within the forwarding plane 389 at branch nodes (see Section 3.6.2). 391 It is possible to combine these three models in any mix. A PCE may be 392 particularly helpful in identifying existing shareable LSPs that can 393 determine what mixture of models to use. 395 3.6.2. P2MP Traffic Engineering 397 The computation of the routes for P2MP trees is non-trivial as 398 suitable branch nodes must be located within the core network. The 399 computation is made more complex by various factors including 400 different replication capabilities of the core network nodes and 401 different objective optimization criteria (such as least sum cost 402 paths known as Steiner trees, and shortest paths to each 403 destination). 405 The complexity of the P2MP computation makes it particularly suitable 406 to offload to a dedicated PCE [PCE-P2MP-REQ]. 408 3.6.3. Aggregation onto P2MP LSPs 410 Aggregation of traffic from multicast VPNs onto core P2MP LSPs is 411 more complicated than for unicast traffic. In the unicast case (see 412 Section 3.5.1) it is possible for all traffic between a pair of PEs 413 to share the same tunnel, but in the multicast case, sharing a tunnel 414 requires that there is a common set of egress PEs or that receiving 415 PEs can discard unwanted traffic. Various solutions to this problem 416 are possible: each requires that the paths of P2MP LSPs are computed 417 and that is something with which PCE can assist. But the fundamental 418 problem of determining how many tunnels to use and how to multiplex 419 traffic onto the tunnels is a function best performed by a distinct 420 VPN Manager component. 422 3.7. VPN Establishment/Addition/Deletion 424 BGP-based auto-discovery mechanisms are widely deployed in VPNs for 425 membership discovery. The auto-discovery mechanism is used not only 426 to automatically detect VPN membership, but also to automatically 427 establish PE-to-PE tunnels after detecting VPN membership. Combining 428 this auto-discovery mechanism and the LSP establishment mechanism, 429 one can establish the VPN's PE-to-PE LSPs automatically. But one 430 challenge of this approach is that when multiple independent PEs set 431 up PE-to-PE LSPs independently, it is impossible to set up the LSPs 432 to be optimal considering network-wide constraints. To accomplish 433 this network-wide optimization, some centralized path computation 434 element is necessary to coordinate the computation of the paths of 435 the LSPs, and PCE can perform this function. 437 3.8. Interworking Between Multiple VPN Domains 439 To enable interworking between multiple VPN domains (such as Inter-AS 440 procedures for IP-VPNs, or multi-hop pseudowire procedures for VPLS) 441 some smart, end-to-end-based path calculation is necessary. A PCE can 442 perform this kind of path calculation, for example, through 443 cooperation with other PCEs. 445 4. PCECP Requirements for PCE Support of VPNs 447 This section sets out requirements that must be met by the PCE 448 Communications Protocol (PCECP) when PCE is used to support path 449 computation for VPNs. These requirements supplement those common 450 requirements described in [RFC4657], and are complementary to 451 additional requirements present in other requirements documents such 452 as [RFC4927], [RFC5376], and [PCE-INTER-LAYER]. 454 4.1. Identification of VPN 456 Since computations may be specific to the VPN that will use the core 457 LSP, it MUST be possible to specify the VPN ID on a path computation 458 request. 460 4.2. Identification of Related VPNs 462 Certain computations of paths for VPN connections may need to exclude 463 or include core resource sharing or traffic aggregation by 464 identifying specific other VPNs. Thus is MUST be possible to specify 465 a list of related VPN IDs on a path computation request. 467 This list SHOULD be accompanied by a context so that it is possible 468 to provide lists of related VPNs for different purposes on the same 469 path computation request. Contexts identified at this time are as 470 follows: 472 - Allowed to share network resources with LSPs for the listed VPNs. 473 - Prohibited from sharing network resources with LSPs for the listed 474 VPNs. 475 - Allowed to carry traffic for the other listed VPNs. 476 - Prohibited from carrying traffic for the other listed VPNs. 478 Further contexts may be defined in the future and the protocol field 479 that defines context SHOULD be reasonably extensible. 481 4.3. Scoping of Addresses 483 If the addresses used in any part of a path computation request or 484 response are not within the scope of the network for which the 485 computation is to be performed (for example, they are customer VPN 486 addresses for core network nodes) this needs to be identified to the 487 PCE. A path computation request MUST allow the PCC to indicate that 488 certain addresses are in the scope of the customer VPN. 490 4.4. Cooperation between Customer PCE and Core PCE 492 In order for cooperation between customer and core PCEs to be most 493 efficient, it SHOULD be possible for an initial path computation 494 request sent from a PCC to the first PCE to identify the other PCEs 495 with which the first PCE should cooperate. 497 It SHOULD also be possible for a path computation response to 498 identify other PCEs for use at further stages in the LSP 499 establishment process. This information would need to be carried in 500 signaling messages to be available at downstream nodes (such as the 501 PEs), but how this information is conveyed in signaling messages is 502 beyond the scope of this document. 504 4.5. Path Diversity 506 Path protection schemes require that path computation requests MUST 507 be able to indicate diversity requirements. 509 PE-PE protection requires that a single path computation request MUST 510 be able to request multiple paths meeting specified diversity 511 requirements. This requirement is already covered in [RFC4657]. 513 CE-CE protection requires that a path computation request MUST be 514 able to request specific diversity from another, previously computed 515 path by specifying the links and nodes of that path. This requirement 516 for exclusions is already covered in [RFC4657]. 518 4.6. Point-to-Multipoint 520 The requirements for PCECP to support path computation for P2MP LSPs 521 are presented in [PCE-P2MP-REQ]. 523 4.7. Incorporating Path Calculation During VPN Membership Discovery 525 In order for a PE (PCC) to request a PCE to calculate PE-to-PE VPN 526 paths, and in order for the PE to set up these LSPs during the VPN 527 establishment/addition/deletion process, the PCE MUST monitor VPN 528 membership discovery. In this context, "monitor" means that the PCE's 529 network map MUST be updated to include VPN membership information. 530 For further discussion of how the PCE network map may be constructed 531 refer to [RFC4655]. 533 5. Manageability Considerations 535 The use of PCECP to compute paths in support of VPNs extends the 536 manageability considerations for PCECP. 538 5.1 Control of Function and Policy 540 No additional controls of function or policy are required over and 541 above those that are required for basic operation of PCECP. However, 542 it should be noted that separate controls may be required for each 543 VPN that is supported. Further, the customer may require access to 544 some or all of the controls for their VPN. 546 5.2 Information and Data Models 548 The PCECP may be modeled and controlled through MIB modules. It may 549 be desirable to divide such modeling and control per VPN. In 550 particular, where access to, or control of MIB data is provided to 551 customers so that they can gather statistics or manage the behavior 552 of PCEs for their VPN, clear separation must be enforced so that 553 customers have no control over or visibility into each other's VPN 554 operation. 556 5.3 Liveness Detection and Monitoring 558 No additional liveness detection and monitoring facilities are 559 required to be added to PCECP because of VPN support. 561 5.4 Verifying Correct Operation 563 There are no additional requirements for verifying the correct 564 operation of the PCECP. 566 If information is made available to allow an operator to verify the 567 correct computation of a path, care must be taken over precisely what 568 information is exposed to customers so as to preserve customer 569 confidentiality. This topic, however, falls outside the scope of 570 manageability considerations for the PCECP. 572 5.5 Requirements on Other Protocols and Functional Components 574 The manageability of PCECP places certain requirements on the 575 manageability of other protocols, in particular on the underlying 576 transport protocol. The application of PCE to VPNs does not extend 577 PCECP's requirements to be able to manage other protocols or 578 functional components. 580 It should be noted that the applicability of PCE to VPNs has 581 significant impact on the management and operation of other protocols 582 used for PCE discovery, VPN membership discovery and advertisement, 583 and LSP signaling. These topics are out of scope for this document. 585 5.6 Impact on Network Operation 587 As described in [RFC4655], the use of PCE may impact the operation of 588 a network. Additionally, there are consequences of applying PCE to 589 VPNs. 591 The PCECP is required to handle issues of congestion that are caused 592 by significant numbers of computation requests issued in a small 593 period of time. In practice, separate PCEs might be used to service 594 the requirements of different VPNs with the result that this problem 595 might not be so significant. 597 Otherwise, the extensions to PCECP to cover the use of PCE for VPNs 598 do not have additional impact on the operation of the core network. 600 5.7 Other Considerations 602 No other management considerations arise. 604 6. Security Considerations 606 Security is an important feature for VPNs. VPN customers expect and 607 require that their data and service information is kept secure from 608 interception or interference by other users of the provider network. 610 Since the provider network will possibly support multiple VPNs as 611 well as other services, the traffic of an individual VPN and the 612 computation information that applies to that VPN are vulnerable 613 within the provider network. It is important that the PCECP exchanges 614 are protected so that there is no visibility of computation 615 information and so that VPN traffic cannot be diverted, for example 616 by the spoofing or manipulation of a computed path. 618 These requirements do not place any additional security requirements 619 on the PCECP above those described in [RFC4657], but the 620 application of PCE in support of VPNs does require that those 621 security requirements be correctly implemented and applied. 623 7. IANA Considerations 625 This document makes no requests for IANA action. 627 8. Acknowledgments 629 TBD 631 9. References 633 9.1. Normative References 635 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 636 requirements levels", RFC 2119, March 1997. 638 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and 639 McManus, J., "Requirements for Traffic Engineering Over 640 MPLS", RFC 2702, September 1999. 642 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 643 "Multiprotocol Label Switching Architecture", RFC 3031, 644 January 2001. 646 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 647 Architecture", RFC 3945, October 2004. 649 [RFC4026] Andersson, L., and Madsen, T., "Provider Provisioned 650 Virtual Private Network (VPN) Terminology", RFC 4026, 651 March 2005. 653 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 654 Computation Element (PCE)-Based Architecture", 655 RFC 4655, August 2006. 657 [RFC4657] Ash, J., and Le Roux, J-L., "Path Computation Element 658 (PCE) Communication Protocol Generic Requirements", 659 RFC 4657, September 2006. 661 9.2. Informative References 663 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., 664 and Malis, A., "A Framework for IP Based Virtual 665 Private Networks", RFC 2764, February 2000 667 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths 668 (LSP) Hierarchy with Generalized Multi-Protocol 669 Label Switching (GMPLS) Traffic Engineering (TE)", 670 RFC 4206, October 2005. 672 [RFC4208] G. Swallow et al., "Generalized Multiprotocol Label 673 Switching (GMPLS) User-Network Interface (UNI): 674 Resource ReserVation Protocol-Traffic Engineering 675 (RSVP-TE) Support for the Overlay Model", RFC 4208, 676 October 2005. 678 [RFC4761] Kompella, K., and Rekhter, Y., "Virtual Private 679 LAN Service (VPLS) Using BGP for Auto-discovery and 680 Signaling", RFC 4761, January 2007. 682 [RFC4762] Lasserre, M., and Kompella, K., "Virtual Private 683 LAN Services over MPLS", RFC 4762, January 2007. 685 [RFC4847] Takeda, T., "Framework and Requirements for Layer 1 686 Virtual Private Networks", RFC 4847, April 2007. 688 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3 689 Provider-Provisioned Virtual Private Networks 690 (PPVPNs)", RFC 4834, April 2007. 692 [RFC4927] Le Roux, J-L, Ed., "Path Computation Element 693 Communication Protocol (PCECP) Specific 694 Requirements for Inter-Area MPLS and GMPLS Traffic 695 Engineering", RFC 4927, June 2007. 697 [RFC5212] K. Shiomoto et al., "Requirements for GMPLS-Based 698 Multi-Region and Multi-Layer Networks (MRN/MLN)", 699 RFC 5212, July 2008. 701 [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the 702 Path Computation Element Communication Protocol 703 (PCECP)", RFC 5376, November 2008. 705 [RFC5394] Bryskin, I., Papadimitriou, D., and Berger, L., 706 "Policy-Enabled Path Computation Framework", RFC 707 5394, December 2008. 709 [RFC5440] Vasseur, JP., et al., "Path Computation Element 710 (PCE) Communication Protocol (PCEP)", RFC 5440, 711 March 2009. 713 [PCE-INTER-LAYER] Oki, E., "PCC-PCE Communication Requirements for 714 Inter-Layer Traffic Engineering", draft-ietf-pce- 715 inter-layer-req, work in progress. 717 [PCE-P2MP-REQ] Yasukawa, S. and Farrel, A., "PCC-PCE Communication 718 Requirements for Point-to-Multipoint Traffic 719 Engineering", draft-ietf-pce-p2mp-req, work in 720 progress. 722 10. Author's Address 724 Seisho Yasukawa (Ed.) 725 NTT Corporation 726 9-11, Midori-Cho 3-Chome 727 Musashino-Shi, Tokyo 180-8585, 728 Japan 729 Email: yasukawa.seisho@lab.ntt.co.jp 731 Adrian Farrel 732 Old Dog Consulting 733 EMail: adrian@olddog.co.uk 735 Full Copyright Statement 737 Copyright (c) 2009 IETF Trust and the persons identified as the 738 document authors. All rights reserved. 740 This document is subject to BCP 78 and the IETF Trust's Legal 741 Provisions Relating to IETF Documents in effect on the date of 742 publication of this document (http://trustee.ietf.org/license-info). 743 Please review these documents carefully, as they describe your rights 744 and restrictions with respect to this document.