Network Working Group Tomonori Takeda (Editor) Internet Draft NTT Proposed Status: Informational Expires: April 2005 October 2004 Applicability analysis of GMPLS protocols to Layer 1 Virtual Private Networks draft-takeda-l1vpn-applicability-01.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. 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 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 April 2005 [Page 1] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 0. Summary (This section to be removed before publication as an RFC.) 0.1. Summary This document describes the applicability of existing GMPLS protocols and mechanisms to support L1VPNs requirements as described in [L1VPN-FW]. In addition, this document identifies several areas where additional protocol extensions are needed to meet the full set of L1VPN services requirements. 0.2. Where does it fit in the picture of the IETF Work The IETF is responsible for GMPLS protocols. L1VPNs are a new layer 1 service that adds new requirements for GMPLS as identified in [L1VPN-FW]. IETF VPN related work areas may also have points of interaction with the content of this document. 0.3. Justification The L1VPN mailing list was set up to discuss issues related to L1VPNs. This document is intended to progress the work by showing the applicability of existing mechanisms and potential solutions (see section 0.4) and identifying several areas where additional work is required. 0.4. Related Internet Documents This document discusses applicability of existing mechanisms and potential solutions drafts (listed below) to L1VPN service requirements as summarized in the following draft. o draft-takeda-l1vpn-framework-02.txt (Oct 2004) "Framework for Layer 1 Virtual Private Networks" This draft examines motivations for L1VPNs, summarizes high level (service level) requirements, and describes L1VPN architectural models. Note this document translates the work of ITU-T Study Group 13 Question 11. This document discusses the applicability of the following solution drafts to L1VPN service requirements. o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt (May 2004) T.Takeda, et al. Expires April 2005 [Page 2] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 "GVPN Services: Generalized VPN Services using BGP and GMPLS 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-05.txt (Oct 2004) "Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model" This draft addresses the application of GMPLS to the overlay model. In one section, the draft provides a description of how the overlay model may be used to support VPN connections across a core GMPLS network. Other drafts will be also mentioned when appropriate. Contents 1. Contributors ............................................. 4 2. Terminology .............................................. 4 3. Introduction ............................................. 4 3.1. Existing Solution Drafts ................................. 5 4. General Guideline ........................................ 6 5. Applicability to Management-based Service Model .......... 6 5.1. Overview of the Service Model ............................ 6 5.2. Applicability of Existing Solutions ...................... 7 5.3. Additional Work Area(s) .................................. 7 6. Applicability to Signaling-based Service Model (Overlay Service Model) .......................................... 8 6.1. Overview of the Service Model ............................ 8 6.2. Applicability of Existing Solutions ...................... 9 6.3. Additional Work Area(s) .................................. 9 7. Applicability to Signaling and Routing Service Model ..... 12 7.1. Virtual Node Service Model ............................... 12 7.1.1. Overview of the Service Model ............................ 12 7.1.2. Applicability of Existing Solutions ...................... 12 7.1.3. Additional Work Area(s) .................................. 13 7.2. Virtual Link Service Model ............................... 14 7.2.1. Overview of the Service Model ............................ 14 7.2.2. Applicability of Existing Solutions ...................... 14 7.2.3. Additional Work Area(s) .................................. 14 7.3. Per VPN Peer Service Model ............................... 15 7.3.1. Overview of the Service Model ............................ 15 7.3.2. Applicability of Existing Solutions ...................... 15 7.3.3. Additional Work Area(s) .................................. 15 8. Management Aspect ........................................ 16 8.1. Fault Management ......................................... 16 8.2. Configuration Management ................................. 17 T.Takeda, et al. Expires April 2005 [Page 3] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 8.3. Security Management ...................................... 17 9. Discussion ............................................... 17 10. Security Considerations .................................. 19 11. IANA Considerations ...................................... 19 12. Acknowledgement .......................................... 19 13. Normative References ..................................... 19 14. Informative References ................................... 19 15. Authors' Addresses ....................................... 22 Appendix I: Network Usage of L1VPN Service Models ............... 22 Intellectual Property Considerations ............................ 23 Full Copyright Statement ........................................ 24 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 (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 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 L1VPN service requirements. 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 information regarding network usage of L1VPN service models is provided in the appendix. T.Takeda, et al. Expires April 2005 [Page 4] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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 management-based service model, signaling-based service model and virtual node service model are well covered by existing documents, with minor extensions. Virtual link service model and per VPN peer service model are not explicitly covered by existing documents, but can be realized by extending current GMPLS protocols and mechanisms. Also, as will be described, the following are possible work areas where additional work would 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, choosing the minimum set of mechanisms is the required additional work. Commonalities of mechanisms over various service models should be considered. Also, various mechanisms should be coordinated in such a way that services are provided in a fully functional manner. This list of additional work areas 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. o MIB module for SPC o Resource management per VPN o PE-PE message exchange o VPN membership information exchange o CE-PE TE link information 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 per VPN peer service model o Management aspect (fault management, configuration management, security management) A MIB module for possible protocol extensions will also need to be studied. 3.1 Existing Solutions Drafts There are two 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 match the framework described in [L1VPN-FW]. T.Takeda, et al. Expires April 2005 [Page 5] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 o [GVPN] 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 [GMPLS-UNI] addresses the application of GMPLS to the overlay model. In one section, the document provides a description of how the overlay model may be used to support VPN connections across a core GMPLS network. 4. General Guideline This section provides general guidelines for L1VPN solutions. 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, it is highly desirable that the same signaling protocols are used in both the signaling-based model and the signaling and routing service model, and routing functions are added or enhanced from signaling-based service model to signaling and routing service model. 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.) - Highly desirable for solutions to provide for the customer and provider a common operational and management perspective in regard to other VPN services, L2 and L3. 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 T.Takeda, et al. Expires April 2005 [Page 6] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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) (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) For static connections, there is no required extension to the MIB modules. For signaled connections, MIB modules should be able to inform the ingress and egress PEs which CE-PE TE link should be used. For the egress side, egress control [EGRESS-CONTROL] can be used. For the ingress side, there are two alternatives to do this. Option1: MIB module extension Define a new MIB object to specify the ingress CE-PE TE link to be used. Option2: MIB object usage extension Use the current MIB objects, but extend the way to use them. There are two possible ways to do this. (1) Set mplsTunnelIngressLSRId in mplsTunnelTable, which corresponds to Tunnel Sender Address in the Sender Template object of RSVP-TE, to the CE-PE TE link address. (2) Set mplsTunnelHopIpAddr of the first MplsTunnelHopEntry in mplsTunnelHopTable, which corresponds to the first element of ERO of RSVP-TE, to the CE-PE TE link address. It may require to define a new mplsTunnelHopAddrType in mplsTunnelHopTable, which corresponds to a new ERO subobject, in order to give precise meaning. T.Takeda, et al. Expires April 2005 [Page 7] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 Detailed analysis of option 1 and 2 is for further study. 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). There are two alternatives to do this. 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. Therefore, no protocol extension is needed. This scheme is especially effective when path computation is done in a centralized manner (e.g., in the management system(s)). Option 2: Routing extension The other alternative is to extend the routing protocol to specify the amount of resources available to each VPN. 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 may be used for this purpose, but this eliminates the opportunity to use link coloring for other purposes (e.g., link coloring within VPNs). Detailed analysis of option 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 such an entity and the PE/P. 6. Applicability to Signaling-based Service Model (Overlay Service Model) 6.1. Overview of the Service Model T.Takeda, et al. Expires April 2005 [Page 8] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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. A CE may optionally receive a list of TE link addresses to which it can request a VPN connection (overlay extension). 6.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 specifying a VPN. The TE link addresses may be customer assigned private addresses. - Signaling: CE-CE LSP setup/deletion/modification - Others: Resource management per VPN etc. Additionally, VPN membership information exchange between a CE and PE is required for overlay extension. [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 VPN membership information exchange by BGP. Customer assigned private addresses are exchanged along with a provider network address (which is reachable in the provider network's routing) and an ID specifying a VPN (i.e., Route Target). This allows PEs to perform address translation/mapping and connectivity restriction. [GVPN] calls the equivalent service model GVPW (Generalized Virtual Private Wire). Finally, [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). This requires the implementation of such IGP. 6.3. Additional Work Area(s) The following additional work areas are identified to support the Signaling-based Service Model. o PE-PE message exchange As described in section 6.1.2, [GMPLS-UNI] and [GVPN] suggest using T.Takeda, et al. Expires April 2005 [Page 9] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 nested signaling for VPN connections. In nested signaling, signaling messages are directly exchanged between PEs. This can be achieved by a tunnel between PEs (one IP hop), or by standard IP forwarding (could be multiple IP hops). These signaling messages must be identified with the VPN for which they are intended. (In other words, it must be possible to identify a session.) When private addresses are assigned to CE-PE TE links or the CE's router ID, and these addresses are used in the Tunnel End Point Address of the Session object and ERO, it is not possible to uniquely identify a session, nor to identify the next hop (destination CE). None of the existing documents specify a mechanism for this. In order to achieve this function there are two alternatives. Option 1: Per VPN control channel In this scheme, separate control channels are set up between PEs, as well as between a CE and PE, for each VPN. Messages received from a specific control channel are mapped to a specific VPN. Protocol extensions are not needed. Note that the choice of control channel is a matter for the operator. However, if we want to automatically set up a per-VPN control channel between PEs, we may need to specify a default control channel, as well as negotiation (signaling) protocols (i.e., VPN auto-discovery (or end point discovery) and control channel establishment). Option 2: VPN ID In this scheme, the signaling protocol is extended to contain an ID identifying a VPN, so that a session can be uniquely identified, and also so that the next hop can be properly determined. This ID may be assigned only to messages between PEs, assuming per VPN control channel between CE and PE. This ID may be globally unique, or may be locally unique (per PE). Both the ingress PE and the egress PE must agree on the value to be used. To automatically exchange values to be used, negation protocols are required. Detailed analysis of options 1 and 2 is for further study. o VPN membership information exchange As described in section 6.2, there are two existing mechanisms based on which VPN membership information exchange is realized. Option 1: BGP-based approach [GVPN] specifies a BGP-based mechanism to realize VPN membership T.Takeda, et al. Expires April 2005 [Page 10] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 information exchange. There is no additional work required, except for detailed specification of format and encoding. Option 2: IGP-based approach 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. 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 See section 5.2. Note that in option 1 of section 5.2, when path computation is done in a separate entity, the interface for PCE (Path Computation Element) [PCE ARCH] needs to be extended for VPN applications. o CE-PE TE link information In 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 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. There are three alternatives for this. Option1: BGP [GVPN] describes potential use of BGP for exchanging CE-PE TE link information. Detailed protocol specifications are needed as additional work. Option 2: OSPF-TE The other alternative is to use OSPF-TE 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 only a PE advertising CE-PE TE link information. T.Takeda, et al. Expires April 2005 [Page 11] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 Option 3: LMP LMP [LMP] can be used to exchange CE-PE TE link information between PEs, with appropriate extensions. Detailed analysis of options 1, 2 and 3 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 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, on a PE and a CE, control channels are separate for each VPN (i.e., a CE-PE control channel is not shared by multiple VPNs). 7. Applicability to Signaling and Routing Service Model 7.1. Virtual Node Service Model 7.1.1. Overview of the Service Model 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 TE 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 The followings are required in this service model. - VPN routing: - Signaling: CE-CE LSP setup/deletion modification - Others: Resource management per VPN etc. [GVPN] covers most of the requirements. Specifically, [GVPN] supports signaling by nested signaling (as in the case of the Signaling-based Service Model). In addition, [GVPN] handles VPN routing by a per VPN database called the GVSI (Generalized Virtual Switching Instance) in PEs. GVSIs are inter- T.Takeda, et al. Expires April 2005 [Page 12] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 connected by tunnel based control channels, and routing adjacencies are established between them. BGP is used for auto-discovery of remote GVSI (VPN auto-discovery) 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). 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.1.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, details may differ (e.g., use of auto-discovery). This requires further discussion. o PE-PE message exchange See section 6.1.3 Note that in the signaling and routing service model, not only signaling messages but also routing messages need to be identified with the VPN for which they are intended. The exchange mechanism for signaling messages and routing messages may be the same, or may be different. o Resource management per VPN See section 6.1.3 o Control plane routing The provider network must be carefully designed 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. T.Takeda, et al. Expires April 2005 [Page 13] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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 packets to be transferred between CE sites (e.g., BGP packets), the provider network must be carefully designed how to route per VPN control packets received from the CE. 7.2. Virtual Link Service Model 7.2.1. Overview of the Service Model 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 the ROUTE_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 FA-LSPs in VPN routing. Note these FA-LSPs (virtual links) may be assigned private addresses, which means customer assigned addresses (or that customers are allowed to configure addresses). This may require extension to current IGP behavior. Note there could be other ways to construct virtual links (e.g., virtual links without actually setting up a FA-LSP [IP/MPLS-GMPLS]). 7.2.3. Additional Work Area(s) There is no additional work area beyond the already identified work area for the Virtual Node Service Model mentioned in section 7.1.3. Note that resource management for a dedicated Data-Plane is a mandatory requirement for Virtual Link Service Model. This could be realized by assigning pre-configured FA-LSPs to each VPN routing protocol instance (no protocol extensions needed). Note as in the case of Virtual Node Service Model, depending on routing representation, details may differ. This requires further T.Takeda, et al. Expires April 2005 [Page 14] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 discussion. 7.3. Per VPN Peer Service Model 7.3.1. Overview of the Service Model 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. Note as in the case of Virtual Node Service Model, depending on routing construction, details may differ. This requires further discussion. 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. T.Takeda, et al. Expires April 2005 [Page 15] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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. At the same time, when RRO is requested, the 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 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. It should be also possible to realize this type of service model by using the virtual router based approach (i.e., every PE/P (or PE/P that contains the end point of virtual links in the 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 allowed to specify the desired level of recovery in connection setup requests. The provider network may constitute a recovery domain (PE-PE recovery). 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. T.Takeda, et al. Expires April 2005 [Page 16] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 o Extra traffic GMPLS recovery mechanisms support extra traffic. Extra traffic allows supporting pre-emptible 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 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 model and 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. Details for additional work areas are for further study. 9. Discussion T.Takeda, et al. Expires April 2005 [Page 17] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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, signaling-based service model and virtual node service model, the existing solutions can be applied with few extensions. As described in section 7.2.2 and 7.2.3, there are no existing solutions to support the virtual link service model and per VPN peer service model. For virtual link service model, 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 the development of additional or enhanced requirements and understanding of the issues. o MIB module for SPC - Optional, but highly required for 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 management-based, signaling-based and virtual node service models - Mandatory requirement for virtual link and per VPN peer service models (support of resource management for dedicated Data-Plane) - Two alternatives (policy or routing extension) - For virtual link service model, can be realized by no protocol extensions (assign pre-configured FA-LSP to each VPN routing instance). - Impact: IGP or none o PE-PE message exchange - Mandatory requirement for signaling-based service model and signaling and routing service model - Two alternatives (per VPN control channel or VPN ID) - Impact: None (but auto-discovery and control channel mechanisms optionally needed) or signaling/routing o CE-PE TE link information - Optional requirement for signaling-based service model - Three alternatives (BGP or OSPF-TE or LMP) - Impact: BGP or IGP or LMP o Routing representation T.Takeda, et al. Expires April 2005 [Page 18] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 - One building block for 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 signaling and routing service model - Impact: Routing o Signaling and routing for support of per VPN peer service model - 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 some of security considerations. Details are for further study. 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 [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. T.Takeda, et al. Expires April 2005 [Page 19] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 [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. [INTER-DOMAIN FW] Farrel, A., et al., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-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., T.Takeda, et al. Expires April 2005 [Page 20] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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", draft-ietf-ccamp-gmpls-egress-control, work in progress. [OSPF-CAP] Vesseur, J.P., et al., "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. [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. [PPVPN-TERM] Andersson, L., and Madsen, T., "Provider Provisioned VPN terminology", draft-ietf-l3vpn-ppvpn-terminology, work in progress. [VR] Knight, P., Editor, "Network based IP VPN Architecture using Virtual Router", draft-ietf- T.Takeda, et al. Expires April 2005 [Page 21] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 l3vpn-vpn-vr, work in progress. [PCE ARCH] Ash, J., et al., "Path Computation Element (PCE) Architecture", draft-ash-pce-architecture, work in progress. [IP/MPLS-GMPLS] Oki, E., et al., "Migrating from IP/MPLS to GMPLS networks", draft-oki-ccamp-gmpls-ip-interworking, 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@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 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 T.Takeda, et al. Expires April 2005 [Page 22] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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. 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 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 T.Takeda, et al. Expires April 2005 [Page 23] Internet Draft draft-takeda-l1vpn-applicability-01.txt October 2004 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 (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 April 2005 [Page 24]