Network Working Group Tomonori Takeda (Editor) Internet Draft NTT Proposed Status: Informational Expires: January 2005 July 2004 Applicability of GMPLS protocols and architectures to Layer 1 Virtual Private Networks draft-takeda-l1vpn-applicability-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides materials to show how existing Generalized Multiprotocol Label Switching (GMPLS) protocols and architectures, and current proposals for modifications to those protocols and architectures can be used to satisfy the requirements of Layer 1 Virtual Private Networks (L1VPNs). In addition, this document identifies any areas where additional protocol extensions or procedures are necessary so that GMPLS T.Takeda, et al. Expires January 2005 [Page 1] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 protocols can be used to satisfy the requirements of L1VPNs, and sets guidelines for possible solution work. 0. Summary (This section to be removed before publication as an RFC.) 0.1. Summary This document shows applicability of existing GMPLS protocols and architectures to L1VPNs. In addition, this document identifies several items where additional protocol extensions are necessary to meet the full set of L1VPN services. 0.2. Where does it fit in the picture of the IETF Work Services may be provisioned across layer 1 networks using GMPLS protocols. L1VPNs may be managed and operated using these protocols as described in this document. GMPLS protocols were developed within the IETF using IP addressing and based on IP and other Internet protocols. The IETF continues to work with GMPLS protocols, enhancing them and applying them to new requirements. VPN related work areas might also have points of interaction with the content of this document. 0.3. Justification L1VPN mailing list is setup to discuss issues related to L1VPNs. This document is intended to progress the work by showing applicability of existing documents (in 0.4), as well to identify several items where additional work is required. 0.4. Related Internet Documents The present draft discusses applicability of existing solutions drafts below to L1VPN service requirements mentioned in the following draft. o draft-takeda-l1vpn-framework-00.txt (Feb 2004) "Framework for Layer 1 Virtual Private Networks" This draft examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. Note this document is based heavily on the work of ITU-T Study Group 13 Question 11. This draft mainly discusses applicability of following solution drafts to L1VPN service requirements mentioned in the above draft. o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt (May 2004) "GVPN Services: Generalized VPN Services using BGP and GMPLS T.Takeda, et al. Expires January 2005 [Page 2] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 Toolkit" This draft describes a suite of port-based Provider-provisioned VPN services called Generalized VPNs (GVPNs) that uses BGP as a VPN auto-discovery and GMPLS as a signaling mechanism. o draft-ietf-ccamp-gmpls-overlay-04.txt (April 2004) "GMPLS UNI: RSVP Support for the Overlay Model" This memo addresses the application of GMPLS to the overlay model. In one section, the memo provides a description of how the overlay model may be used to support VPN connections across a core GMPLS network. Contents 1. Contributors ............................................. 4 2. Terminology .............................................. 4 3. Introduction ............................................. 4 4. General Guideline ........................................ 5 5. Applicability to Management-based Service Models ......... 5 5.1. Overview of the Service Models ........................... 6 5.2. Applicability of Existing Solutions ...................... 6 5.3. Additional Work Area(s) .................................. 6 6. Applicability to Signaling-based Service Models .......... 7 6.1. Overlay Service Models ................................... 7 6.1.1. Overview of the Service Models ........................... 7 6.1.2. Applicability of Existing Solutions ...................... 7 6.1.3. Additional Work Area(s) .................................. 7 6.2. Overlay Extension Service Models ......................... 8 6.2.1. Overview of the Service Models ........................... 8 6.2.2. Applicability of Existing Solutions ...................... 8 6.2.3. Additional Work Area(s) .................................. 9 7. Applicability to Signaling and Routing Service Models .... 9 7.1. Virtual Node Service Models .............................. 9 7.1.1. Overview of the Service Models ........................... 9 7.1.2. Applicability of Existing Solutions ...................... 9 7.1.3. Additional Work Area(s) .................................. 9 7.2. Virtual Link Service Models .............................. 10 7.2.1. Overview of the Service Models ........................... 10 7.2.2. Applicability of Existing Solutions ...................... 10 7.2.3. Additional Work Area(s) .................................. 10 7.3. Per VPN Peer Service Models .............................. 10 7.3.1. Overview of the Service Models ........................... 11 7.3.2. Applicability of Existing Solutions ...................... 11 7.3.3. Additional Work Area(s) .................................. 11 8. Management Aspect ........................................ 12 8.1. Fault Management ......................................... 12 8.2. Configuration Management ................................. 13 9. Discussion ............................................... 13 10. Security Considerations .................................. 14 11. IANA Considerations ...................................... 14 12. Acknowledgement .......................................... 14 T.Takeda, et al. Expires January 2005 [Page 3] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 13. Normative References ..................................... 14 14. Informative References ................................... 14 15. Authors' Addresses ....................................... 16 16. Intellectual Property Considerations ..................... 17 17. Full Copyright Statement ................................. 17 1. Contributors The details of this document are the result of contributions from several authors who are listed here in alphabetic order. Contact details for these authors can be found in a separate section near the end of this document. Adrian Farrel (Olddog Consulting) Hamid Ould-Brahim (Nortel Networks) Dimitri Papadimitriou (Alcatel) Tomonori Takeda (NTT) 2. Terminology The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-RTG], [PPVPN-TERM] and [L1VPN-FW]. 3. Introduction This document shows the applicability of existing Generalized Multiprotocol Label Switching (GMPLS) protocols and architectures to Layer 1 Virtual Private Networks (L1VPNs). In addition, this document identifies several items where additional protocol extensions or modifications are necessary to meet L1VPN services. In particular, this document shows section by section (from section 5 to 7) the applicability of GMPLS protocols and architectures to each L1VPN service model mentioned in [L1VPN-FW], along with additional work areas needed to fully support the requirements for each service model. Note management aspects some of which are common over various service models will be described separately in section 8. Note that discussion in this document is limited to areas where GMPLS protocols and architectures are relevant. As will be described in detail in this document, support of management-based service models, signaling-based service models and virtual node service models are well covered by existing documents, with minor extensions. Virtual link service models and per VPN peer service models are not explicitly covered by existing documents, but would be well realized by extending current GMPLS protocols and architectures. Also, as will be described in detail, the following are possible work T.Takeda, et al. Expires January 2005 [Page 4] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 areas where additional work would be required to fully support the requirements for each L1VPN service model. Some of the requirements are optional meaning that the additional work is also optional. The list of additional work areas will be updated in later versions of this document along with development of the additional or enhanced requirements and increased understanding of the issues. o MIB module for SPC o Resource management per VPN o Tunnel mechanisms o CE-PE TE link information o Control plane routing (routing information exchange related to control plane topology, per VPN control packet routing) o Signaling and routing for support of per VPN peer service models o Management aspect (fault management, configuration management) A MIB module for possible protocol extensions will also need to be studied. 4. General Guideline This section provides several general guidelines for L1VPN solutions. In other words, this section provides general requirements that any solution for any service model should consider. Note applicability to specific service models will be separately described in following sections. One important general guideline is that solutions should be incremental. In other words, the same mechanisms should be maximally reused in various service models, and as service models vary and additional functionalities are required, delta functionalities should be added. For example, in signaling-based service models and signaling and routing service models, it is highly desirable that the same signaling protocols are used, and routing functions are added or enhanced from signaling-based service models to signaling and routing service models. In addition, the following are general guidelines. - Solutions should consider interoperability with non-VPN devices (devices that do not support any specific L1VPN extension). - Solutions should be scalable and manageable. - Solutions should be secure. (i.e., providers should be able to screen and protect information based on their operational policies.) Note that some deployments may wish to support multiple L1 connection types (such as VC3, VC4, etc.) at the same time. Specific functionalities may need to be considered for these scenarios. This is for further study. 5. Applicability to Management-based Service Models T.Takeda, et al. Expires January 2005 [Page 5] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 5.1. Overview of the Service Models The customer and the provider communicate via a management interface. The provider management system(s) communicate with the PE/P to set up a connection. 5.2. Applicability of Existing Solutions SNMP MIB modules are one way to realize connection setup/deletion/modification from the management system(s). In particular, GMPLS-LSR-STD-MIB [LSR MIB] can control static connections, while GMPLS-TE-STD-MIB [TE MIB] can control signaled connections. As indicated in [L1VPN-FW], the specification of interface(s) between management system(s) is out of the scope of this document. 5.3. Additional Work Area(s) The following additional work areas are identified to support the Management-based Service Models. o MIB module for SPC (Soft Permanent Connection) For static connections, there is no required extension to the MIB Modules. For signaled connections, MIB modules may need to be extended to inform the ingress PE which CE-PE TE link should be used. Note that there are several other ways to control signaled connections without MIB module extensions. One such way is: (1) Use GMPLS-LSR-STD-MIB for CE-PE TE link and PE-P/PE TE link cross-connect at the ingress PE (2) Then use GMPLS-TE-STD-MIB to request signaling with egress control [EGRESS-CONTROL] However, this increases overhead in terms of message exchange and required states. As an alternative, extension of MIB modules for SPC is highly desirable. o Resource management per VPN In this type of service model, one optional requirement is resource management for a dedicated Data-Plane (the provider network partitions link resources per VPN for exclusive use by a particular VPN), and resource management for sharing the Data-Plane among a specific set of VPNs (the provider network assigns link resources to a specific set of VPNs). Note in [L1VPN-FW], the term U-Plane is T.Takeda, et al. Expires January 2005 [Page 6] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 generally used for Data-Plane. A simple way to meet this requirement is to implement resource management functionalities in the management system(s). However, if the PE/P need path computation locally, not relying on the management system(s), then support of resource management in PE/P (e.g., routing protocol extension) is necessary. This is especially beneficial in the case of dynamic restoration (restoration that does not reserve backup resources in advance). Note link coloring may be used for this purpose, but this eliminates the opportunity to use link coloring for other purposes (e.g., link coloring within VPNs). When path computation is done in the management system(s), it would be important that resource information is synchronized between the management system(s) and PE/P. 6. Applicability to Signaling-based Service Models 6.1. Overlay Service Models 6.1.1. Overview of the Service Models In this type of service model, there is no routing between the CE and the PE. Connections are setup by GMPLS signaling between the CE and the PE, and then across the provider network. 6.1.2. Applicability of Existing Solutions [GVPN] and [GMPLS-UNI] cover most of the requirements. Specifically, [GVPN] and [GMPLS-UNI] suggest signaling procedures for VPN connections (i.e., nesting). In addition, [GVPN] covers auto- discovery of VPN instances, and CE-PE pair address exchange between PEs by BGP. This allows PEs to perform address translation/mapping and connectivity restriction. [GVPN] calls the equivalent service model GVPW (Generalized Virtual Private Wire). The other possibility is to use IGP based node capability advertisement for auto-discovery and CE-PE pair addresses exchange (e.g., based on [OSPF-TE-CAP] with extensions). This requires implementation of such IGP. 6.1.3. Additional Work Area(s) The following additional work areas are identified to support the Overlay Service Models. o Resource management per VPN T.Takeda, et al. Expires January 2005 [Page 7] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 This is an optional requirement. Note there could be L1VPN solutions where path computation is conducted in centralized fashion (e.g., in management system(s), PCE). In this case, it is possible to implement resource management functionalities solely in those entities. However, implementing resource management functionality in PE/P is beneficial in certain scenarios, especially in restoration. See section 5.1.3 for related description. o Tunnel mechanism [GMPLS-UNI] and [GVPN] propose to use control plane tunnels between PEs. In addition, [GVPN] proposes to use BGP for auto-discovery of tunnel end points. However, [GMPLS-UNI] and [GVPN] do not specify a specific tunnel mechanism for default. Since tunnel mechanisms are strongly related to what information should be carried in auto- discovery mechanisms, a default tunnel mechanism may need to be specified. By doing this, required information to be exchanged by auto-discovery mechanisms can be identified. o CE-PE TE link information In signaling-based service models, it may be useful to consider not only TE link information within the provider network (PE-P, PE-PE TE links), but also remote CE-PE TE link information in path computation. This prevents connection setup failure due to lack of resources of remote CE-PE TE links. Therefore, CE-PE TE link information should be optionally propagated within the provider network to be used for path computation. Note, there could be a L1VPN solution where connectivity restriction, address translation/mapping etc. are performed not in PEs, but in other entities, such as a centralized server. In this case, the interface between the PE and the other entity may need to be specified. This could utilise existing mechanisms such as COPS or LDAP. Also note [GVPN] assumes that on a PE and a CE, control channels are separate for each VPN (i.e., CE-PE control channel is not shared by multiple VPNs). 6.2. Overlay Extension Service Models 6.2.1. Overview of the Service Models Requirements for this type of service models are almost the same as the ones for overlay service models. One additional requirement is membership information exchange between the CE and the PE. 6.2.2. Applicability of Existing Solutions T.Takeda, et al. Expires January 2005 [Page 8] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 [GVPN] covers the requirement to exchange membership information between the CE and the PE by BGP. 6.2.3. Additional Work Area(s) There is no additional work area beyond those identified for the Overlay Service Models. 7. Applicability to Signaling and Routing Service Models 7.1. Virtual Node Service Models 7.1.1. Overview of the Service Models In this type of service model, there is private routing between the CE and the PE or to be more precise between the CE routing protocol and the VPN routing protocol instance running on the PE. The provider network is considered as one private node from the customer's perspective. The routing information exchanged between the CE and the PE includes CE-PE link information, CE sites, and may include FA-LSPs (connections between CEs (or Cs)), CE sites routing information related to control plane topology. 7.1.2. Applicability of Existing Solutions [GVPN] covers most of requirements. Specifically, [GVPN] handles VPN routing by a per VPN database called GVSI (Generalized Virtual Switching Instance) in PEs. GVSIs are inter- connected by tunnel based control channel, and routing adjacency is established between them. BGP is used for auto-discovery of remote GVSI in the same VPN. GVSIs advertise VPN routing information by using the same ROUTER_ID to represent the provider network as one node. [GVPN] calls the equivalent service model GVPXC (Generalized Virtual Private Cross-Connect). 7.1.3. Additional Work Area(s) The following additional work areas are identified to support the Virtual Node Service Models. o Tunnel mechanism See section 6.1.3 o Resource management per VPN See section 6.1.3 o Control plane routing T.Takeda, et al. Expires January 2005 [Page 9] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 The provider network must carefully design whether to allow routing information related to control plane topology of the provider network to be leaked to the CE. If routing information related to control plane topology of the provider network is leaked to the CE, this routing information may need to be assigned private addresses. When the provider network supports routing information related to control plane topology of CE sites to be exchanged between the CE and the PE, and allows control packet transferring between CE sites (e.g., BGP packets), the provider network must carefully design how to route per VPN control packets received from the CE. 7.2. Virtual Link Service Models 7.2.1. Overview of the Service Models In this type of service model, virtual links are established between PEs. The routing information exchanged between the CE and the PE includes CE-PE TE link, CE sites, virtual links, and may include FA-LSP and CE sites routing information related to control plane topology. 7.2.2. Applicability of Existing Solutions Currently, there is no solution document for this type of service model. However, simple modifications of [GVPN], in addition to enhancements mentioned in section 7.1.3, may realize this type of service model. Modifications could be: - Do NOT modify ROUTE_ID of TE link information when advertising TE link to the CE (in OSPF packet header as well as in LSA header) - Setup FA-LSPs (GVSI-LSPs in [GVPN] term) between PEs to construct virtual links, and advertise these FA-LSPs in VPN routing. Note these FA-LSPs (virtual links) may be assigned private addresses, which means customer assigned addresses (or customers are allowed to configure addresses). This may require extension from current IGP behavior. Note there could be other ways to construct virtual links (e.g., virtual link without actually setting up a FA-LSP). 7.2.3. Additional Work Area(s) There is no additional work area from virtual node service models mentioned in section 7.1.3. Note resource management for dedicated Data-Plane is a mandatory requirement for virtual link service models. 7.3. Per VPN Peer Service Models T.Takeda, et al. Expires January 2005 [Page 10] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 7.3.1. Overview of the Service Models In this type of service model, the provider partitions TE links within the provider network per VPN. The routing information exchanged between the CE and the PE includes CE-PE TE links, CE sites, as well as partitioned portions of the provider network, and may include FA-LSPs and CE sites routing information related to control plane topology. Note that PEs may advertise abstracted routing information of the provider network to CEs. Note scalability must be carefully considered for advertising provider network routing information to the CE [INTER-DOMAIN FW]. 7.3.2. Applicability of Existing Solutions Currently, there is no solution document for this type of service model. However, [GVPN] provides several functionalities to meet this type of service model, as described in section 7.1.2. The other possibility is to use virtual router based approach (virtual routers (VPN instances) on every node which is the end point of at least one virtual link) [VR]. 7.3.3. Additional Work Area(s) As described in section 7.3.2, it could be possible to realize this service model by extending [GVPN] including following aspects, in addition to aspects mentioned in section 7.1.3. o Topology filtering The PE must choose TE links that are assigned to a specific VPN, and then advertise these TE links to a specific set of CEs corresponding to that VPN. o Topology abstraction The PE may abstract routing information of the provider network, and then advertise abstracted topology information to the CE. It means that the PE may construct a TE link where a direct physical link does not exit, or the PE may construct a single node to represent multiple nodes and TE links. Note scalability must be carefully considered [INTER-DOMAIN FW]. o ERO/RRO expansion/modification The CE may specify ERO with abstracted topology. The provider network must expand this ERO to match the provider network topology. Note this must be done even if strict route is specified in ERO passed from the CE. T.Takeda, et al. Expires January 2005 [Page 11] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 At the same time, when RRO is requested, RRO passed to the CE must be either edited to match the abstracted topology, or removed. o Private address The provider network may support private address for routing information provided to the customer. This means that the customer is able to assign private addresses to partitioned portion of TE links within the provider network. It would be also possible to realize this type of service models by using virtual router based approach (i.e., every PE/P (or PE/P that contains the end point of virtual links in abstracted topology) containing virtual router (VPN instance) for each VPN). Details for additional work areas for this type of service model are for further study. 8. Management Aspect 8.1. Fault Management The provider network may support various recovery techniques mentioned in [P&R TERM]. The customer may be able to specify the desired level of recovery in connection setup requests. The provider network may constitute a recovery domain (PE-PE recovery). Following aspects must be considered particularly for L1VPNs. o Shared recovery When the provider network supports shared recovery (e.g., shared mesh restoration), the provider network may be able to support shared recovery only within the same VPN and/or shared recovery among multiple VPNs. The default mode is to be specified. If the provider network supports both, the provider network must provide configuration tools for operators. o Extra traffic GMPLS supports functionalities called extra traffic. Extra traffic is user traffic carried over recovery resources when these resources are not being used for the recovery of normal traffic [P&R TERM]. When the provider network supports extra traffic, the provider network may be able to support extra traffic only within the same VPN and/or extra traffic among multiple VPNs. The default mode is to be specified. If the provider network supports both, the provider network must T.Takeda, et al. Expires January 2005 [Page 12] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 provide configuration tools for operators. 8.2. Configuration Management Some VPN specific configuration aspects must be considered, such as: o Configuration of resource management per VPN Physical link resources may be dedicated, share by a specific set of VPNs, or shared by any VPNs. The provider network must provide configuration tools for resource management per VPN. o Configuration of virtual links For virtual link service models and per VPN peer service models, the provider network must provide configuration tools for operators. o Configuration of service model for each VPN When the provider network supports multiple service models, the provider network must provide configuration tools for operators. 9. Discussion This section summarizes items that existing solutions may need to be extended to fulfill full set of functionalities to realize various L1VPN service models mentioned in sections 5 to 7. Note that several items that existing solutions are missing are optional features. For management-based service model, signaling- based service models and virtual node service models, existing solutions can be applied with few extensions for optional requirements. As described in section 7.2.2 and 7.2.3, there are no existing solutions to support virtual link service models and per VPN peer service models. For virtual link service models, however, minor extensions from existing solutions are expected to meet the requirements. Note the list of additional work areas will be updated in later versions of this document with development of additional or enhanced requirements and understanding of the issues. o MIB module for SPC - Optional, but highly required for management-based service models - Impact: MIB module o Resource management per VPN - Optional requirement for management-based, signaling-based and T.Takeda, et al. Expires January 2005 [Page 13] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 virtual node service models - Mandatory requirement for virtual link and per VPN peer service models (support of resource management for dedicated Data-Plane) - Impact: Routing o Tunnel mechanisms - Optional requirement for signaling-based service models and signaling and routing service models. - Impact: Auto-discovery o CE-PE TE link information - Optional requirement for signaling-based service models - Impact: Routing o Control plane routing - Optional requirement for signaling and routing service models - Impact: Routing o Signaling and routing for support of per VPN peer service models - Impact: Routing, signaling (details to be studied) o Management aspects - Default mode to be specified for shared recovery and extra traffic - Support of configuration tools mandatory for fault management and configuration management - Impact: mostly on operational tools (impacts on protocols to be studied) 10. Security Considerations TBD 11. IANA Considerations TBD 12. Acknowledgement We would like to thank Marco Carugi, Ichiro Inoue and Takumi Ohba for their useful comments and suggestions. 13. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [L1VPN-FW] Takeda, T., Editor "Framework for Layer 1 Virtual Private Networks", draft-takeda-l1vpn-framework, work in progress. 14. Informative References T.Takeda, et al. Expires January 2005 [Page 14] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Recommendation, September 2003. [Y.1313] Y.l1vpnarch - Layer 1 Virtual Private Network service and network architectures, ITU-T draft Recommendation. [GMPLS-UNI] Swallow, G., et al., "GMPLS UNI: RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay work in progress. [GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn- bgpgmpls, work in progress. [INTER-DOMAIN FW] Farrel, A., et al., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel-ccamp- inter-domain-framework, work in progress. [P&R TERM] Mannie, E., and Papadimitriou, D. (editors), "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", draft-ietf-ccamp-gmpls-recovery- terminology, work in progress. [LSR MIB] Nadeau, T., et al., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", draft-ietf- ccamp-gmpls-lsr-mib, work in progress. [TE MIB] Nadeau, T., et al., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", draft-ietf-ccamp- gmpls-te-mib, work in progress. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. T.Takeda, et al. Expires January 2005 [Page 15] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", draft-ietf-ccamp- gmpls-routing, work in progress. [EGRESS CONTROL] Berger, L., "GMPLS Signaling Procedure For Egress Control", draft-ietf-ccamp-gmpls-egress-control, work in progress. [OSPF-TE-CAP] Vesseur, J.P., et al., "OSPF MPLS Traffic Engineering capabilities", draft-vasseur-ccamp- ospf-te-caps, work in progress. [PPVPN-TERM] Andersson, L., and Madsen, T., "PPVPN terminology", draft-andersson-ppvpn-terminology, work in progress. [VR] Knight, P., Editor, ügNetwork based IP VPN Architecture using Virtual Routersüh, draft-ietf- l3vpn-vpn-vr, work in progress. 15. Authors' Addresses Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 Email: adrian@olddog.co.uk Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 Email: dimitri.papadimitriou@alcatel.be Tomonori Takeda NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 7434 Email : takeda.tomonori@lab.ntt.co.jp T.Takeda, et al. Expires January 2005 [Page 16] Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004 16. Intellectual Property Considerations 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. 17. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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. T.Takeda, et al. Expires January 2005 [Page 17]