Network Working Group Tomonori Takeda (Editor) Internet Draft NTT Proposed Status: Informational Expires: January 2006 July 2005 Applicability analysis of GMPLS protocols to Layer 1 Virtual Private Networks draft-takeda-l1vpn-applicability-03.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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document provides an applicability analysis on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to satisfy the requirements of Layer 1 Virtual Private Networks (L1VPNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy the requirements of L1VPNs, and provides guidelines for potential extensions. T.Takeda, et al. Expires January 2006 [Page 1] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 Contents 1. Contributors ............................................. 3 2. Terminology .............................................. 3 3. Introduction ............................................. 3 3.1. Work Items ............................................... 4 3.2. Existing Solution Drafts ................................. 4 4. General Guidelines ....................................... 5 5. Applicability to Management-based Service Model .......... 6 5.1. Overview of the Service Model ............................ 6 5.2. Applicability of Existing Solutions ...................... 6 5.3. Additional Work Area(s) .................................. 6 6. Applicability to Signaling-based Service Model (Basic Mode) ................................................... 8 6.1. Overlay Service Model .................................... 8 6.1.1. Overview of the Service Model ............................ 8 6.1.2. Applicability of Existing Solutions ...................... 9 6.1.3. Additional Work Area(s) .................................. 10 7. Applicability to Signaling and Routing Service Model (Enhanced Mode) .......................................... 13 7.1. Overlay Extension Service Model .......................... 13 7.1.1. Overview of the Service Model ............................ 13 7.1.2. Applicability of Existing Solutions ...................... 13 7.1.3. Additional Work Area(s) .................................. 13 7.2. Virtual Node Service Model ............................... 14 7.2.1. Overview of the Service Model ............................ 14 7.2.2. Applicability of Existing Solutions ...................... 15 7.2.3. Additional Work Area(s) .................................. 15 7.3. Virtual Link Service Model ............................... 16 7.3.1. Overview of the Service Model ............................ 16 7.3.2. Applicability of Existing Solutions ...................... 16 7.3.3. Additional Work Area(s) .................................. 16 7.4. Per-VPN Peer Service Model ............................... 17 7.4.1. Overview of the Service Model ............................ 17 7.4.2. Applicability of Existing Solutions ...................... 17 7.4.3. Additional Work Area(s) .................................. 17 8. Management Aspects ....................................... 19 8.1. Fault Management ......................................... 19 8.2. Configuration Management ................................. 19 8.3. Security Management ...................................... 20 9. Discussion ............................................... 20 10. Security Considerations .................................. 22 11. IANA Considerations ...................................... 22 12. Acknowledgement .......................................... 22 13. Normative References ..................................... 23 14. Informative References ................................... 23 15. Authors' Addresses ....................................... 25 Appendix I: Network Usage of L1VPN Service Models ............... 26 T.Takeda, et al. Expires January 2006 [Page 2] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 Intellectual Property Considerations ............................ 27 Full Copyright Statement ........................................ 27 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) 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], [RFC4026] and [L1VPN-FW]. 3. Introduction This document shows the applicability of existing Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to Layer 1 Virtual Private Networks (L1VPNs). In addition, this document identifies several areas where additional protocol extensions or modifications are needed to meet the L1VPN service requirements set out in [L1VPN-FW]. In particular, this document shows section by section (from section 5 to 7) the applicability of GMPLS protocols and mechanisms 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 that management aspects, some of which are common over various service models, are described separately in section 8. Additional, non-normative information regarding network usage of L1VPN service models is provided in the appendix. 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 Management-based service model, the Signaling-based service model, the Overlay Extension service model and the Virtual Node service model are well covered by existing documents, with only minor protocol extensions required. The Virtual Link service model and the T.Takeda, et al. Expires January 2006 [Page 3] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 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. Also, as will be described, the following are possible work areas where additional work may be required to fully support the requirements for each L1VPN service model. Some of the requirements are optional therefore the additional work is also optional. Also, some items below may have more than one existing mechanism (with possible extensions). For those items, the required work is to choose the minimum set of mechanisms. Commonalities of mechanisms over various service models 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 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, it is expected that 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. o MIB module for SPC o Resource management per VPN o Signaling mechanisms o VPN membership information exchange within the provider network o CE-PE TE link information exchange within the provider network o VPN membership information exchange between a CE and a PE o CE-PE TE link information exchange between a CE and a PE o Routing representation (how a VPN should be represented in routing, e.g., single area, multi area, multi AS) o Control plane routing (routing information exchange related to control plane topology, per-VPN control packet routing) o Signaling and routing for support of the Per-VPN Peer service model o Management aspects (fault management, configuration management, security management) o MIB modules for protocol extensions 3.2. Existing Solutions Drafts This section lists existing solutions documents that describe how L1VPNs 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 T.Takeda, et al. Expires January 2006 [Page 4] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 match the framework described in [L1VPN-FW]. Further solutions 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 [GMPLS-UNI] addresses the application of GMPLS to the overlay model. The document provides a description of how the overlay model may be used to support VPN connections across a core GMPLS network. 4. General Guidelines This section provides general guidelines for L1VPN solutions. Note that applicability to specific service 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 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 Signaling-based service model and the Signaling and Routing service model. 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. - It should be considered 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. - Solutions should be secure. Providers should be able to screen and protect information based on their operational policies. T.Takeda, et al. Expires January 2006 [Page 5] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 - 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. 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 Model 5.1. Overview of the Service Model 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. Note that in this service model the PE-PE connections may be signaled using GMPLS under management control at the ingress PE, or may be statically provisioned through management control of the PEs and Ps. Thus, it remains appropriate to describe signaling and routing mechanisms within this service model. 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) (i.e. customer and provider) 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 Model. o MIB module for SPC (Soft Permanent Connection) The notion of an SPC only applies if the PE-PE connection is signaled. There are no required extensions to the MIB modules to support the static parts of the connections (CE-PE links) since they can be managed as normal static links using [LSR-MIB]. T.Takeda, et al. Expires January 2006 [Page 6] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 For the signaled part of the connection (PE-PE), the ingress and egress PEs need to know which (static) CE-PE TE links to use. This information can be carried to the egress PE using egress control [EGRESS-CONTROL], but needs to be configurable at the ingress PE. There are two alternatives. Option1: MIB module extension Define two new MIB objects as part of the specification of the TE LSP [TE-MIB] to specify the ingress and egress CE-PE TE links to be used. Option2: MIB object usage extension Use the current MIB objects, but define new, extended meanings. There are two possible ways to do this. (1) Set the mplsTunnelIngressLSRId in the mplsTunnelTable (that corresponds to the Tunnel Sender Address in the Sender Template object of RSVP-TE) to the ingress CE-PE TE link address. Set the mplsTunnelHopIpAddr of the final MplsTunnelHopEntry in the mplsTunnelHopTable to the egress CE-PE TE link address. (2) Set the mplsTunnelHopIpAddr of the first MplsTunnelHopEntry in the mplsTunnelHopTable to the ingress CE-PE TE link address. This may require a new mplsTunnelHopAddrType value to be defined in order to give precise meaning. Set the mplsTunnelHopIpAddr of the final MplsTunnelHopEntry in the mplsTunnelHopTable to the egress CE-PE TE link address. Detailed analysis of options 1 and 2 is for further study. o Resource management per VPN In the Management-based service model, the data plane may be managed to create two optional functional requirements. - Resource management to create a dedicated per-VPN data plane. The provider network partitions link resources per-VPN for exclusive use by a particular VPN. - Resource management to share part of the data plane among a specific sub-set of VPNs. The provider network assigns link resources to a specific sub-set of VPNs. The default behavior, without this option, is that all resources are available for use by any VPN. If either of these options are applied with a statically managed T.Takeda, et al. Expires January 2006 [Page 7] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 PE-PE connection then the required function is a matter for policy within the network management tool for the core network. No extensions are required. There are two alternatives to achieve this function for signaled PE-PE connections. Option 1: Policy A simple way to meet this requirement is to implement resource management functionalities as a policy solely in the entity that computes a path. No protocol extensions are needed because links and resources can be explicitly configured using [TE-MIB] and signaled using [RFC3473]. This scheme is especially effective when path computation is done in a centralized manner (e.g., in the management system(s)) and is similar to the policy applied to achieve these functional options using statically configures PE-PE connections. Option 2: Routing extension The other alternative is advertise the amount of resources available to each VPN using extensions to the TE information flooding performed by the routing protocol within the core provider network. In this scheme, the PE/P can compute a path in a distributed way, thus this scheme is especially beneficial in the case of dynamic restoration (restoration that does not reserve backup resources in advance). Note that link coloring might be used for this purpose, but this would eliminate the opportunity to use link coloring for other purposes (e.g., link coloring within VPNs). Detailed analysis of options 1 and 2 is for further study. o Other considerations When path computation is done in a centralized entity (e.g., management system(s)), it is important that resource information is synchronized between the core provider network and such an entity. 6. Applicability to Signaling-based Service Model (Basic Mode) 6.1. Overlay Service Model 6.1.1. Overview of the Service Model T.Takeda, et al. Expires January 2006 [Page 8] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 In this service model, there is no routing exchange between the CE and the PE. Connections are setup by GMPLS signaling between the CE and the PE, and then across the provider network. Note that routing operates within the provider network and may be used by PEs to exchange information specific to the VPNs supported by the provider network. 6.1.2. Applicability of Existing Solutions The following are required in this service model. - VPN membership information exchange: CE-PE TE link address exchange between PEs, along with information associated with a VPN. The TE link addresses may be customer assigned private addresses. - Signaling: CE-CE LSP setup, deletion and modification - Others: Resource management per VPN etc. [GVPN] and [GMPLS-UNI] cover most of the requirements. Specifically, [GVPN] covers VPN membership information exchange by BGP running on the PEs. Customer assigned private addresses for customer site CEs are configured on the PE that provides VPN access to the customer site, and are exchanged by BGP along with a provider network address (which is reachable in the provider network's routing) and an ID associated with the VPN (i.e., Route Target). This allows PEs to perform address translation/mapping and connectivity restriction. The other possibility is to use IGP based VPN membership information exchange (e.g., similar to as an AS external route, or based on [OSPF-NODE-ADDR], with extensions for VPN applications). In addition, [GVPN] and [GMPLS-UNI] suggest two signaling mechanisms for VPN connections. o Shuffling [GVPN] Information carried in RSVP-TE messages identifying a LSP (i.e., SESSION and SENDER_TEMPLATE objects) is translated by the ingress and egress PE. There is one end-to-end session (i.e., CE-CE), but the identifiers of that session change along the path of the LSP. o Nesting [GVPN][GMPLS-UNI][LSP HIER] When Path message arrives at the ingress PE, the ingress PE checks whether there is appropriate PE-PE connectivity. If there is not, it initiates a PE-PE FA-LSP. The CE-CE LSP is carried nested T.Takeda, et al. Expires January 2006 [Page 9] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 hierarchically within the FA-LSP. There are two sessions (i.e., CE-CE and PE-PE). LSP stitching [STITCHING] operates in a similar manner to LSP nesting. The properties of the PE-PE LSP segment are such that exactly one end-to-end LSP can be stitched to the LSP segment i.e., the PE-PE LSP and the CE-CE LSP correspond exactly one to one. There are two sessions (i.e., CE-CE and PE-PE). LMP [LMP] may be running between a CE and a PE. In that case, the PE is able to obtain customer assigned private addresses on directly attached CEs automatically. This eliminates configuring manually the customer assigned private addresses on PEs, which are distributed by membership information exchange mechanisms. 6.1.3. Additional Work Area(s) The following additional work areas are identified to support the Overlay service model. o Signaling mechanisms As described in section 6.1.2, [GMPLS-UNI] and [GVPN] suggest two signaling mechanisms for VPN connections. Option 1: Shuffling In this mechanism, objects need to be translated at the ingress and egress PEs. It is necessary to specify rules for this translation and mechanisms to ensure that the information is available in order to perform the translation. Option 2: Nesting In this mechanism, there is a need to set up a PE-PE FA-LSP. In the case of nesting, PE-PE direct signaling message exchange takes place, and this message exchange may use the provider network addressing space, or the VPN addressing space. It may be necessary to specify an addressing space to be used. When the provider network addressing space is used, there must be a mechanism to identify which VPN each message is associated with at PEs. Otherwise, the PE received the message is not able to proceed the message furthermore (i.e., session identification, and next hope resolution). This mechanism needs to be specified. When the VPN addressing space is used by forming per-VPN control T.Takeda, et al. Expires January 2006 [Page 10] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 channels between PEs, the identification of VPN is straightforward. However, the mechanisms to realize per-VPN control channels need to be specified (e.g., IP-based tunnel, physically separate control channels). Detailed analysis, including under which condition signaling mechanisms (shuffling or nesting) should be used, is for further study. o VPN membership information exchange within the provider network As described in section 6.1.2, there are two existing mechanisms for the functional option of exchanging VPN membership information within the provider network. This model does not support VPN membership exchange between CE and PE (see section 7.1) and so such information is assumed to be configured within the provider network, usually on the PEs. Option 1: BGP-based [GVPN] specifies a BGP-based mechanism to realize VPN membership information exchange between PEs without informing core Ps. Configuration of this information is performed at the PEs that provide access to a VPN. There is no additional work required, except to update [GVPN] for detailed specification of format and encoding. Option 2: IGP-based OSPF allows AS external routes to be advertised. In addition, [OSPF-NODE-ADDR] extends OSPF-TE to advertise a router's local addresses. These mechanisms can be used to advertise CE-PE TE link addresses within the core provider network. In order to support customer assigned private addresses and connectivity restrictions, this mechanism needs to be extended to exchange information similar to an RT (Route Target) and possibly an RD (Route Distinguisher), along with CE-PE TE link addresses. Detailed analysis of options 1 and 2 is for further study. o Resource management per VPN Section 5.2 describes how provider network resources can be partitioned for use by a single VPN or a sub-set of VPNs. Note that in option 1 of section 5.2, when path computation is done in a separate entity, the interface to the PCE (Path Computation Element) [PCE ARCH] may need to be extended for VPN identification. Note also that it is also possible to apply resource partitioning T.Takeda, et al. Expires January 2006 [Page 11] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 in the CEs and on the CE-PE links in this model. It will be necessary, however, to ensure consistent configuration through the network management tools of both the customer and provider equipment to provide this function. o CE-PE TE link information exchange within the provider network In the Signaling-based service model, 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 on 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. There are two alternatives for this. Option1: BGP-based [GVPN] describes potential use of BGP for exchanging CE-PE TE link information. Detailed protocol specifications are needed as additional work. This option is consistent with the BGP-based membership exchange described above. Option 2: IGP-based An alternative is to use IGP to advertise CE-PE TE links. Since a CE does not participate in routing protocol exchange with the provider network, TE link information must be properly constructed by the PE advertising full CE-PE TE link information. This option is consistent with the IGP-based membership exchange described above. Detailed analysis of options 1 and 2 is for further study. o Other considerations 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 policy server. In this case, the interface between the PE and the other entity may need to be specified. This could utilize existing mechanisms such as COPS or LDAP. Also note that [GVPN] assumes that a PE and a CE communicate using separate control channels for each VPN (i.e., a CE-PE control channel is not shared by multiple VPNs). As described above, this facilitates easy separation of VPN signaling messages, but is achieved at the cost of extra configuration at the CE and PE. If T.Takeda, et al. Expires January 2006 [Page 12] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 a shared control channel is desired in the [GVPN] solution, additional mechanisms such as VPN identification within signaling messages, may be required. 7. Applicability to Signaling and Routing Service Model (Enhanced Mode) 7.1. Overlay Extension Service Model 7.1.1. Overview of the Service Model This service model is a slight extension from the Overlay service model (section 6.1) 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 (a list of CE addresses within the same VPN). The CE may also receive some of 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. - 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. 7.1.2. Applicability of Existing Solutions The following are required in this service model. - 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 by BGP for overlay extension. The other possibility is to use IGP based VPN membership information exchange (e.g., similar to as an AS external route, or based on [OSPF-NODE-ADDR], with extensions for VPN applications). 7.1.3. Additional Work Area(s) o VPN membership information exchange between a CE and a PE T.Takeda, et al. Expires January 2006 [Page 13] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 As described in section 7.1.2, there are two existing mechanisms based on which VPN membership information exchange is realized. Option 1: BGP-based [GVPN] suggests a BGP-based mechanism to realize VPN membership information exchange between a CE and a PE. Option 2: IGP-based OSPF allows AS external routes to be advertised. In addition, [OSPF-NODE-ADDR] extends OSPF-TE to advertise a router's local addresses. These mechanisms can be used to advertise CE-PE TE link addresses between a CE and a PE. Detailed analysis of options 1 and 2 is for further study. o CE-PE TE link information exchange between a CE and a PE As just mentioned [GVPN] suggests a BGP-based mechanism to realize VPN membership information exchange. Such a mechanism does not extend well to carrying additional TE information about the CE-PE link either between PEs or between PE and CE because it is generally agreed that BGP should not be used to transport TE information. However, there is no reason in principle why specific, tightly specified extensions should not be used to transport this additional information within the limited context of the L1VPN. An alternative is to use an IGP mechanism to distribute this information. [GVPN] does not constrain the CE-PE routing protocol to be BGP, so this option could be used in either of the options listed for membership exchange. Note that the additional membership and TE information might be considered as superfluous within the core provider network were it to be flooded by an IGP to all P devices. An option, in this case might be to run a separate instance of the IGP including only the CEs and PEs. Mechanisms other than routing protocols could be used to exchange reachability/TE information between the CE and the PE. 7.2. Virtual Node Service Model 7.2.1. Overview of the Service Model T.Takeda, et al. Expires January 2006 [Page 14] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 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 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, 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 CE sites. 7.2.2. Applicability of Existing Solutions The followings are required in this service model. - VPN routing - Signaling: CE-CE LSP setup, deletion, and modification - Others: Resource management per VPN etc. [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. 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. In addition, [GVPN] supports nested signaling (as in the case of the Signaling-based service model). There are other ways to realize VPN auto-discovery. One such way is to use an IGP-based mechanism (e.g., based on [OSPF-CAP] or [OSPF-NODE-ADDR] with extensions). Other possibilities are to use a server based approach (e.g., DNS, based on [DNS DISCOVERY], RADIUS, based on [RADIUS DISCOVERY]) and multicast (e.g., based on [RFC2917]). 7.2.3. Additional Work Area(s) The following additional work areas are identified to support the Virtual Node service model. o Routing representation In the Virtual Node service model, one item that should be considered is how to represent a VPN in routing (e.g., single IGP area, multiple IGP areas, multiple ASes). Depending on the routing representation, solution details may differ (e.g., use of T.Takeda, et al. Expires January 2006 [Page 15] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 auto-discovery). This requires further discussion. o Resource management per VPN See section 6.1.3 o Control plane routing An explicit decision must be taken about whether the provider network's control plane topology information should be leaked to the CE. If it is, it may be necessary to separate the address spaces. Further, if control messages (e.g., BGP messages) can be transferred between CE sites using the provider network control plane, care must be taken over how to route per VPN control packets received from the CE. 7.3. Virtual Link Service Model 7.3.1. Overview of the Service Model In this service model, virtual links are established between PEs. The routing information exchanged between the CE and the PE includes CE-PE TE links, CE sites, virtual links (i.e., PE-PE links), and may include CE-CE (or C-C) Forwarding Adjacencies as well as control plane topology from the CE sites. 7.3.2. Applicability of Existing Solutions Currently, there is no solution document for this type of service model. 7.3.3. Additional Work Area(s) Simple modifications of [GVPN], in addition to enhancements mentioned in section 7.2.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). - Set up 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. Note there could be other ways to construct virtual links (e.g., T.Takeda, et al. Expires January 2006 [Page 16] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 virtual links without actually setting up a FA-LSP [MRN REQ]). There is no additional work area beyond the work already identified for the Virtual Node service model mentioned in section 7.2.3, and that described above. Note that 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: as in the case of the Virtual Node service model, solution details may differ depending on the routing representation. This requires further discussion. 7.4. Per-VPN Peer Service Model 7.4.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, 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 the 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]. 7.4.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.2.2. One way is to extend mechanisms for the Virtual Node service model. The other way is to extend mechanisms for the Virtual Link service model. 7.4.3. Additional Work Area(s) As described in section 7.4.2, there are two approaches for this service model. Note that as in the case of the Virtual Node service mode, solution details may differ depending on routing representation. This requires further discussion. o Signaling and routing for support of the per-VPN Peer service T.Takeda, et al. Expires January 2006 [Page 17] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 model Option 1: Virtual node-based 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. - 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. - 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]. - ERO/RRO expansion/modification The CE may specify an ERO with abstracted topology. The provider network must expand this ERO to match the provider network topology. Note this must be done even if a strict route is specified in the ERO passed from the CE. At the same time, when an RRO is requested, the RRO passed to the CE must be either edited to match the abstracted topology, or removed. - Private address The provider network may support private addresses for routing information provided to the customer. This means that the customer is able to assign private addresses to a partitioned portion of the TE links within the provider network. Option 2: Virtual link-based 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 T.Takeda, et al. Expires January 2006 [Page 18] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 contain VPN routing instances. There may be no additional protocol extensions needed from the Virtual Link service model. Detailed analysis of options 1 and 2 is for further study. 8. Management Aspects 8.1. Fault Management The provider network may support various recovery techniques mentioned in [P&R TERM]. The customer may be allowed to specify the desired level of recovery in connection setup requests. The provider network may constitute a recovery domain (PE-PE recovery). The following aspects need to be considered relative to 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 recovery mechanisms support extra traffic. Extra traffic allows supporting preemptable traffic on 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 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, shared by a specific sub-set of VPNs, or shared by any VPNs. The provider network must T.Takeda, et al. Expires January 2006 [Page 19] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 provide configuration tools for resource management per VPN. o Configuration of virtual links For the Virtual Link service model and the Per-VPN Peer service model, 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. 8.3. Security Management o CE-PE security When a CE-PE control channel is physically shared by multiple VPNs, security mechanisms need to be applied for data integrity and confidentiality of control messages exchanged. Furthermore, when a CE-PE control channel is dynamically setup, authentication need to be performed. The mechanisms to achieve these include IPsec. Denial of service attack is one significant security threat. The provider network must have mechanisms to detect denial of service attach, and to protect against it reactively and proactively. Details for additional work areas are for further study. o CE-CE security The provider network must restrict connections between CEs in the same VPN. As such, the provider network must avoid mis-connection under any scenario, including failures, recovery and preemption. Furthermore, when customers want to assure security against the provider network, the customers may apply their own security mechanisms (CE-CE security). IPsec can be used for this purpose. 9. Discussion This section summarizes items for which existing solutions may need to be extended in order to fulfill the full set of L1VPN service model functionalities. Note that several of these items are in support of optional features. For the Management-based service model, the Signaling-based service model, the Overlay Extension service model and the Virtual Node service model, the existing solutions can be applied with few T.Takeda, et al. Expires January 2006 [Page 20] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 extensions. As described in sections 7.3.2 and 7.4.2, there are no existing solutions to support the Virtual Link service model and the Per-VPN 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 MIB module for SPC - Optional, but highly required for the Management-based service model - Two alternatives (MIB module extension or MIB object usage extension) - Impact: MIB module or none o Resource management per VPN - Optional requirement for the Management-based, the Signaling-based, the Overlay extension and the Virtual Node service models - Mandatory requirement for the Virtual Link and the Per-VPN Peer service models (support of resource management for dedicated data plane) - Two alternatives (policy or routing extension) - For the Virtual Link service model, can be realized by no protocol extensions (assign pre-configured FA-LSPs to each VPN routing instance). - Impact: None or IGP o Signaling mechanisms - Mandatory requirement for the Signaling-based service model and the Signaling and Routing service model - Two alternatives (shuffling or nesting) - Impact: Signaling o VPN membership information exchange within the provider network - Mandatory requirement for the Signaling-based service model and the Overlay Extension service model - Two alternatives (BGP or IGP) - Impact: BGP or IGP o CE-PE TE link information exchange within the provider network - Optional requirement for the Signaling-based service model and the Overlay Extension service model - Two alternatives (BGP or IGP) - Impact: BGP or IGP T.Takeda, et al. Expires January 2006 [Page 21] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 o VPN membership information exchange between a CE and a PE - Mandatory requirement for the Overlay Extension service model - Two alternatives (BGP or IGP) - Impact: BGP or IGP o CE-PE TE link information exchange between a CE and a PE - Optional requirement for the Overlay Extension service model - Two alternatives (BGP or IGP) - Impact: BGP or IGP o Routing representation - One building block for the Signaling and Routing service model - Further discussion required (single area, multi areas, multi ASes, etc.) - Impact: Details to be studied (routing, use of auto-discovery, etc.) o Control plane routing - Optional requirement for the Signaling and Routing service model - Impact: Routing o Signaling and routing for support of the Per-VPN Peer service model - Two options (virtual node-based, virtual link-based) - 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 - Details for security management to be studied - Impact: mostly on operational tools (impacts on protocols to be studied) 10. Security Considerations Section 8.3 describes security considerations. 11. IANA Considerations This document defines no new protocols or extensions and makes no requests to IANA for registry management. 12. Acknowledgement We would like to thank Marco Carugi, Ichiro Inoue and Takumi Ohba for their useful comments and suggestions. T.Takeda, et al. Expires January 2006 [Page 22] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 13. Normative References [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [L1VPN-FW] Takeda, T., Editor "Framework for Layer 1 Virtual Private Networks", draft-takeda-l1vpn-framework, work in progress. 14. 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. [GMPLS-UNI] Swallow, G., et al., "Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 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. [LSP HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp- hierarchy, work in progress. [STITCHING] Ayyangar, A. (editor), "Label Switched Path Stitching with Generalized MPLS Traffic Engineering", draft-ietf-ccamp-lsp-stitching, work in progress. [INTER-DOMAIN FW] Farrel, A., et al., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp- inter-domain-framework, work in progress. T.Takeda, et al. Expires January 2006 [Page 23] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 [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. [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", RFC 4003, February 2005. [OSPF-CAP] Lindem, A. (editor), "Extensions to OSPF for Advertising Optional Router Capabilities", draft-ietf-ospf-cap, work in progress. [OSPF-NODE-ADDR] Aggarwal, R., Kompella, K., "Advertising a Router's Local Addresses in OSPF TE Extensions", draft-ietf-ospf-te-node-addr, work in progress. T.Takeda, et al. Expires January 2006 [Page 24] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 [LMP] Lang, J., "Link Management Protocol (LMP)", draft-ietf-ccamp-lmp, work in progress. [DNS DISCOVERY] Squire, M., et al., "Using DNS for VPN Discovery", draft-luciani-ppvpn-vpn-discovery (Expired). [RADIUS DISCOVERY] Weber, G., Editor "Using RADIUS for PE-Based VPN Discovery", draft-ietf-l2vpn-radius-pe-discovery (Expired). [RFC2917] Muthukrishnan, K., Malis, A., " A Core MPLS IP VPN Architecture", RFC2917, September 2000. [RFC4026] Anderssion, L., and Madsen, T., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [PCE ARCH] Ash, J., et al., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [MRN REQ] Shiomoto, K., et al., "Requirements for GMPLS- based multi-region and multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. 15. Authors' 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, T.Takeda, et al. Expires January 2006 [Page 25] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 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 Appendix I: Network Usage of L1VPN Service Models This appendix provides additional information concerning network usage of the L1VPN service models. o Management-based service model In this model, the provider network can support non-GMPLS capable CEs. Therefore, this model is best suited when customer networks are non-GMPLS, e.g., legacy SONET/SDH and IP/MPLS networks. It is expected that the provider network requires no or minimal GMPLS extensions for L1VPN specific functions. o Signaling-based service model In this model, by implementing GMPLS signaling functions in CEs, the customer can request an LSP setup/deletion/modification to the provider by signaling. Other customer site nodes (C devices) do not need to be GMPLS-capable. Customers will receive rapid failure notifications of an LSP by using notification mechanisms available in GMPLS RSVP-TE. There are some L1VPN specific extensions required within the provider network. Concerning customer network routing information, since only CE-PE TE link addresses are contained within the provider network, it is expected that there is less concern on scalability. Trust relationships between the customer and the provider may need to be carefully considered. o Signaling and Routing service model In this model, a customer can seamlessly operate its VPN using end-to-end GMPLS. Therefore, this model is best suited when customer networks are operated by GMPLS. For the service model where the provider network's routing information is not provided to customers (i.e., Virtual Node T.Takeda, et al. Expires January 2006 [Page 26] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 service model), a customer can outsource routing complexity within the provider network to the provider. On the other hand, in the service model where the provider network routing information is provided to customers (i.e., Virtual Link service model and Per-VPN Peer service model), customers play more of a role. For example, by allowing customers to assign SRLG IDs for virtual links, customers can compute and set up end to end disjoint LSPs in their VPN. There are some L1VPN specific extensions required within the provider network. Concerning customer network routing information, since the customer network routing information is contained within the provider network, scalability must be carefully considered. Trust relationships between the customer and the provider may need to be carefully considered as well. 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. Full Copyright Statement Copyright (C) The Internet Society (2005). 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, T.Takeda, et al. Expires January 2006 [Page 27] Internet Draft draft-takeda-l1vpn-applicability-03.txt July 2005 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 2006 [Page 28]