RFC 4031
Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
RFC 4031 💖 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
okay bestie, this is the title block tea ☕✨ It's from the Network Working Group and it's RFC 4031. The title is "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)" 🎀
- Authors: M. Carugi, Ed. from Nortel Networks, and D. McDysan, Ed. from MCI 👑
- Category: Informational 🦋
- Date: April 2005 🌸
- Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🙈
Status of This Memo 📝
this memo is here to give info to the Internet community 🌈 it does NOT specify an Internet standard of any kind, so it's not a standard, babe 💅 and distribution of this memo is unlimited 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2005). 🌸
Abstract 🔥
this doc is all about requirements for Layer 3 Virtual Private Networks (L3VPNs) 🫶 it lays out what applies to a bunch of different ways a Service Provider may use to provision a Virtual Private Network (VPN) service 🎀
it's written from the service provider point of view, based on past experience with IP-based service offerings and the ever-evolving needs of their customers 💅 it starts by defining terminology and stating the general requirements, then gets into the detailed requirements from both the customer side and the service provider side ✨
Table of Contents 🗂️
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document. . . . . . . . . . . . . . . . . 4
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Contributing Authors. . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Virtual Private Network . . . . . . . . . . . . . . . . 6
3.2. Users, Sites, Customers, and Agents . . . . . . . . . . 6
3.3. Intranets, Extranets, and VPNs. . . . . . . . . . . . . 6
3.4. Networks of Customer and Provider Devices . . . . . . . 7
3.5. Access Networks, Tunnels, and Hierarchical Tunnels. . . 7
3.6. Use of Tunnels and Roles of CE and PE in L3VPNs . . . . 8
3.6.1. PE-Based L3VPNs and Virtual Forwarding
Instances . . . . . . . . . . . . . . . . . . . 8
3.6.2. CE-Based L3VPN Tunnel Endpoints and Functions . 10
3.7. Customer and Provider Network Management. . . . . . . . 10
4. Service Requirements Common to Customers and Service
Providers . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Isolated Exchange of Data and Routing Information . . . 11
4.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Quality of Service. . . . . . . . . . . . . . . . . . . 12
4.3.1. QoS Standards . . . . . . . . . . . . . . . . . 12
4.3.2. Service Models. . . . . . . . . . . . . . . . . 13
4.4. Service Level Specification and Agreements. . . . . . . 14
4.5. Management. . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Interworking. . . . . . . . . . . . . . . . . . . . . . 15
5. Customer Requirements . . . . . . . . . . . . . . . . . . . . 15
5.1. VPN Membership (Intranet/Extranet). . . . . . . . . . . 15
5.2. Service Provider Independence . . . . . . . . . . . . . 16
5.3. Addressing. . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Routing Protocol Support. . . . . . . . . . . . . . . . 16
5.5. Quality of Service and Traffic Parameters . . . . . . . 16
5.5.1. Application Level QoS Objectives. . . . . . . . 17
5.5.2. DSCP Transparency . . . . . . . . . . . . . . . 17
5.6. Service Level Specification/Agreement . . . . . . . . . 18
5.7. Customer Management of a VPN. . . . . . . . . . . . . . 18
5.8. Isolation . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 19
5.10. Migration Impact. . . . . . . . . . . . . . . . . . . . 19
5.11. Network Access. . . . . . . . . . . . . . . . . . . . . 19
5.11.1. Physical/Link Layer Technology. . . . . . . . . 20
5.11.2. Temporary Access. . . . . . . . . . . . . . . . 20
5.11.3. Sharing of the Access Network . . . . . . . . . 20
5.11.4. Access Connectivity . . . . . . . . . . . . . . 20
5.12. Service Access. . . . . . . . . . . . . . . . . . . . . 23
5.12.1. Internet Access . . . . . . . . . . . . . . . . 23
5.12.2. Hosting, Application Service Provider . . . . . 24
5.12.3. Other Services. . . . . . . . . . . . . . . . . 24
5.13. Hybrid VPN Service Scenarios. . . . . . . . . . . . . . 24
6. Service Provider Network Requirements . . . . . . . . . . . . 24
6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Discovering VPN Related Information . . . . . . . . . . 26
6.5. SLA and SLS Support . . . . . . . . . . . . . . . . . . 26
6.6. Quality of Service (QoS) and Traffic Engineering. . . . 27
6.7. Routing . . . . . . . . . . . . . . . . . . . . . . . . 27
6.8. Isolation of Traffic and Routing. . . . . . . . . . . . 28
6.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 28
6.9.1. Support for Securing Customer Flows . . . . . . 28
6.9.2. Authentication Services . . . . . . . . . . . . 29
6.9.3. Resource Protection . . . . . . . . . . . . . . 30
6.10. Inter-AS (SP)VPNs . . . . . . . . . . . . . . . . . . . 30
6.10.1. Routing Protocols . . . . . . . . . . . . . . . 31
6.10.2. Management. . . . . . . . . . . . . . . . . . . 31
6.10.3. Bandwidth and QoS Brokering . . . . . . . . . . 31
6.10.4. Security Considerations . . . . . . . . . . . . 32
6.11. L3VPN Wholesale . . . . . . . . . . . . . . . . . . . . 32
6.12. Tunneling Requirements. . . . . . . . . . . . . . . . . 33
6.13. Support for Access and Backbone Technologies. . . . . . 33
6.13.1. Dedicated Access Networks . . . . . . . . . . . 34
6.13.2. On-Demand Access Networks . . . . . . . . . . . 34
6.13.3. Backbone Networks . . . . . . . . . . . . . . . 35
6.14. Protection, Restoration . . . . . . . . . . . . . . . . 35
6.15. Interoperability. . . . . . . . . . . . . . . . . . . . 35
6.16. Migration Support . . . . . . . . . . . . . . . . . . . 36
7. Service Provider Management Requirements. . . . . . . . . . . 36
7.1. Fault Management. . . . . . . . . . . . . . . . . . . . 37
7.2. Configuration Management. . . . . . . . . . . . . . . . 37
7.2.1. Configuration Management for PE-Based VPNs. . . 38
7.2.2. Configuration Management for CE-Based VPNs. . . 39
7.2.3. Provisioning Routing. . . . . . . . . . . . . . 39
7.2.4. Provisioning Network Access . . . . . . . . . . 39
7.2.5. Provisioning Security Services. . . . . . . . . 40
7.2.6. Provisioning VPN Resource Parameters. . . . . . 40
7.2.7. Provisioning Value-Added Service Access . . . . 40
7.2.8. Provisioning Hybrid VPN Services. . . . . . . . 41
7.3. Accounting. . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Performance Management. . . . . . . . . . . . . . . . . 42
7.4.1. Performance Monitoring. . . . . . . . . . . . . 42
7.4.2. SLA and QoS Management Features . . . . . . . . 42
7.5. Security Management . . . . . . . . . . . . . . . . . . 43
7.5.1. Resource Access Control . . . . . . . . . . . . 43
7.5.2. Authentication. . . . . . . . . . . . . . . . . 43
7.6. Network Management Techniques . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References. . . . . . . . . . . . . . . . . . 45
10.2. Informative References. . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 501. Introduction 🦋
okay so this section is the scope and outline of the whole doc 🌸
so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read the way RFC 2119 ([RFC2119]) describes 📖✨
1.1. Scope of This Document 🎀
okay so this section is all about what this doc actually covers, bestie 💖 It's about requirements specific to Layer 3 Virtual Private Networks (L3VPN) 🦋. The stuff that's generic to both L2 and L3 VPNs lives over in [RFC3809] 🫶.
This doc points out requirements that may apply to one or more individual approaches a Service Provider might use to provision a Layer 3 (e.g., IP) VPN service ✨. It borrows the terminology and common components for Layer 3 VPNs from [L3VPN-FR], plus the generic VPN terminology from [PPVPN-TERM] 💅.
Specifying the technical means to provide L3VPN services is outside the scope here 🙈. Other docs cover that, like the L3 VPN framework document [L3VPN-FR] and several sets of documents, one for each technical approach for providing L3VPN services 🌸.
The technical approaches targeted by this doc include the network-based (PE-based) L3VPN category (aggregated routing VPNs [2547bis] and virtual routers [PPVPN-VR]) and the CE-based L3VPNs category [CE-PPVPN][IPSEC-PPVPN] 👑. The doc tells the L3VPN categories apart by where the endpoints of tunnels exist, as detailed in the L3VPN framework document [L3VPN-FR] 🧚. Terminology that describes whether equipment faces a customer or the service provider network is used to define the various types of L3VPN solutions 💜.
This doc is meant to be a "checklist" of requirements 📝. It gives a consistent way to evaluate and document how well each approach satisfies specific requirements ✨. The applicability statement docs for each approach should present the results of that evaluation. This doc is not intended to compare one approach to another, so no ranking drama here 💀.
This doc looks at requirements from several points of view 🌈. It starts with considerations common to customers and service providers that aren't covered in the generic provider provisioned VPN requirement doc [RFC3809], then moves on to a customer perspective, and wraps up with the specific needs of a Service Provider (SP) 💖.
The following L3VPN deployment scenarios are considered in this doc:
- Internet-wide: VPN sites attached to arbitrary points in the Internet.
- Single SP/single AS: VPN sites attached to the network of a single provider within the scope of a single AS.
- Single SP/multiple ASes: VPN sites attached to the network of a single provider consisting of multiple ASes.
- Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide the VPN service.
The above deployment scenarios have a lot of requirements in common 🍓. These include SP requirements for security, privacy, manageability, interoperability, and scalability, including service provider projections for the number, complexity, and rate of change of customer VPNs over the next several years 📈. When a requirement applies to a specific deployment scenario, the terminology above is used to state the context of that requirement 🔥.
1.2. Outline 🗺️
okay here's the roadmap for the rest of the doc, bestie 🧭. Section 2 lists the contributing authors 🌷. Section 3 gives definitions of terms and concepts 📚. Section 4 covers requirements common to both customers and service providers that aren't covered in the generic provider provisioned VPN requirement doc [RFC3809] 🫶. Section 5 states requirements from a customer perspective 👛. Section 6 states network requirements from a service provider perspective 🛰️. Section 7 states service provider management requirements 🛠️. Section 8 describes security considerations 🔐. Section 9 lists acknowledgments 💌. Section 10 provides a list of references cited herein 📖. Section 11 lists the authors' addresses 📬.
2. Contributing Authors 🌷
this doc is the combined effort of the two co-editors and the following contributing authors 💜:
- Luyuan Fang
- Ananth Nagarajan
- Junichi Sumimoto
- Rick Wilder
3. Definitions 📚
this section gives the definitions of the terms and concepts used all through the doc 🧠. The terminology is taken from [PPVPN-TERM] and [L3VPN-FR] ✨.
3.1. Virtual Private Network 🦋
"L3 Virtual Private Network" (L3VPN) refers to the L3 communication between a set of sites making use of a shared network infrastructure 💖.
"Provider Provisioned VPN" (PPVPN) refers to VPNs for which the service provider participates in the management and provisioning of the VPN 👑.
3.2. Users, Sites, Customers, and Agents 👯
User: A user is an entity (e.g., a human being using a host, a server, or a system) authorized to use a VPN service 🙋.
Site: A site is a set of users that have mutual L3 (i.e., IP) reachability without use of a specific service provider network 🌸. A site may consist of a set of users that are in geographic proximity. Note that a topological definition of a site (e.g., all users at a specific geographic location) may not always conform to this definition 🙈. For example, two geographic locations connected via another provider's network would also constitute a single site, as communication between the two locations does not involve the use of the service provider offering the L3 VPN service 🧩.
Customer: A single organization, corporation, or enterprise that administratively controls a set of sites 🏢.
Agent: A set of users designated by a customer who has the authorization to manage a customer's VPN service offering 🎟️.
3.3. Intranets, Extranets, and VPNs 🌈
Intranet: An intranet restricts communication to a set of sites that belong to one customer 🏠. An example is branch offices at different sites that need to talk to a headquarters site 🏬.
Extranet: An extranet allows the specification of communication between a set of sites that belong to different customers 🤝. In other words, two or more organizations have access to a specified set of each other's sites 👀. Examples of extranets include multiple companies cooperating in joint software development, a service provider having access to information from the vendors' corporate sites, different companies, or universities participating in a consortium 🎓. An extranet often has further restrictions on reachability, for example, at a host and individual transport level 🔒.
Note that an intranet or extranet can exist across a single service provider network with one or more ASes, or across multiple service provider networks 🌐.
L3 Virtual Private Network (L3VPN): An alternative definition of VPN refers to a specific set of sites that have been configured to allow communication as either an intranet or an extranet 💜. Note that a site is a member of at least one VPN and may be a member of many VPNs 🫶.
3.4. Networks of Customer and Provider Devices 🔌
L3VPNs are composed of the following types of devices 🧱.
Customer Edge (CE) device: A CE device faces the users at a customer site 🙋♀️. The CE has an access connection to a PE device. It may be a router or a switch that allows users at a customer site to communicate over the access network with other sites in the VPN 📡. In a CE-based L3VPN, as intended in this document (provider-provisioned CE-based VPN), the service provider manages (at least partially) the CE device 🛠️.
Provider Edge (PE) device: A PE device faces the provider network on one side and attaches via an access connection over one or more access networks to one or more CE devices 🌉. It participates in the Packet Switched Network (PSN) in performing routing and forwarding functions 🧭.
Note that the definitions of Customer Edge and Provider Edge do not necessarily describe the physical deployment of equipment on customer premises or a provider point of presence 🏗️.
Provider (P) device: A device within a provider network that interconnects PE (or other P) devices but does not have any direct attachment to CE devices 🛤️. The P router does not keep VPN state and is VPN unaware [PPVPN-TERM] 🙈.
Packet Switched Network (PSN): A (IP or MPLS [RFC3031]) network through which the tunnels supporting the VPN services are set up [PPVPN-TERM] 🧵.
Service Provider (SP) network: An SP network is a set of interconnected PE and P devices administered by a single service provider in one or more ASes 🏛️.
3.5. Access Networks, Tunnels, and Hierarchical Tunnels 🚇
VPNs are built between CEs by using access networks, tunnels, and hierarchical tunnels across a PSN 🧁.
Access connection: An access connection provides connectivity between a CE and a PE 🔗. This includes dedicated physical circuits, virtual circuits (such as Frame Relay), ATM, Ethernet (V)LAN, or IP tunnels (e.g., IPsec, L2TP [RFC2661]) 💫.
Access network: An access network provides access connections between CE and PE devices 🛣️. It may be a TDM network, an L2 network (e.g., FR, ATM, and Ethernet), or an IP network over which access is tunneled (e.g., by using L2TP) 🌀.
Tunnel: A tunnel between two entities is formed by encapsulating packets within another encapsulating header for the purposes of transmission between those two entities in support of a VPN application 🎁. Examples of protocols commonly used for tunneling are GRE, IPsec, IP-in-IP tunnels, and MPLS 🦄.
Hierarchical Tunnel: Encapsulating one tunnel within another forms a hierarchical tunnel 🪆. The innermost tunnel protocol header defines a logical association between two entities (e.g., between CEs or PEs) [VPNTUNNEL] 🤯. Note that the tunneling protocols need not be the same at different levels in a hierarchical tunnel 🌈.
3.6. Use of Tunnels and Roles of CE and PE in L3 VPNs 🎀
This section summarizes the points where tunnels terminate and the functions implemented in the CE and PE devices that differentiate the two major categories of L3VPNs for which requirements are stated, namely PE-based and CE-based L3VPNs 💅. See the L3VPN framework document for more detail [L3VPN-FR] ✨.
3.6.1. PE-Based L3VPNs and Virtual Forwarding Instances ✨
okay so in a PE-based L3VPN service, a customer site gets IP layer (aka layer 3) service from the SP 💅. The PE is hooked up to one or more CEs through an access connection 🔌. The PE forwards user data packets based on info in the IP layer header, like an IPv4 or IPv6 destination address 🎀. And from the CE's point of view, the PE just looks like a layer 3 device, like an IPv4 or IPv6 router 🦋.
Virtual Forwarding Instance (VFI): In a PE-based L3VPN service, the PE has a VFI for each L3 VPN it serves 💜. The VFI terminates tunnels that connect to other VFIs, and it also terminates access connections for the CEs. It holds the info on how to forward data that comes in over the CE-PE access connection to the VFIs in other PEs that support the same L3VPN 🗺️. The VFI includes the router information base and the forwarding information base for an L3VPN [L3VPN-FR]. A VFI enables router functions that are dedicated to one particular VPN, like separating forwarding from routing and supporting overlapping address spaces 👑. The routing protocols in the PEs and the CEs work together to fill up the VFI 🧩.
The next bit explains how PEs use tunnels and hierarchical tunnels, and the figures show it best 😭. Figure 1.1 shows a PE using a separate tunnel for each VPN. Like the figure shows, the tunnels let the VFIs on each PE device talk to each other 🌸.
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |==================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
|CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |==================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.1. PE Usage of Separate Tunnels to Support VPNsFigure 1.2 shows a different vibe: one single hierarchical tunnel between the PE devices carries traffic for the VPNs 🎀. The innermost encapsulating protocol header is what lets the PE work out which VPN a packet is meant for 🕵️♀️.
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==============< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.2. PE Usage of Shared Hierarchical Tunnels to Support VPNs3.6.2. CE-Based L3VPN Tunnel Endpoints and Functions 🔐
Figure 1.3 is the CE-based L3VPN reference model 📐. Here, typically a single level of tunnel (e.g., IPsec) ends at pairs of CEs 🤝. Usually a CE serves one customer site, so its forwarding and routing are physically separate from every other customer's 🏠. The PE doesn't know which specific CE devices belong to which VPN 🙈. So the VPN functions get set up through provisioned configs on the CE devices, and the shared PE and P network only gives the routing and forwarding that supports the tunnel endpoints between CE devices 🛤️. The tunnel topology connecting the CE devices may be a full or partial mesh, depending on what the VPN customer needs and what their traffic looks like 🕸️.
+---------+ +--------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ Tunnel |router| |device| : | of |
| of |=:================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | Tunnel +------+ : +------+
|device|=:================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +----------+ +----------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | |management| |management| | | : |
|interface| | | function | | function | | |Customer |
| | | +----------+ +----------+ | |interface|
| | | | | |
+---------+ +--------------------------------+ +---------+
| Access | |<-------- SP network(s) ------->| | Access |
| network | | | | network |
Figure 1.3. CE-Based L3VPN3.7. Customer and Provider Network Management 🛠️
Customer Network Management Function: A customer network management function gives a customer agent a way to query or configure customer-specific info, or to get alarms about their VPN 📣. That customer-specific info covers things like contact, billing, site, access network, IP address, and routing protocol parameters 📋. It can use a mix of a proprietary network management system, an SNMP manager, or a directory service (e.g., LDAP [RFC3377] [RFC2251]) 🗂️.
Provider Network Management Function: A provider network management function offers a lot of the same abilities as a customer network management system, but across all customers 🌐. It does NOT include customer confidential info like keying material 🔑. The point of giving the provider a view that matches the customer's is to help with troubleshooting and problem resolution 🧯. This kind of system also lets the provider query, configure, or get alarms about any infrastructure that supports the L3VPN service 🏗️. It can use a mix of a proprietary network management system, an SNMP manager, or a directory service (e.g., LDAP [RFC3377] [RFC2251]) 💜.
4. Service Requirements Common to Customers and Service Providers 💖
Lots of the requirements that apply to both the customer and the provider are general in nature, or apply to both L2 and L3VPNs. Those are described in [RFC3809] 📚. This section has the requirements that aren't covered in [RFC3809] and are specific to L3VPNs 👑.
4.1. Isolated Exchange of Data and Routing Information 🔒
A mechanism must be provided for isolating the distribution of reachability information to only those sites associated with a VPN 🚧.
L3VPN solutions shall define means that prevent routers in a VPN from interacting with unauthorized entities, and that avoid introducing undesired routing information that could corrupt the VPN routing information base [VPN-CRIT] 🙅♀️.
A means must be provided to constrain or isolate the distribution of addressed data to only those VPN sites determined by either routing data and/or configuration 🎯.
A single site shall be capable of being in multiple VPNs. The VPN solution must ensure that traffic is exchanged only with sites in the same VPN 🫶.
The internal structure of a VPN should not be advertised or discoverable from outside that VPN 🤫.
Note that isolation of forwarded data or exchange of reachability information to only those sites that are part of a VPN may be viewed as a form of security - for example, [Y.1311.1], [MPLSSEC] 🛡️.
4.2. Addressing 🏷️
IP addresses must be unique within the set of sites reachable from the VPNs of which a particular site is a member 🔢.
A VPN solution must support IPv4 and IPv6 as both the encapsulating and encapsulated protocol 🌈.
If a customer has private or non-unique IP addresses, then a VPN service SHOULD be capable of translating such customer private or non-unique IP addresses for communicating with IP systems having public addresses 🔁.
4.3. Quality of Service ⭐
To the extent possible, L3VPN QoS should be independent of the access network technology 🦋.
4.3.1. QoS Standards ✨
okay bestie, first things first: the L3VPN WG's charter says it is NOT making new protocols or extending existing ones 🙅♀️ so everything here has to be built from stuff that already exists. An L3VPN shall be able to support QoS in one or more of these already-defined modes:
- Best Effort (mandatory support for all L3VPN types)
- Aggregate CE Interface Level QoS ("hose" level QoS)
- Site-to-site ("pipe" level QoS)
- Intserv (i.e., RSVP) signaled
- Diffserv marked
- Across packet-switched access networks
Also, any QoS case may need the CE and/or PE to do shaping and/or policing 🫶
L3VPN CEs should be capable of supporting integrated services (Intserv) for certain customers, especially for session stuff like switched voice or video 📞 Intserv-capable CE devices shall support these Internet standards:
- Resource reSerVation Protocol (RSVP) [RFC2205]
- Guaranteed Quality of Service providing a strict delay bound [RFC2212]
- Controlled Load Service providing performance equivalent to that of an unloaded network [RFC2211]
Then there's Diffserv 🌈 L3VPN CE and PE should be capable of supporting differentiated service (Diffserv). Diffserv-capable L3VPN CE and PE shall support these per hop behavior (PHB) [RFC2475] types:
- Expedited Forwarding (EF) - The departure rate of an aggregate class of traffic from a device that must equal or exceed a configured rate [RFC3246].
- Assured Forwarding (AF) - A means for a provider Diffserv (DS) domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain. Four AF classes are defined, where each AF class implies allocation in each DS node of a certain amount of forwarding resources (e.g., buffer space and bandwidth) [RFC2597].
A CE or PE that supports an L3VPN service may classify a packet for a particular Intserv or Diffserv service based on one or more of these IP header fields: protocol ID, source port number, destination port number, destination address, or source address 🎀
And for a specifiable set of Internet traffic, L3VPN devices should support Random Early Detection (RED) so things degrade gracefully when the network gets congested 🌸
4.3.2. Service Models 💅
A service provider must be able to offer QoS to a customer for at least these generic service types: managed-access VPN service or edge-to-edge QoS VPN service [RFC3809]. Here's the L3VPN-specific detail 👀
Managed-access L3VPN service gives QoS on the access connection between the CE and the PE. For example, diffserv would only be turned on at the CE router and the customer-facing ports of the PE router. Lowkey the big win is that this doesn't need Diffserv in the SP backbone at all 🦋 The SP may use policing for inbound traffic at the PE, and the CE may do shaping for outbound traffic. Another managed-access example is when the SP does the packet classification and diffserv marking itself. An SP may offer several packet classification profiles that customers can pick from, or make custom profiles for specific customer needs. In general, more complex QoS policies should be left to the customer to implement 💖
An edge-to-edge QoS VPN service gives QoS from edge device to edge device. The edge device can be either a PE or a CE, depending on where the demarcation point between provider and customer is. This can run across one or more provider backbones 🧚
The CE requirements for this model are the same as for managed-access VPN service. The difference is that here QoS is delivered from one edge of the SP network(s) to the other edge 🫶
4.4. Service-Level Specification and Agreements 📜
There's a general discussion of SLAs in [RFC3809]. On top of that, SLS measurements for quality based on the DiffServ scheme SHOULD be based on the following classification:
- A Point-to-Point SLS [Y.1311.1], sometimes also called the "Pipe" model, defines traffic parameters along with the QoS objectives for traffic exchanged between a pair of VPN sites (i.e., points). A Point-to-Point SLS is analogous to the SLS typically supported over point-to-point Frame Relay or ATM PVCs or an edge-to-edge MPLS tunnel. The set of SLS specifications to all other reachable VPN sites would define the overall Point-to-Point SLS for a specific site.
- A Point-to-Cloud SLS [Y.1311.1], sometimes also called the "Hose" model, defines traffic parameters along with the QoS objectives for traffic exchanged between a CE and a PE for traffic going to a set (either all or a subset) of other sites in the VPN (i.e., the cloud), as applicable. Put another way, a point-to-cloud SLS measures compliance across all packets sent from a given VPN site toward the SP network as one aggregate (i.e., regardless of which VPN site each packet is headed to).
- A Cloud-to-Point SLS (a case not covered by this SLS is where flows from multiple sources may congest the interface toward a specific site).
Traffic parameters and actions SHOULD be defined for packets going to and from the demarcation between the service provider and the site. For example, policing may be defined on ingress and shaping on egress 🍓
4.5. Management 🛠️
An SP and its customers MUST be able to manage the capabilities and characteristics of their VPN services. Where possible, automated operations and interoperability with standard management platforms SHOULD be supported 🤖
The ITU-T Telecommunications Management Network (TMN) model has this generic requirements structure:
- Engineer, deploy, and manage the switching, routing, and transmission resources supporting the service, from a network perspective (network element management).
- Manage the VPN networks deployed over these resources (network management).
- Manage the VPN service (service management).
- Manage the VPN business, mainly provisioning administrative and accounting information related to the VPN service customers (business management).
Service management should include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Provisioning, and Security, as detailed in section 7 💜
4.6. Interworking 🤝
Interworking among the different solutions that provide L3VPN services is highly desirable. See the L3VPN framework document for more details on interworking scenarios [L3VPN-FR]. Interworking SHOULD be supported in a scalable manner ✨
Interworking scenarios MUST at least consider traffic and routing isolation, security, QoS, access, and management aspects. This is essential for network migration, so that service stays continuous between sites that belong to different parts of the network 🚀
5. Customer Requirements 👑
This section covers extra requirements from the customer's point of view 💅
5.1. VPN Membership (Intranet/Extranet) 🎀
When an extranet is formed, a customer agent from each organization first approves adding a site to an extranet VPN. It's a business decision between the parties involved. The solution SHOULD give these organizations a way to control extranet communication involving the L3VPN exchange of traffic and routing information 🔒
5.2. Service Provider Independence 🦋
Customers MAY require VPN service that spans multiple administrative domains or service provider networks. Therefore, a VPN service MUST be able to span multiple AS and SP networks, but still act and appear as a single, homogeneous VPN from the customer's point of view 🌈
A customer might also start with a VPN in a single AS with a certain SLA, then ask to expand the service across multiple ASes/SPs. In this case, as well as for all kinds of multi-AS/SP VPNs, VPN service SHOULD be able to deliver the same SLA to all sites in a VPN, no matter which AS/SP the site homes to 🧚
5.3. Addressing 🏠
A customer needs an L3VPN to support these IP address assignment schemes:
- Customer-assigned, non-unique, or [RFC1918] private addresses
- Globally unique addresses obtained by the customer
- Globally unique addresses statically assigned by the L3VPN service provider
- On-demand, dynamically assigned IP addresses (e.g., DHCP), whether the access is temporary (e.g., remote) or permanent (e.g., dedicated)
When an L3VPN service combines non-unique or private addresses with Internet access, mechanisms that let traffic move between the customer's address space and the globally unique Internet address space MAY be supported. NAT is a good example, since many customers and some service providers use it today for this 🙈 A preferred solution would be to assign unique addresses, either IPv4 or IPv6. However, some customers don't want to renumber their networks, so 🥺
5.4. Routing Protocol Support 🛣️
There SHOULD be no restriction on the routing protocols used between CE and PE routers, or between CE routers. At least these protocols MUST be supported: static routing, and IGP protocols such as RIP, OSPF, IS-IS, and BGP [L3VPN-FR] 💖
5.5. Quality of Service and Traffic Parameters 💎
QoS is expected to be a big deal for some customers in an L3VPN service. QoS requirements cover scenarios involving an intranet, an extranet, and shared access between a VPN site and the Internet 🌸
5.5.1. Application-Level QoS Objectives 🎯
A customer mainly cares that the L3VPN service gives their applications the QoS and level of traffic they need so the applications perform acceptably. Voice, interactive video, and multimedia apps are expected to need the strictest QoS. These real-time apps are sensitive to delay, delay variation, loss, availability, and/or reliability 😭 Another group, including some multimedia and interactive video apps, high-performance web browsing, and file-transfer-heavy apps, needs near real-time performance. Finally, best effort apps aren't sensitive to degradation. They're elastic and can adapt to degraded performance conditions 🫧
Picking the right QoS and service type for each app's needs matters a lot during periods of congestion in an SP network. Sensitive apps will likely pick per-flow Integrated services (Intserv) with precise SLA guarantees measured per flow. Non-sensitive apps will likely rely on a Diffserv class-based QoS 🔥
The fundamental customer application requirement is that an L3VPN solution MUST support both the Intserv QoS model for selected individual flows and Diffserv for aggregated flows 👑
A customer application SHOULD experience consistent QoS no matter which access network technology is used at the different sites connected to the same VPN 🌈
5.5.2. DSCP Transparency ✨
Okay bestie, the DSCP a user sets, as it arrives at the ingress CE, SHOULD be capable of being relayed transparently to the egress CE 💅 (see section 2.6.2 of [RFC3270] and [Y.1311.1]). RFC 2475 says interior or boundary nodes inside a DS domain can change the DSCP, but customer VPNs MAY have other requirements, like:
- applications that use the DSCP in a manner differently from the DSCP solution supported by the SP network(s) 🎀
- customers using more DSCPs within their sites than the SP network(s) supports 🌸
- support for a carrier's carrier service, where one SP is the customer of another L3VPN SP. Such an SP should be able to resell VPN service to his or her VPN customers independently of the DSCP mapping solution supported by the carrier's carrier SP 👑
Note that DSCP transparency has no implication on the QoS or SLA requirements 🦋. If an SP supports DSCP transparency, then that SP needs to carry only the DSCP values across its domain but MAY map the received DSCP to some other value for QoS support across its domain 💜.
5.6. Service-Level Specification/Agreement 📜
Most customers just want their apps to perform well 🥹. An SLA is basically the vehicle for customer recourse when the SP(s) don't perform or manage a VPN service well in a measurable sense. So when a customer is buying service under an SLA, their customer agent
MUST have access to the measures from the SP(s) that support the SLA 🔥.
5.7. Customer Management of a VPN 🧚
A customer MUST have a means to view the topology, operational state, order status, and other parameters associated with his or her VPN 👀.
Most aspects of management information about CE devices and customer attributes of an L3VPN that are manageable by an SP SHOULD be capable of being configured and maintained by an authenticated, authorized customer agent 🛠️. Still, some aspects, like encryption keys, SHALL NOT be readable nor writable by management systems 🔐. Non-negotiable, iykyk 🙈.
A customer agent SHOULD be able to make dynamic requests for changes to traffic parameters ⚡. A customer SHOULD be able to receive real-time response from the SP network in response to these requests ⏱️. One example is a "Dynamic Bandwidth management" capability that enables real-time response to customer requests for changes of allocated bandwidth allocated to his or her VPN [Y.1311.1] 📈. Main character energy for sure ✨.
A customer who may not be able to afford the resources to manage his own sites SHOULD be able to outsource the management of the entire VPN to the SP(s) supporting the VPN network 🫶.
5.8. Isolation 🦋
These features include traffic and routing information exchange isolation, similar to what you get in VPNs based on Layer 1 and Layer 2 (e.g., private lines, FR, or ATM) [MPLSSEC]. It's giving private line energy, but make it virtual 💖.
5.9. Security 🔒
The suite of L3VPN solutions SHOULD support a range of security related features 🛡️. Higher levels of security services, such as edge-to-edge encryption, authentication, or replay attack, should be supported 😭. More details on customer requirements for security are described in [VPNSEC] 📚.
Security in an L3VPN service SHOULD be as transparent as possible to the customer 🫧, with the obvious exception of support for remote or temporary user access, as detailed in section 5.11.2.
L3VPN customers MUST be able to deploy their own internal security mechanisms in addition to those deployed by the SP 💪, so they can secure specific applications or traffic at a granularity finer than that on a site-to-site basis 🎯.
If a customer requires QoS support in an L3VPN, then this request MUST be communicated to the SP either by using unencrypted fields or via an agreed security association 🗝️. For example, applications could send RSVP messages in support of Intserv either in the clear or encrypted with a key negotiated with the SP. Another case is where applications using an IPsec tunnel could copy the DSCP from the encrypted IP header to the header of the tunnel's IP header 🌈.
5.10. Migration Impact 🚚
Often, customers are migrating from an already deployed private network toward one or more L3VPN solutions 📦. A typical private network scenario is CE routers connected via real or virtual circuits 🔌. Ideally, minimal incremental cost SHOULD result during the migration period 💸. Furthermore, if necessary, any disruption of service SHOULD also be minimized 🙏.
A range of scenarios of customer migration MUST be supported 🌷. Full migration of all sites MUST be supported 🏠. Support for cases of partial migration is highly desirable [Y.1311.1] 🥰. That is, legacy private network sites that belong to the L3VPN service SHOULD still have L3 reachability to the sites that migrate to the L3VPN service 🤝.
5.11. Network Access 🌐
Every L3 packet exchanged between the customer and the SP over the access connection MUST appear as it would on a private network providing an equivalent service to that offered by the L3VPN 🫡.
5.11.1. Physical/Link Layer Technology 🔌
L3VPNs SHOULD support a broad range of physical and link-layer access technologies 📡, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, and mobile radio access 📶. The capacity and QoS achievable may depend on the specific access technology in use 🧃.
5.11.2. Temporary Access 🚪
The VPN service offering SHOULD allow both permanent and temporary access to one or more L3VPNs for authenticated users across a broad range of access technologies 🎫. Support for remote or temporary VPN access SHOULD include ISDN, PSTN dial-in, xDSL, or access via another SP network 📞. The customer SHOULD be able to choose from alternatives for authentication of temporary access users 🔑. The choices for access authentication are SP-provided, third-party, or customer-provided authentication 🗂️.
A significant number of VPN users may not be permanently attached to one VPN site 🧳. To limit access to a VPN to authorized users, it is first necessary to authenticate them 🛂. Authentication SHALL apply as configured by the customer agent and/or SP where a specific user may be part of one or more VPNs 🧩. The authentication function SHOULD be used to invoke all actions necessary to join a user to the VPN automatically 🤖.
A user SHOULD be able to access an L3VPN via a network having generic Internet access 🌍.
Mobile users may move within an L3VPN site 🏃♀️. Mobile users may also have temporary connections to different L3VPN sites within the same VPN 🗺️. Authentication SHOULD be provided in both of these cases 🔐✨.
5.11.3. Sharing of the Access Network 🤝
In a PE-based L3VPN, if the site shares the access network with other traffic (e.g., access to the Internet), then data security in the access network is the responsibility of the L3VPN customer 🥺. Bestie, that one's on you 💅.
5.11.4. Access Connectivity
Hold up, we need to talk about how a network can be connected to more than one place at a time 🌸 Various physical connectivity setups MUST be supported, like multi-homed sites, backdoor links between customer sites, and devices homed to two or more SP networks 💅 L3VPN solutions SHOULD support at least the kinds of physical or link-layer arrangements shown in Figure 2.1 🦋 Support for other physical connectivity scenarios with arbitrary topology is desirable ✨
Okay so, any access arrangement with multiple physical or logical paths from a CE to other CEs and PEs MUST support redundancy and SHOULD support load balancing 🫶 Resiliency uses redundancy to keep a CE site connected to other CE sites and, optionally, other services 💖 Load balancing is the way to do traffic engineering so the capacity on redundant links actually gets used for better performance while the redundant parts are up 🔥
For multi-homing to a single SP, load balancing SHOULD be supported by the PE across the CE to PE links 🎀 For example, in case (a), the two PEs SHOULD provide load balancing over the two links connecting to the single CE 💜 In case (c), the two PEs SHOULD provide load balancing over the two links connecting to the two CEs 🌈
Also, the load-balancing parameters (for example, the ratio of traffic across the load-balanced links, or the preferred link) SHOULD be provisionable based on the customer's requirements 🍓 The load-balancing capability may also be used to get resiliency when access connectivity fails 🧚 For example, in case (b), a CE may connect to two different SPs over diverse access networks 😭 Resiliency MAY be enhanced even further as shown in case (d), where CEs connected via a "back door" connection attach to different SPs 👑 Furthermore, arbitrary combinations of the above methods, with a few examples shown in cases (e) and (f), should be supportable by any L3VPN approach ⭐
For multi-homing to multiple SPs, load balancing capability MAY also be supported by the PEs in the different SPs 🙈 (Clearly, this is a more complex type of load balancing to pull off, since it needs policy and service agreements between the SPs so they can interoperate 💀)
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |router| | |router| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|router| +---------|router| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+\\ +------+ +------+\\ +------+
| \\ | | \\ |
|Back \\ | |Back \\
+---------------
|door \\ | SP network |door \\
+---------------
|link \\ | |link \\ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(e) (f)
Figure 2.1. Representative types of access arrangements5.12. Service Access
Customers MAY also need access to other services, as we'll see in this section 🎀
5.12.1. Internet Access
Customers SHOULD be able to have L3VPN and Internet access over the same access network for one or more of the customer's sites 💖
Customers SHOULD be able to direct Internet traffic from the set of sites in the L3VPN to one or more customer sites that have firewalls, other security-oriented devices, and/or NATs that process all traffic between the Internet and the customer's VPN 🛡️
L3 VPN Customers SHOULD be able to receive traffic from the Internet addressed to a publicly accessible resource that is not part of the VPN, like an enterprise's public web server 🌐
As stated in Section 5.3, if a customer L3VPN uses private or non-unique IP addresses, then network address translation (NAT) or a similar mechanism MUST be provided either by the customer or the SP so that traffic can be exchanged with devices outside the customer's L3VPN 😤
5.12.2. Hosting, Application Service Provider
A customer SHOULD be able to access hosting, other application services, or other Application Service Providers (ASP) over an L3 L3VPN service 🧚 This MAY require that an ASP participate in one or more VPNs with the customers that use such a service 💜
5.12.3. Other Services
In conjunction with a VPN service, a customer MAY also want access to other services, such as DNS, FTP, HTTP, NNTP, SMTP, LDAP, VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, Streaming, E-commerce, Directory, Firewall, etc. 🌸 The resources that implement these services could be physically dedicated to each VPN 🍓 If the resources are logically shared, then they MUST have access separated and isolated between VPNs, in a manner consistent with the L3VPN solution, to meet this requirement 🔥
5.13. Hybrid VPN Service Scenarios
Intranet or extranet customers have plenty of reasons to want hybrid networks that mix more than one VPN solution type 🌈 These include migration, mergers, extranet customers with different VPN types, the need for different capabilities between different sets of sites, temporary access, and different availability of VPN solutions from different service providers 👑
The framework and solution approaches SHOULD include provisions for interworking, interconnection, and/or reachability between different L3VPN solutions, in a way that does not overly complicate provisioning, management, scalability, or performance ✨
6. Service Provider Network Requirements
This section describes requirements from a service provider perspective 💅
6.1. Scalability
[RFC3809] lists projections of L3VPN sizing and scalability requirements and metrics related to specific solutions 📊
6.2. Addressing
As described in Section 4.2, SPs MUST have support for public and private IP addresses, IPv4 and IPv6, for both unicast and multicast 🌍 In order to support this range of addressing schemes, SPs need the following support from L3VPN solutions 🫶
An L3VPN solution MUST be able to assign blocks of addresses from its own public IP address space to L3VPN customer sites, so that advertisement of routes to other SPs and other sites aggregates efficiently 🦋
An L3VPN solution MUST be able to use address assignments made by a customer 🎀 These customer-assigned addresses may be public or private 💖
If private IP addresses are used, an L3VPN solution MUST provide a means for an SP to translate such addresses to public IP addresses for communication with other VPNs, by using overlapping addresses or the Internet 😭
6.3. Identifiers
A number of identifiers MAY be necessary for SP use in management, control, and routing protocols 🧚 Requirements for at least the following identifiers are known 🌈
An SP domain MUST be uniquely identified at least within the set of all interconnected SP networks when supporting a VPN that spans multiple SPs 🔥 Ideally, this identifier should be globally unique (for example, an AS number) 💜
An identifier for each VPN SHOULD be unique, at least within each SP's network 🍓 Ideally, the VPN identifier SHOULD be globally unique to support the case where a VPN spans multiple SPs (for example, [RFC2685]) 🌸
A CE device SHOULD have a unique identifier, at least within each SP's network 💅
A PE device SHOULD have a unique identifier, at least within each SP's network 🫶
The identifier of a device interconnecting SP networks MUST be unique within the set of aforementioned networks 👑
Each site interface SHOULD have a unique identifier, at least within each PE router supporting such an interface 🎀
Each tunnel SHOULD have a unique identifier, at least within each router supporting the tunnel 🦋
6.4. Discovering VPN Related Information ✨
okay bestie, setting up CE and PE devices is a whole job for a service provider 😭. So solutions SHOULD strive to include methods that let VPN information be dynamically discovered (or learned) by the PE and/or CE, so there's less config to juggle 💅. These are the specific requirements for intra- and inter-provider VPNs [VPNDISC] 🫶.
Every device involved in a VPN SHALL be able to identify and authenticate itself to other devices in the VPN 🔐. After learning VPN membership, devices SHOULD be able to exchange configuration information securely ✨. The VPN information MUST include at least the IP address of the PE and may be extensible to provide additional information 🌸.
Each device in a VPN SHOULD be able to figure out which other devices belong to the same VPN 👀. A membership discovery scheme like that MUST prevent unauthorized access and allow authentication of the source 🚫.
Distribution of VPN information SHOULD be limited to the devices involved in that VPN 🤫.
In the case of a PE-based VPN, a solution SHOULD support the means for attached CEs to authenticate each other and verify that the SP's VPN network is correctly configured 🧐.
The mechanism SHOULD respond to VPN membership changes in a timely manner ⏰. That means no longer than the provisioning timeframe, typically on the order of minutes, and it could be as short as the timeframe required for "rerouting", typically on the order of seconds ⚡.
Dynamically creating, changing, and managing multiple VPN assignments to sites and/or customers is another aspect of membership that MUST be addressed in an L3VPN solution 💜.
6.5. SLA and SLS Support 📝
so typically, a Service Provider offering an L3VPN service commits to specific Service Level Specifications (SLS) as part of a contract with the customer, as described in section 4.4 and [RFC3809] 🤝. That kind of Service Level Agreement (SLA) means SP requirements for measuring Specific Service Level Specifications (SLS) for quality, availability, response time, and configuration intervals 📊.
6.6. Quality of Service (QoS) and Traffic Engineering 🚦
QoS is a big deal for an L3VPN 🔥. The SP controls how resources get provisioned and how parameters get configured in at least the PE and P devices and, in some cases, the CE device too, so the onus is on the SP to provide either managed QoS access service, or edge-to-edge QoS service, as defined in section 4.3.2 💅.
Each L3VPN approach MUST describe the traffic engineering techniques available for an SP to meet the QoS objectives 🎯. These descriptions of traffic engineering techniques SHOULD quantify scalability and achievable efficiency 📈. Traffic engineering support MAY be on an aggregate or per-VPN basis 🧩.
QoS policies MUST not be impacted by security mechanisms 🙅♀️. For example, Diffserv policies MUST not be impacted by the use of IPSec tunnels using the mechanisms explained in RFC 2983 [RFC2983] 🔒.
As stated in RFC 2475, a mapping function from customer provided Diffserv marking to marking used in an SP network should be provided for L3 VPN services 🗺️.
If a customer requires DSCP transparency, as described in section 5.5.2, an L3VPN service MUST deliver the same value of DSCP field in the IP header received from the customer to the egress demarcation of the destination 🎀.
6.7. Routing 🛣️
The distribution of reachability and routing policy SHOULD be constrained to the sites that are members of the VPN 🫧.
Optionally, the exchange of such information MAY use some form of authentication (e.g., MD5) 🔑.
Functions to isolate the SP network and customer VPNs from anomalous routing behavior from a specific set of customer sites SHOULD be provided 🛡️. Examples of such functions are controls for route flap dampening, filters that accept only prefixes configured for a specific CE, a maximum number of routes accepted for each CE, or a maximum rate at which route updates can be received from a CE 🙌.
When VPN customers use overlapping non-unique IP addresses, the solution MUST define a means to distinguish between such overlapping addresses on a per-VPN basis 🧠.
Furthermore, the solution SHOULD provide an option that either allows or prevents advertisement of VPN routes to the Internet 🌐.
Ideally, the choice of an SP's IGP SHOULD not depend on the routing protocol(s) used between PE and CE routers in a PE-based VPN 🍓.
Furthermore, it is desirable that an SP SHOULD have a choice regarding the IGP routing protocol 💭.
The additional routing burden that an SP must carry should be articulated in each specific L3VPN solution 📦.
6.8. Isolation of Traffic and Routing 🧱
The internal structure of an L3VPN network SHOULD not be visible to outside networks (e.g., the Internet or any connected VPN) 👻.
From a high-level SP perspective, a PE-based L3VPN MUST isolate the exchange of traffic and routing information to only those sites that are authenticated and authorized members of a VPN 🔐.
In a CE-based VPN, the tunnels that connect the sites effectively meet this isolation requirement if both traffic and routing information flow over the tunnels 🚇.
An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA requirements that isolates VPN traffic from the effects of traffic offered by non-VPN customers 🏝️. Also, L3VPN solutions SHOULD provide a means to isolate the effects that traffic congestion produced by sites as part of one VPN can have on another VPN 🚧.
6.9. Security 🔐
this section is all about securing customer flows 💖, providing authentication services for temporary, remote, or mobile users 🧳, and protecting service provider resources involved in supporting an L3VPN 🏰. More detailed security requirements are provided in [VPNSEC] 📚.
6.9.1. Support for Securing Customer Flows 🎀
In order to meet the general requirement for providing a range of security options to a customer, each L3VPN solution MUST clearly spell out the configuration options that can work together and how they can do so 🧩.
When a VPN solution operates over a part of the Internet, it should support a configurable option to support one or more of the following standard IPsec methods for securing a flow for a specified subset of a customer's VPN traffic:
- Confidentiality, so that only authorized devices can decrypt it 🤫
- Integrity, to ensure that the data has not been altered 🧷
- Authentication, to ensure that the sender is indeed who he or she claims to be 🪪
- Replay attack prevention 🚫
The above functions SHOULD be applicable to "data traffic" of the customer, which includes the traffic exchanged between sites between temporary users and sites, and even between temporary users 🧳. It SHOULD also be possible to apply these functions to "control traffic", such as routing protocol exchanges, that are not necessarily perceived by the customer but are nevertheless essential to maintain his or her VPN 🫶.
Furthermore, such security methods MUST be configurable between different end points, such as CE-CE, PE-PE, and CE-PE 🔧. It is also desirable to configure security on a per-route or per-VPN basis [VPNSEC] ✨.
A VPN solution MAY support one or more encryption schemes, including AES, and 3DES 🔒. Encryption, decryption, and key management SHOULD be included in profiles as part of the security management system 🗂️.
6.9.2. Authentication Services 🪪
A service provider MUST provide authentication services in support of temporary user access requirements, as described in section 5.11.2 🧳.
Furthermore, traffic exchanged within the scope of VPN MAY involve several categories of equipment that must cooperate to provide the service [Y.1311.1] 🤝. These network elements can be CE, PE, firewalls, backbone routers, servers, management stations, etc. These network elements learn about each other's identity, either via manual configuration or via discovery protocols, as described in section 6.4. When network elements must cooperate, these network elements SHALL authenticate peers before providing the requested service 🫡. This authentication function MAY also be used to control access to network resources 🚪.
The peer identification and authentication function described above applies only to network elements participating in the VPN. Examples include:
- traffic between a CE and a PE 🔁
- traffic between CEs belonging to the same VPN 👯
- CE or PE routers dealing with route announcements for a VPN 📣
- policy decision point [RFC3198] and a network element 🧠
- management station and an SNMP agent 🖥️
For a peer authentication function, each L3VPN solution SHOULD describe where necessary, how it shall be implemented, how secure it must be, and the way to deploy and maintain identification and authentication information necessary to operate the service 🛠️.
6.9.3. Resource Protection 🏯
recall from the definitions in section 3.3 that a site can be part of an intranet with sites from the only same organization, can be part of an extranet involving sites from other organizations, can have access to the Internet, or can have any combination of these scopes of communication 🌍. Within these contexts, a site might be subject to various attacks coming from different sources 😬. Potential sources of attack include:
- users connected to the supporting public IP backbone 🛜
- users from the Internet 🌐
- users from temporary sites belonging to the intranet and/or extranet VPN the site is part of 🧳
Security threats and risks that a site may encounter include the following:
- Denial of service, for example mail spamming, access connection congestion, TCP SYN attacks, and ping attacks 💀
- Intrusion attempts, which may eventually lead to denial of service (e.g., a Trojan horse attack) 🐴
Additional threat scenarios are defined in [VPNSEC]. An L3VPN solution MUST state how it addresses each potential threat scenario 📋.
The devices in the L3VPN network must provide some means of reporting intrusion attempts to the service provider resources 🚨.
6.10. Inter-AS (SP)VPNs 🌉
the scenario for VPNs spanning multiple Autonomous Systems (AS) or Service Providers (SP) requires standard solutions 🤝. The scenario where multiple ASes are involved is the most general case and is therefore the one described here. The scenarios of concern are the CE-based and PE-based L3VPNs defined in section 3 🧭.
In each scenario, all applicable SP requirements, such as traffic and routing isolation, SLAs, management, security, and provisioning. MUST be preserved across adjacent ASes 🫶. The solutions MUST describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters [VPNIW] 📝.
An essential pre-condition for an inter-AS VPN is an agreement between the ASes involved that spells out at least trust, economic, and management responsibilities 🤝💸.
The overall scalability of the VPN service MUST allow the L3VPN service to be offered across potentially hundreds of SPs, with the overall scaling parameters per SP given in [RFC3809] 📈🌈.
6.10.1. Routing Protocols 🛤️
If the link between ASes is not trusted, routing protocols running between those ASes MUST support some form of authentication 🔐. For example, the TCP option for carrying an MD5 digest may be used to enhance security for BGP [RFC2385] 🛡️.
BGP MUST be supported as the standard inter-AS routing protocol to control the path taken by L3VPN traffic 👑.
6.10.2. Management 🧚
okay so the general requirements for managing a single AS also apply to a whole chain of ASes stuck together 🔗 the rules don't change just because there's more than one network involved. the minimum set of those capabilities looks like this:
- Diagnostic tools (e.g., ping, traceroute)
- Secured access to one AS management system by another
- Configuration request and status query tools
- Fault notification and trouble-tracking tools
6.10.3. Bandwidth and QoS Brokering 💜
okay bestie, when a VPN spans multiple ASes, we want a brokering mechanism 🤝 that asks the other domains and/or networks carrying traffic to various sites for SLA parameters like bandwidth and QoS. brokering across ASes isn't super common in today's networks yet, but it's lowkey essential for keeping SLAs in inter-AS VPNs. this section lists the requirements for features that would make all of this work. the big goal: a solution SHOULD be able to determine whether a set of ASes can establish and guarantee uniform QoS in support of an L3VPN ✨
brokering can be manual, like one provider asking another for a specific set of bandwidth and QoS parameters for traffic going to and from a specific set of sites. it can also be automated, where a device dynamically requests and receives certain bandwidth and SLA/QoS parameters. for example, in an L3VPN over MPLS, a PE might negotiate the label for different traffic classes to reach a PE sitting in a neighboring AS 🦋 or it can be a mix of both. for more detailed requirements on the automated approach, check out [TE-INTERAS].
brokering on a per-VPN basis is not desirable, because that approach would not scale 😭 so a solution MUST provide some means to aggregate QoS and bandwidth brokering requests between ASes. one method could be for SPs to make an agreement specifying the maximum amount of bandwidth for specific QoS parameters for all VPN customers using the SP network. alternatively, such aggregation might be done per hierarchical tunnel between PE routers in different ASes supporting an L3VPN service [TE-INTERAS].
6.10.4. Security Considerations 🔐
this part is serious, bestie, so listen up 💀 if a tunnel traverses multiple SP networks and passes through an unsecured SP, POP, NAP, or IX, then security mechanisms MUST be employed. these security mechanisms include encryption, authentication, and resource protection, as described in section 6.9, plus security management, as covered in section 7.5. for example, a provider should consider using both authentication and encryption for a tunnel used as part of an L3VPN that traverses another service provider's network 🛡️
6.11. L3VPN Wholesale 🛍️
the architecture MUST support the possibility of one service provider offering VPN service to another service provider. another example is when one service provider sells L3VPN service at wholesale to another service provider, who then resells that VPN service to his or her customers 💅
the wholesaler's VPN MUST be transparent to the addressing and routing used by the reseller. no peeking, periodt 🙈
support for additional levels of hierarchy (for example, three levels at which a reseller can again resell the VPN service to yet another VPN provider) SHOULD be provided. it's giving russian doll energy 🪆
the Carrier's Carrier scenario is the term this document uses for this category of L3VPN wholesale (although some scenarios of Inter-AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale category, too). various carrier's carrier scenarios should be supported, such as when:
- the customer carriers do not operate L3VPN services for their clients;
- the customer carriers operate L3VPN services for their clients, but these services are not linked with the L3VPN service offered by the Carrier's Carrier; and
- the customer carriers operate L3VPN services for their clients, and these services are linked with the L3VPN service offered by the Carrier's Carrier ("Hierarchical VPNs" scenario).
6.12. Tunneling Requirements 🚇
connectivity between CE sites or PE devices in the backbone SHOULD use a range of tunneling technologies, such as L2TP, IPSEC, GRE, IP-in-IP, and MPLS 🌈
to set up tunnels between routers, every router MUST support static configuration for tunneling and MAY support a tunnel setup protocol. if one is employed, a tunnel establishment protocol SHOULD be capable of conveying information such as:
- Relevant identifiers
- QoS/SLA parameters
- Restoration parameters
- Multiplexing identifiers
- Security parameters
there MUST be a means to monitor the following aspects of tunnels:
- Statistics, such as amount of time spent in the up and down state.
- Count of transitions between the up and down state.
- Events, such as transitions between the up and down states.
the tunneling technology used by the VPN Service Provider and its associated mechanisms for tunnel establishment, multiplexing, and maintenance MUST meet the requirements on scaling, isolation, security, QoS, manageability, etc. ✨ no shortcuts allowed
6.13. Support for Access and Backbone Technologies 🌐
this section describes requirements for aspects of access and backbone network technologies, looked at from an SP point of view 👑
some SPs MAY desire that a single network infrastructure suffices for all services: public IP, VPNs, traffic engineering, and differentiated services [L2VPN]. one network to rule them all 💅
6.13.1. Dedicated Access Networks 🧵
ideally, the L3VPN service SHOULD be independent of physical, link layer, or even network technology of the access network. however, the characteristics of access networks MUST be accounted for when the QoS aspects of SLAs for VPN service offerings are specified. the access details matter, bestie 📝
6.13.2. On-Demand Access Networks 🚪
service providers SHOULD be able to support temporary user access, as described in section 5.11.2, by using dedicated or dial-in access network technology 📞
L3VPN solutions MUST support the case where a VPN user directly accesses the VPN service through an access network connected to the service provider. they MUST also describe how they can support the case where one or more other service provider networks are used for access to the service provider supporting the L3VPN service. it's giving multi-hop main character energy 🌸
ideally, all information necessary to identify and authenticate users for an intranet SHOULD be stored and maintained by the customer. in an extranet, one customer SHOULD be able to maintain the authentication server, or the customers involved in the extranet MAY choose to outsource the function to a service provider 🔑
identification and authentication information could be made available to the service provider for controlling access, or the service provider may query a customer-maintained server. furthermore, one SP may act as access for the SP providing the VPN service. if the access SP performs identification and authentication on behalf of the VPN SP, an agreement MUST be reached on a common specification. receipts or it didn't happen 🤝
support for at least the following authentication protocols SHALL be supported: PAP, CHAP, and EAP, as they are currently used in a wide range of equipment and services 🫶
6.13.3. Backbone Networks 🦴
ideally, the backbone interconnecting SP, PE, and P devices SHOULD be independent of physical and link layer technology. nevertheless, the characteristics of backbone technology MUST be taken into account when specifying the QoS aspects of SLAs for VPN service offerings 🔥
6.14. Protection, Restoration 🛟
when primary and secondary access connections are available, an L3VPN solution MUST provide restoration of access connectivity whenever the primary access link from a CE site to a PE fails. this capability SHOULD be as automatic as possible, which means the traffic should be directed over the secondary link soon after failure of the primary access link is detected. furthermore, reversion to the primary link SHOULD be dynamic, if configured to do so [VPN-NEEDS]. backup plan, but make it automatic ⚡
as mentioned in section 5.11.4, in the case of multi-homing, the load balancing capability MAY be used to achieve a degree of redundancy in the network. in the case of failure of one or more (but not all) of the multi-homed links, the load balancing parameters MAY be dynamically adjusted to redirect the traffic rapidly from the failed link(s) to the surviving links. once the failed link(s) is (are) restored, the original provisioned load balancing ratio SHOULD be restored to its value prior to the failure 🔄
an SP SHOULD be able to deploy protection and restoration mechanisms within his or her backbone infrastructure to increase reliability and fault tolerance of the VPN service offering. these techniques SHOULD be scalable, and therefore should strive not to perform such function in the backbone on a per-VPN basis. ✨ scale or bust
appropriate measurements and alarms that indicate how well network protection and restoration mechanisms are performing MUST be supported 🚨
6.15. Interoperability 🤝
service providers are interested in interoperability in at least the following scenarios:
- Facilitating use of PE and managed CE devices within a single SP network.
- Implementing L3VPN services across two or more interconnected SP networks.
- Achieving interworking or interconnection between customer sites using different L3VPN approaches or different implementations of the same approach.
each approach MUST describe whether any of the above objectives can be met. if an objective can be met, the approach MUST describe how such interoperability could be achieved. in particular, the approach MUST describe the inter-solution network interface, encapsulation method(s), routing protocol(s), security, isolation, management, and all other applicable aspects of the overall VPN solution provided [VPNIW]. play nice with the other solutions, bestie 🧚
6.16. Migration Support 🦋
service providers MUST have a graceful means to migrate a customer, with minimal service disruption, on a site-by-site basis to an L3VPN approach 🌷
if L3VPN approaches can interwork or interconnect, then service providers MUST have a graceful means to migrate a customer, with minimal service disruption, on a site-by-site basis whenever interworking or interconnection is changed. smooth glow-up only 💖
7. Service Provider Management Requirements 📋
a service provider MUST have a means to view the topology, operational state, order status, and other parameters associated with each customer's VPN. furthermore, an SP MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers. full visibility, no hidden drama 👀
currently, proprietary methods are often used to manage VPNs. the additional expense of operators using multiple proprietary management methods (e.g., command line interface (CLI) languages) to access such systems is undesirable. therefore, devices SHOULD provide standards-based interfaces wherever feasible 💅 ugh, so much extra work for no reason
the remainder of this section presents detailed SP management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories. much of this text was adapted from ITU-T Y.1311.1. 🌈
7.1. Fault Management 🚨
okay so fault management is basically the whole "something broke, now what?" toolkit 🛠️ and it has five parts bestie:
- indication of customers impacted by failure,
- fault detection (incidents reports, alarms and failure visualization),
- fault localization (analysis of alarms reports and diagnostics),
- incident recording or logs (creation and follow-through of trouble tickets), and
- corrective actions (traffic, routing, and resource allocation).
ngl the first one is the big deal. PE-based VPNs all share the same underlying network infrastructure 🌐, so the NMS MUST give the provider a way to tell which VPN customers got hit when something in that infrastructure fails. The NMS SHOULD also point to the related customer configuration info so people can isolate the problem and figure out what to fix 🔍. main character debugging energy 💅
Detecting faults caused by configuration errors is also super desirable 🙈 because those can break VPN service or mess with other requirements like traffic and routing isolation. This is a likely case of compromised security [VPNSEC]. Detecting these errors is genuinely hard, because the problem can involve more than one node and can reach across a global view 😭. One approach could be a protocol that systematically checks whether all constraints and consistency checks hold among tunnel configuration parameters at the various end points 🧩.
A capability to verify L3 reachability within a VPN MUST be provided for diagnostic purposes 🎯.
A capability to verify the parameter configuration of a device supporting an L3VPN MUST be provided for diagnostic purposes 🧪.
7.2. Configuration Management 🎀
Overall, the NMS must support a configuration necessary to realize the desired L3-reachability of an L3VPN ✨. Toward this end, an NMS MUST provide configuration management to provision at least the following L3VPN components: PE,CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section. If shared access to the Internet is provided, then this option MUST also be configurable 🌸.
VPN configuration and topology are highly dependent on a customer's organization, so provisioning systems MUST address a broad range of customer-specific requirements 🏢. The NMS MUST ensure that these devices and protocols are provisioned consistently and correctly 💖.
Provisioning for adding or removing sites SHOULD be as localized and automated as possible 🤖.
Configuration management for VPNs, according to service templates defined by the provider MUST be supported 📋. A service template contains fields that, when used, yield a definite service requirement or policy. For example, a template for an IPSec tunnel would contain fields such as tunnel end points, authentication modes, encryption and authentication algorithms, pre-shared keys (if any), and traffic filters 🔐. An SLA template would contain fields such as delay, jitter, and throughput and packet loss thresholds, as well as end points over which the SLA has to be satisfied 📈. In general, a customer's service order can be regarded as a set of instantiated service templates. This set can, in turn, be regarded as the logical service architecture of the customer's VPN 🦋.
Service templates can also be used by the provider to define the service architecture of the provider's own network 🏗️. For example, OSPF templates could contain fields such as the subnets that form a particular area, the area identifier, and the area type. BGP service template could contain fields that, when used, would yield a BGP policy, such as for expressing a preference about an exit router for a particular destination 🚪.
The set of service templates SHOULD be comprehensive in that it can capture all service orders in some meaningful sense 📚.
The provider SHOULD provide means to translate service templates into device configurations so that associated services can be provisioned 🔄.
Finally, the approach SHOULD provide means to check whether a service order is correctly provisioned. This would represent one method of diagnosing configuration errors. Configuration errors can arise due to a variety of reasons: manual configuration, intruder attacks, and conflicting service requirements 😬.
7.2.1. Configuration Management for PE-Based VPNs
Requirements for configuration management unique to a PE-based VPN are as follows 📝:
- The NMS MUST support configuration of at least the following aspects of L3 PE routers: intranet and extranet membership, CE routing protocol for each access connection, routing metrics, and tunnels.
- The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs, hierarchical tunnels, and access connections, as described in section 6.3.
- Tunnels MUST be configured between PE and P devices. This requires coordination of identifiers of tunnels, hierarchical tunnels, VPNs, and any associated service information, for example, a QoS/SLA service.
- Routing protocols running between PE routers and CE devices MUST be configured per VPN.
- For multicast service, multicast routing protocols MUST also be configurable.
- Routing protocols running between PE routers and between PE and P routers MUST also be configured.
- The configuration of a PE-based L3VPN MUST be coordinated with the configuration of the underlying infrastructure, including Layer 1 and 2 networks interconnecting components of an L3VPN 🔗.
7.2.2. Configuration Management for CE-Based VPN
Requirements for configuration management unique to a CE-based VPN are as follows 🧾:
- Tunnels MUST be configured between CE devices. This requires coordination of identifiers of tunnels, VPNs, and any associated service information, for example, a QoS/SLA service.
- Routing protocols running between PE routers and CE devices MUST be configured. For multicast service, multicast routing protocols MUST also be configurable.
7.2.3. Provisioning Routing
A means for a service provider to provision parameters for the IGP for an L3VPN MUST be provided. This includes link level metrics, capacity, QoS capability, and restoration parameters 🛣️.
7.2.4. Provisioning Network Access
A service provider MUST have the means to provision network access between SP-managed PE and CE, as well as the case where the customer manages the CE 🔌.
7.2.5. Provisioning Security Services
When a security service is requested, an SP MUST have the means to provision the entities and associated parameters involved with the service. For example, for IPsec service, tunnels, options, keys, and other parameters must be provisioned at either the CE or the PE. In the case of an intrusion detection service, the filtering and detection rules must be provisioned on a VPN basis 🛡️.
7.2.6. Provisioning VPN Resource Parameters
A service provider MUST have a means to provision resources associated with VPN services dynamically. For example, in a PE-based service, the number and size of virtual switching and forwarding table instances must be provisionable 🧠.
Dynamic VPN resource assignment is crucial for coping with the frequent change requests from customers (e.g., sites joining or leaving a VPN), as well as for achieving scalability 📊. The PEs SHOULD be able to dynamically assign the VPN resources dynamically. This capability is especially important for dial and wireless VPN services 📱.
If an SP supports a "Dynamic Bandwidth management" service, then the provisioning system MUST be able to make requested changes within the ranges and bounds specified in the SLA. Examples of SLA parameters are response time and probability of being able to service such a request ⏱️.
7.2.7. Provisioning Value-Added Service Access
An L3VPN service provides controlled access between a set of sites over a common backbone 🏰. However, many service providers also offer a range of value-added services (for example, Internet access, firewall services, intrusion protection, IP telephony and IP Centrex, application hosting, and backup) 🎁. It is outside of the scope of this document to define whether and how these different services interact with the VPN to solve issues such as addressing, integrity, and security. However, the VPN service MUST be able to provide access to these various types of value-added services 🤝.
A VPN service SHOULD allow the SP to supply the customer with different kinds of standard IP services, such as DNS, NTP, and RADIUS, that are needed for ordinary network operation and management 🧚. The provider SHOULD be able to provide IP services to multiple VPN customers 💜.
A firewall function MAY be required to restrict access to the L3VPN from the Internet [Y.1311] 🧱.
A managed firewall service MUST be carrier grade. For redundancy and failure recovery, a means for firewall fail-over should be provided. Managed firewall services that may be provided include dropping specified protocol types, intrusion protection, and traffic-rate limiting against malicious attacks 🔥.
Managed firewalls MUST be supported on a per-VPN basis, although multiple VPNs may be supported by the same physical device (e.g., in a PE-based solution). Managed firewalls SHOULD be provided at the major access point(s) for the L3VPN. Managed firewall services may be embedded in CE or PE device or implemented in standalone devices 🏷️.
The NMS SHOULD allow a customer to outsource the management of an IP networking service to the SP providing the VPN or to a third party 🫶.
The NMS SHOULD support collection of information necessary for optimal allocation of IP services in response to customer orders 🗂️.
Reachability to and from the Internet to sites within a VPN MUST be configurable by an SP. This could be controlled by configuring routing policy to control distribution of VPN routes advertised to the Internet 🌈.
7.2.8. Provisioning Hybrid VPN Services
Configuration of interworking or interconnection between L3VPN solutions SHOULD be also supported. Ensuring that security and end-to-end QoS issues are provided consistently SHOULD be addressed 🦄.
7.3. Accounting 💸
Many service providers require collection of measurements regarding resource usage for accounting purposes. The NMS MAY need to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time when the SLS is not met 🧮.
An L3VPN solution MUST describe how the following accounting functions can be provided:
- Measurements of resource utilization.
- collection of accounting information.
- storage and administration of measurements.
Some providers may require near - real time reporting of measurement information and may offer this as part of a customer network management service ⚡.
If an SP supports a "Dynamic Bandwidth management" service, then the dates, times, amounts, and interval required to perform requested bandwidth allocation change(s) MUST be traceable for monitoring and accounting purposes 🗓️.
Solutions should state compliance with accounting requirements, as described in section 1.7 of RFC 2975 [RFC2975] 📑.
7.4. Performance Management 📈
Performance management MUST support functions involved with monitoring and collecting performance data for devices, facilities, and services, as well as determining conformance to SLS, such as QoS and availability measurements 💅.
Performance management SHOULD also support analysis of important aspects of an L3VPN, such as bandwidth utilization, response time, availability, QoS statistics, and trends based on collected data 🌟.
7.4.1. Performance Monitoring
okay so the NMS MUST keep an eye on device behavior 👀 to check the performance metrics tied to an SLA 💅 different services need different measurement techniques, so the way you measure can change depending on what the SLA is for ✨ QoS, security, multicast, and temporary access are all example services 🦋 these techniques MAY be intrusive or non-intrusive, depending on which parameters are being monitored 🫶
the NMS MUST also monitor the parts of the VPN that aren't directly tied to an SLA 👀 think resource utilization, device state, and transmission facilities 🔥 it also has to control monitoring resources like probes and remote agents at the network access points that customers and mobile users rely on 🌸
7.4.2. SLA and QoS Management Features
the NMS SHOULD support SLAs between an SP and the different VPN customers, following the matching SLSes 💖 it does this by measuring the indicators defined for the SLA on a regular basis ⭐
the NMS SHOULD use the QoS parameter measurement definitions, techniques, and methods defined by the IETF IP Performance Metrics (IPPM) working group for delay, loss, and delay variation 🧚 that's the official playbook, bestie 💅
the NMS SHOULD support allocating and measuring end-to-end QoS requirements against QoS parameters for one or more VPN network(s) 👑
devices supporting L3VPN SLAs SHOULD have real-time performance measurements with indicators and threshold crossing alerts 🚨 such thresholds should be configurable 🎀
7.5. Security Management
the security management function of the NMS MUST include features that guarantee the security of devices, access connections, and protocols within the L3VPN network(s) 🔐 it also covers the security of customer data and control, as described in section 6.9 🫶 security is literally the whole vibe here 💜
7.5.1. Resource Access Control
resource access control decides what privileges a user has to access particular applications and VPN network resources 🗝️ without it, only the data and control traffic is protected, and the devices that provide the L3VPN network are left wide open 😭 access control keeps those devices safe by making sure users can only reach the resources and applications they're authorized to use 🛡️
in particular, access to the routing and switching resources managed by the SP MUST be tightly controlled to prevent and/or effectively mitigate a malicious attack 🚫 more detailed requirements in this area are described in [VPNSEC] 📖
7.5.2. Authentication
authentication is the process of verifying that the sender is actually who they claim to be 🪪 the NMS MUST support standard methods for authenticating users who try to access management services 🔑
scalability is critical, because the number of nomadic and mobile clients is growing super fast 📈 the authentication scheme used for these deployments MUST be manageable for large numbers of users and VPN access points 👑
strong authentication schemes SHALL be supported to keep both VPN access point-to-VPN access point communication (like PE to PE in a PE-based case) and client-to-VPN access point communication (like CE-to-PE in a PE-based case) secure 🔒 this matters a LOT for preventing VPN access point spoofing 😱 that's when an attacker tricks a PE or CE into thinking the attacker is the VPN access point ☠️ if the attacker pulls that off, the device sends its VPN traffic straight to the attacker, who could then forward it to the real access point after breaking confidentiality or integrity 💀 basically, a non-authenticated VPN AP can be spoofed with a man-in-the-middle attack, because the endpoints never verify each other 🙈 a weakly authenticated VPN AP may be subject to the same attack 🫠 strongly authenticated VPN APs are not subject to these attacks, because the man-in-the-middle can't be authenticated as the real AP thanks to the strong authentication algorithms 🛡️💖
7.6. Basis and Presentation Techniques of Management Information
each L3VPN solution approach MUST specify the management information base (MIB) modules for the network elements involved in L3VPN services 📚 this is an essential requirement for network provisioning 🧚 the approach SHOULD identify any information that isn't in a standard FCAPS-related MIB but is still needed to meet a generic requirement 🍓
an IP VPN (Policy) Information model, when it's available, SHOULD reuse the policy information models being developed in parallel for specific IP network capabilities [IM-REQ] 🌈 that includes the QoS Policy Information Model [QPIM] and the IPSEC Configuration Policy Model [IPSECIM] ✨ the IP VPN Information model SHOULD also give the OSS adequate "hooks" to correlate service level specifications with traffic data collected from network elements 🪝 policies can include rules that control the corrective actions taken by OSS components that monitor the network and make sure it meets service requirements 🫶
more requirements on VPN information models are given in reference [IM-PPVPN] 📖 the big one: an information model MUST allow an SP to change VPN network dimensions with minimal influence on provisioning issues 🔥 the adopted model SHOULD apply to both small/medium and large-scale L3VPN scenarios 💅
some service providers MAY require systems that visually, audibly, or logically present FCAPS information to internal operators and/or customers 🎧👀
8. Security Considerations 🚨
security considerations show up at several levels and in several dimensions within L3VPNs, as detailed throughout this document 🔐 this section is a summary that points you to the detailed supporting info in [L3VPN-SEC] [VPNSEC] 📖
the requirements in this document separate the traditional notions of security requirements, like integrity, confidentiality, and authentication, from issues like isolating (or separating) the exchange of VPN data and control traffic between specific sets of sites (as defined in sections 3.3 and 4.1) 🧱 more detail on security requirements is given from the customer and service provider perspectives in sections 5.9 and 6.9, respectively 💜 more detail on data and control traffic isolation requirements is given from the customer and service provider perspectives in sections 5.1 and 6.8, respectively 🫶
and on top of all that, requirements about managing security from a service provider perspective are described in section 7.5 👑
9. Acknowledgements 🎀
the authors want to give a huge shoutout to the people who kicked off the VPN requirements work inside ITU-T SG13 🌟 and to the authors of the original IP VPN requirements and framework document [RFC2764] 💖 they also thank Tom Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le Garrec 🫶 the authors are also grateful for the helpful suggestions and direction from the technical advisors, Alex Zinin, Scott Bradner, Bert Wijnen, and Rob Coltun 👑 finally, they wish to acknowledge the insights and requirements they picked up from the many documents listed in the references section 📚 citations to those documents were only made where the authors believed the source document would give extra insight 🧠
10. References
10.1. Normative References
[RFC3377]Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. 📚[RFC1918]Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🏠[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑[RFC2205]Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 🌊[RFC2211]Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. ⚖️[RFC2212]Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. 💎[RFC2251]Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. 📇[RFC2475]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. 🏗️[RFC2597]Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. 🎯[RFC2661]Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. 🚇[RFC2685]Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. 🆔[RFC3246]Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. 🚀[RFC3270]Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. 🏷️[RFC3809]Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. 🌐
10.2. Informative References ✨
okay bestie, this is the reading list 📚💅 these are the informative references, so they give background and context rather than being strictly required. most of them are still "Work in Progress" drafts, which means they're living documents that are still being cooked 🍳
- [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in Progress.
- [IM-PPVPN] Lago, P., et al., "An Information Model for Provider Provisioned Virtual Private Networks", Work in Progress.
- [IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy Information Model", Work in Progress.
- [IPSECIM] Jason, J., "IPsec Configuration Policy Model", Work in Progress.
- [CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work in Progress.
- [IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned VPNs", Work in Progress.
- [L2VPN] Rosen, E., et al., "An Architecture for L2VPNs", Work in Progress.
- [MPLSSEC] Behringer, M., "Analysis of the Security of the MPLS Architecture", Work in Progress.
- [PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology", Work in Progress.
- [L3VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress.
- [L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress.
- [PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network based IP VPN Architecture using Virtual Routers", Work in Progress.
- [QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS Information Model", Work in Progress.
- [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
- [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
- [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
- [TE-INTERAS] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic Engineering requirements", Work in Progress.
- [VPNDISC] Squire, M. et al., "VPN Discovery Discussions and Options", Work in Progress.
- [VPNIW] Kurakami, H., et al., "Provider-Provisioned VPNs Interworking", Work in Progress.
- [VPNSEC] De Clercq, J., et al., "Considerations about possible security extensions to BGP/MPLS VPN", Work in Progress.
- [VPNTUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN Tunnels and Core Connectivity", Work in Progress.
- [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., "Criteria for Evaluating VPN Implementation Mechanisms", Work in Progress.
- [VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment of an IP VPN service offering : a service provider perspective", Work in Progress.
- [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture", Y.1311.1 ITU-T Recommendation, July 2001.
- [Y.1311] Knightson, K. (editor), "Network based VPNs - Generic Architecture and Service Requirements", Y.1311 ITU-T Recommendation, March 2002.
Authors' Addresses 💌
Marco Carugi (co-editor) Nortel Networks Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE
EMail: marco.carugi@nortel.com
Dave McDysan (co-editor) MCI 22001 Loudoun County Parkway Ashburn, VA 20147, USA
EMail: dave.mcdysan@mci.com
Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA
EMail: Luyuanfang@att.com
Ananth Nagarajan Juniper Networks
EMail: ananth@juniper.net
Junichi Sumimoto NTT Communications Corporation 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
EMail: j.sumimoto@ntt.com
Rick Wilder Alcatel
EMail: rick.wilder@alcatel.com
Full Copyright Statement 🎀
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 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 ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
and that's the whole spec, bestie!! we made it all the way to the end 🦋✨
📦 where this page comes from
- ietf: rfc4031 2005-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms