Network Working Group Internet Draft Tomonori Takeda (Editor) Proposed Status: Informational NTT Expires: May 2007 November 2006 Applicability analysis of Generalized Multiprotocol Label Switching (GMPLS) protocols for the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode draft-ietf-l1vpn-applicability-enhanced-mode-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 This document provides an applicability analysis on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to satisfy the requirements of the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode. L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Enhanced Mode of operation features exchange of routing information between the layer 1 network and the customer domain. T.Takeda, et al. Expires May 2007 [Page 1] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy the requirements of the L1VPN Enhanced Mode, and provides guidelines for potential extensions. Table of Contents 1. Contributors...................................................2 2. Terminology....................................................3 3. Introduction...................................................3 3.1 Work Items....................................................3 3.2 Existing Solutions Drafts.....................................4 4. General Guidelines.............................................4 5. Overlay Extension Service Model................................5 5.1 Overview of the Service Model.................................5 5.2 Applicability of Existing Solutions...........................6 5.3 Additional Work Area(s).......................................6 6. Virtual Node Service Model.....................................6 6.1 Overview of the Service Model.................................6 6.2 Applicability of Existing Solutions...........................6 6.3 Additional Work Area(s).......................................7 7. Virtual Link Service Model.....................................7 7.1 Overview of the Service Model.................................7 7.2 Applicability of Existing Solutions...........................7 7.3 Additional Work Area(s).......................................7 8. Per-VPN Peer Service Model.....................................8 8.1 Overview of the Service Model.................................8 8.2 Applicability of Existing Solutions...........................8 8.3 Additional Work Area(s).......................................8 9. Discussion.....................................................9 10. Manageability Considerations..................................9 11. Security Considerations......................................10 12. References...................................................10 12.1 Normative References........................................10 12.2 Informative References......................................10 13. Acknowledgments..............................................12 14. Author's Addresses...........................................12 15. Intellectual Property Consideration..........................13 16. Full Copyright Statement.....................................13 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. Deborah Brungard (AT&T) Adrian Farrel (Old Dog Consulting) T.Takeda, et al. Expires May 2007 [Page 2] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 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], [RFC4202], [RFC4026] and [L1VPN-FW]. 3. Introduction This document shows the applicability of existing Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode. In addition, this document identifies several areas where additional protocol extensions or modifications are needed to meet the L1VPN Enhanced Mode service requirements set out in [L1VPN-FW]. In particular, this document shows section by section (from Section 5 to 8) the applicability of GMPLS protocols and mechanisms to each sub-model of the Enhanced Mode mentioned in [L1VPN-FW], along with additional work areas needed to fully support the requirements for each sub-model. Note that discussion in this document is limited to areas where GMPLS protocols and mechanisms are relevant. As will be described in this document, support of the Overlay Extension service model and the Virtual Node service model are well covered by existing protocol mechanisms already described in other documents, with only minor protocol extensions required. The Virtual Link service model and the Per-VPN Peer service model are not explicitly covered by existing documents, but can be realized by extending current GMPLS protocols and mechanisms as described in this document. The following section lists areas where additional work may be required to fully support the requirements for each sub-model. Some of the requirements are optional, therefore the additional work is also optional. Commonalities of mechanisms over various sub-models, as well as over the L1VPN Basic Mode need to be considered. Also, various mechanisms should be coordinated in such a way that services are provided in a fully functional manner. 3.1 Work Items T.Takeda, et al. Expires May 2007 [Page 3] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 This list of additional work areas is a summary derived from the main body of this document. The list will be updated in later versions of this document along with the development of the additional or enhanced requirements and increased understanding of the issues. As work progresses on protocol extensions, this list will be updated to remove completed items, and the body of this document will be updated to describe the analysis of protocol extensions. The intention is that this whole section is removed when the work has been completed and this document progresses to become an RFC. o Routing representation (how a VPN should be represented in routing, e.g., single area, multi-area, multi-AS). See Sections 6.3 and 7.3. o Signaling and routing for support of the Per-VPN Peer service model. See Section 8.3. 3.2 Existing Solutions Drafts This section lists existing solution documents that describe how the L1VPN Enhanced Mode may be constructed using the mechanisms of GMPLS. This document draws on those solutions and explains their applicability and suggests further extensions to make the solutions more closely match the framework described in [L1VPN-FW]. Further solution documents may be listed in a future version of this document. o [GVPN] describes a suite of port-based Provider-provisioned VPN services called Generalized VPNs (GVPNs) that use BGP for VPN auto-discovery and GMPLS as a signaling mechanism. o [L1VPN-BM] addresses the L1VPN Basic Mode signaling. Note that although [L1VPN-BM] specifies signaling mechanisms for L1VPN Basic Mode, it is applicable to the L1VPN Enhanced Mode, unless otherwise specified. Therefore, main focus of this document is how to realize routing related information exchange between a CE and a PE. 4. General Guidelines This section provides general guidelines for L1VPN solutions. Note that applicability to specific sub-models will be separately described in following sections. One important general guideline is that protocol mechanisms should be re-used where possible. This means that solutions should be incremental, building on existing protocol mechanisms rather than developing wholly new protocols. Further, as service models are extended or developed resulting in the requirement for additional functionalities, deltas should be added to the protocol mechanisms rather than developing new techniques. [L1VPN-FW] describes how the T.Takeda, et al. Expires May 2007 [Page 4] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 service models can be seen to provide "cascaded" functionality, and this should be leveraged to achieve re-use of protocol extensions so that, for example, it is highly desirable that the same signaling protocols and extensions are used in both the Basic Mode and the Enhanced Mode. In addition, the following are general guidelines. - The support of L1VPNs should not necessitate any change to core (P) devices. Therefore, any protocol extensions made to facilitate L1VPNs need to be made in a backward compatible way allowing GMPLS aware P devices to continue to function. - Customer (C) devices not directly involved in providing L1VPN services should also be protected from protocol extensions made to support L1VPNs. Again, such protocol extensions need to be backward compatible. Note however, that some L1VPN service models allow for VPN connectivity between C devices rather than between CE devices: in this case, the C devices may need to be aware of protocol extensions. - Solutions should aim to minimize the protocol extensions on CE devices. - Solutions should be scalable and manageable. Solutions should not require L1VPN state to be maintained on the P devices as much as possible. - Solutions should be secure. Providers should be able to screen and protect information based on their operational policies. - Solutions should provide an operational view of the L1VPN for the customer and provider. There should be a common operational and management perspective in regard to other (L2 and L3) VPN services. 5. Overlay Extension Service Model 5.1 Overview of the Service Model This service model complements the Basic Mode and may assume all of the requirements, solutions and work items for that model. In this service model, a CE receives from its attached PEs a list of TE link addresses to which it can request a VPN connection (i.e., membership information). The CE may also receive some TE information concerning these CE-PE links within the VPN (e.g., switching type). The CE does not receive any of the following from the PE. - Routing information about the core provider network. - Information about P device addresses. - Information about P-P, PE-P or PE-PE TE links. T.Takeda, et al. Expires May 2007 [Page 5] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 - Routing information about other customer sites. The CE may have access to routing information about the remainder of the VPN (C-C and CE-C links), but this is exchanged by control plane tunneling on the CE-CE connections and is not passed to the CE in the control plane exchange between PE and CE. 5.2 Applicability of Existing Solutions The following are required in this service model (in addition to requirements in the L1VPN Basic Mode). - VPN membership information exchange between a CE and PE. - CE-PE TE link information exchange between a CE and a PE. [GVPN] covers the requirement to exchange membership information between the CE and the PE based on BGP. Furthermore, [BGP-TE] allows the exchange of CE-PE TE link information between a CE and a PE. 5.3 Additional Work Area(s) None. 6. Virtual Node Service Model 6.1 Overview of the Service Model In this service model, there is a private routing exchange between the CE and the PE, or to be more precise between the CE routing protocol instance 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 TE link information, customer network (i.e., remote CE sites), and may include TE links (Forwarding Adjacencies) connecting CEs (or Cs) across the provider network as well as control plane topology information from the customer network (i.e., CE sites). 6.2 Applicability of Existing Solutions The following are required in this service model. - VPN routing - Signaling: CE-CE Label Switching Path (LSP) setup, deletion, and modification [GVPN] covers most of the requirements. Specifically, [GVPN] handles VPN routing by a per VPN database called the GVSI (Generalized Virtual Switching Instance) held in each PE. T.Takeda, et al. Expires May 2007 [Page 6] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 GVSIs are inter-connected by tunnel-based control channels, and routing adjacencies are established between them. BGP is used for auto-discovery of remote GVSIs (VPN auto-discovery) in the same VPN. GVSIs advertise VPN routing information by using a single ROUTER_ID to represent the provider network as one node. It is also possible to use IGP-based auto-discovery (based on [L1VPN- OSPF-DISC]), instead of BGP-based auto-discovery. Signaling mechanisms are covered by [L1VPN-BM]. 6.3 Additional Work Area(s) o Routing Representation [GVPN] allows flexible routing configuration for each VPN (e.g., single IGP area, multiple IGP areas, or multiple ASes). However, it may be valuable to consider how to represent a VPN in routing. This may simplify the solution (e.g., in terms of scalability). This requires further discussion. 7. Virtual Link Service Model 7.1 Overview of the Service Model In this service model, virtual links are established between PEs. A virtual link is assigned to each VPN and disclosed to the corresponding CEs. The routing information exchanged between the CE and the PE includes CE-PE TE links, customer network (i.e., remote CE sites), virtual links (i.e., PE-PE links) assigned to each VPN, and may include CE-CE (or C-C) Forwarding Adjacencies as well as control plane topology from the customer network (i.e., CE sites). 7.2 Applicability of Existing Solutions Currently, there is no solution document for this type of service model. 7.3 Additional Work Area(s) Simple modifications of [GVPN], in addition to enhancements mentioned in Section 6.3, may realize this type of service model. Modifications could be: - Do NOT modify the ROUTER_ID of the TE link information when advertising a CE-PE TE link to the CE (in the OSPF packet header as well as in the LSA header). T.Takeda, et al. Expires May 2007 [Page 7] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 - Set up Forwarding Adjacency LSPs (FA-LSPs, GVSI-LSPs in [GVPN] terms) between PEs to construct virtual links, and advertise these FAs in VPN routing. Note these FAs (virtual links) may be assigned private addresses, which means customer assigned addresses (or that customers are allowed to configure addresses). This may require extensions to current IGP behavior. There could be other ways to construct virtual links (e.g., virtual links without actually setting up an FA-LSP [MRN-REQ]). Resource management for a dedicated data plane is a mandatory requirement for the Virtual Link service model. This could be realized by assigning pre-configured FA-LSPs to each VPN routing protocol instance (no protocol extensions needed) in order to instantiate the necessary FAs. Note that as in the case of the Virtual Node service model, solution details may differ depending on the routing representation. This requires further discussion. 8. Per-VPN Peer Service Model 8.1 Overview of the Service Model In this 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, customer network (i.e., remote CE sites), as well as partitioned portions of the provider network, and may include CE-CE (or C-C) Forwarding Adjacencies and control plane topology from customer network (i.e., CE sites). Note that PEs may abstract routing information about the provider network and advertise it to CEs. Note scalability must be carefully considered for advertising provider network routing information to the CE [INTER-DOMAIN-FW]. 8.2 Applicability of Existing Solutions Currently, there is no solution document for this type of service model. 8.3 Additional Work Area(s) There are two approaches for this service model. o Signaling and routing for support of the per-VPN Peer service model Option1: Virtual Link based approach T.Takeda, et al. Expires May 2007 [Page 8] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 The Per-VPN Peer service model may be realized by extending the virtual link technique so that not only PEs but also Ps that contain end points of virtual links in the abstracted topology contain VPN routing instances. There may be no additional protocol extensions needed from the Virtual Link service model. Option2: Virtual Node based approach The Per-VPN Peer service model may be realized by extending the virtual node technique so that PEs selectively advertise provider internal TE links to CEs. There are several extensions needed for this. Details are for further study. 9. Discussion This section summarizes items for which existing solutions may need to be extended in order to fulfill the full set of L1VPN Enhanced Mode functionalities. For the Overlay Extension service model and the Virtual Node service model, the existing solutions can be applied with few extensions. As described in Sections 7.2 and 8.2, there are no existing solutions to support the Virtual Link service model and the Per-VP Peer service model. For the Virtual Link service model, however, minor extensions from existing solutions are expected to meet the requirements. Note that the list of additional work areas will be updated in later versions of this document with the development of additional or enhanced requirements and further understanding of the issues. o Routing representation - One building block for the Enhanced Mode - Further discussion required (single area, multi areas, multi ASes, etc.) - Impact: Details to be studied (routing etc.) o Signaling and routing for support of the Per-VPN Peer service model - Details for further study 10. Manageability Considerations Section 11 of [L1VPN-FW] describes manageability considerations for L1VPNs. T.Takeda, et al. Expires May 2007 [Page 9] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 This document defines a following new manageability requirement specific for the L1VPN Enhanced Mode. MIB modules MUST be available for any protocol extensions for the L1VPN Enhanced Mode. A future revision of this document may cover more aspects. 11. Security Considerations Section 12 of [L1VPN-FW] describes security considerations for L1VPNs. This document defines a following new security requirements specific for the L1VPN Enhanced Mode. In the L1VPN Enhanced Mode, since there is a routing adjacency between a CE and a PE, care must be taken whether the provider network's control plane topology information is leaked to the CE. Due to security concerns, this is not recommended in general, and there must be a mechanism to prevent such operation. A future revision of this document may cover more aspects. 12. References 12.1 Normative References [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [L1VPN-FW] Takeda, T., Editor "Framework and Requirements for Layer 1 Virtual Private Networks", draft-ietf- l1vpn-framework, work in progress. 12.2 Informative References For information on the availability of this document, please see http://www.itu.int. [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Recommendation, September 2003. For information on the availability of this document, please see http://www.itu.int. [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network architectures, ITU-T Recommendation, July 2004. T.Takeda, et al. Expires May 2007 [Page 10] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 [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. [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4202] Kompella, K., et al., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4026] Anderssion, L., and Madsen, T., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [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. [RFC4208] Swallow, G., et al., "Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface: Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model," RFC4208, October 2005. [L1VPN-BM] Fedyk, D., and Rekhter, Y., Editors, "Layer 1 VPN Basic Mode," draft-fedyk-l1vpn-basic-mode, work in progress. [L1VPN-BGP-DISC] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "BGP-based Auto-Discovery for L1VPNs," draft-ietf- l1vpn-bgp-auto-discovery, work in progress. [L1VPN-OSPF-DISC] Bryskin, I., and Berger, L., "OSPF Based L1VPN Auto-Discovery," draft-ietf-l1vpn-ospf-auto- discovery, work in progress. T.Takeda, et al. Expires May 2007 [Page 11] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 [INTER-DOMAIN-FW] Farrel, A., et al., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- domain-framework, work in progress. [BGP-TE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic Engineering Attribute", draft-fedyk-bgp- te-attribute, work in progress. [MRN-REQ] Shiomoto, K., et al., "Requirements for GMPLS- based multi-region and multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-reqs, work in progress. 13. Acknowledgments Authors would like to thank Marco Carugi, Ichiro Inoue, and Takumi Ohba for valuable comments in the early development of this document. 14. Author's Addresses Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 Email: dbrungard@att.com 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@nortel.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 T.Takeda, et al. Expires May 2007 [Page 12] draft-ietf-l1vpn-applicability-enhanced-mode-00.txt November 2006 Email: takeda.tomonori@lab.ntt.co.jp 15. Intellectual Property Consideration 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. 16. Full Copyright Statement Copyright (C) The IETF Trust (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. 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, THE IETF TRUST 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 May 2007 [Page 13]