Network Working Group Seisho Yasukawa Internet Draft NTT Category: Informational Expires: March 2007 September 2006 PCC-PCE Communication Requirements for VPNs draft-yasukawa-pce-vpn-req-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. An important application of MPLS and GMPLS networks is Virtual Private Networks (VPNs) that may be constructed using Label Switched Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may be applied as a tool to compute the paths of such tunnels in order to achieve better use of the network resources and to provide better levels of service to the VPN customers. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements that are specific to the application of PCE to VPNs. S. Yasukawa [Page 1] draft-yasukawa-pce-vpn-req-01.txt September 2006 Contents 1. Terminology .................................................... 3 1.1. Conventions used in this document ............................ 3 1.2. PCE, VPN, MPLS and GMPLS Terminology ......................... 3 2. Introduction ................................................... 3 3. Core Network Requirements in Support of VPNs ................... 4 3.1. VPN-Specific Behavior ........................................ 5 3.1.1. Per-VPN Policy ............................................. 5 3.1.2. Per-VPN Constraints and Algorithms ......................... 5 3.1.3. Per-VPN Resources .......................................... 5 3.1.4. LSP Protection Schemes and Resource Sharing ................ 5 3.2. Customer Control of The Core Network ......................... 6 3.3. Private Address Spaces ....................................... 6 3.4. CE-CE Service Protection Schemes ............................. 6 3.5. Aggregation Schemes .......................................... 6 3.5.1. Sharing Core Tunnels ....................................... 6 3.5.2. Handling Core Scalability .................................. 7 3.6. Multicast Considerations ..................................... 7 3.6.1. Unicast or Multicast LSPs .................................. 7 3.6.2. P2MP Traffic Engineering ................................... 8 3.6.3. Aggregation onto P2MP LSPs ................................. 9 3.7. VPN establishment/addition/deletion .......................... 9 3.8. Interworking between multiple VPN domains .................... 9 4. PCECP Requirements for PCE Support of VPNs ..................... 9 4.1. Identification of VPN ........................................ 9 4.2. Identification of Related VPNs .............................. 10 4.3. Scoping of Addresses ........................................ 10 4.4. Cooperation between Customer PCE and Core PCE ............... 10 4.5. Path Diversity .............................................. 10 4.6. Point-to-Multipoint ......................................... 11 4.7. Incorporating path calculation during VPN membership discovery ................................................. 11 5. Manageability Considerations .... ............................. 11 5.1 Control of Function and Policy ............................... 11 5.2 Information and Data Models .................................. 11 5.3 Liveness Detection and Monitoring ............................ 11 5.4 Verifying Correct Operation .................................. 12 5.5 Requirements on Other Protocols and Functional Components .... 12 5.6 Impact on Network Operation .................................. 12 5.7 Other Considerations ......................................... 12 6. Security Considerations ....................................... 12 7. IANA Considerations ........................................... 13 8. Acknowledgments ............................................... 13 9. References .................................................... 13 9.1. Normative References ........................................ 13 9.2. Informative References ...................................... 14 10. Author's Address ............................................. 15 11. Intellectual Property Statement .............................. 15 S. Yasukawa [Page 2] draft-yasukawa-pce-vpn-req-01.txt September 2006 1. Terminology 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. PCE, VPN, MPLS and GMPLS Terminology PCE terminology is defined in [RFC4655]. Applicable MPLS terminology may be found in [RFC3031] and [RFC2702]. GMPLS terminology is defined in [RFC3945] VPN terminology can be found in [RFC4026] with additional terms in [L3MVPN-REQ] and [L1VPN-FW]. The reader is assumed to be familiar with this terminology. 2. Introduction The Virtual Private Network (VPN) is an important service offered by network providers to their customers. A lot of different VPN technologies such as IP-VPN and VPLS [RFC2764], [BGP-VPLS], [LDP-VPLS] are developed and deployed into many service providers' networks to enhance their service capabilities. VPN technologies have also has been extended to support multicast service [L3MVPN-REQ] and layer 1 [L1VPN-FW]. Multiprotocol Label Switching (MPLS) [RFC3031] and Generalized MPLS (GMPLS) [RFC3945] are often used to provide VPN solutions within provider core networks since Label Switched Paths (LSPs) provide traffic trunks that can be used to connect customers' VPN sites. These LSPs can be traffic engineered to help meet service level agreements (SLAs) and to enhance the manageability of providers' networks. To meet customer demands and to realize competitive VPN network infrastructures, one promising possibility for service providers (SPs) is to deploy a common IP/MPLS network infrastructure for several VPN services. To realize this, the core network operator faces the following challenges. - The SP must accommodate within a common IP/MPLS core network multiple VPN services which might have different network policies. This may require sophisticated traffic engineering mechanisms for the TE-LSPs that support more than one VPN. S. Yasukawa [Page 3] draft-yasukawa-pce-vpn-req-01.txt September 2006 - The SP must introduce automatic VPN establishment/addition/deletion mechanisms on top of an IP/MPLS core network to reduce their Operational Expenditure (OPEX). This requires some automatic path calculation and setup mechanisms during VPN establishment/addition/ deletion processes. - The SP must introduce VPN interworking functions that enable interworking between multiple domains of the same VPN service (e.g., Inter-AS operation), and interworking between multiple VPN service networks. Designing TE-LSPs is a key technical component to meet these challenges. The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing network paths and routes based on a network graph, and applying computational constraints. PCE is applicable to the computation of traffic engineered paths for MPLS and GMPLS LSPs, and so it is natural to seek to apply the same technology to VPNs. The specific applicability of PCE to VPNs is discussed in [PCE-VPN-APPL]. In the PCE architecture, the Path Computation Element Communication Protocol (PCECP) is used to exchange path computation requests and responses between Path Computation Clients (PCCs) and PCEs, and also between PCEs. Generic requirements for PCECP are presented in [PCE-COM-REQ]. PCECP is described in [PCECP]. This document presents a set of requirements for the Path Computation Element Communication Protocol (PCECP) when PCE is used in support of VPNs. Specific requirements for PCECP in support of point-to-multipoint path computation such as might be used in support of multicast VPNs are described in [PCE-P2MP-REQ]. 3. Core Network Requirements in Support of VPNs This section is not intended to describe the function of VPNs, nor to provide a full description of how core networks support VPNs. Its purpose is to enumerate the principal features and functions that are used to support VPNs within a core network and with which PCE might be able to assist. This material is only present to give context to Section 4 that lists the specific PCECP requirements in support of VPNs - for a fuller discussion of the use of PCE to support VPNs see [PCE-VPN-APPL]. S. Yasukawa [Page 4] draft-yasukawa-pce-vpn-req-01.txt September 2006 3.1. VPN-Specific Behavior 3.1.1. Per-VPN Policy A core network may apply different policies to the VPN connections established on behalf of different VPNs. Some policy decisions may be made at the time of path computation and could, therefore, be implemented through PCE provided that PCE has access to the correct policy information (perhaps through a policy server [PCE-POLICY]), and is aware of the associated VPN ID. 3.1.2. Per-VPN Constraints and Algorithms It is conceivable that different path computation behavior might be applied for the VPN connections belonging to different VPNs. This might, for example, reflect the different SLAs made for the different VPN services/customers. PCE can implement such differences in computational characteristics through specific requests or by being configured to provide different default behaviors according to the VPN ID. 3.1.3. Per-VPN Resources In order to make it simpler to guarantee service levels core network resources may be assigned as reserved for use in support of a specific VPN or to be shared amongst only a subset of the total number of VPNs. This division of resources has an obvious impact on path computation and, provided the information can be made available to PCE in its traffic engineering database (TED) and that the VPN ID is supplied along with the path computation request, PCE can provide a path that conforms to the resource allocation configuration. 3.1.4. LSP Protection Schemes and Resource Sharing The SLA negotiated between network provider and VPN customer will dictate the level of LSP protection required within the network. A PCE can be used to compute protected (i.e. resource disjoint) paths. Some protection schemes (1:n, extra traffic, etc.) allow resources used for protection paths to be shared. It may be a condition of the SLA that protection resources used to support one VPN are not shared outside that VPN, or are shared only with a subset of other VPNs. This might be a condition imposed for security or to improve protection guarantees. PCE can compute protection paths limited to a subset of the network resources. Full support of this function would, however, either require that PCE keep track of the VPNs that use shareable resources by updating its TED, or that PCE is fully stateful. S. Yasukawa [Page 5] draft-yasukawa-pce-vpn-req-01.txt September 2006 3.2. Customer Control of The Core Network The customer network may wish to exert some control over the path of the VPN connection in the core network using techniques such as those in [RFC4206] and [RFC4208]. Such control may be expressed as inclusion constraints to the computation of the path of the VPN connection LSP, and PCE can compute paths with such constraints. 3.3. Private Address Spaces VPNs may operate private address spaces. This only has two consequences for the core network. - Reachability information may be required to convert the tuple {VPN ID, destination CE address} to the target destination PE address in order that a PE-to-PE LSP can be set up across the core network. Provided that PCE is configured with or learns the appropriate mapping tables and knows the VPN ID, it can provide this translation as part of the path computation. The target address would need to be flagged as a CE address and not as the destination of the core LSP. - The customer network may exert some control over the path of the VPN connection in the core network as described in Section 3.3. In this case, the core addresses supplied from the customer network to the source PE in an explicit route may be expressed using the customer VPN's private address space. Again, PCE is capable of providing the required translation as part of the path computation operation. 3.4. CE-CE Service Protection Schemes The LSP protection described in Section 3.1.4 applies to PE-PE connections. It is also possible that the VPN will wish to operate CE-CE protection by forming separate CE-CE connections over the core network, usually by connecting each CE to more than one PE. Such CE-CE connections need to use disjoint paths within the core network, but unless the VPN exerts control over these paths (see Section 3.2) the responsibility for ensuring diversity is delegated to the core network. Since the CE-CE connections are established separately, the core network cannot compute a pair of mutually disjoint paths. Instead, the second path must be computed to avoid the resources of the first path. PCE can perform such a computation using the details of the first path as exclusions in the second computation. 3.5. Aggregation Schemes Support of VPNs with very many access points may cause significant scaling issues for a core network. Similarly, the support of a large number of VPNs may cause problems. Aggregation solutions may be applied to improve scaling within the core network. PCE can perform such computations. 3.5.1. Sharing Core Tunnels Where a pair of PEs both provide access to a set of VPNs, there is no requirement for multiple LSP tunnels across the core between the PEs. Traffic between the VPN sites can share a tunnel. A stateful PCE that is requested to compute the path of a new PE-PE LSP might be able to indicate that an existing LSP would be suitable. This function, however, might be more appropriately implemented in a VPN Manager component [PCE-VPN-APPL]. S. Yasukawa [Page 6] draft-yasukawa-pce-vpn-req-01.txt September 2006 3.5.2. Handling Core Scalability Core network scalability may become an issue when mesh connectivity is required between very many PEs since this may result in exceptionally many LSPs crossing the middle of the network. One mechanism to handle this is to build a mesh of hierarchical LSP tunnels within the core of the core network, and to use these to provide forwarding adjacencies [RFC4206] or to operate a layered (client/server) network [MLN-REQ]. PCE can compute the paths of PE-PE LSPs that use these core tunnels as forwarding adjacencies. Alternatively, when a multi-layered approach is taken, PCE may be an ideal computation tool where inter-layer or separate layer TE visibility is available [PCE-INTER-LAYER]. 3.6. Multicast Considerations VPNs may be required to support multicast traffic [L3MVPN-REQ]. Various solutions have been proposed including some that use traffic engineered MPLS LSPs within the core network. 3.6.1. Unicast or Multicast LSPs VPN connectivity for multicast VPNs may be provided by unicast or multicast LSPs. Data sourced through a CE and passed to a PE must be distributed across the network and delivered through multiple PEs to many CEs that participate in the same VPN. There are three models as follows. a. PE Replication. In this model multicast traffic is replicated by the ingress PE and distributed on unicast (point-to-point) LSPs to the egress PEs. The egress PEs may, themselves, be responsible for further replication if there are multiple attached CEs. This model does not place any different requirements on the traffic engineering model from unicast VPNs. PCE can be used in the same way. b. Rendezvous Point Replication Replication can be placed within the network through the use of a rendezvous point. A unicast LSP carries data from the ingress PE to the rendezvous point where it is replicated and distributed to egress PEs along other unicast LSPs. Rendezvous points may also be used to support multicast VPNs with multiple data sources. Further, a hierarchy of such points of S. Yasukawa [Page 6] draft-yasukawa-pce-vpn-req-01.txt September 2006 replication could be constructed to achieve better network utilization. Again, the point-to-point LSPs are no different from the TE LSPs described before and PCE can be used to compute their paths. PCE might also be used to select an appropriate rendezvous point for a traffic flow in a VPN, and where a hierarchy of replication points is used, PCE could coordinate them so that no egress PCE receives duplicate data. These latter functions, however, are more suited to a VPN Manager [PCE-VPN-APPL] leaving PCE to perform path computation operations consistent with its specification in [RFC4655]. c. Multicast LSPs Most efficient use of the core network can be made by establishing multicast LSPs, otherwise known as point-to-multipoint (P2MP) LSPs. These provide a distribution tree from the ingress PE to the egress PEs. Data replication happens within the forwarding plane at branch nodes. It is possible to combine these three models in any mix. PCE may be particularly helpful in identifying existing shareable LSPs that can determine what mixture to use. 3.6.2. P2MP Traffic Engineering The computation of the routes for P2MP trees is non-trivial as suitable branch nodes must be located within the core network. The computation is made more complex by various factors including different replication capabilities of the core network nodes and different objective optimization criteria (such as least sum cost paths known as Steiner trees, and shortest paths to each destination). The complexity of the P2MP computation makes it particularly suitable to offload to a dedicated PCE. S. Yasukawa [Page 8] draft-yasukawa-pce-vpn-req-01.txt September 2006 3.6.3. Aggregation onto P2MP LSPs Aggregation of traffic from multicast VPNs onto core P2MP LSPs is more complicated than for unicast traffic. In the unicast case (see Section 3.5.1) it is possible for all traffic between a pair of PEs to share the same tunnel, but in the multicast case, sharing a tunnel requires that there is a common set of egress PEs or that receiving PEs can discard unwanted traffic. Various solutions to this problem are possible: each requires that the paths of P2MP LSPs are computed and that is something with which PCE can assist. But the fundamental problem of determining how many tunnels to use and how to multiplex traffic onto the tunnels is a function best performed by a VPN manager [PCE-VPN-APPL]. 3.7. VPN establishment/addition/deletion BGP-based auto-discovery mechanisms are widely deployed in VPNs for membership discovery. The auto-discovery mechanism is used not only to automatically detect VPN membership, but also to automatically establish PE-to-PE tunnels after detecting VPN membership. Combining this auto-discovery mechanism and the LSP establishment mechanism, one can establish the VPN's PE-to-PE LSPs automatically. But one challenge of this approach is that when multiple independent PEs set up PE-to-PE LSPs independently, it is impossible to set up the LSPs to be optimal considering network-wide constraints. To accomplish this network-wide optimization, some centralized path computation element is necessary to coordinate the computation of the paths of the LSPs, and PCE can perform this function. 3.8. Interworking between multiple VPN domains To enable interworking between multiple VPN domains (such as Inter-AS procedures for IP-VPNs, or multi-hop pseudowire procedures for VPLS) some smart, end-to-end-based path calculation is necessary. PCE can perform this kind of path calculation. 4. PCECP Requirements for PCE Support of VPNs This section sets out requirements that must be met by the PCE Communications Protocol (PCECP) when PCE is used to support path computation for VPNs. These requirements supplement those common requirements described in [PCE-COM-REQ], and are complementary to additional requirements present in other requirements documents such as [PCE-INTER-AREA], [PCE-INTER-AS], [PCE-INTER-LAYER]. 4.1. Identification of VPN Since computations may be specific to the VPN that will use the core LSP, it MUST be possible to specify the VPN ID on a path computation request. S. Yasukawa [Page 9] draft-yasukawa-pce-vpn-req-01.txt September 2006 4.2. Identification of Related VPNs Certain computations of paths for VPN connections may need to exclude or include core resource sharing or traffic aggregation by identifying specific other VPNs. Thus is MUST be possible to specify a list of related VPN IDs on a path computation request. This list SHOULD be accompanied by a context so that it is possible to provide lists of related VPNs for different purposes on the same path computation request. Contexts identified at this time are as follows: - Allowed to share network resources with LSPs for the listed VPNs. - Prohibited from sharing network resources with LSPs for the listed VPNs. - Allowed to carry traffic for the other listed VPNs. - Prohibited from carrying traffic for the other listed VPNs. Further contexts may be defined in the future and the protocol field that defines context SHOULD be reasonably extensible. 4.3. Scoping of Addresses If the addresses used in any part of a path computation request or response are not within the scope of the network for which the computation is to be performed (for example, they are customer VPN addresses for core network nodes) this needs to be identified to the PCE. A path computation request MUST allow the PCC to indicate that certain addresses are in the scope of the customer VPN. 4.4. Cooperation between Customer PCE and Core PCE In order for cooperation between customer and core PCEs to be most efficient, it SHOULD be possible for a path computation request to identify the desired cooperating PCEs. It SHOULD also be possible for a path computation response to identify other PCEs for use at further stages in the LSP establishment process. How this information is conveyed in signaling messages is beyond the scope of PCE. 4.5. Path Diversity Path protection schemes require that path computation requests MUST be able to indicate diversity requirements. PE-PE protection requires that a single path computation request MUST be able to request multiple paths meeting specified diversity requirements. This requirement is already covered in [PCE-COM-REQ]. S. Yasukawa [Page 10] draft-yasukawa-pce-vpn-req-01.txt September 2006 CE-CE protection requires that a path computation request MUST be able to request specific diversity from another, previously computed path by specifying the links and nodes of that path. This requirement for exclusions is already covered in [PCE-COM-REQ]. 4.6. Point-to-Multipoint The requirements for PCECP to support path computation for P2MP LSPs are presented in [PCE-P2MP-REQ]. 4.7. Incorporating path calculation during VPN membership discovery In order for a PE (PCC) to request a PCE to calculate PE-to-PE VPN paths and for the PE to set up these LSPs during the VPN establishment/addition/deletion process, PCE MUST monitor VPN membership discovery. In this context, "monitor" means that the PCE's network map MUST be updated to include VPN membership information. For further discussion of how the PCE network map may be constructed refer to [RFC4655]. 5. Manageability Considerations The use of PCECP to compute paths in support of VPNs extends the manageability considerations for PCECP. 5.1 Control of Function and Policy No additional controls of function or policy are required over and above those that are required for basic operation of PCECP. However, it should be noted that separate controls may be required for each VPN that is supported. Further, the customer may require access to some or all of the controls for their VPN. 5.2 Information and Data Models The PCECP may be modeled and controlled through MIB modules. It may be desirable to divide such modeling and control per VPN. In particular, where access to MIB data or control is provided to customers so that they can gather statistics or manage the behavior of PCEs for their VPN, clear separation must be enforced so that customers have no control over or visibility into each other's VPN operation. 5.3 Liveness Detection and Monitoring No additional liveness detection and monitoring facilities are required to be added to PCECP because of VPN support. S. Yasukawa [Page 11] draft-yasukawa-pce-vpn-req-01.txt September 2006 5.4 Verifying Correct Operation There are no additional requirements for verifying the correct operation of the PCECP. If information is made available to allow an operator to verify the correct computation of a path, care must be taken over precisely what information is exposed to customers so as to preserve customer confidentiality. This topic, however, falls outside the scope of manageability considerations for the PCECP. 5.5 Requirements on Other Protocols and Functional Components The manageability of PCECP places certain requirements on the manageability of other protocols, in particular on the underlying transport protocol. The application of PCE to VPNs does not extend PCECP's requirements to be able to manage other protocols or functional components. It should be noted that the applicability of PCE to VPNs has significant impact on the management and operation of other protocols used for PCE discovery, VPN membership discovery and advertisement, and LSP signaling. These topics are out of scope for this document, but are discussed in [PCE-VPN-APPL]. 5.6 Impact on Network Operation As described in [RFC4655] the use of PCE may impact the operation of a network. Additionally, as described in [PCE-VPN-APPL], there are consequences of applying PCE to VPNs. The PCECP is required to handle issues of congestion that are caused by significant numbers of computation requests issued in a small period of time. In practice, separate PCEs might be used to service the requirements of different VPNs with the result that this problem might not be so significant. Otherwise, the extensions to PCECP to cover the use of PCE for VPNs do not have additional impact on the operation of the core network. 5.7 Other Considerations No other management considerations arise. 6. Security Considerations Security is an important feature for VPNs. VPN customers expect and require that their data and service information is kept secure from interception or interference by other users of the provider network. S. Yasukawa [Page 12] draft-yasukawa-pce-vpn-req-01.txt September 2006 Since the provider network will possibly support multiple VPNs as well as other services, the traffic of an individual VPN and the computation information that applies to that VPN are vulnerable within the provider network. It is important that the PCECP exchanges are protected so that there is no visibility of computation information and so that VPN traffic cannot be diverted, for example by the spoofing or manipulation of a computed path. These requirements do not place any additional security requirements on the PCECP above those described in [PCE-COM-REQ], but the application of PCE in support of VPNs does require that those security requirements be correctly implemented and applied. 7. IANA Considerations This document makes no requests for IANA action. 8. Acknowledgments The author would like to thank Adrian Farrel for his input to this draft. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and McManus, J., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching Architecture", RFC 3945, October 2004. [RFC4026] Andersson, L., and Madsen, T., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. S. Yasukawa [Page 13] draft-yasukawa-pce-vpn-req-01.txt September 2006 [PCE-COM-REQ] Ash, J., Le Roux, J-L., et al., "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in progress. 9.2. Informative References [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC4208] G. Swallow et al., "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [L1VPN-FW] Takeda, T., "Framework and Requirements for Layer 1 Virtual Private Networks", draft-ietf-l1vpn- framework, work in progress. [L3MVPN-REQ] Morin, T., "Requirements for Multicast in L3 Provider-Provisioned VPNs", draft-ietf-l3vpn- ppvpn-mcast-reqts, work in progress. [MLN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-reqs, work in progress. [PCE-INTER-AREA] Le Roux, J-L., "PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area (G)MPLS Traffic Engineering ", draft-ietf-pce-pcecp-interarea-reqs, work in progress. [PCE-INTER-AS] Bitar, N., et al., "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", draft-ietf-pce-interas-pcecp-reqs, work in progress. [PCE-INTER-LAYER] Oki, E., "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", draft-ietf-pce- inter-layer-req, work in progress. [PCE-P2MP-REQ] Yasukawa, S., "PCC-PCE Communication Requirements for Point-to-Multipoint Traffic Engineering", draft-yasukawa-pce-p2mp-req, work in progress. S. Yasukawa [Page 14] draft-yasukawa-pce-vpn-req-01.txt September 2006 [PCE-VPN-APPL] Yasukawa, S., "Applicability of the PCE Architecture to the Operation of VPNs", draft- yasukawa-pce-vpn-applicability, work in progress. [PCECP] Vasseur, JP., et al., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work in progress. [PCE-POLICY] Bryskin, I., Papadimitriou, D., and Berger, L., "Policy-Enabled Path Computation Framework", draft-ietf-pce-policy-enabled-path-comp, work in progress. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and Malis, A., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000 [BGP-VPLS] Kompella, K., and Rekhter, Y., "Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling", draft-ietf-l2vpn-vpls-bgp, work in progress. [LDP-VPLS] Lasserre, M., and Kompella, K., "Virtual Private LAN Services over MPLS", draft-ietf-l2vpn-vpls-ldp, work in progress. 10. Author's Address Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: s.yasukawa@hco.ntt.co.jp 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this S. Yasukawa [Page 15] draft-yasukawa-pce-vpn-req-01.txt September 2006 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. S. Yasukawa [Page 16]