RFC 4026
Provider Provisioned Virtual Private Network (VPN) Terminology
RFC 4026 🎀 Provider Provisioned Virtual Private Network (VPN) Terminology
okay bestie, this is the RFC that sorts out the VPN vocab mess 💅✨ Its title block says it's from the Network Working Group, numbered 4026, and written by L. Andersson and T. Madsen, both from Acreo AB. It's Informational 🦋 (not a standard!) and it's dated March 2005. The title block doesn't list anything it obsoletes or updates.
Status of This Memo
This memo gives info to the Internet community 🌸. It does not specify an Internet standard of any kind 🙈. Distribution is unlimited, so share it with everyone 💜
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
so the whole provider-provisioned VPN thing got SO popular 🔥 that people kept writing memos with different, overlapping solutions 😭. The working groups (first PPVPN, then L2VPN and L3VPN) talked it all out and wrote specs, which led to a bunch of new concepts for describing VPN services 🧚.
The problem is that more than one term can mean the same concept 💀, and sometimes one term means more than one concept 🙃. This doc is here to make the terminology clearer and more intuitive, which honestly is iconic ✨
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. PPVPN Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Provider Provisioned Virtual Private Network Services . . . . 4
3.1. Layer 3 VPN (L3VPN) . . . . . . . . . . . . . . . . . . 4
3.2. Layer 2 VPN (L2VPN) . . . . . . . . . . . . . . . . . . 4
3.3. Virtual Private LAN Service (VPLS) . . . . . . . . . . . 4
3.4. Virtual Private Wire Service (VPWS) . . . . . . . . . . 4
3.5. IP-Only LAN-Like Service (IPLS) . . . . . . . . . . . . 5
3.6. Pseudo Wire (PW) . . . . . . . . . . . . . . . . . . . . 5
3.7. Transparent LAN Service (TLS) . . . . . . . . . . . . . 5
3.8. Virtual LAN (VLAN) . . . . . . . . . . . . . . . . . . . 6
3.9. Virtual Leased Line Service (VLLS) . . . . . . . . . . . 6
3.10. Virtual Private Network (VPN) . . . . . . . . . . . . . 6
3.11. Virtual Private Switched Network (VPSN) . . . . . . . . 6
4. Classification of VPNs . . . . . . . . . . . . . . . . . . . . 7
5. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Customer Edge Device (CE) . . . . . . . . . . . . . . . 8
5.1.1. Device Based CE Naming . . . . . . . . . . . . . 9
5.1.2. Service Based CE Naming . . . . . . . . . . . . 9
5.2. Provider Edge (PE) . . . . . . . . . . . . . . . . . . . 10
5.2.1. Device Based PE Naming . . . . . . . . . . . . . 10
5.2.2. Service Based PE Naming . . . . . . . . . . . . 10
5.2.3. Distribution Based PE Naming . . . . . . . . . . 11
5.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1 Provider Router (P) . . . . . . . . . . . . . . 11
5.4. Naming in Specific Internet Drafts . . . . . . . . . . . 11
5.4.1. Layer 2 PE (L2PE) . . . . . . . . . . . . . . . 11
5.4.2. Logical PE (LPE) . . . . . . . . . . . . . . . . 12
5.4.3. PE-CLE . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. PE-Core . . . . . . . . . . . . . . . . . . . . 12
5.4.5. PE-Edge . . . . . . . . . . . . . . . . . . . . 12
5.4.6. PE-POP . . . . . . . . . . . . . . . . . . . . . 12
5.4.7. VPLS Edge (VE) . . . . . . . . . . . . . . . . . 12
6. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Attachment Circuit (AC) . . . . . . . . . . . . . . . . 12
6.2. Backdoor Links . . . . . . . . . . . . . . . . . . . . . 13
6.3. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 13
6.4. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5. MAC Address Learning . . . . . . . . . . . . . . . . . . 13
6.5.1. Qualified Learning . . . . . . . . . . . . . . . 13
6.5.2. Unqualified Learning . . . . . . . . . . . . . . 13
6.6. Signalling . . . . . . . . . . . . . . . . . . . . . . . 13
7. 'Boxes' . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Aggregation Box . . . . . . . . . . . . . . . . . . . . 14
7.2. Customer Premises Equipment (CPE) . . . . . . . . . . . 14
7.3. Multi-Tenant Unit (MTU) . . . . . . . . . . . . . . . . 14
8. Packet Switched Network (PSN) . . . . . . . . . . . . . . . . 14
8.1. Route Distinguisher (RD) . . . . . . . . . . . . . . . . 15
8.2. Route Reflector . . . . . . . . . . . . . . . . . . . . 15
8.3. Route Target (RT) . . . . . . . . . . . . . . . . . . . 15
8.4. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.5. Tunnel Multiplexor . . . . . . . . . . . . . . . . . . . 16
8.6. Virtual Channel (VC) . . . . . . . . . . . . . . . . . . 16
8.7. VC Label . . . . . . . . . . . . . . . . . . . . . . . . 16
8.8. Inner Label . . . . . . . . . . . . . . . . . . . . . . 16
8.9. VPN Routing and Forwarding (VRF) . . . . . . . . . . . . 16
8.10. VPN Forwarding Instance (VFI) . . . . . . . . . . . . . 16
8.11. Virtual Switch Instance (VSI) . . . . . . . . . . . . . 17
8.12. Virtual Router (VR) . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 201. Introduction 💖
a bunch of memos went to the old PPVPN working group and the L2VPN, L3VPN, and PWE3 groups 📬. They're all tackling the same space: letting end customers have provider-provisioned virtual private networking 🌈. The services vary a lot, but the proposed solutions have lots in common ✨
That led to a partial set of new concepts for describing these VPN services 🧚. Once again, more than one term can cover the same concept, and sometimes the same term covers more than one concept 💀
So this document is basically a foundation for one unified terminology for the L2VPN and L3VPN working groups 👑. Where it helps, it uses the parallel concepts from PWE3 as references 🫶
2. PPVPN Terminology 🎀
the concepts and terms here came from Internet Drafts sent to the L2VPN and L3VPN mailing lists (and earlier, the PPVPN list) 📨, plus RFCs that matter to those working groups. The focus is on stuff that's specific to the PPVPN area, but that's not a strict rule 🙈 For example, some PWE3 and (Generalized) MPLS concepts are closely related, so they're in here too. The authors also tried to find the earliest uses of each term and concept, which is lowkey detective work 🔍
This doc is meant to fully cover the core documents from the L2VPN and L3VPN groups, which are [L3VPN-REQ], [L2VPN-REQ], [L3VPN-FRAME], [L2VPN], and [RFC3809] 📚. The goal is a comprehensive, unified set of concepts for those documents, and by extension for the whole PPVPN area 💅 To get there, it also helps to understand some of the history of how the area's concepts developed 🦋
The document is structured in four major sections 🌸. Section 4 lists the different services that have been or will be specified. Section 5 lists the building blocks used to specify those services. Section 6 lists the functions needed in those services. Section 7 lists some typical devices used in customer and provider networks 🍓
3. Provider Provisioned Virtual Private Network Services ✨
this section defines the terminology that connects the set of services to the solutions specified by the L2VPN and L3VPN working groups 🫶. The "pseudo wire" concept belongs to PWE3, but it's included here for reference 🧚 For requirements in provider provisioned VPNs, see [L3VPN-REQ].
Every term and abbreviation is listed with a short description of the service 💜 The list goes from the more general info to the more specific, and the names of services the IETF is actively working on are moved up top 🔥. Older, more dated terminology gets pushed toward the end 👵
3.1. Layer 3 VPN (L3VPN) 🌐
An L3VPN interconnects sets of hosts and routers based on Layer 3 addresses. See [L3VPN-FRAME] 🫶
3.2. Layer 2 VPN (L2VPN) 🦋
there are three types of L2VPNs described in this doc: Virtual Private Wire Service (VPWS) (Section 3.4), Virtual Private LAN Service (VPLS) (Section 3.3), and IP-only LAN-like Service (IPLS) (Section 3.5) 💖
3.3. Virtual Private LAN Service (VPLS) 🌈
a VPLS is a provider service that emulates the full functionality of a traditional Local Area Network (LAN) 🏠. It lets you connect several LAN segments over a packet switched network (PSN), and the remote LAN segments act like one single LAN. For early work on defining a solution and protocol for a VPLS, see [L2VPN-REQ], [VPLS-LDP], and [VPLS] 📚
In a VPLS, the provider network emulates a learning bridge 🌉. Forwarding decisions are made based on MAC addresses, or on MAC addresses plus the VLAN tag 💅
3.4. Virtual Private Wire Service (VPWS) 🔌
A Virtual Private Wire Service (VPWS) is a point-to-point circuit (link) that connects two Customer Edge devices ⭐. The link is set up as a logical link through a packet switched network. The CE in the customer network connects to a PE in the provider network through an Attachment Circuit (see Section 6.1), and that Attachment Circuit can be either a physical or a logical circuit 🧚
The PEs in the core network are connected via a PW 🦋
The CE devices can be routers, bridges, switches, or hosts 💻. In some implementations, a set of VPWSs gets used to build a multi-site L2VPN 🌸. An example of a VPWS solution is described in [PPVPN-L2VPN] 🍓
A VPWS is different from a VPLS (Section 3.3) because a VPLS is point-to-multipoint, while a VPWS is point-to-point. See [L2VPN] 👑
3.5. IP-Only LAN-Like Service (IPLS) 🎀
An IPLS is very like a VPLS (see Section 3.3), except for these things 🙈:
- it is assumed that the CE devices (see Section 5.1) are hosts or routers, not switches
- it is assumed that the service will only carry IP packets, plus supporting packets like ICMP and ARP (otherwise, layer 2 packets that don't contain IP aren't supported)
- the assumption that only IP packets are carried by the service applies equally to IPv4 and IPv6 packets
While this service is a functional subset of the VPLS service, it's considered separately 💜 because it may be possible to provide it using different mechanisms. That could let it run on certain hardware platforms that can't support full VPLS functionality [L2VPN] 🔥
3.6. Pseudo Wire (PW) 🦋
okay so the PWE3 working group at the IETF is the crew that specifies pseudo wire tech 🧚 a pseudo wire is an emulated point-to-point connection over a packet switched network, and it lets you interconnect two nodes using any L2 technology 💖 PWs share some of the building blocks and architecture constructs with the point-to-multipoint solutions, e.g., PE (see Section 5.2) and CE (see Section 5.1). same cast, different show ✨ an early solution for PWs is described in [TRANS-MPLS]. encapsulation formats that get used a lot in VPWS, VPLS, and PWs are described in [ENCAP-MPLS]. requirements for PWs live in [RFC3916], and [PWE3-ARCH] gives you the architectural framework for PWs 📚
3.7. Transparent LAN Service (TLS) 🌸
TLS was an early name for the VPLS service 🫶 it got replaced by VPLS, which is the current term, so that's the one to use 💅
3.8. Virtual LAN (VLAN) 🍓
the term VLAN was specified by IEEE 802.1Q, and it's a method of telling traffic apart on a LAN by tagging the Ethernet frames 🏷️ by extension, VLAN is also used to mean the traffic separated by Ethernet frame tagging or similar mechanisms 💜
3.9. Virtual Leased Line Service (VLLS) 💀
the term VLLS has been replaced by the term VPWS. VLLS showed up in a now dated document meant to create metrics for comparing different L2VPN solutions. that document has now expired, and the work was terminated 😭
3.10. Virtual Private Network (VPN) 👑
VPN is a generic term covering the use of public or private networks to create groups of users that are separated from other network users and that may communicate among them as if they were on a private network 🔐 it's possible to enhance the level of separation (e.g., by end-to-end encryption), but that's outside the scope of IETF VPN working group charters. this VPN definition is from [RFC2764].
in the [L3VPN-FRAME], the term VPN is used to refer to a specific set of sites as either an intranet or an extranet that have been configured to allow communication. note that a site is a member of at least one VPN and may be a member of many. ✨
in this document, "VPN" is also used as a generic name for all services listed in Section 3.
3.11. Virtual Private Switched Network (VPSN) 🙈
the term VPSN has been replaced by the term VPLS. its requirements have been merged into the L3VPN [L3VPN-REQ] and L2VPN [L2VPN-REQ] requirements.
4. Classification of VPNs 🌈
the terminology used in [RFC3809] is defined based on the figure below. bestie, look at this taxonomy 😭
PPVPN
________________|__________________
| |
Layer 2 Layer 3
______|_____ ______|______
| | | |
P2P P2M PE-based CE-based
(VPWS) _____|____ ______|____ |
| | | | |
VPLS IPLS BGP/MPLS Virtual IPsec
IP VPNs Router
Figure 1the figure above is a taxonomy of PPVPN technologies 🗺️ here are some of the definitions:
CE-based VPN: a VPN approach in which the shared service provider network does not have any knowledge of the customer VPN. this information is limited to CE equipment. all the VPN-specific procedures are performed in the CE devices, and the PE devices are not aware in any way that some of the traffic they are processing is VPN traffic (see also [L3VPN-FRAME]). the way that CE devices hold all the secrets 🙈
PE-Based VPNs: a Layer 3 VPN approach in which a service provider network is used to interconnect customer sites using shared resources. specifically, the PE device maintains VPN state, isolating users of one VPN from users of another. because the PE device maintains all required VPN states, the CE device may behave as if it were connected to a private network. specifically, the CE in a PE-based VPN must not require any changes or additional functionality to be connected to a PPVPN instead of a private network. main character energy for the CE, honestly 👑
the PE devices know that certain traffic is VPN traffic. they forward the traffic (through tunnels) based on the destination IP address of the packet, and optionally based on other information in the IP header of the packet. the PE devices are themselves the tunnel endpoints. the tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels) [L3VPN-FRAME] 🦋
Virtual Router (VR) style: a PE-based VPN approach in which the PE router maintains a complete logical router for each VPN that it supports. each logical router maintains a unique forwarding table and executes a unique instance of the routing protocols. these VPNs are described in [L3VPN-VR].
BGP/MPLS IP VPNs: a PE-based VPN approach in which the PE router maintains a separate forwarding environment and a separate forwarding table for each VPN. in order to maintain multiple forwarding table instances while running only a single BGP instance, BGP/MPLS IP VPNs mark route advertisements with attributes that identify their VPN context. these VPNs are based on the approach described in [RFC2547bis] 🧠
RFC 2547 Style: the term has been used by the L3VPN to describe the extensions of the VPNs defined in the informational RFC 2547 [RFC2547]. this term has now been replaced by the term BGP/MPLS IP VPNs 🫶
5. Building Blocks 🧱
starting with specifications of L3VPNs (e.g., the 2547 specification [RFC2547] and [RFC2547bis] and Virtual Routers [L3VPN-VR]), a way of describing the building blocks and allocation of functions in VPN solutions was developed. the building blocks are often used in day-to-day talk as if they were physical boxes, common for all services.
however, for different reasons, this is an oversimplification. any of the building blocks could be implemented across more than one physical box. how common the use of such implementations will be is beyond the scope of this document 🤷♀️
5.1. Customer Edge Device (CE) 🎀
a CE is the name of the device with the functionality needed on the customer premises to access the services specified by the former PPVPN working group in relation to the work done on L3VPNs [L3VPN-FRAME]. the concept has been modified; e.g., when L2VPNs and CE-based VPNs were defined. this is addressed further in the sub-sections of this section.
there are two different aspects that have to be considered in naming CE devices. one could start with the type of device that is used to implement the CE (see Section 5.1.1). it is also possible to use the service the CE provides, whereby the result will be a set of "prefixed CEs" (see Section 5.1.2).
it is common practice to use "CE" to indicate any of these boxes, as it is very often unambiguous in the specific context 💖
5.1.1. Device Based CE Naming
5.1.1.1. Customer Edge Router (CE-R)
a CE-R is a router in the customer network interfacing the provider network. there are many reasons to use a router in the customer network; e.g., in an L3VPN using private IP addressing, this is the router that is able to do forwarding based on the private addresses. another reason to require the use of a CE-R on the customer side is that one wants to limit the number of MAC-addresses that need to be learned in the provider network 🧮
a CE-R could be used to access both L2 and L3 services. 🌐
5.1.1.2. Customer Edge Switch (CE-S)
a CE-S is a service aware L2 switch in the customer network interfacing the provider network. in a VPWS or a VPLS, it is not strictly necessary to use a router in the customer network; a layer 2 switch might very well do the job 🔌
5.1.2. Service Based CE Naming
the list below contains examples of how different functionality has been used to name CEs. there are many examples of this type of naming, and we only cover the most frequently used functional names. as these are functional names, it is quite possible that on a single piece of equipment there are platforms for more than one type of function. for example, a router might at the same time be both a L2VPN-CE and a L3VPN-CE. it might also be that the functions needed for a L2VPN-CE or L3VPN-CE are distributed over more than one platform. 🧩
5.1.2.1. L3VPN-CE
an L3VPN-CE is the device or set of devices on the customer premises that attaches to a provider provisioned L3VPN; e.g., a 2547bis implementation. 🍓
5.1.2.2. VPLS-CE
a VPLS-CE is the device or set of devices on the customer premises that attaches to a provider provisioned VPLS. 🌸
5.1.2.3. VPWS-CE
a VPWS-CE is the device or set of devices on the customer premises that attaches to a provider provisioned VPWS. 🦋
5.2. Provider Edge (PE) 🌟
a PE is the name of the device or set of devices at the edge of the provider network with the functionality that is needed to interface with the customer. without further qualifications, PE is very often used for naming the devices since it is made unambiguous by the context 💅
in naming PEs there are three aspects that we need to consider: the service they support, whether the functionality needed for that service is distributed across more than one device, and the type of device they are built on. 🎯
5.2.1. Device Based PE Naming
both routers and switches may be used to implement PEs; however, the scaling properties will be radically different depending on which type of equipment is chosen. 📊
5.2.1.1. Provider Edge Router (PE-R)
a PE-R is a L3 device that participates in the PSN (see Section 8) routing and forwards packets based on the routing information. 🛣️
5.2.1.2. Provider Edge Switch (PE-S)
a PE-S is a L2 device that participates in, for example, a switched Ethernet, and takes forwarding decisions on packets based on L2 address information. 🔀
5.2.2. Service Based PE Naming
5.2.2.1. L3VPN-PE
an L3VPN-PE is a device or set of devices at the edge of the provider network interfacing the customer network, with the functionality needed for an L3VPN. 💜
5.2.2.2. VPWS-PE
a VPWS-PE is a device or set of devices at the edge of the provider network interfacing the customer network, with the functionality needed for a VPWS. 🧚
5.2.2.3. VPLS-PE
a VPLS-PE is a device or set of devices at the edge of the provider network interfacing the customer network, with the functionality needed for a VPLS. 👑
5.2.3. Distribution Based PE Naming
for scaling reasons, in the VPLS/VPWS cases it is sometimes desired to distribute the functions in the VPLS/VPWS-PE across more than one device. for example, it is feasible to allocate MAC address learning on a comparatively small and inexpensive device close to the customer site, while participation in the PSN signalling and setup of PE to PE tunnels is done by routers closer to the network core. ✨
when distributing functionality across devices, a protocol is needed to exchange information between the Network facing PE (N-PE) (see Section 5.2.3.1) and the User facing PE (U-PE) (see Section 5.2.3.2). 🫶
5.2.3.1. Network Facing PE (N-PE)
the N-PE is the device to which the signalling and control functions are allocated when a VPLS-PE is distributed across more than one box. 🌈
5.2.3.2. User Facing PE (U-PE)
the U-PE is the device to which the functions needed to take forwarding or switching decisions at the ingress of the provider network are allocated. 🎀
5.3. Core 🌈
5.3.1. Provider Router (P) 🧚
okay so the P is defined as a router in the core network that does not have interfaces directly toward a customer 🏰. Therefore, a P router does not need to keep VPN state and is VPN unaware. it's the quiet backstage crew, no VPN memories needed 🤫✨
5.4. Naming in Specific Internet Drafts 💅
5.4.1. Layer 2 PE (L2PE)
L2PE is the joint name of the devices in the provider network that implement L2 functions needed for a VPLS or a VPWS. it's the group name for the whole L2 squad 🫶
5.4.2. Logical PE (LPE)
okay this one is a little vintage 🕰️. The term Logical PE (LPE) originates from a dated Internet Draft, "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture", and was used to describe a set of devices used in a provider network to implement a VPLS. In an LPE, VPLS functions are split up across small devices (PE-Edges/U-PE) and devices attached to a network core (PE-Core/N-PE) 🧩. In an LPE solution, the PE-edge and PE-Core can be interconnected by a switched Ethernet transport network or uplinks. The LPE will appear to the core network as a single PE, so it's giving one big main character 👑. In this document, the devices that make up the LPE are called N-PE and U-PE.
5.4.3. PE-CLE
PE-CLE is an alternative name for the U-PE, suggested in the expired Internet Draft "VPLS architectures". bestie, it's an old name, so no cap, we don't really use it anymore 🙈
5.4.4. PE-Core
See the origins and use of this concept in Section 5.4.2. 🔁
5.4.5. PE-Edge
See the origins and use of this concept in Section 5.4.2. 🔁
5.4.6. PE-POP
PE-POP is an alternative name for the U-PE, suggested in the expired Internet Draft "VPLS architectures". same energy as PE-CLE, a little outdated 🍓
5.4.7. VPLS Edge (VE)
The term VE originates from a dated Internet Draft on a distributed transparent LAN service, and it was used to describe the device a provider network uses to hand off a VPLS to a customer 🎀. In this document, the VE is called a VPLS-PE. This name is dated.
6. Functions 🛠️
okay so in this section we group together a bunch of concepts and terms that have to happen to make the VPN services work. the whole crew is here ✨
6.1. Attachment Circuit (AC)
In a Layer 2 VPN, the CE is attached to the PE via an Attachment Circuit (AC). The AC may be a physical or logical link 🔗.
6.2. Backdoor Links
Backdoor Links are links between CE devices that are provided by the end customer rather than by the SP 🚪. They may be used to interconnect CE devices in multiple-homing arrangements [L3VPN-FRAME].
6.3. Endpoint Discovery
Endpoint discovery is the process by which the devices that are aware of a specific VPN service find all customer facing ports that belong to the same service 🔍.
The requirements on endpoint discovery and signalling are discussed in [L3VPN-REQ]. It was also the topic of a now dated Internet Draft reporting from a design team activity on VPN discovery 🕰️.
6.4. Flooding
Flooding is a function related to L2 services. When a PE receives a frame with an unknown destination MAC address, that frame is sent out over (flooded) every other interface 🌊. it's giving "send it everywhere and see who answers" energy.
6.5. MAC Address Learning
MAC address learning is a function related to L2 services. When a PE receives a frame with an unknown source MAC address, the relationship between that MAC address and the interface is learned for future forwarding purposes 🧠. In a layer 2 VPN solution from the L2VPN WG, this function is allocated to the VPLS-PE 💖.
6.5.1. Qualified Learning
In qualified learning, the learning decisions at the U-PE are based on the customer Ethernet frame's MAC address and VLAN tag, if a VLAN tag exists. If no VLAN tag exists, the default VLAN is assumed 🏷️.
6.5.2. Unqualified Learning
In unqualified learning, learning is based on a customer Ethernet frame's MAC address only. simple, clean, no extras 💅.
6.6. Signalling
Signalling is the process by which the PEs that have VPNs behind them exchange information to set up PWs, PSN tunnels, and tunnel multiplexers 📡. This process might be automated through a protocol or done by manual configuration. Different protocols may be used to establish the PSN tunnels and exchange the tunnel multiplexers 🤝.
7. 'Boxes' 📦
we list a set of boxes that will typically be used in an environment that supports different kinds of VPN services. We have chosen to include some names of boxes that originate outside the protocol specifying organisations, so yes, there's some outside drama in here too 🎭.
7.1. Aggregation Box
The aggregation box is typically an L2 switch that is service unaware and is used only to aggregate traffic to more function rich points in the network 🧺.
7.2. Customer Premises Equipment (CPE)
The CPE equipment is the box that a provider places with the customer 🏠. It serves two purposes: giving the customer ports to plug in to, and making it possible for a provider to monitor the connectivity to the customer site 🔌. The CPE is typically a low cost box with limited functionality and, in most cases, is not aware of the VPN services offered by the provider network. The CPE equipment is not necessarily the equipment to which the CE functions are allocated, but it is part of the provider network and is used for monitoring purposes 👀.
The CPE name is used primarily in network operation and deployment contexts and should not be used in protocol specifications 🙅♀️.
7.3. Multi-Tenant Unit (MTU)
An MTU is typically an L2 switch placed by a service provider in a building where several customers of that service provider are located 🏢. The term was introduced in an Internet Draft specifying a VPLS solution with function distributed between the MTU and the PE in the context of a [VPLS] 🧩.
The MTU device name is used primarily in network operation and deployment contexts and should not be used in protocol specifications, as it is also an abbreviation used for Maximum Transmit Units. this one is a whole trap, bestie, so be careful 🚨
8. Packet Switched Network (PSN) 🌐
A PSN is the network through which the tunnels supporting the VPN services are set up 🛣️.
8.1. Route Distinguisher (RD)
A Route Distinguisher [RFC2547bis] is an 8-byte value that, together with a 4 byte IPv4 address, identifies a VPN-IPv4 address family 🆔. If two VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN 💜. no collisions, we love to see it.
8.2. Route Reflector
A route reflector is a network element owned by a Service Provider (SP) that is used to distribute BGP routes to the SP's BGP-enabled routers [L3VPN-FRAME] 📣.
8.3. Route Target (RT)
A Route Target attribute [RFC2547bis] can be thought of as identifying a set of sites or, more precisely, a set of VRFs (see Section 8.9) 🎯.
Associating a particular Route Target with a route allows that route to be placed in all VRFs used for routing traffic received from the corresponding sites 📍.
A Route Target attribute is also a BGP extended community used in [RFC2547] and [BGP-VPN]. A Route Target community is used to constrain VPN information distribution to the set of VRFs. A route target can be perceived as identifying a set of sites or, more precisely, a set of VRFs 💖.
8.4. Tunnel
A tunnel is connectivity through a PSN that is used to send traffic across the network from one PE to another 🚇. The tunnel provides a means to transport packets from one PE to another. Separation of one customer's traffic from another customer's traffic is done based on tunnel multiplexers (see Section 8.5). How the tunnel is established depends on the tunnelling mechanisms provided by the PSN; e.g., the tunnel could be based on the IP-header, an MPLS label, the L2TP Session ID, or the GRE Key field 🧵.
8.5. Tunnel Multiplexor
A tunnel multiplexor is an entity that is sent with the packets traversing the tunnel. It makes it possible to decide which instance of a service a packet belongs to and from which sender it was received 🪪. In [PPVPN-L2VPN], the tunnel multiplexor is formatted as an MPLS label 🏷️.
8.6. Virtual Channel (VC)
A VC is transported within a tunnel and identified by its tunnel multiplexer 📮. A virtual channel is identified by a VCI (Virtual Channel Identifier). In the PPVPN context, a VCI is a VC label or tunnel multiplexer, and in the Martini case, it is equal to the VCID 🦋.
8.7. VC Label
In an MPLS-enabled IP network, a VC label is an MPLS label used to identify traffic within a tunnel that belongs to a particular VPN; i.e., the VC label is the tunnel multiplexer in networks that use MPLS labels 🔖.
8.8. Inner Label
"Inner label" is another name for VC label (see Section 8.6) 🔁.
8.9. VPN Routing and Forwarding (VRF)
In networks running 2547 VPN's [RFC2547], PE routers maintain VRFs 🗂️. A VRF is a per-site forwarding table. Every site to which the PE router is attached is associated with one of these tables. A particular packet's IP destination address is looked up in a particular VRF only if that packet has arrived directly from a site that is associated with that table 🏰.
8.10. VPN Forwarding Instance (VFI)
VPN Forwarding Instance (VFI) is a logical entity that resides in a PE that includes the router information base and forwarding information base for a VPN instance [L3VPN-FRAME] 🧠.
8.11. Virtual Switch Instance (VSI)
In a layer 2 context, a VSI is a virtual switching instance that serves one single VPLS [L2VPN]. A VSI performs standard LAN (i.e., Ethernet) bridging functions. Forwarding done by a VSI is based on MAC addresses and VLAN tags, and possibly on other relevant information on a per VPLS basis. The VSI is allocated to the VPLS-PE or, in the distributed case, to the U-PE 🔀.
8.12. Virtual Router (VR)
A Virtual Router (VR) is software and hardware based emulation of a physical router. Virtual routers have independent IP routing and forwarding tables, and they are isolated from each other; see [L3VPN-VR] 🪞✨.
9. Security Considerations 🚨
This is a terminology document, and as such it doesn't have direct security implications 🙏. Security considerations will be specific to solutions, frameworks, and specification documents whose terminology is collected and discussed in this document. so the real security drama lives in those documents, not here 😤.
10. Acknowledgements 🫶
Much of the content in this document is based on discussion in the PPVPN design teams for "auto discovery" and "l2vpn" 💌.
Dave McDysan, Adrian Farrel, and Thomas Narten have carefully reviewed the document and given many useful suggestions 🌸.
Thomas Narten converted an almost final version of this document into XML, after extracting an acceptable version from Word became too painful 💻. Avri Doria has been very helpful in guiding us in the use of XML 🧚.
11. Informative References 📚✨
okay bestie, these are the reading-list references, the stuff the spec points at for background without being required to implement it 🫶 I've kept every title, author, and date exactly as written, so you can look any of them up:
[L2VPN]Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work in Progress, June 2004. 🧚[L2VPN-REQ]Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Work in Progress, October 2004. 💅[VPLS]Kompella, K., "Virtual Private LAN Service", Work in Progress, January 2005. 🌸[VPLS-LDP]Lasserre, M. and V. Kompella, "Virtual Private LAN Services over MPLS", Work in Progress, September 2004. 🎀[BGP-VPN]Ould-Brahim, H., Rosen, E., and Y. Rekhter, "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", Work in Progress, May 2004. 🦋[L3VPN-FRAME]Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress, July 2003. 💜[RFC3809]Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. ⭐[L3VPN-REQ]Carugi, M. and D. McDysan, "Service requirements for Layer 3 Virtual Private Networks", Work in Progress, July 2004. 🍓[RFC2547bis]Rosen, E., "BGP/MPLS IP VPNs", Work in Progress, October 2004. 🔥[L3VPN-VR]Knight, P., Ould-Brahim, H. and B. Gleeson, "Network based IP VPN Architecture using Virtual Routers", Work in Progress, April 2004. 🌈[PWE3-ARCH]Bryant, S. and P. Pate, "PWE3 Architecture", Work in Progress, March 2004. 👑[RFC3916]Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. 🫶[PPVPN-L2VPN]Kompella, K., "Layer 2 VPNs Over Tunnels", Work in Progress, June 2002. 🙈[ENCAP-MPLS]Martini, L., "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", Work in Progress, September 2004. 💖[TRANS-MPLS]Martini, L. and N. El-Aawar, "Transport of Layer 2 Frames Over MPLS", Work in Progress, June 2004. ✨[RFC2547]Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. 🦋[RFC2764]Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. 💅
Authors' Addresses 🎀
these are the humans who wrote it, so you know who to thank (or blame) 😭
Loa Anderson Acreo AB
EMail: loa@pi.se
Tove Madsen Acreo AB
EMail: tove.madsen@acreo.se
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. 🫶✨
📦 where this page comes from
- ietf: rfc4026 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms