RFC 4847
Framework and Requirements for Layer 1 Virtual Private Networks
RFC 4847: Framework and Requirements for Layer 1 Virtual Private Networks 🦋
Okay bestie, this one is by T. Takeda, Ed. from NTT, and it's an Informational RFC from April 2007 💅. Informational means it's sharing info with the internet community. It doesn't set an internet standard, so nobody is forced to follow it. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🌸.
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).
Abstract 💜
This document gives you a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs) ✨. The whole point of this framework is to help people develop and standardize protocols and mechanisms that let L1VPNs work together interoperably 🫶.
It looks at why anyone would want L1VPNs, lists the high level (service level) requirements, and sketches out some of the architectural models that could be used to build them 🧚.
Table of Contents 🌈
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 ........................................351. Introduction ✨
This document looks at why L1VPNs are worth building 🌸, gives the high-level (service-level) requirements, and outlines some of the architectural models that could be used to build them.
The main goal here is to present the requirements and architecture, based on work done within Question 11 of Study Group 13 of the ITU-T 💖.
L1VPNs provide services over layer 1 networks 🦋. This document gives a framework for L1VPNs, and for how that framework can be realized by layer 1 networks controlled by Generalized Multi-Protocol Label Switching (GMPLS) protocols 🔥.
Using GMPLS protocols to provide L1VPN services has a few perks, like:
- Flexible network operation.
- Use of standardized protocols.
- Use of common control and measurement plane protocols applicable to various layer 1 networks, including Time Division Multiplexing (TDM) networks and optical networks.
2. Terminology 📚
Okay so the requirement words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document should be read exactly as described in [RFC2119] 💅.
The reader is assumed to already know the stuff in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC3945], [RFC4208], and [RFC4026] 🧠.
So, a Layer 1 Network is any transport network that does connectivity and/or switching using spatial switching (for example, incoming port or fiber to outgoing port or fiber), lambda-switching, or time-division-multiplex-switching 🌈.
An L1VPN is a service that a core layer 1 network offers to give layer 1 connectivity between two or more customer sites 💜. The customer gets some control over how that connectivity gets set up and what type it is ✨. Another way to say it: an L1VPN is a VPN whose data plane runs at layer 1 🫶. You'll find more about the essence of an L1VPN in Section 3.
This document also uses these new terms:
- Virtual link: A provider network Traffic Engineering (TE) link that gets advertised to customers in routing information, for purposes that include path computation. There may or may not be a direct data link between the two end points of a virtual link 🦋.
- Virtual node: A provider network logical node that gets advertised to customers in routing information. A virtual node may stand for a single physical node, or for 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 is part of the VPN membership. Heads up: a data plane interface is tied to a TE link end point 👀. For example, if a CE router's interface is a channelized interface (defined in SONET/SDH), then a channel inside that 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. In some scenarios, a connection can be set up between a pair of C (Customer) devices, using this CE-CE VPN connection as a segment or forwarding adjacency defined in [RFC4206] 💅.
Also, the following terms line up with Provider Provisioned VPN (PPVPN) terminology [RFC4026]. In this document they mean what they mean in the L1VPN context, unless said otherwise 💖.
- CE device: A CE device is a customer device that gets L1VPN service from the provider. It's connected to at least one PE device. A CE device can be all kinds of things, like a Time Division Multiplexing (TDM) switch, a router, or a layer 2 switch 🌸. It doesn't have to be able to switch at layer 1, but it does need to be able to receive a layer 1 signal and either switch it or terminate it with adaptation ✨. A CE device can be attached to one or more C devices on the customer site, and it can also be a host that uses a layer 1 connection directly 🫶.
- PE device: A PE device is a provider device that gives L1VPN service to the customer. It's 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]) 🔥. Or, a PE device can 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's only connected 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 (for example, the owner of the CE devices) 💜. A customer can hand off managing its CE devices to other organizations, including the provider itself 👑.
- Provider: A provider has authority over managing the provider network 💅.
- Membership information: A list of CE-PE TE link addresses that belong to the same VPN. Membership information ties together a CE, a PE, and a VPN 🎀.
3. Overview 🌸
3.1. Network Topology 🗺️
The layer 1 network, made of OXCs, TDM switches, or PXCs, can be seen as PE devices that give access from outside the network, plus P devices that only operate inside the core of the network 💖. Outside the layer 1 network is the customer network, made of C devices that reach the layer 1 network through CE devices ✨.
A CE and a PE are connected by one or more links 🫶. A CE can also be connected to more than one PE, and a PE can have more than one CE connected to it 🦋.
A layer 1 connection is provided between a pair of CEs 💜. That connection follows the hierarchy defined in [RFC4206]. So a CE-CE connection can be nested inside a lower layer connection (for example, a VC3 connection over an STM1 connection) 🔥. Likewise, the switching capabilities of the interfaces on the CEs, PEs, and Ps that a connection gets routed over also follow the hierarchy defined in [RFC4206] 🌈.
3.2. Introducing Layer 1 VPNs ✨
okay so PPVPNs have already been a whole thing in earlier docs like [RFC4664] and [RFC4110] 🫶 and the terminology for them lives in [RFC4026], which gets extra specific about layer 2 and layer 3 VPNs 💅
so the realization of L1VPNs can be built by extending the PPVPN concepts down to the layer 1 network 🦋 bestie, it's giving "we need to upgrade the mechanisms," because meeting the requirements in this document may need extensions to the existing control plane mechanisms inside the layer 1 network AND to the service provisioning at the edge (CE and PE devices) 🔥 and the actual L1VPN service gets delivered at the interface between CE and PE devices 🎀
the big difference between L1VPNs and L2/L3 VPNs is this: 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 that get provisioned through the control plane, and CE-CE data plane connectivity is kept up by signaling mechanisms that rely on that control plane connectivity 🧚 also, CE-CE control plane connectivity over the provider network is required for certain levels of L1VPN service, and it can be achieved by swapping control packets between CEs over the provider network's control plane 💜 we dig into this more in Section 10.2 🌸
3.3. Current Technologies for Dynamic Layer 1 Provisioning 🍓
okay so previous standards work has focused on dynamic connections inside the layer 1 network (signaling and routing), plus interfaces for requesting services between the user and the layer 1 network over the User-Network Interface (UNI), and between networks over the External Network-Network Interface (E-NNI) 💖 (see [RFC3945], [RFC4208], [RFC4139], and [RFC4258]) ✨
current UNIs come with features for requesting end-to-end (that is, CE to CE) services, including constraints like explicit paths, bandwidth requirements, protection needs, and (of course) destinations 👑
current E-NNIs have features to exchange routing information, and to request end-to-end services too 🦋
the UNIs and E-NNIs can be used in the context of L1VPNs 🌈 for example, the UNI can sit between the CE and the PE, and the E-NNI can sit between PEs (inter-AS/SP L1VPNs), or between the CE and the PE 💅
but!! the existing UNI and E-NNI specs don't have enough parameters to support VPNs without some additions 😭 for example, there's no way to tell apart control messages that arrive over a shared control link (a control link shared by multiple VPNs) at a UNI/E-NNI 💀 those messages need to be disambiguated so we know which L1VPN they belong to 🙈 a control link is just an IP link used for setting up a control channel between nodes 🫶
another example: there's no clearly defined way to distribute membership information for use with UNI/E-NNI 💔 this is needed to discover where the CEs are and that they exist, so L1 connections can reach them 🧚 membership distribution is typically handled by the provider, and it can be done with things like static provisioning or by piggybacking on routing protocols (e.g., see Section 4.2.1 of [RFC4110]) 🌸 the method used for membership distribution depends on the solution used to support L1VPNs, which is out of scope for this document ✨
also, customer addressing realms can overlap with each other, and they can overlap with the service provider addressing realm too 🙈 that needs address mapping mechanisms, but those aren't well defined in the existing UNI/E-NNI specs 🫠
lastly, there's no clearly defined way to restrict connectivity among CEs (or over a UNI/E-NNI) 😤 and while E-NNIs allow routing information exchange, there's no clearly defined way to allow limited exchange (a specific set of routing info distributed to a specific set of CEs) 💜
so yeah, to fully support L1VPNs in a fully functional way, these extra capabilities and the other requirements set out later in this document need to be addressed 👑
note that inter-AS/SP L1VPNs need extra analysis that's beyond the focus of this document 🎀
3.4. Relationship with ITU-T 🌈
the foundation of this document comes from the work of ITU-T Study Group 13, Question 11, like [Y.1312] and [Y.1313] 🧚 this group has been researching and specifying both the requirements and the architecture of L1VPNs for a while now 💖 so in this context, the foundation of this document represents the ITU-T's findings, presented in terms and a format that feel familiar to the IETF ✨
in particular, this document is limited to the areas the IETF cares about 💅 that means it's limited to layer 1 networks that use IP as the underlying support for their control plane 🦋
the foundation of this document presents the requirements and architectures developed within the ITU-T so the IETF can understand them better and so the two bodies can cooperate more 🫶
some work related to the L1VPN solution space has already been done within the IETF 🌸
- Motivations 💜
the general benefits and desirability of VPNs have been described many times and in many places ([RFC4110] and [RFC4664]) 💅 this document doesn't dwell on the merits of VPNs as such, and instead focuses entirely on how the VPN concept applies to layer 1 networks 🔥
similarly, the utility and value of a control plane for configuring, managing, and operating a layer 1 network is well-rehearsed [RFC3945] 😭
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 criteria that the provider defines, possibly agreed with each customer. To achieve the required level of availability for the customer connections, the service provider's network may use restoration or protected resources [RFC4427]. 👑
- Performance: The quality of the service delivered to customers, e.g., the number of error-seconds per month. 🎀
the layer 1 services can 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 makes the most sense in the context of this service interface, like so 🧚
- 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). 💖
- 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 managing both the network infrastructure and the end-user connections 💜 for dynamic services, the management plane of the provider network is only responsible for configuring the infrastructure, and end-user connections get established dynamically via the control plane of the provider network upon customer request 👑
this document doesn't preclude other advanced services and topology support, like point-to-multipoint (P2MP) services, as part of the layer 1 services 🌈 but those are for further study 🙈
4.1.1. L1VPN for Dynamic Layer 1 Provisioning ✨
private network services in the second category in 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 like connectivity restriction, a separate policy, and distribution of membership information applied to a specific group 💅
4.2. Merits of L1VPN 🌸
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 a layer 1 network by placing the VPN management in the control of a third party. This frees the customer from needing 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 🧚
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 layer 1 network lets the provider make more comprehensive use of the spare (that is, previously unused) resources within the network 🫶 this could be achieved by applying a network model where the provider is responsible for deciding how resources are used and for provisioning the connection through the layer 1 network 💅
4.3. L1VPN Deployment Scenarios 🍓
in large carrier networks providing various kinds of service, it's often the case that multiple service networks are supported over a shared transport network 🔥 by applying L1VPNs, multiple internal service networks (which may be managed and operated separately) can be supported over a shared layer 1 transport network that's controlled and managed using GMPLS 🦋 on top of that, 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 🌐
okay so a multi-service backbone is when each service department at a carrier that gets the carrier's L1VPN service runs a different kind of higher-layer service 💅. The customer getting the L1VPN service (aka each service department) can offer its own services, and those payloads can be any layer, like ATM, IP, or TDM 🦋. The layer 1 transport network and each service network belong to the same organization, but they can be managed separately 🧚. From the L1VPN service provider's point of view, those services are invisible and aren't part of the L1VPN service at all. The provider doesn't even know what kind of service is riding inside the layer 1 payload 🙈.
The benefit is giving the same layer 1 transport network resources to multiple services 🔥. A big-capacity backbone (data plane) can get built economically when several services share the resources, and it usually comes with flexibility to change topologies, while each service department keeps its own control functions separate 💜. So every customer can pick the specific set of features they need for their own service ✨.
Note that it's also possible to control and manage these service networks and the layer 1 transport network with GMPLS in the integrated model [RFC3945] instead of using L1VPNs 🎀. Still, using L1VPNs is beneficial in these ways:
- 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 🫶.
4.3.2. Carrier's Carrier 👑
A carrier's carrier is when one carrier that gets another carrier's L1VPN service provides its own services on top 💖. In this setup the two carriers are in different organizations, so it makes sense that the information provided at the service demarcation points is more limited than in the multi-service backbone case 😭. Less control of the L1VPN service is handed over at those demarcation points too. 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 gets to focus on a specific service 🧁. For example, the L1VPN customer might focus on L3 services, like providing secure access to the Internet, while the L1VPN provider focuses on the layer 1 service, like providing long-haul bandwidth between cities 🌸. The L1VPN customer can build its own network out of layer 1 resources supplied by the L1VPN provider, usually with flexibility to modify topologies, while keeping the control functions for each customer carrier separate 🦋.
4.3.3. Layer 1 Resource Trading 💸
Besides the scenarios where the second tier service provider uses a single core service provider (as mentioned in Section 4.3.2), the second tier provider can also get services from more than one core service provider 🌈. In that case, the second tier service provider gets some perks like route redundancy and dynamic carrier selection based on 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 figure out how to best use the core providers 🧠. For example, if one core service provider can no longer 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 reducing exposure to failures in each provider, which means improving availability 🛡️.
4.3.4. Inter-AS and Inter-SP L1VPNs 🗺️
Besides the scenarios where a single connection between two CEs is routed over a single service provider (as mentioned in Section 4.3.2), a connection can also be routed over multiple ASes within one service provider (called inter-AS L1VPN), or over multiple service providers (called inter-SP L1VPN) 💫.
The inter-AS L1VPN scenario can build a single L1VPN out of network resources administered by different domains of one service provider 🏠. Those administrative domains might not usually have a collaborative relationship at layer 1, so the inter-AS L1VPN opens up a new business model for jointly delivering services to a customer 🤝. Considering inter-AS L1VPNs needs further analysis that's beyond the scope of this document 📚.
The inter-SP scenario can build a single L1VPN out of services provided by multiple regional providers 🌍. There could be all kinds of business relationships among providers and customers, and this scenario comes with way more manageability, security, privacy, policy, and commercial issues than the simpler inter-AS L1VPN case 😵💫. Considering inter-SP L1VPN needs further analysis beyond the scope of this document too 🫠.
4.3.5. Scheduling Service 📅
In some deployment scenarios, customers of L1VPN services may want to set up layer 1 connections not on-demand, but at a planned time in the future 🗓️. Or, even if customers want to use layer 1 connections on-demand, they might be able to tolerate some delay, for example because of a lack of resources at that moment ⏳.
In those scenarios, the provider can reserve bandwidth at a specified time in the future, and can establish the VPN connections according to a schedule 🎯. This makes it possible to use bandwidth more efficiently over time (aka support more demand) 💅. This service, the scheduling service, may be used to support customers who use layer 1 connections for data backup applications, content delivery applications, and some other applications 💾.
Furthermore, customers may be able to specify when to release layer 1 connections in advance 🔓. By considering that information, the provider may be able to engineer scheduling even further, which leads to still more efficient bandwidth usage 🚀.
Note that scheduling of L1VPN services requires time-scoped resource management, which isn't well considered in current GMPLS protocols and needs support from the management plane 🧩. Also, offering scheduling service and on-demand service on the same infrastructure needs careful consideration 🤔.
5. Reference Model 🗂️
5.1. Management Systems 🖥️
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 ModelIn 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 the 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] 🌸.
As shown in the reference model, a provider network may contain one or more management systems 🖥️. A management system may support functions including provisioning, monitoring, billing, and recording 📊. Provider management systems may also communicate with customer management systems in order to provide services 🤝. Sections 7 and 11 provide more detail 👀.
6. Generic Service Description 🎀
This section describes generic L1VPN services 🧚. Detailed descriptions are provided through 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.
Note that it's necessary to disambiguate control plane messages exchanged between CE and PE if the CE-PE relationship applies to more than one VPN 🙈. This makes it possible to determine which VPN those control plane messages apply to 🔍. Such disambiguation might be achieved by allocating a separate control channel to each VPN (either using a separate physical channel, a separate logical channel such as an IP tunnel, or using separate addressing) 🦋.
A customer addressing realm consists of CE-PE TE link addresses and CE-PE control channel addresses, as well as customer site addresses (C and CE addresses) 🏡. Customer addressing realms may overlap, and may also overlap with the service provider addressing realm 🌀.
NATs or firewalls might reasonably be placed at customer interfaces, or between administrative domains within the core network 🧱. Addressing in the L1VPN model must handle such eventualities 💪. Traversal of NATs and firewalls within the customer network might have implications for L1VPN services that connect C devices, and that is for further study 🔮.
6.2. Generic Service Features 💅
okay so L1VPN has two generic service features, and honestly they're the whole vibe 🫶
- Connectivity restriction: Layer 1 connectivity is only given to a limited set of CEs' data plane interfaces, which are called VPN end points ✨ (This set is the L1VPN membership, so it's basically the guest list 🎀)
- Per VPN control and management: the customer gets some level of control and management capability 👑 The details change depending on the service models in Section 7, so stay tuned bestie 🦋
7. Service Models 🌸
okay this section is where we get into the actual Layer 1 VPN service models that GMPLS-enabled networks can support 💖 Every one of them comes from the generic service description we just went through 🧚
These layer 1 networks get managed and controlled with GMPLS signaling as described in [RFC3471] and [RFC3473], plus 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 inside 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, and 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 system(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 system(s) may communicate by utilizing the CE-PE control channel(s) ✨
7.1. Management-Based Service Model 🎀
Figure 7.1 shows you the Management-based service model, and it's giving very "the managers do the talking" energy 💅
+--------------------+
: | |
+----------+ : | +----------+ |
| 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 ModelIn this service model, customer management systems and provider management systems talk to each other 🫶 Customer management systems go to provider management systems to ask for layer 1 connection setup/deletion between a pair of CEs 💌 They can also grab extra info, like resource availability and monitoring information, from the provider management systems 📊 And the big tea is that there is no control message exchange between a CE and PE 🙈
The provider network may be based on GMPLS 🌟 If it is, mechanisms to support soft permanent connections can be applied 🧚 Heads up though, interfaces between management systems are not within the scope of this document 🚫
7.2. Signaling-Based Service Model (Basic Mode) 🦋
In this service model, the CE-PE interface's functional repertoire is limited to path setup signaling only 💖 The provider's network is not involved in distributing the customer network's routing information, so no routing drama here 🌸
Note in addition that customer management system(s) and provider management system(s) may still communicate, so customers can get detailed monitoring, fault information, and so on 🎀
7.2.1. Overlay Service Model 🧚
Figure 7.2 shows the Overlay service model, which is very minimalist and I'm obsessed 😭
+--------------------+
: | | :
: | | :
+----+ : +----+ +----+ : +----+
| CE |---:---| PE | | PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.2: Overlay Service ModelIn 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 between a CE and a PE, so there's no routing neighbor/peering relationship going on at all 🙅 The CE does not receive routing information from remote customer sites, and it doesn't get routing information about the provider network either 🤐
The CE's interface may be assigned a public or private address, and that address 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 🗺️ Distributing membership information between PEs is typically done by the provider, and it can be realized with mechanisms like static provisioning, or by piggybacking on routing protocols (auto-discovery) ✨
There are various ways customers can perceive the provider network 👀 In one example, the whole provider network may be considered as one node, and 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 that model requires the network to be represented to the VPN sites as a virtual node 🌟 That means some form of routing advertisement is implied, and this is not in scope for the Signaling-based service model 🙅♀️
7.3. Signaling and Routing Service Model (Enhanced Mode) 👑
In this service model, the CE-PE interface provides the signaling capabilities from the Basic Mode, plus it permits limited exchange of information between the control planes of the provider and the customer 💅 This helps with things like discovering customer network routing information (reachability or TE information in remote customer sites), or parameters of the part of the provider's network dedicated to the customer 🧠
By letting CEs obtain customer network routing information, a so-called N-square routing problem could be solved 🔥
On top of that, a customer can use traffic engineering capabilities by using the received traffic engineering-based routing information 🌈 For example, a customer can set up 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, not necessarily between CEs, with more effective traffic engineering 🚀
So the customer interface is based on GMPLS signaling and mechanisms to exchange reachability/TE information 📡 Typically, a routing protocol is used between a CE and PE, or more precisely between a CE and the VPN routing context instantiated on the PE 🧩 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 this service model does not preclude the use of mechanisms other than routing protocols to exchange reachability/TE information 🦋
As with the Signaling-based service model, customer management system(s) and provider management system(s) may communicate in order to provide detailed monitoring, fault information, etc. to customers 🎀
Four specific types of the Signaling and Routing service model exist 🧚 They are the Overlay Extension service model, the Virtual Node service model, the Virtual Link service model and the Per-VPN Peer service model 🌈 Which one you get depends on how customers perceive the provider network in routing and signaling, meaning the level of information details a customer is allowed to receive in routing and signaling 💅
7.3.1. Overlay Extension Service Model ✨
This service model complements the Overlay service model 💖 In this service model, a CE receives a list of CE-PE TE link addresses that it can use to request a VPN connection (in other words, membership information) 🗂️ This list may include additional info about these TE links, like the switching type 🔌 Mechanisms other than routing could be used to exchange reachability/TE information between the CE and the PE 🫶
7.3.2. Virtual Node Service Model 🌟
Figure 7.3 shows the Virtual Node service model, and it's pure main character energy 👑
+--------------------+
: | | :
+----+ : | | : +----+
| CE |---:---| Virtual Node |---:---| CE |
+----+ : | | : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.3: Virtual Node Service ModelIn 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 (in other words, 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 🔥
7.3.3. Virtual Link Service Model 🦋
Okay bestie, the Virtual Link service model is so pretty. Figure 7.4 shows it. ✨
+--------------------+
: | | :
: | Virtual | :
+----+ : +----+ link +----+ : +----+
| CE |---:---| PE |**************| PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.4: Virtual Link Service ModelSo in this model, a virtual link gets built between PEs. If you want the official definition of a virtual link, go check the terminology in Section 2, because that's the source of truth 📚. Each VPN gets its own virtual link, and that link gets shown to the matching CEs. Basically the CE learns about its CE-PE links, the customer network (aka the remote customer sites), and the virtual links assigned to each VPN. Main character energy 👑
Here's the special part that makes it iconic. The provider network hands out data plane link resources for the exclusive use of each virtual link. Nobody else gets to borrow them 🔒 The TE attributes of a virtual link are decided by whichever data plane link resources were allocated to it. Virtual links also work as an abstraction of the provider network for customers, both for admin reasons and to leave out "unnecessary information" 🙈
Note that in this service model, both end points of each virtual link must be a PE device. No exceptions, periodt 💅
7.3.4. Per-VPN Peer Service Model 🧚
Next up is the Per-VPN Peer service model, and honestly it's a total glow-up. Figure 7.5 has the vibes:
+--------------------+
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |---:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.5: Per-VPN Peer Service ModelThis one is a generalization and a combo of the Virtual Link service model and the Virtual Node service model, which we covered in Sections 7.3.2 and 7.3.3 respectively 🎀
Here the provider splits up the TE links inside the provider network per VPN, and it tells the matching CEs about each VPN's TE link info. So a CE gets routing information about its CE-PE links, the customer network (remote customer sites), and the partitioned chunks of the provider network. ✨
Heads up that PEs are allowed to advertise abstracted routing info about the provider network to CEs. That's for admin purposes and to skip "unnecessary information," so it's not a bug 🙃 In other words, virtual links might get built between two nodes that don't have a direct data link between them, or virtual nodes might stand in for a bunch of physical nodes and the 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. That's the rule, bestie 💜
8. Service Models and Service Requirements 💖
Okay this section is where everything comes together. Section 7 is all about what information gets exchanged between the CE and PE. This section adds the other piece: how data plane resources get allocated for each VPN. Hot combo 🔥
Quick note: in the ITU-T documents they say "U-Plane" instead of "data plane." Same thing, different name, iykyk 🌸
Data plane resource allocation
- 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.)
- Shared or dedicated:
Information exchanged between CE and PE
- 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. Basically it's its own thing and doesn't change the service model definitions 💅
Table 1 shows how the service requirements and service models combine. Check out this grid 👀
| 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 modelsSo the difference between the Virtual Link and Per-VPN Peer service models comes down to whether customers can see the P devices. With Virtual Link, the end points of virtual links have to be PE devices, so P devices stay hidden from customers 🙈 With Per-VPN Peer, at least one virtual node that stands in for P devices (one single P, or a set of Ps) is visible to customers 👁️
Note that when customers get provider network routing information in the form of a virtual link, customers must be able to specify such links for a VPN connection over the provider network in signaling. They have to be able to ask for it, bestie 💖
8.1. Detailed Service Level Requirements 🎀
On top of the requirements in Table 1, there are some more detailed service requirements. They're generally common to the various service models, except where it says otherwise.
- Selection of layer 1 service class: Customers MAY be allowed to specify a layer 1 service class (e.g., availability level) for a VPN connection. Further details are described in 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. > Heads up, this one's serious 🚨
9. Recovery Aspects 🛡️
9.1. Recovery Scope 🌷
GMPLS has a bunch of recovery techniques for different recovery scenarios [RFC4427]. The provider network can use these techniques to protect VPN connections as part of the L1VPN service. For example:
- 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.
- CE-PE recovery
- The recovery scope is either or both of the ingress and egress CE-PE links of the CE-CE VPN connection.
- 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 🚀
9.2. Recovery Resource Sharing Schemes ✨
Okay bestie, the provider network can support a few different recovery resource sharing schemes 💅:
- Shared recovery
If the provider network supports shared recovery (e.g., shared mesh restoration [RFC4427]), it may share 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.
- Extra traffic
GMPLS recovery mechanisms support extra traffic 🔥. Extra traffic lets preemptable traffic ride on recovery resources whenever those resources aren't being used to recover protected normal traffic [RFC4427].
In the L1VPN world, extra traffic applies to CE-CE VPN connections, or to the PE-PE part of a CE-CE VPN connection. That PE-PE case only applies when there's hierarchy, meaning the CE-CE connection is nested on top of a PE-PE connection. We're going to look at that second case here 👀.
When the provider network lets a CE-CE VPN connection be set up as "extra traffic," it means that connection can use a PE-PE connection that protects some other CE-CE VPN connection. The provider network may restrict an extra traffic CE-CE VPN connection to 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. 🌈
10. Control Plane Connectivity 🎀
10.1. Control Plane Connectivity between a CE and a PE
In the Signaling-based service model and the Signaling and Routing service model, there must be a control channel (IP-level connectivity) between a CE and its PE 📡. How that control channel gets set up can vary depending on addressing and security.
As stated in Section 6.1, we need to disambiguate control plane messages exchanged between the CE and PE if the CE-PE relationship applies to more than one VPN 🧩. Also, private addresses may be assigned to CE-PE control channels.
Security aspects of the CE-PE control channel are discussed in Section 12 🔐.
10.2. Control Plane Connectivity between CEs
A customer network connected by VPN connections may be controlled by MPLS or GMPLS, and the VPN connections may be treated as TE links within that customer network 🕸️. In those cases, there must be control plane (IP-level) connectivity between the CEs, so control messages like signaling and routing messages can be exchanged between them. Also, some recovery techniques need Notify message exchange between the ingress and egress of the VPN connection, which means the CEs need control plane connectivity too 😭. There are several ways to get there.
- Use of VPN connections as in-band control channels
If the CEs can inject control messages into the VPN connections and pull them back out at the far end, then control messages can travel in-band 🫧. For example, when a VPN connection is a Packet Switch Capable (PSC) TE link in the customer network, this is totally transparent to the L1VPN service provider.
- Use of overhead associated with the VPN connections
If the VPN connection gives the customer network connectivity at a different switching capability (which implies a different network technology layer) from what the provider network uses for the CE-PE and PE-PE connectivity, then the customer network can use any overhead available within the VPN connection as a control channel to connect the CEs 🧃. For example, if a VPN connection provides a TDM TE link in the customer network but is supported by a technology such as lambda or fiber, then the CEs may use the overhead (DCC) as a control channel, as long as the network supports transparent transfer of that overhead. This is transparent to the L1VPN service provider too.
- Use of control-channel-specific VPN connections
The customer sets up VPN connections dedicated to being control channels 🎧. This is transparent to the L1VPN service provider. But control plane traffic is usually pretty light compared to the capacity of VPN connections, so this can be an expensive solution for the customer 💸.
- Use of separate network
A customer may use another network and network service, such as private line service, L3VPN service, L2VPN service, or Internet access service, to set up CE-CE control channel connectivity 🌐. This is transparent to the L1VPN service provider.
- 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 🔁.
Using that, CE-CE control message exchange could be realized as part of the service the L1VPN service provider offers. Basically, the provider network takes control messages received over the CE-PE control channel, carries them to the other side of the provider network, and delivers them through the PE-CE control channel 🚚. How that works inside 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) attacks 🚨. Traffic saturation over the control plane network also needs to be carefully managed. And 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.
11. Manageability Considerations 🛠️
Manageability considerations for GMPLS are described in existing documents, such as [RFC3945]. Manageability considerations for L3VPN are also described in existing documents, such as [RFC4176]. These manageability considerations should also be applied in L1VPNs, and this section describes those aspects. There are also some L1VPN-specific manageability considerations, such as configuration and accounting 📋.
- 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. It also 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 🤝.
- 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 ✅.
- Accounting management
The provider network MUST support accounting management. It MUST be able to record usage of VPN connections for each customer 🧾.
- 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 that aren't directly associated with the SLA, such as network resource utilization 🔍.
- Security management
The provider network MUST support security management. See Section 12 for details 🛡️.
- Management systems
To support its various management functions, 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 those functions.
In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported 📚.
- Management of customer networks
Customers MAY outsource management of their network (especially CEs and CE-CE links) to the provider network 🧑💻. In that case, the provider MUST be able to manage the customer network, as well as the provider network.
12. Security Considerations 🔐
Security is clearly one of the essential requirements in L1VPNs 💜. This section highlights the key security requirements. Security considerations for L3VPNs and L2VPNs are described in existing documents, such as [RFC4110], [RFC4111], and [RFC4664]. These security considerations should also be applied in L1VPNs, and this section describes those aspects. There are also some L1VPN-specific security considerations, such as connectivity restriction and shared control links 😤.
This section first describes the types of information that need to be secured. Then it describes security features or aspects. Finally, it covers some considerations about scenarios where security mechanisms are applied 🎬.
12.1. Types of Information
It MUST be possible to secure the information exchanged between the customer and the provider 🔒. This includes data plane information, control plane information, and management plane information.
At layer 1, data plane information is normally assumed to be secured once connections are established, since those connections are dedicated to each VPN 🧷. That is, it's not possible to communicate unless there's a connection. So in L1VPNs, the main concern for data plane security is restricting VPN connections to be used only within the same VPN, as described in Section 6.2 🚧. Note that a customer may want to protect data plane information not only from other customers, but also from the provider 👀. In that case, the customer may apply their own security mechanisms for data plane information (CE-CE security), as described later.
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 that these types of information MAY be accessible to authorized entities 🗝️.
12.2. Security Features ✨
okay bestie, this is the part where the spec lists the security features it wants. no cap, these are the non-negotiables 🔒💅
- Data integrity 🎀 The information exchanged between the customer and the provider MUST be delivered unchanged.
- Confidentiality 🫶 The information exchanged between the customer and the provider MUST NOT be disclosed to a third party.
- Authentication 🪪 The entity requesting the service to the provider MUST be identified and have its identity authenticated, and the provider providing the service MUST also be identified and have its identify authenticated.
- 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. main character energy for who gets in 👑
- DoS attack detection and protection 🛡️ The provider network MUST have mechanisms to detect DoS attack and to protect against it reactively and proactively. we are not letting the flood through, periodt 🌊💀
12.3. Scenarios 🎬
okay so there are two scenarios (or occasions) where the security mechanisms get applied 🦋 One is the service contract phase, where they're applied once. The other is the service access phase, where they're applied every single time the service gets requested. iykyk 🧚
- Service contract scenario (static) 📜 This one covers adding new physical devices, like CE devices, data links and control links. It MUST be guaranteed that these physical devices are connected to the right entity. Also, authority to access specific information MAY be given to each customer as a part of the service contract. the paperwork is giving clean 🍓
- Service access scenario (dynamic) 🔁 This one covers receiving connection requests, routing information exchange requests (e.g., attempts to establish a neighbor relationship in routing protocols, or command request via the management plane interface), and management information retrieval requests. Here's the tea: if a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, and the entity connected over that channel was identified in the service contract phase, the provider can ensure who is requesting the service. The channel could also be considered secure. BUT when the communication channel is physically shared among customers, security mechanisms MUST be available and SHOULD be enforced. Examples of such security mechanisms include IPsec [RFC4302] and [RFC4303]. Note that even with physically separate channels, customers may wish to apply security mechanisms for 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 the connection request is between VPN end points belonging to the same VPN. the gatekeeping is serious 🔐
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. 🫧
13. Acknowledgements 🙏
the material in this document is based on the work of the ITU-T Study Group 13 💖
we'd like to thank Dimitri Papadimitriou, Deborah Brungard, Yakov Rekhter, Alex Zinin, Igor Bryskin, Adrian Farrel, and Ross Callon for their useful comments and suggestions 🌸
thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for helpful input during IESG review 🫶
14. Contributors 👩💻
the foundation of this document is based heavily on the work of ITU-T Study Group 13, Question 11. SG13/Q11 has been looking into the service requirements and architecture for Layer 1 VPNs for a while, and this document is basically a summary and development of the conclusions they reached. Building on that material, the IETF (and the L1VPN WG in particular) developed this framework and these requirements for supporting L1VPNs using GMPLS protocols. literal teamwork moment 🤝✨
the details of this document came from contributions by several authors, 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)15. Normative References 📚
these are the references the spec leans on, so read them like they're the group chat pinned messages 📌
[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>.16. Informative References 💭
these ones are just for extra context, bestie, not required reading 🧃
[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.Authors' Addresses 📮
Raymond Aubin
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Canada
Phone: +1 (613) 763 2208
EMail: aubin@nortel.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@nortel.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@nortel.com
Tomonori Takeda, Editor
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.jpFull Copyright Statement ©️
Copyright (C) The IETF Trust (2007). 🌈
this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💜
this document and the information in it 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. no warranties, bestie, just vibes 🫠
Intellectual Property 🧠
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under those rights might or might not be available, and it doesn't claim to have independently checked for such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79 📖
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF's online 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 required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 💌
funding for the RFC Editor function is currently provided by the Internet Society. 🫶🌸
📦 where this page comes from
- ietf: rfc4847 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms