Network Working Group                                    Seisho Yasukawa
Internet Draft                                                       NTT
Category: Informational
Expires: August 2006                                       February 2006

               PCC-PCE Communication Requirements for VPNs

                   draft-yasukawa-pce-vpn-req-00.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 functions of path
   computation 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 the 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 "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-00.txt                          February 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 [PCE-ARCH].

   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 [xxx] and VPLS [xxx]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] recently.

   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 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 some sophisticated traffic engineering mechanisms
     for the TE-LSPs that support more than one VPN.


S. Yasukawa                                                     [Page 2]


draft-yasukawa-pce-vpn-req-00.txt                          February 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 [PCE-ARCH]
   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].

   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
   the next section 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].

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), and is aware of
   the associated VPN ID.


S. Yasukawa                                                     [Page 3]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

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

   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 in order to make it simpler to guarantee service
   levels. 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. Protection Schemes and Resource Sharing

   The SLA negotiated between network provider and VPN customer will
   dictate the level of protection required within the network. A PCE
   can 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 certainly compute protection paths
   limited to a subset of the network resources. Full support of this
   function would, however, either require that PCE kept track of the
   VPNs that use shareable resources by updating its TED, or that PCE is
   fully stateful.

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.

S. Yasukawa                                                     [Page 4]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

   - 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 Protection Schemes

   The 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

   For a core network, support of VPNs with very many access points may
   cause significant scaling issues. 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 5]


draft-yasukawa-pce-vpn-req-00.txt                          February 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 [MRN-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-00.txt                          February 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
      [PCE-ARCH].

   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, of course, 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,
   known as Steiner, and shortest path).

   The complexity of the P2MP computation may make it particularly
   suitable to offload to a dedicated PCE.

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].

S. Yasukawa                                                     [Page 7]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

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 detect VPN membership automatically, 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 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.

4.2. Identification of Related VPNs

   Certain computations 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.

S. Yasukawa                                                     [Page 8]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

   - 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.

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 within the control plane 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].

   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.7. Point-to-Multipoint

   The requirements for PCECP to support path computation for P2MP LSPs
   are presented in [PCE-P2MP-REQ].






S. Yasukawa                                                     [Page 9]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

4.8. 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.

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 control 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 PCE 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.

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

S. Yasukawa                                                    [Page 10]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

   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 [PCE-ARCH] 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.

   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.




S. Yasukawa                                                    [Page 11]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

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.

   [PCE-ARCH]    Farrel, A., Vasseur, JP., and Ash, J., "Path
                 Computation Element (PCE) Architecture",
                 draft-ietf-pce-architecture, work in progress.

   [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.





S. Yasukawa                                                    [Page 12]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

   [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.

   [MRN-REQ]         K. Shiomoto et al., "Requirements for GMPLS-based
                     multi-region networks (MRN)", draft-shiomoto-ccamp-
                     gmpls-mrn-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-leroux-pce-pcecp-
                     interarea-reqs, work in progress.

   [PCE-INTER-AS]    Bitar, N., Zhang, R., and Kumaki, K., "Inter-AS PCE
                     Requirements", draft-bitar-zhang-interas-PCE-req,
                     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.

   [PCE-VPN-APPL]    Yasukawa, S., "Applicability of the PCE
                     Architecture to the Operation of VPNs", draft-
                     yasukawa-pce-vpn-applicability, 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: yasukawa.seisho@lab.ntt.co.jp




S. Yasukawa                                                    [Page 13]


draft-yasukawa-pce-vpn-req-00.txt                          February 2006

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
   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 14]