Network Working Group Tomonori Takeda (Editor) Internet Draft NTT Expires: August 2005 February 2005 Framework for Layer 1 Virtual Private Networks draft-takeda-l1vpn-framework-03.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 a framework for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs. The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. 0. Summary (This section to be removed before publication as an RFC.) T.Takeda, et al. Expires August 2005 [Page 1] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 0.1. Summary This document describes a framework for Layer 1 VPNs (L1VPNs). L1VPNs provide services over layer 1 networks, such as WDM and TDM networks. This document provides a framework for L1VPNs and the realization of the framework by those networks being controlled by GMPLS protocols. 0.2. Where does it fit in the picture of the IETF Work Services may be provisioned across layer 1 networks using GMPLS protocols. L1VPNs may be managed and operated using these protocols as described in this document. GMPLS protocols were developed within the IETF using IP addressing and based on IP and other Internet protocols. The IETF continues to work with GMPLS protocols, enhancing them and applying them to new requirements. VPN related work areas might also have points of interaction with the content of this document. 0.3. Justification This document exists to demonstrate the service level requirements for L1VPNs and to create a framework for L1VPNs within the existing Internet architectures. As such, this document is the justification for better understanding of L1VPNs within the IETF. Study Group 13 of the ITU-T has been investigating the service level requirements for L1VPNs with input from major network service providers and equipment vendors. There is a strong feeling within SG13 that the desirability of L1VPN services is growing and that there is a need for a minimum set of common approaches that will lead to interoperable solutions. 0.4. Related Internet Documents Much of the background work for this document has been directly developed within the ITU-T and is presented as [Y.1312] and [Y.1313]. However, some Internet drafts are related to this topic and the following three ones are relevant ones. o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt (May 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. T.Takeda, et al. Expires August 2005 [Page 2] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 o draft-ietf-ccamp-gmpls-overlay-05.txt (October 2004) "Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model" This memo addresses the application of GMPLS to the overlay model. In one section, the memo provides a description of how the overlay model may be used to support VPN connections across a core GMPLS network. o draft-ietf-l3vpn-ppvpn-terminology-04.txt (September 2004) "Provider Provisioned VPN terminology" This draft sets out terminology common to all Provider Provisioned VPNs. Although this draft specifically targets L2VPNs and L3VPNs, the terminology may be used to L1VPNs as well. Contents 1. Contributors ............................................... 4 2. Terminology ................................................ 4 3. Introduction ............................................... 5 3.1 Overview ................................................... 6 3.1.1 Network Topology ........................................... 6 3.1.2 Introducing Layer 1 VPNs ................................... 6 3.1.3 Current Technologies for Dynamic Layer 1 Provisioning ...... 7 3.2 Relationship with ITU-T .................................... 7 4. Motivations ................................................ 8 4.1 Basic Layer 1 Services ..................................... 8 4.1.1 L1VPN for Dynamic Layer 1 Provisioning ..................... 9 4.2 Merits of L1VPN ............................................ 10 4.2.1 Customer Merits ............................................ 10 4.2.2 Provider Merits ............................................ 10 4.3 L1VPN Deployment Scenarios ................................. 10 4.3.1 Multi-Service Backbone ..................................... 11 4.3.2 Carrier's Carrier .......................................... 11 4.3.3 L1 Resource Trading ........................................ 12 4.3.4 Inter-SP L1 VPN ............................................ 12 4.3.5 Other Scenarios ............................................ 13 5. Reference models ........................................... 13 5.1 Management Systems ......................................... 14 6. Generic Service Description ................................ 14 6.1 CE Construct ............................................... 14 6.2 Generic Service Features ................................... 14 7. Service Models ............................................. 15 7.1 Management-based Service Model ............................. 15 7.2 Signaling-based Service Model (Overlay Service Model) ...... 16 7.3 Signaling and Routing Service Model ........................ 17 7.3.1 Virtual Node Service Model ................................. 17 7.3.2 Virtual Link Service Model ................................. 18 T.Takeda, et al. Expires August 2005 [Page 3] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 7.3.3 Per VPN Peer Service Model ................................. 18 8. Service Models and Service Requirements .................... 19 9. Security Considerations .................................... 21 9.1 Types of Information ....................................... 22 9.2 Security Features .......................................... 22 9.3 Scenarios .................................................. 23 10. Acknowledgements ........................................... 23 11. Normative References ....................................... 24 12. Informative References ..................................... 24 13. Authors' Addresses ......................................... 25 14. Intellectual Property Consideration ........................ 26 15. Full Copyright Statement ................................... 26 1. Contributors This document is based heavily on the work of ITU-T Study Group 13 Question 11. SG13/Q11 has been investigating the service requirements and architecture for Layer 1 VPNs for some time, and this document is a summary and development of the conclusions they have reached. As such, ITU-T SG13 should be seen as a major contributor to this document. 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. Raymond Aubin (Nortel) Marco Carugi (Nortel) Ichiro Inoue (NTT) Hamid Ould-Brahim (Nortel) Tomonori Takeda (NTT) 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-ROUTING] and [PPVPN-TERM]. In addition, following new terms are used within this document. - Virtual link: A provider network TE link provided to customers in routing information for purposes which include path computation. A data link may or may not exist between two end points of a virtual link. T.Takeda, et al. Expires August 2005 [Page 4] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 - Virtual node: A provider network logical node provided to customers in routing information. A virtual node may represent a single physical node or multiple physical nodes and links. - VPN end point: CE's data plane interface, connected to a PE device, which is part of the VPN membership. Note, a data plane interface is the transmission unit associated with a connection, and includes a channel in a channelized interface. - VPN connection (or connection in L1VPN context): A connection between a pair of VPN end points. Note in some scenarios, a connection may be established between a pair of Cs (customer devices), using this CE-CE VPN connection as a segment or forwarding adjacency. Note following terms are aligned with PPVPN terminology, and in this document, have a meaning in the context of L1VPNs, unless specified. - CE (Customer Edge) device: A CE device is a customer device that receives L1VPN service from the provider. A CE device is connected to at least one PE device. A CE device can be a variety of devices, for example, TDM cross connect, router and L2 switch. A CE device may also be attached to one or more C devices on the customer site. - PE (Provider Edge) device: A PE device is a provider device that provides L1VPN service to the customer. A PE device is connected to at least one CE device. A layer 1 PE device is a Time Division Multiplex (TDM) switch, Optical Cross-Connect (OXC) or Fiber Switch (FXC). Or a PE device may be an EPL (Ethernet Private Line) type of device, that maps Ethernet frames on L1 connections. - P (Provider) device: A P device is a provider device, which is connected only to other provider devices (P or PE devices). A layer 1 P is a TDM switch, OXC, or FXC. - Customer: A Customer has authority over a set of CE devices within the same VPN (e.g., the owner of CE devices). Note that a customer may outsource the management of CE devices to other organizations, including to the provider itself. - Provider: A Provider has authority over the management of the provider network. 3. Introduction The document examines motivations for Layer 1 Virtual Private Networks (L1VPNs), provides high level (service level) requirements, and outlines some of the architectural models that might be used to T.Takeda, et al. Expires August 2005 [Page 5] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 build L1VPNs. The objective of the document is mainly to present the requirements and architecture work in this field that has been undertaken within the ITU-T. L1VPNs provide services over layer 1 networks. This document provides a framework for L1VPNs and the realization of the framework by those networks being controlled by GMPLS protocols. 3.1 Overview 3.1.1 Network Topology The layer 1 network, made of Optical Cross-Connects (OXCs), Time Division Multiplex (TDM) capable switches, or Fiber Switches (FXCs) may be seen as consisting of provider edge (PE) devices that give access from outside of the network, and provider (P) devices that operate only within the core of the network. Similarly, outside the layer 1 network is the customer network consisting of customer (C) devices with access to the layer 1 network made through customer edge (CE) devices. A CE and PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it. 3.1.2 Introducing Layer 1 VPNs The concept of a provider provisioned VPN (PPVPN) has been established through many previous documents such as [L2VPN-FRAME] and [L3VPN-FRAME]. Terminology for PPVPNs is set out in [PPVPN-TERM] with special reference to layer 2 and layer 3 VPNs. The realization of Layer 1 VPNs (L1VPNs) can be based on extensions of the concepts of the PPVPN to the layer 1 network. It must be understood that meeting the requirements set out in this document may necessitate modifications to the existing mechanisms both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). It is at the interface between CE and PE devices that the L1VPN service is provided. Note that one of the fundamental differences between L1VPNs and L2/L3 VPNs is that in L1VPNs data plane connectivity does not guarantee control plane connectivity (and vice versa). CE-PE control plane connectivity is essential, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity. The provision of CE-CE control plane connectivity over T.Takeda, et al. Expires August 2005 [Page 6] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 the provider network is also an unique aspect of the L1VPN services, by which control packets can be exchanged between CEs over the control plane of the provider network (e.g., to exchange signaling messages, using VPN connection as a segment of FA) 3.1.3 Current Technologies for Dynamic Layer 1 Provisioning Pre-existing efforts at standardization have focused on the provision of dynamic connections within the layer 1 network (signaling and routing), and the interfaces for requesting services between the CE and PE or between PEs at network boundaries (UNI and E-NNI respectively). No change in principle would be required to the operation within the network, and the E-NNI is not in scope for current L1VPN considerations. But the UNI is very relevant since it is a means by which the CE can make service requests to the PE to establish services (that is, connections) across the layer 1 network to remote CEs. Current UNIs include features to facilitate requests for end-to-end (that is, CE to CE) service requests that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and (of course) destinations. The UNIs, however, do not provide a sufficiently high level of service to support VPNs without some additions. For example, there is no way to distinguish between control messages received over a shared control link (i.e., a control link shared by multiple VPNs) at a UNI, and these messages must be disambiguated with respect to the L1VPN to which they apply. Further, there is currently no leakage of routing information across the PE to CE boundary. While this restriction may be considered desirable from the perspective of network separation, VPN operation may benefit from the dynamic exchange of routing information between CEs that provide access to the VPNs. In order that L1VPNs can be supported in a fully functional manner, these deficiencies and other requirements set out later in this document must be addressed. 3.2 Relationship with ITU-T This document is based on the work of the ITU-T Study Group 13 Question 11. This group has been researching and specifying both the requirements and the architecture of L1VPNs for some time. In this context, this document is a representation of the findings of the ITU-T, and a presentation of those findings in terms and format that T.Takeda, et al. Expires August 2005 [Page 7] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 are familiar to the IETF. In particular, this document is limited to the areas of concern of the IETF. That is, it is limited to layer 1 networks that utilize IP as the underlying support for their control plane. The intention of this document is to present the requirements and architectures developed within the ITU-T to the IETF for better understanding and further cooperation between the two bodies. Some work related to L1VPN solution space has already been done within the IETF. This document intends to set a framework of requirements and architectures into which all possible solutions can fit. 4. Motivations In this discussion many merits and motivations may be taken for granted. The general benefits and desirability of VPNs has been described many times and in many places. This document does not dwell on the merits of VPNs as such, but focuses entirely on the applicability of the VPN concept to layer 1 networks. Similarly, the utility and value of a control plane for the configuration, management and operation of a layer 1 network is well-rehearsed. 4.1 Basic Layer 1 Services Basic layer 1 services may be characterized in terms that include: - Connectivity: Between a pair of CEs. - Capacity: For example, the bit rate for a TDM service or the capacity of a lambda. - Transparency: For example, for an SDH network, overhead transparency. - Availability: The percentage of time that the offered service meets the agreed criteria. To achieve the required level of availability for the customer connections the service provider's network may use restoration or protected resources. - Performance: The quality of the service delivered to customers, e.g., the number of error-seconds per month. The layer 1 services may be categorized based on the combination of connectivity features (data plane) and service control capability features (control plane) available to the customer. A CE is associated with the service interface between a customer site and the T.Takeda, et al. Expires August 2005 [Page 8] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 network, and the categorization can be seen in the context of this service interface as follows. 1. A single connection between a pair of CEs. - Static Service The classic private line service achieved through a permanent connection. - Dynamic Service Either a switched connection service, or a customer-controlled soft permanent connection service 2. Multiple connections among a set of CEs. - Static Service A private network service consisting of a mesh of permanent connections. - Dynamic Service A dynamic private network service consisting of any combination of switched connection services and customer-controlled soft permanent connection services. For both service types, connections are point-to-point, and can be permanent, soft-permanent, or switched. For a static service, the management plane of the provider network is responsible for the management of both the network infrastructure and the end user connections. For dynamic services, the management plane the provider network is only responsible for the configuration of the infrastructure; end user connections are established dynamically via the control plane of the provider network through customer request. Note that the ITU-T allows the second categorization of service type to embrace a variety of C-plane types. 4.1.1 L1VPN for Dynamic Layer 1 Provisioning Private network services in the second category (above) can be enhanced so that multiple private networks are supported across the layer 1 network as virtual private networks. These are Layer 1 Virtual Private Networks (L1VPNs). Note the first category would include L1VPNs for VPNs with only two CEs as a special case. Compared to the first type of service, the L1VPN service has features such as connectivity restriction, a separate policy per VPN, and distribution of membership information. 4.2 Merits of L1VPN T.Takeda, et al. Expires August 2005 [Page 9] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 4.2.1 Customer Merits From the customer's perspective, there are two main benefits to a L1VPN. These benefits apply over and above the advantages of access to a dynamically provisioned network. - The customer can outsource the direct management of an optical network by placing the VPN management in the control of a third party. This frees the customer from the need to configure and manage the connectivity information for the CEs that participate in the VPN. - The customer can make small-scale use of an optical network. So, for example, by sharing access to the optical network with many other users, the customer sites can be connected together across the optical network without bearing the full cost of deploying and managing the optical network. To some extent, the customer may also gain from the provider's benefits (see below). That is, if the provider is able to extract more value from the layer 1 network, and provide better differentiated services, the customer will benefit from lower priced services that are better tailored to the customer's needs. 4.2.2 Provider Merits The provider benefits from the customer's perception of benefits. In particular, the provider can build on dynamic, on-demand services by offering new VPN services and off-loading the CE-to-CE configuration requirements from the customers Additionally, a more flexible VPN structure applied to the optical network allows the provider to make more comprehensive use of the spare (that is, previously unused) resources within the network. In particular, since the PE could be responsible for routing the connection through the optical network, the optical network can reclaim control of how resources are used and adjust the paths so that optimal use is made of all available resources. 4.3 L1VPN Deployment Scenarios In large carrier networks providing various kinds of service, it is often the case that multiple service networks are supported over a shared transport network. L1VPNs are expected to support this type of network architecture. Namely, by applying L1VPNs, multiple internal service networks, which may be managed and operated separately, can be supported over a shared layer 1 transport network controlled and T.Takeda, et al. Expires August 2005 [Page 10] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 managed by GMPLS. In addition, L1VPNs can support capabilities to offer innovative services to external clients. Some more specific deployment scenarios are as follows. 4.3.1 Multi-Service Backbone A multi-service backbone is characterized in terms such that one service department of a carrier receiving the carrier's L1VPN service provides different kinds of higher-layer service. The customer receiving the L1VPN service (i.e., each service department) can offer its own services whose payloads can be any layer (e.g., ATM, IP, TDM). From the L1VPN service provider point of view, these services are not visible and are not part of the L1VPN service. That is, the type of service being carried within the L1 payload is not known by the service provider. The benefit is that the same L1 core network resources are shared by multiple services. A large capacity backbone network (data plane) can be built economically by having the resources shared by multiple services usually with flexibility to modify topologies, while separating the control functions. Thus, each customer can select a specific set of features that are needed to provide their own service. Note it is also possible to control and manage these service networks and the L1 core network by using GMPLS as a unified control plane, instead of using L1VPNs. However, using L1VPNs is beneficial in following points. - Independent address space for each of the service networks - Network isolation (topology information isolation, fault isolation among service networks) - Independent L1 resource view for each of the service networks - Independent policies that could be applied for each of the service networks 4.3.2 Carrier's Carrier A carrier's carrier is characterized in terms such that one carrier that receives another carrier's L1VPN service provides its own services. In this scenario, two carriers may be in different organizations (or may be separately managed within the same organization). It is, therefore, expected that the information provided at the service demarcation points is more limited than in the multi-service backbone case. Similarly, more less control of the L1VPN service is given at the service demarcation points. For example, customers of L1VPN service receive: T.Takeda, et al. Expires August 2005 [Page 11] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 - more limited view of L1VPN service provider network - more limited control over L1VPN service provider network. One of the merits is that each carrier can concentrate on a specific service. For example, the customer of the L1VPN service may focus on L3 services, e.g., providing secure access to the Internet, leaving the L1VPN provider to focus on the L1 service, e.g., providing a long haul bandwidth between cities. The L1VPN customer can construct its own network using L1 resources supplied by the L1VPN provider, usually with flexibility to modify topologies, and utilize dedicated C-Plane functionalities. 4.3.3 L1 Resource Trading In addition to the scenarios where the second tier service provider is using a single core service provider as mentioned above, it is possible for the second tier provider to receive services from more than one core service provider. In this scenario, there are some benefits for the second tier service provider such as dynamic carrier selection based on the price and route redundancy. The second tier service provider can support a function that enables a L1 resource trading service. Using resource information published by its core service providers, a second tier service providers can decide how to best use those providers. For example, if one core service provider is no longer able to satisfy requests for service, an alternate service provider can be used. Or the second tier service provider could choose to respond to price changes over time. Another example of second tier service provider use is to reduce exposure to failures in each provider (improve availability). 4.3.4 Inter-SP L1 VPN In addition to the scenarios where a single connection between two CEs is routed over a single service provider, it is possible that a connection is routed over multiple service providers. This service scenario is called Inter-SP L1VPN. This scenario can be used to construct a single L1VPN from services provided by multiple regional providers. There could be a variety of business relationships among providers and customers. 4.3.5 Other scenarios There can be some more complex L1VPN scenarios such as: - The case when one or both CE-PE links of a L1VPN connection are not T.Takeda, et al. Expires August 2005 [Page 12] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 static, but are based on L1VPN connections in their own right provided by the same or different L1VPN service provider; 5. Reference models Figure 5.1 describes the L1VPN reference model. +--------------------------------+ | | | | : +------+ | +------------+ | : | CE | | | Management | | : |device| | | system(s) | +------+ : | of | | +------------+ | |==:=|VPN A| | | | : +------+ +------+ : | L1 | PE | : +------+ | CE | : | connection |device| : | CE | |device| : +------+ +------+ | | : |device| | of |=:==| |==========| |==========| |--:-| of | |VPN A| : | | | | +------+ : |VPN B| +------+ : | PE | | P | | : +------+ +------+ : |device| |device| | : +------+ | CE | : | | | | +------+ : | CE | |device|=:==| |==========| |==========| |--:-|device| | of | : +------+ +------+ | | : | of | |VPN B| : | | PE | : |VPN A| +------+ : | |device| : +------+ : | | | : +------+ : | | |==:=| CE | : | +------+ : |device| : | | : | of | : | | : |VPN B| : | | : +------+ Customer | | Customer interface | | interface +--------------------------------+ |<------ Provider network ------>| | | Figure 5.1: L1VPN reference model In L1VPN, L1 connections are provided between CEs' data plane interfaces within the same VPN. In Figure 5.1, a connection is provided between the left-hand CE of VPN A and the upper right-hand CE of VPN A, and another connection is provided between the left-hand CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark). These L1 connections are called VPN connections. 5.1 Management Systems T.Takeda, et al. Expires August 2005 [Page 13] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 As shown in the reference model, a provider network may contain a management system(s). A management system(s) may support functions including provisioning, monitoring, billing and recording. Provider management system(s) may also communicate with customer management system(s) in order to provide services. 6. Generic Service Description This section describes generic service descriptions. More detailed service description is described as specific service models in section 7. 6.1 CE Construct - The CE device may support more than one customer VPN. - CE-PE data plane links (between data plane interfaces) may be shared by multiple VPNs. (assuming that each CE-PE control plane link maps one-to-one to a VPN, and maps one-to-one or many-to-one to the data plane link) Note that the requirement to have a separate CE-PE control channel per VPN is because current reference points (UNI, E-NNI) do not provide a way to disambiguate signaling messages that belong to different VPNs. This requirement might go away (that is, a CE-PE control channel may be allowed to be shared between multiple VPNs) if a new VPN reference point is introduced in future, or if suitable modifications are made to the UNI or E-NNI reference points. 6.2 Generic Service Features L1VPN has following two generic service features. - Connectivity restriction: Layer 1 connectivity is provided to a limited set of CE's data plane interfaces, called VPN end points. (This set forms the L1VPN membership.) - Per VPN control and management: Some level of control and management capability is provided to the customer. Details differ depending on service models described in section 7. 7. Service Models This section describes Layer 1 VPN service models, derived from the generic service description presented above, that can be supported by Generalized MPLS (GMPLS) protocols enabled networks. Such layer 1 networks are managed and controlled using GMPLS as described in [RFC3471] and [RFC3473]. It must be understood that meeting the requirements set out in this document may necessitate T.Takeda, et al. Expires August 2005 [Page 14] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 modifications to the existing GMPLS protocols both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). Such modifications are discussed in [L1VPN-APP]. A CE and a PE are connected by one or more data links. The ends of each link are usually represented as GMPLS-capable interfaces. Note in this document, service models are classified by semantics of information exchanged over the customer interface. 7.1 Management-based Service Model Figure 7.1 describes the management-based service model. +--------------------+ | | +----------+ | +----------+ | | Customer | | | Provider | | |Management| : | |Management| | | system(s)|-:-----|----| system(s)| | +----------+ : | +----------+ | : | | : | | +----+ : +----+ +----+ +----+ : +----+ | CE |-------:---| PE |----| P |----| PE |---:-------| CE | +----+ : +----+ +----+ +----+ : +----+ : | | : : +--------------------+ : : |<-Provider network->| : Customer Customer interface interface Figure 7.1: Management-based service model In this service model, customer management system(s) and provider management system(s) communicate with each other. Customer management system(s) access provider management system(s) to request L1 connection setup/deletion between a pair of CEs. Customer management system(s) may obtain additional information, such as resource availability information and monitoring information, from provider management system(s). There is no control message exchange between a CE and PE. The provider network may be based on GMPLS. In this case, existing protocols to meet this service model may need to be extended (e.g., to support soft permanent connections). However, interfaces between management systems are not within the scope of this document. Interfaces between management systems and network devices may need to be studied further. T.Takeda, et al. Expires August 2005 [Page 15] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 7.2 Signaling-based Service Model (Overlay Service Model) Figure 7.2 describes the signaling-based service model. +--------------------+ | | +----+ : +----+ +----+ : +----+ | CE |-------:---| PE | | PE |---:-------| CE | +----+ : +----+ +----+ : +----+ : | | : : +--------------------+ : : |<-Provider network->| : Customer Customer interface interface Figure 7.2: Signaling-based service model In this service model, the customer interface is based on GMPLS UNI overlay. The CE requests L1 connection setup/deletion to a remote CE. There is no routing between a CE and PE. The CE does not receive routing information of remote customer sites, nor routing information of the provider network. The CE's interface may be assigned a public or private address, that designates VPN end points. A CE may optionally receive a list of TE link addresses to which it can request a VPN connection (a list of addresses within the same VPN) (overlay extension). Furthermore, this document does not preclude the case that a CE receives additional information concerning these TE links (e.g., switching type). Note, in the overlay extension service model, information a CE can receive is limited to the CE-PE TE link. There are various ways that customers perceive the provider network. In one example, the whole provider network may be considered as one node - the path specified and recorded in signaling messages reflects this. Note that this is distinct from the Virtual Node service model described in section 7.3.1 because such a model requires that the network is represented to the VPN sites as a virtual node - that is, some form of routing advertisement is implied, and this is not in scope for the Signaling-based service model. Note that in addition, there may be communication between customer management system(s) and provider management system(s) in order to provide detailed monitoring, fault information etc. to customers. 7.3 Signaling and Routing Service Model In this service model, the customer interface is based on GMPLS T.Takeda, et al. Expires August 2005 [Page 16] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 signaling and routing. The CE requests L1 connection setup/deletion to a remote CE. There is routing between a CE and PE, or more precisely between a CE and the VPN routing context instantiated on the PE. This solves a so-called N-square routing problem [GVPN]. In addition, by using the received traffic engineering-based routing information, a customer can use traffic engineering capabilities within his portion of the provider network. For example, a customer can setup two disjoint connections between a pair of CEs. Another example is that a customer can request a connection between a pair of devices within customer sites, and not necessarily between CEs, with more effective traffic engineering. Link state routing information would be needed to implement the above two example scenarios. Some scenarios may be satisfied with reachability routing information only. Note that in addition, there may be communication between customer management system(s) and provider management system(s) in order to provide detailed monitoring, fault information etc. to customers. Three specific types of the signaling and routing service model are the virtual node service model, the virtual link service model and the per VPN peer service model, depending on how customers perceive the provider network in routing and signaling. 7.3.1 Virtual Node Service Model Figure 7.3 describes the virtual node service model. +--------------------+ | | +----+ : | | : +----+ | CE |-------:-----| Virtual Node |-----:-------| CE | +----+ : | | : +----+ : | | : : +--------------------+ : : |<-Provider network->| : Customer Customer interface interface Figure 7.3: Virtual node service model In this type of service model, the whole provider network is represented by a virtual node (defined in section 2). The customer perceives the provider network as one single node, i.e., a Generalized Virtual Private Cross-Connect (GVPXC) [GVPN]. The CE receives routing information of CE-PE links and remote customer sites. T.Takeda, et al. Expires August 2005 [Page 17] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 7.3.2 Virtual Link Service Model Figure 7.4 describes the virtual link service model. +--------------------+ | Virtual | +----+ : +----+ link +----+ : +----+ | CE |-------:---| PE |**************| PE |---:-------| CE | +----+ : +----+ +----+ : +----+ : | | : : +--------------------+ : : |<-Provider network->| : Customer Customer interface interface Figure 7.4: Virtual link service model In this service model, a virtual link is constructed between PEs. For the definition of a virtual link, please refer to terminology in section 2. The CE receives routing information of CE-PE links, remote customer sites, as well as virtual links. A special property of the virtual links used in this service model is that the provider network allocates data plane link resources for the exclusive use of each virtual link. The TE attributes of a virtual link are determined according to data plane link resources allocated to this virtual link. Virtual links are abstraction of the provider network to customers, for administrative purposes, as well as for excluding "unnecessary information". 7.3.3 Per VPN Peer Service Model Figure 7.5 describes the per VPN peer service model. +--------------------+ | | +----+ : +----+ +----+ +----+ : +----+ | CE |-------:---| PE |----| P |----| PE |---:-------| CE | +----+ : +----+ +----+ +----+ : +----+ : | | : : +--------------------+ : : |<-Provider network->| : Customer Customer interface interface Figure 7.5: Per VPN peer service model In this service model, the provider partitions the TE links within the provider network per VPN, and discloses per VPN TE link T.Takeda, et al. Expires August 2005 [Page 18] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 information to corresponding CEs. As such, a CE receives routing information of CE-PE links, remote customer sites, as well as partitioned portions of the provider network. Note that PEs may advertise abstracted routing information of the provider network to CEs, for administrative purpose, as well as for excluding "unnecessary information". In other words, virtual links may be constructed between two nodes where direct data links do not exist, or virtual nodes may be constructed to represent multiple physical nodes and links. In the per VPN peer service model, at least one virtual node corresponding to P devices (one single P or a set of Ps) must be visible to customers. In the virtual link service model, every end point of virtual links must be a PE device. In the virtual node service model, there must be one single virtual node, and this virtual node must be connected with every CE in the VPN. 8. Service Models and Service Requirements Service models mentioned in section 7 are related to which information is exchanged between CE and PE. In addition, service models differ in how data plane resources are allocated for each VPN. Note in original ITU-T documents, the term "U-Plane" is used instead of "data plane". o Data plane resource allocation - Shared or dedicated : Shared means that provider network data plane links are shared by multiple (i.e., any or a specific set of) VPNs. (Data plane links are allocated to a VPN when a VPN connection is requested, and data plane links allocated to one VPN at one time can be allocated to another VPN at another time.) Dedicated means that provider network data plane links are partitioned per VPN. (Data plane links allocated to one VPN can not be used by other VPNs.) o Information exchanged between CE and PE - Signaling - Membership information : A list of TE link addresses within the same VPN (associated with VPN end points) - Customer network routing information - Provider network routing information T.Takeda, et al. Expires August 2005 [Page 19] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 Table 1 shows combination of service requirements and service models. | Data plane | Data plane | shared | dedicated ---------------------------+------------------+------------------- Signaling | Overlay | Overlay ---------------------------+------------------+------------------- Signaling + | Overlay | Overlay Membership information | (extension) | (extension) ---------------------------+------------------+------------------- Signaling + | | Membership information + | Virtual node | Virtual node Customer network routing | | information | | ---------------------------+------------------+------------------- Signaling + | | Membership information + | | Virtual link Customer network routing | Not applicable | information + | | Per VPN peer Provider network routing | | information | | Table 1: Combination of service requirements and service models As described in section 7.3.3, the difference between the virtual link service model and the per VPN peer service model is whether customers have visibility of P devices. In the virtual link service model, every end point of virtual links must be a PE device, thus P devices are not visible to customers. In the per VPN peer service model, at least one virtual node corresponding to P devices (one single P or a set of Ps) is visible to customers. Note when provider network routing information is provided to customers, customers must be able to specify explicit links for a VPN connection over the provider network. Some additional and more detailed service requirements are provided below. They are generally common to the various service models. - Selection of layer 1 class of service: Customers may be optionally allowed to specify a layer 1 class of service (e.g., availability level) for a VPN connection. - Reception of performance information: Customers may be optionally allowed to receive performance information of their VPN connections (e.g., performance monitoring data). When data plane links are dedicated, customers may be optionally allowed to receive T.Takeda, et al. Expires August 2005 [Page 20] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 performance information of links dedicated to them. - Reception of fault information: Customers may be optionally allowed to receive fault information of their VPN connections (e.g., failures, data plane alarms, rejections). When data plane links are dedicated, customers may be optionally allowed to receive fault information of links dedicated to them. - Reception of connection information: Customers may be optionally allowed to receive information of current VPN connections. - Reception of accounting information: Customers receive accounting information of each VPN. - Specification of policy: Customers may be optionally allowed to specify policies (e.g., path computation policies, recovery policies including parameters) for each VPN. - Security: The communication between the customer and the provider must be secure. Further details are described in section 9. - Filtering: Unnecessary information (e.g., information concerning other VPNs) must not be provided to each customer. Further details are described in section 9. - Requests/indications for arbitrary CE-CE control plane information delivery 9. Security Considerations Security is clearly one of essential requirements in L1VPNs. In this section, key security requirements are highlighted. Security considerations for L3VPNs and L2VPNs are described in existing documents, such as in [L3VPN-FRAME] and [L2VPN-FRAME] respectively. These security considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific security considerations for L1VPNs, such as connectivity restriction and shared control links. This section first describes types of information to be secured. Then, security features or aspects are described. Finally, some considerations concerning scenarios where security mechanisms are applied is described. 9.1 Types of Information The information exchanged between the customer and the provider must be secured. This includes data plane information, control plane information and management plane information. At Layer 1, data plane T.Takeda, et al. Expires August 2005 [Page 21] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 information is normally assumed to be secured by default. In L1VPNs, VPN connections must be restricted within the same VPN, as described in section 6.2. In addition, information contained in the provider network must be secured. This includes VPN service contract information, current VPN connection information, VPN membership information, and system information. Note these types of information may be accessible to authorized entities. 9.2 Security Features Security features includes followings: o Data integrity The information exchanged between the customer and the provider must be identical. o Confidentiality The information exchanged between the customer and the provider must not be retrieved by the third party. o Authentication The entity requesting the service to the provider must be identified. o Access control Access to the information contained in the provider network must be restricted to the authorized entity. 9.3 Scenarios There are mainly two scenarios (or occasions) that security mechanisms are applied. One is service contract phase, where security mechanisms are applied once in service contract phase. The other is service access phase, where security mechanisms are applied every time service is requested. o Service contract scenario (static) This scenario includes addition of new physical devices, such as CE devices, data links and control links. It must be guaranteed that these physical devices are connected to the right entity. In addition, authority to access specific information is given to each customer as a part of service contract. T.Takeda, et al. Expires August 2005 [Page 22] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 o Service access scenario (dynamic) This scenario includes reception of connection request, routing information exchange request, and management information retrieval request. If communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, and the entity connected over this communication channel is identified in the service contract phase, the provider can ensure who is requesting the service. Also, the communication channel could be considered as secure. However, when communication channel is physically shared among customers, security mechanisms should be enforced. Note even in the case of physically separate communication channel, customers may wish to apply security mechanisms, such as IPsec, for assuring higher security. When the entity requesting the service is identified, the provider must ensure that the request is authorized for that entity. This includes assuring that connection request is between VPN end points belonging to the same VPN. Also note that customers may wish to apply their own security mechanisms for data plane information (CE-CE security). This includes IPsec for IP traffic. Those security mechanisms must be transparent to customers as much as possible. 10. Acknowledgements The material in this document is based on the work of the ITU-T Study Group 13. We would like to thank Dimitri Papadimitriou, Deborah Brungard and Yakov Rekhter for their useful comments and suggestions. 11. Normative References [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12. 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 T.Takeda, et al. Expires August 2005 [Page 23] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 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. [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-UNI] Swallow, G., et al., "GMPLS UNI: RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress. [GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (editors), "Routing Extensions in Support of Generalized MPLS", draft- ietf-ccamp-gmpls-routing, work in progress. [L2VPN-FRAME] Andersson, L., and Rosen, E. (editors), "Framework for Layer 2 Virtual Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework, work in progress. [L3VPN-FRAME] Callon, R., and Suzuki, M. (editors), "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework, work in progress. [PPVPN-TERM] Andersson, L., and Madsen, T., "PPVPN terminology", draft-ietf-l3vpn-ppvpn-terminology, work in progress. [GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN Services: Generalized VPN Services using BGP and T.Takeda, et al. Expires August 2005 [Page 24] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls, work in progress. [L1VPN-APP] T. Takeda (Ed.), "Applicability analysis of GMPLS protocols to Layer 1 Virtual Private Networks", draft-takeda-l1vpn-applicability, work in progress. 13. Authors' Addresses Raymond Aubin Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 763 2208 Email: aubin@nortelnetworks.com Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE Phone: +33 1 6955 7027 Email: marco.carugi@nortelnetworks.com Ichiro Inoue NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6076 Email: inoue.ichiro@lab.ntt.co.jp 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 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 14. Intellectual Property Consideration The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed T.Takeda, et al. Expires August 2005 [Page 25] Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005 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. 15. 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 August 2005 [Page 26]