Network Working Group T. Takeda, Ed. Request for Comments: 4847 NTT Category: Informational April 2007 Framework and Requirements for Layer 1 Virtual Private Networks Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document provides a framework and service level requirements 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. 1. Introduction ....................................................3 2. Terminology .....................................................3 3. Overview ........................................................5 3.1. Network Topology ...........................................5 3.2. Introducing Layer 1 VPNs ...................................5 3.3. Current Technologies for Dynamic Layer 1 Provisioning ......6 3.4. 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 ............................................9 4.2.1. Customer Merits .....................................9 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. Layer 1 Resource Trading ...........................12 4.3.4. Inter-AS and Inter-SP L1VPNs .......................12
4.3.5. Scheduling Service .................................13 5. Reference Model ................................................14 5.1. Management Systems ........................................15 6. Generic Service Description ....................................15 6.1. CE Construct ..............................................15 6.2. Generic Service Features ..................................16 7. Service Models .................................................16 7.1. Management-Based Service Model ............................17 7.2. Signaling-Based Service Model (Basic Mode) ................17 7.2.1. Overlay Service Model ..............................18 7.3. Signaling and Routing Service Model (Enhanced Mode) .......19 7.3.1. Overlay Extension Service Model ....................20 7.3.2. Virtual Node Service Model .........................20 7.3.3. Virtual Link Service Model .........................21 7.3.4. Per-VPN Peer Service Model .........................22 8. Service Models and Service Requirements ........................22 8.1. Detailed Service Level Requirements .......................24 9. Recovery Aspects ...............................................25 9.1. Recovery Scope ............................................25 9.2. Recovery Resource Sharing Schemes .........................26 10. Control Plane Connectivity ....................................27 10.1. Control Plane Connectivity between a CE and a PE .........27 10.2. Control Plane Connectivity between CEs ...................28 11. Manageability Considerations ..................................29 12. Security Considerations .......................................31 12.1. Types of Information .....................................32 12.2. Security Features ........................................32 12.3. Scenarios ................................................33 13. Acknowledgements ..............................................34 14. Contributors ..................................................34 15. Normative References ..........................................35 16. Informative References ........................................35
RFC2119]. The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC3945], [RFC4208], and [RFC4026]. In this context, a Layer 1 Network is any transport network that has connectivity and/or switching using spatial switching (e.g., incoming port or fiber to outgoing port or fiber), lambda-switching, or time- division-multiplex-switching. A Layer 1 VPN (L1VPN) is a service offered by a core layer 1 network to provide layer 1 connectivity between two or more customer sites, and where the customer has some control over the establishment and type of the connectivity. An alternative definition is simply to say that an L1VPN is a VPN whose data plane operates at layer 1. Further details of the essence of an L1VPN are provided in Section 3.
In addition, the following new terms are used within this document: - Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link. - Virtual node: A provider network logical node advertised to customers in routing information. A virtual node may represent a single physical node, or multiple physical nodes and the links between them. - VPN end point: A Customer Edge (CE) device's data plane interface, which is connected to a Provider Edge (PE) device, and which is part of the VPN membership. Note that a data plane interface is associated with a TE link end point. For example, if a CE router's interface is a channelized interface (defined in SONET/SDH), a channel in the channelized interface can be a data plane interface. - VPN connection (or connection in the L1VPN context): A connection between a pair of VPN end points. Note that in some scenarios a connection may be established between a pair of C (Customer) devices using this CE-CE VPN connection as a segment or forwarding adjacency defined in [RFC4206]. Note that the following terms are aligned with Provider Provisioned VPN (PPVPN) terminology [RFC4026], and in this document, have a meaning in the context of L1VPNs, unless otherwise specified. - CE 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, Time Division Multiplexing (TDM) switch, router, and layer 2 switch. A CE device does not have to have the capability to switch at layer 1, but it is capable of receiving a layer 1 signal and either switching it or terminating it with adaptation. A CE device may be attached to one or more C devices on the customer site, and it may be a host using a layer 1 connection directly. - PE 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 TDM switch, an Optical Cross- Connect (OXC) (see [RFC3945]), or a Photonic Cross-Connect (PXC) (see [RFC3945]). Alternatively, a PE device may be an Ethernet Private Line (EPL) type of device that maps Ethernet frames onto layer 1 connections (by means of Ethernet over TDM etc.).
- P (Provider) device: A P device is a provider device that is connected only to other provider devices (P or PE devices). A layer 1 P is a TDM switch, OXC, or PXC. - 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. - Membership information: A list of CE-PE TE link addresses belonging to the same VPN. Membership information contains the association of a CE, a PE, and a VPN. RFC4206]. That is, a CE-CE connection may be nested in a lower layer connection (e.g., VC3 connection over STM1 connection). Likewise, the switching capabilities of the interfaces of the CEs, PEs, and Ps on which a connection is routed, follow the hierarchy defined in [RFC4206]. RFC4664] and [RFC4110]. Terminology for PPVPNs is set out in [RFC4026] with special reference to layer 2 and layer 3 VPNs. The realization of 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
extensions 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 the fundamental difference between L1VPNs and L2/L3 VPNs is that in L1VPNs, data plane connectivity does not guarantee control plane connectivity (and vice versa). But CE-PE control plane connectivity is required for L1VPN services provisioned through the control plane, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity. Furthermore, the provision of CE-CE control plane connectivity over the provider network is also required for certain levels of L1VPN service, and this can be achieved by the exchange of control packets between CEs over the control plane of the provider network. This aspect is discussed further in Section 10.2. RFC3945], [RFC4208], [RFC4139], and [RFC4258]). Current UNIs include features to facilitate requests for end-to-end (that is, CE to CE) services that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and (of course) destinations. Current E-NNIs include features to exchange routing information, as well as to facilitate requests for end-to-end services. The UNIs and E-NNIs may be applied in the context of L1VPNs. For example, the UNI may be applied between the CE and the PE, and the E-NNI may be applied between PEs (inter-AS/SP L1VPNs), or between the CE and the PE. However, the existing UNI and E-NNI specifications do not provide sufficient parameters 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/E-NNI, and these messages must be disambiguated to determine the L1VPN to which they apply. A control link is an IP link used for establishing a control channel between nodes.
Another example is that there is no clearly defined way of distributing membership information to be used in combination with UNI/E-NNI. This function is necessary in order to discover the existence and location of the CEs to be connected by L1 connections. Distribution of membership information is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (e.g., see Section 4.2.1 of [RFC4110]). Note that the method chosen for distribution of membership information depends on the solution used for supporting L1VPNs, which is outside of the scope of this document. Furthermore, customer addressing realms may overlap with each other, and may also overlap with the service provider addressing realm. This requires address mapping mechanisms, but such mechanisms are not well defined in existing UNI/E-NNI specifications. Lastly, there is no clearly defined way to restrict connectivity among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing information exchange, but there is no clearly defined way to allow limited routing information exchange (i.e., a specific set of routing information is distributed to a specific set of CEs). In order for L1VPNs to be supported in a fully functional manner, these additional capabilities and other requirements set out later in this document must be addressed. Note that inter-AS/SP L1VPNs require additional analysis beyond the focus of this document. Y.1312] and [Y.1313]. This group has been researching and specifying both the requirements and the architecture of L1VPNs for some time. In this context, the foundation of this document is a representation of the findings of the ITU-T, and a presentation of those findings in terms and format that 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 foundation of this document presents the requirements and architectures developed within the ITU-T for better understanding within the IETF and to further cooperation between the two bodies.
Some work related to the L1VPN solution space has already been done within the IETF. RFC4110] and [RFC4664]). 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 [RFC3945]. RFC4427]. - 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 provider 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 (i.e., the customer is in control of when the signaled part is established). 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 service types 1 and 2, 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 of 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 upon customer request. This document does not preclude other advanced services and topology support, such as point-to-multipoint (P2MP) services, as part of the layer 1 services, but these are for further study. Section 4.1 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 that the first category in Section 4.1 would include L1VPNs with only two CEs as a special case. Compared to the first category of service, the L1VPN service has features such as connectivity restriction, a separate policy, and distribution of membership information applied to a specific group.
- The customer can outsource the direct management of a layer 1 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 a layer 1 network. So, for example, by sharing the layer 1 network infrastructure with many other users, the customer sites can be connected together across the layer 1 network without bearing the full cost of deploying and managing the layer 1 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, the customer will benefit from lower priced services that are better tailored to the customer's needs.
RFC3945] instead of using L1VPNs. However, using L1VPNs is beneficial in the following points: - Independent address space for each of the service networks. - Network isolation (topology information isolation, fault isolation among service networks). - Independent layer 1 resource view for each of the service networks. - Independent policies that could be applied for each of the service networks. These points may apply to the management plane functionalities as well as to the control plane functionalities.
service demarcation points. For example, customers of an L1VPN service receive: - A more limited view of the L1VPN service provider network. - More limited control over the 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 layer 1 service, e.g., providing a long-haul bandwidth between cities. The L1VPN customer can construct its own network using layer 1 resources supplied by the L1VPN provider, usually with flexibility to modify topologies, while separating the control functions for each customer carrier. Section 4.3.2, 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 route redundancy and dynamic carrier selection based on the price. The second tier service provider can support a function that enables a layer 1 resource trading service. Using resource information published by its core service providers, a second tier service provider can decide how to best use the core 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 of service over time. Another example of second tier service provider use is to reduce exposure to failures in each provider (i.e., to improve availability). Section 4.3.2, it is possible that a connection is routed over multiple ASes within a service provider (called inter-AS L1VPN) or over multiple service providers (called inter-SP L1VPN). The inter-AS L1VPN scenario can be used to construct a single L1VPN from network resources administered by different domains of a single
service provider. These administrative domains might not usually have a collaborative relationship at layer 1, and so the inter-AS L1VPN offers a new business model for joint delivery of services to a customer. Consideration of inter-AS L1VPNs requires further analysis beyond the scope of this document. The inter-SP 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, and this scenario contains many more manageability, security, privacy, policy, and commercial issues than the more simple inter-AS L1VPN case. Consideration of inter-SP L1VPN requires further analysis beyond the scope of this document.
Figure 5.1 describes the L1VPN reference model. : +--------------------+ : : | +------------+ | : : | | Management | | : +------+ : | | system(s) | | : +------+ | C | : | +------------+ | : | CE | +------+ |device| : | | : |device|--| C | +------+ : | +------+ : | of | |device| | : | | |=:=|VPN A| +------+ | : | | | : +------+ +------+ : | | PE | : +------+ +------+ | CE | : | |device| : | CE | +------+ | C | |device| : +------+ +------+ | | : |device| | C | |device|--| of |=:=| |==| |==| |-:-| of |--|device| +------+ |VPN A| : | | | | +------+ : |VPN B| +------+ +------+ : | PE | | P | | : +------+ +------+ : |device| |device| | : +------+ +------+ | CE | : | | | | +------+ : | CE | +------+ | C |--|device|=:=| |==| |==| |-:-|device|--| C | |device| | of | : +------+ +------+ | | : | of | |device| +------+ |VPN B| : | | PE | : |VPN A| +------+ +------+ : | |device| : +------+ | : | | | : +------+ | : | | |=:=| CE | +------+ +------+ : | +------+ : |device| | C | | C | : | | : | of |--|device| |device| : | | : |VPN B| +------+ +------+ : | | : +------+ : | | : Customer | | Customer interface | | interface +--------------------+ |<---- Provider ---->| | network | Key: ==== Layer 1 Connection -- link Figure 5.1: L1VPN Reference Model In an L1VPN, layer 1 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 layer 1 connections are called VPN connections.
Note that as mentioned in Section 3.1, these VPN connections follow the hierarchy defined in [RFC4206]. Sections 7 and 11 provide more detail. Section 7.
Section 7. RFC3471] and [RFC3473], and GMPLS routing as described in [RFC4202]. It must be understood that meeting the requirements set out in this document may necessitate extensions 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). 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 that in this document, service models are classified by the semantics of information exchanged over the customer interface. The customer interface may be instantiated by the CE-PE control plane communication and/or the management plane communication between the customer management systems(s) and the provider management system(s). Note that how to realize a CE-PE control channel is discussed in Section 10.1. Customer management system(s) and provider management systems(s) may communicate by utilizing the CE-PE control channel(s).
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 systems and provider management systems communicate with each other. Customer management systems access provider management systems to request layer 1 connection setup/deletion between a pair of CEs. Customer management systems may obtain additional information, such as resource availability information and monitoring information, from provider management systems. There is no control message exchange between a CE and PE. The provider network may be based on GMPLS. In this case, mechanisms to support soft permanent connections can be applied. However, interfaces between management systems are not within the scope of this document.
Note in addition that there may be communication between customer management system(s) and provider management system(s) in order to provide customers with detailed monitoring, fault information, etc. Figure 7.2 describes the Overlay service model. +--------------------+ : | | : : | | : +----+ : +----+ +----+ : +----+ | CE |---:---| PE | | PE |---:---| CE | +----+ : +----+ +----+ : +----+ : | | : : | | : : +--------------------+ : : | | : : |<-Provider network->| : Customer Customer interface interface Figure 7.2: Overlay Service Model In this service model, the customer interface is based on the GMPLS UNI Overlay [RFC4208]. The CE requests layer 1 connection setup/deletion to a remote CE. There is no routing protocol running (i.e., no routing neighbor/peering relationship) between a CE and a PE. The CE does not receive routing information from remote customer sites, nor routing information about the provider network. The CE's interface may be assigned a public or private address, that designates VPN end points. In this model, membership information needs to be configured on PEs, so that the PE that receives a Path message from the ingress CE can identify the remote PE connected to the egress CE. Distribution of membership information between PEs is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (auto-discovery). 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.2 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.
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 as a virtual node (defined in Section 2). The customer perceives the provider network as one single node. The CE receives routing information about CE-PE links and the customer network (i.e., remote customer sites). Note that in this service model, there must be one single virtual node, and this virtual node must be connected with every CE in the VPN.
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. A virtual link is assigned to each VPN and disclosed to the corresponding CEs. As such, the CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as virtual links assigned to each VPN. 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 an abstraction of the provider network to customers for administrative purposes as well as to exclude "unnecessary information". Note that in this service model, both end points of each virtual link must be a PE device.
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 This service model is a generalization and combination of the Virtual Link service model and the Virtual Node service model mentioned in Sections 7.3.2 and 7.3.3 respectively. In this service model, the provider partitions the TE links within the provider network per VPN, and discloses per-VPN TE link information to corresponding CEs. As such, a CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as partitioned portions of the provider network. Note that PEs may advertise abstracted routing information about the provider network to CEs for administrative purpose as well as to exclude "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 between them. 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. Section 7 are related to what information is exchanged between CE and PE. In addition, service models differ in how data plane resources are allocated for each VPN. Note that in the 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 dynamically 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 are statically allocated to one VPN and can not be used by other VPNs.) o Information exchanged between CE and PE - Signaling - Membership information (optionally includes TE information of the associated CE-PE TE links) - Customer network routing information (reachability only, or may include TE information) - Provider network routing information (TE information) Note that link management information (e.g., LMP [RFC4204]) may be exchanged between a CE and a PE, but this is orthogonal to the definition of the service models. 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 previous sections, 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, the end points of virtual links must be PE devices, 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 that when customers receive provider network routing information in the form of virtual link, customers must be able to specify such links for a VPN connection over the provider network in signaling. Section 9.
- Reception of performance information: Customers MAY be allowed to receive performance information for their VPN connections (e.g., performance monitoring data). When data plane links are dedicated, customers MAY be allowed to receive performance information for links dedicated to them. - Reception of fault information: Customers MAY be allowed to receive fault information for their VPN connections (e.g., failure notification by RSVP-TE, data plane alarm notification through the management plane, notification of connection setup rejection causes). Note that this does not prevent customers from using Operations and Management (OAM) mechanisms for, or on, their VPN connections. When data plane links are dedicated, customers MAY be allowed to receive fault information for links dedicated to them. - Reception of connection information: Customers MAY be allowed to receive information for current VPN connections (through the management plane). - Reception of accounting information: Customers MUST be able to receive accounting information for each VPN. - Specification of policy: Customers MAY be 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 12. - Filtering: Unnecessary information (e.g., information concerning other VPNs) MUST NOT be provided to each customer. This applies particularly to the Signaling and Routing service model, but is also relevant to the Signaling-based service model and to the Management-based service model. Further details are described in Section 12. RFC4427]. The provider network may apply these recovery techniques to protect VPN connections as part of the L1VPN service, for example as follows:
o PE-PE recovery The provider network constitutes a recovery domain, and the recovery scope is the PE-PE part of the CE-CE VPN connection. It should be possible for the provider network to hide the provider network recovery operation from the customer. Namely, it should be possible to configure the provider network to not notify the customer when a failure occurs and a PE-PE recovery operation successfully repairs the failure. Further, when PE-PE recovery fails and the failure should be notified to the customer, it should be possible for the provider network to hide its internal topology. o CE-PE recovery The recovery scope is either or both of the ingress and egress CE-PE links of the CE-CE VPN connection. o CE-CE recovery The recovery scope is the entire CE-CE VPN connection. When a failure needs to be notified to a customer so that the customer can initiate recovery operation, it should be possible for the provider network to hide its internal topology. These recovery schemes may be applied in combination. Customers may be allowed to specify the desired recovery level in a connection setup request. Furthermore, the customer may be allowed to specify the desired recovery level in a way that is agnostic of the recovery technique (e.g., when the recovery operation does not require cooperation between the provider network and the customer network). In such cases, the provider network must translate the specified recovery level into specific recovery techniques, based on operational policies. This allows enhanced recovery techniques above and beyond the GMPLS specifications to be used in the provider network. RFC4427]), the provider network may provide
sharing recovery resources between VPN connections that serve with only the same VPN, a specific set of VPNs, or any VPN. The default mode is sharing recovery resources with any VPN. o Extra traffic GMPLS recovery mechanisms support extra traffic. Extra traffic allows the transfer of preemptable traffic on the recovery resources when these resources are not being used for the recovery of protected normal traffic [RFC4427]. In the context of L1VPNs, extra traffic is applied for CE-CE VPN connections, or PE-PE part of CE-CE VPN connections. The latter case may be applied only when there is hierarchy (i.e., CE-CE VPN connection is nested on top of PE-PE connection). In this section, the latter aspect is analyzed. When the provider network allows a CE-CE VPN connection to be set up as "extra traffic", it means that the VPN connection may use a PE-PE connection that protects some other CE-CE VPN connection. In such a case the provider network may restrict extra traffic CE-CE VPN connection to use resources (i.e., the PE-PE connections) that: - protect VPN connections from the same VPN as the extra traffic connection. - are used for a specific set of VPNs. - are available for any VPN. The default mode is to support preemptable traffic on recovery resources reserved for any VPN. Section 6.1, it is necessary to disambiguate control plane messages exchanged between the CE and PE if the CE-PE relationship is applicable to more than one VPN. Furthermore, private addresses may be assigned to CE-PE control channels.
Security aspects of the CE-PE control channel are discussed in Section 12.
o Use of separate network A customer may utilize another network and network service, such as private line service, L3VPN service, L2VPN service, or Internet access service, to establish CE-CE control channel connectivity. This operation is transparent to the L1VPN service provider. o Use of CE-PE control channels In the Signaling-based service model, and the Signaling and Routing service model, there must be control plane (IP-level) connectivity between the CE and PE, as described in Section 10.1. By utilizing this, CE-CE control message exchange could be realized as part of the service provided by the L1VPN service provider. Namely, the provider network transfers control messages received over the CE-PE control channel to the other side of the provider network and delivers them through the PE-CE control channel. The realization of this within the provider network is up to the operator, but where the provider network uses a GMPLS control plane, the customer control plane messages could be forwarded through the provider control plane, perhaps using IP tunnels. Care must be taken to protect the provider network and other customers from Denial of Service (DoS) attack. Traffic saturation over the control plane network needs to be carefully managed as well. Note that if private addresses are assigned to the CE-PE control channels, the provider network must support VPN-scoped routing and forwarding for control messages. RFC3945]. Also, manageability considerations for L3VPN are described in existing documents, such as [RFC4176]. These manageability considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific manageability considerations for L1VPNs, such as configuration and accounting. o Fault management The provider network MUST support fault management. It MUST support liveness detection, and monitoring and verification of correct operation.
When a failure occurs, the provider network SHOULD correlate the failure. Also, it SHOULD be able to detect which customer is affected by the failure. If the provider network can resolve failures without intervention from the customer network, it MUST be possible to configure the provider network to not report failures to the customers. However, it MAY be part of an agreement between a customer and provider that failures are reported to the customer, regardless. o Configuration management The provider network MUST support configuration management, such as the following. - Service mode/model configuration. - Network representation configuration: Configuration of virtual node and virtual link. - Resource allocation configuration: Dedicated, shared. See Section 8 for more detail. - Recovery policy configuration: For example, recovery resource sharing schemes, such as shared recovery, extra traffic. See Section 9 for more detail. - Membership configuration. - Network/Element level configuration: For example, TE link configuration. It SHOULD be possible for the provider network to verify that configuration is correctly made. o Accounting management The provider network MUST support accounting management. It MUST be able to record usage of VPN connections for each customer. o Performance management The provider network MUST support performance management. In particular, it MUST support performance monitoring of parameters associated with the Service Level Agreement (SLA), such as bit error rate per VPN connection, and SLA verification.
In addition, it MUST support performance monitoring and analysis of parameters related to the network and equipment not directly associated with the SLA, such as network resource utilization. o Security management The provider network MUST support security management. See Section 12 for details. o Management systems In order to support various management functionalities, the provider network relies on management systems and related tools. GMPLS protocols and potential extensions of GMPLS MUST be able to work with management systems and related tools to provide such functionalities. In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported. o Management of customer networks Customers MAY outsource management of their network (especially CEs and CE-CE links) to the provider network. In such case, the provider MUST be able to manage the customer network, as well as the provider network. RFC4110], [RFC4111], and [RFC4664]. 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.
Section 6.2. Note that a customer may wish to assure data plane information security against not only other customers, but also the provider. In such case, the customer may wish to apply their own security mechanisms for data plane information (CE-CE security), as later described. 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.
o Access control Access to the information contained in the provider network, which may be information about the customer networks or the existence of customers, as well as about the provider network, MUST be restricted to the authorized entity. o DoS attack detection and protection The provider network MUST have mechanisms to detect DoS attack and to protect against it reactively and proactively. RFC4302] and [RFC4303]. Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms to assure higher security, and such mechanisms MUST be available.
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 [RFC4302] and [RFC4303] for IP traffic.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Recommendation, September 2003, available from <http://www.itu.int>. [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network architectures, ITU-T Recommendation, July 2004, available from <http://www.itu.int>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC4111] Fang, L., Ed., "Security Framework for Provider- Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005. [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi- Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.