RFC 4664
Framework for Layer 2 Virtual Private Networks (L2VPNs)
RFC 4664: Framework for Layer 2 Virtual Private Networks (L2VPNs) 🎀
(Part 1 of 10)
okay bestie, let's start with the title block because it's giving important info 💅
- Stream: Network Working Group
- RFC number: 4664
- Category: Informational 📚
- Authors: L. Andersson, Ed. (Acreo AB) and E. Rosen, Ed. (Cisco Systems, Inc.) 🧚
- Date: September 2006
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🌸
Status of This Memo ✨
so this memo is giving "for your information" energy 🫶 It's not an Internet standard of any kind. It just provides info for the Internet community. And the distribution of this memo is unlimited, so share away! 🦋
Copyright Notice 🌈
Copyright (C) The Internet Society (2006).
Abstract 💜
okay so here's the tea: this document gives you a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs) 🌸 The whole point is to help folks build the protocols and mechanisms that let L2VPNs work together across different setups (aka interoperable 🫶).
Table of Contents 📖
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Objectives and Scope of the Document .......................3
1.3. Layer 2 Virtual Private Networks ...........................3
1.4. Terminology ................................................4
2. Models ..........................................................5
2.1. Reference Model for VPWS ...................................5
2.1.1. Entities in the VPWS Reference Model ................5
2.2. Reference Model for VPLS ...................................6
2.2.1. Entities in the VPLS Reference Model ................8
2.3. Reference Model for Distributed VPLS-PE or VPWS-PE .........9
2.3.1. Entities in the Distributed PE Reference Models .....9
2.4. VPWS-PE and VPLS-PE ........................................9
3. Functional Components of L2 VPN .................................9
3.1. Types of L2VPN ............................................10
3.1.1. Virtual Private Wire Service (VPWS) ................10
3.1.2. Virtual Private LAN Service (VPLS) .................10
3.1.3. IP-Only LAN-Like Service (IPLS) ....................11
3.2. Generic L2VPN Transport Functional Components .............11
3.2.1. Attachment Circuits ................................11
3.2.2. Pseudowires ........................................12
3.2.3. Forwarders .........................................14
3.2.4. Tunnels ............................................15
3.2.5. Encapsulation ......................................16
3.2.6. Pseudowire Signaling ...............................16
3.2.6.1. Point-to-Point Signaling ..................18
3.2.6.2. Point-to-Multipoint Signaling .............18
3.2.6.3. Inter-AS Considerations ...................19
3.2.7. Service Quality ....................................20
3.2.7.1. Quality of Service (QoS) ..................20
3.2.7.2. Resiliency ................................21
3.2.8. Management .........................................22
3.3. VPWS ......................................................22
3.3.1. Provisioning and Auto-Discovery ....................23
3.3.1.1. Attachment Circuit Provisioning ...........23
3.3.1.2. PW Provisioning for Arbitrary
Overlay Topologies ........................23
3.3.1.3. Colored Pools PW Provisioning Model .......25
3.3.2. Requirements on Auto-Discovery Procedures ..........27
3.3.3. Heterogeneous Pseudowires ..........................28
3.4. VPLS Emulated LANs ........................................29
3.4.1. VPLS Overlay Topologies and Forwarding .............31
3.4.2. Provisioning and Auto-Discovery ....................33
3.4.3. Distributed PE .....................................33
3.4.4. Scaling Issues in VPLS Deployment ..................36
3.5. IP-Only LAN-Like Service (IPLS) ...........................36
4. Security Considerations ........................................37
4.1. Provider Network Security Issues ..........................37
4.2. Provider-Customer Network Security Issues .................39
4.3. Customer Network Security Issues ..........................39
5. Acknowledgements ...............................................40
6. Normative References ...........................................41
7. Informative References .........................................411. Introduction ✨
1.1. Conventions Used in This Document 📝
Here's how the key words work in this doc 💖 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [RFC2119]. Those are the official vibes, so don't go freelancing with them 🙈
1.2. Objectives and Scope of the Document 🎯
okay so the goal here is pretty simple: this document is a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs) 💅 It's meant to help folks standardize protocols and mechanisms so L2VPNs can be interoperable ✨
When the doc says "provider provisioned VPNs," it means Virtual Private Networks (VPNs) where the Service Provider (SP) is part of managing and provisioning the VPN 🧚
If you want the requirements for L2VPNs, go check [RFC4665] 📚
This document gives reference models for L2VPNs and talks about their functional components 🦋 It digs into the technical stuff that matters when designing standards and mechanisms for L2VPNs, including the ones needed for interworking and security. Lowkey important! 🔐
It also covers a bunch of different technical approaches to L2VPNs. The goal is to show how they connect and what issues might make you pick one over another 🌈 But the doc does not try to pick a favourite. No winner here, bestie 💜
1.3. Layer 2 Virtual Private Networks 🌸
There are two fundamentally different kinds of Layer 2 VPN service a service provider could offer a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There's also the option of an IP-only LAN-like Service (IPLS) 🫶
A VPWS is a VPN service that gives you an L2 point-to-point service. Since it's point-to-point, the service itself has very few scaling issues 🦋 Any scaling issues would come from how many end-points a particular PE can support 💅
A VPLS is an L2 service that emulates LAN service across a Wide Area Network (WAN) 🌍 When it comes to how much state has to be kept at the edges to support forwarding, it has the scaling characteristics of a LAN. Other scaling issues might come from how many end-points a particular PE can support. (See Section 3.4.4.) 🧚
Note that VPLS uses a service with no native multicast capability to emulate a service that does have native multicast capability. So yeah, there will be scalability issues when it comes to handling multicast traffic in VPLS 😭
A VPLS service may also have longer delays and less reliable transport than a native LAN service would. The standard LAN control protocols may not have been designed for that kind of environment, so they might have scaling problems when they run there 💀
1.4. Terminology 📖
The list of technical terms used when talking about L2VPNs is in the companion document [RFC4026] 💖
2. Models 🧩
2.1. Reference Model for VPWS 🎀
Here's the VPWS reference model, shown in Figure 1 ✨
Attachment PSN Attachment
Circuits tunnel Circuits
+
+-----+ pseudo +-----+
| | wire | |
| CE1 |--+ +--| CE2 |
| | | +-----+ +-----+ +-----+ | | |
+-----+ +----|---- | | P | | ----+----+ +-----+
|VPWS\---|-----|-----|/VPWS|
| PE1 |===|=====|=====| PE2 |
| /|---|-----|-----|\\ |
+-----+ +----|---- | | | | ----|----+ +-----+
| | | +-----+ +-----+ +-----+ | | |
| CE3 |--+ +--| CE4 |
| | | |
+-----+ +-----+
Figure 12.1.1. Entities in the VPWS Reference Model 🦋
so the P, PE (VPWS-PE), and CE devices, plus the PSN tunnel, are all defined in [RFC4026] 💅 The attachment circuit and pseudowire get their own discussion in Section 3 🌸
The PE keeps it simple: it maps between the PW and the attachment circuit using only local info, meaning the PW demultiplexor and the incoming/outgoing logical/physical port. Main character PE energy, no cap 👑✨
2.2. Reference Model for VPLS 🧚
okay so this diagram is the VPLS reference model, and it's giving main character energy 💅 PE devices that are VPLS-capable create a logical interconnect, so the CE devices in one VPLS look like they're all sitting on a single bridged Ethernet 🫶 A VPLS can hold a single VLAN or multiple tagged VLANs.
The VPLS reference model is shown in Figures 2 and 3.
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ................... | +-----+
VPLS A | +----+ +----+ | VPLS A
| |VPLS| |VPLS| |
+--| PE |--Routed---| PE |-+
+----+ Backbone +----+
/ . | . \ _ /\_
+-----+ / . | . \ / \ / \ +-----+
+ CE +--+ . | . +--\ Access \----| CE |
+-----+ . +----+ . | Network | +-----+
VPLS B .....|VPLS|........ \ / VPLS B
| PE | ^ -------
+----+ |
| |
| |
+-----+ |
| CE3 | +-- Emulated LAN
+-----+
VPLS A
Figure 2
|-----Routed Backbone-----|
| (P Routers) |PSN Tunnels,
Emulated LAN | |Pseudowires
.......................................................................
. | | .
. |---------------------|----| |--------|-----------------| .
. | --------------------|--- | | -------|---------------- | .
. | VPLS Forwarder | | VPLS Forwarder | .
. | ----------|------------- | | ----------|------------- | .
..|.................................................................|..
| | Emulated LAN | | | Emulated LAN |
| | Interface | VPLS-PEs | | Interface |
| | | <----> | | |
| ----------|------------ | | ----------|------------ |
| | Bridge | | | | Bridge | |
| -|--------|---------|-- | | ---|-------|---------|- |
|--|--------|---------|----| |----|-------|---------|---|
| | | | | |
| | Access | | | Access |
| | Networks| | | Networks|
| | | | | |
| | | | | |
CE devices CE devices
Figure 3okay, so from Figure 3 we learn that in VPLS, a CE device attaches (possibly through an access network) to a "bridge" module of a VPLS-PE 🌸 Inside the VPLS-PE, that bridge module attaches through an "Emulated LAN Interface" to an Emulated LAN. Every VPLS gets its own Emulated LAN instance 🦋 Figure 3 also shows the inside of the Emulated LAN: it's made of "VPLS Forwarder" modules connected by pseudowires, and those pseudowires might be traveling through PSN tunnels over a routed backbone. iconic 🍓
A "VPLS instance" is a set of VPLS Forwarders (no more than one per PE) connected by pseudowires. simple, but so important ✨
the functionality the bridge module has to support depends on the service the SP is offering its customers, plus a bunch of details about the SP's network 🙈 At minimum, the bridge module MUST be able to learn MAC addresses and "age them out" in the standard manner. BUT, if the PE devices have backdoor connections with each other over a Layer 2 network, they may need to be full IEEE bridges ([IEEE8021D]) running a spanning tree with each other. Spelling out exactly what bridge modules need in particular situations is out of scope for this document, though 💀
this framework says each "bridge module" has a single "Emulated LAN interface". It does NOT specify how many bridge modules a VPLS-PE can contain, and it doesn't specify how many VPLS instances can attach to one bridge module over a single "Emulated LAN interface" either 🎀
so the framework is compatible with at least these three models:
- Model 1
A VPLS-PE contains a single bridge module and supports a single VPLS instance. The VPLS instance is an Emulated LAN; if that Emulated LAN contains VLANs, 802.1Q [IEEE8021Q] tagging MUST be used to indicate which packets are in which VLANs.
- Model 2
A VPLS-PE contains a single bridge module, but supports multiple VPLS instances. Each VPLS instance is thought of as a VLAN (in effect, an "Emulated VLAN"), and the set of VPLS instances are treated as a set of VLANs on a common LAN. Since each VLAN uses a separate set of PWs, there is no need for 802.1Q tagging. 🦄
- Model 3
A VPLS-PE contains an arbitrary number of bridge modules, each of which attaches to a single VPLS instance.
There may be other models as well, some of which are combinations of the 3 models above. Different models may have different characteristics, and different scopes of applicability. 🌈
Each VPLS solution SHOULD specify the model or models that it is supporting. Each solution SHOULD also specify the necessary bridge functionality that its bridge modules MUST support. 🫶
This framework does not specify the way in which bridge control protocols are used on the Emulated LANs. 🙃
2.2.1. Entities in the VPLS Reference Model 🍒
The PE (VPLS-PE) and CE devices are defined in [RFC4026].
2.3. Reference Model for Distributed VPLS-PE or VPWS-PE 🌷
VPLS-PE/VPWS-PE
Functionality . . . . . . .
. . . . . . . . . . . . .
. . . .
+----+ . +----+ +----+ . . Service .
| CE |--.--|U-PE|----|N-PE|-.---. Provider .
+----+ . +----+ +----+ . . Backbone .
. . . . . . . . . . . . .2.3.1. Entities in the Distributed PE Reference Models 🧁
A VPLS-PE or a VPWS-PE functionality may be distributed to more than one device. The device closer to the customer/user is called the User-facing PE (U-PE), and the device closer to the core network is called Network-facing PE (N-PE). 💖
For further discussion, see Section 3.4.3.
The terms "U-PE" and "N-PE" are defined in [RFC4026].
2.4. VPWS-PE and VPLS-PE 💜
the VPWS-PE and VPLS-PE are functionally very similar, bestie, because they both use forwarders to map attachment circuits to pseudowires 👯♀️ The only real difference is that a forwarder in a VPWS-PE does a one-to-one mapping between the attachment circuit and the pseudowire, while a forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that maps multiple attachment circuits to multiple pseudowires (for further discussion, see Section 3). ✨
3. Functional Components of L2 VPN 👑
this section lays out a functional model for L2VPN, which lets you break an L2VPN architecture down into its functional components 🧩 That shows the roles the different protocols and mechanisms play, so it's way easier to see the differences and similarities between the proposed L2VPN architectures. iykyk 🤓
Section 3.1 gives an overview of the different types of L2VPNs. In Section 3.2, we talk about the functional components that all the types have in common. After that, there's a section for each L2VPN service type being considered. Those later sections cover functional components that may be specific to particular L2VPN types, plus type-specific features of the generic components. 🎀
3.1. Types of L2VPN 🦋
The types of L2VPN are told apart by the characteristics of the service they offer to the customers of the Service Provider (SP). 💅
3.1.1. Virtual Private Wire Service (VPWS) 🪄
in a VPWS, each CE device gets a set of point-to-point virtual circuits.
The other end of each virtual circuit is another CE device. Frames a CE transmits on such a virtual circuit get received by the CE device at the other end-point of that circuit. Forwarding from one CE to another isn't affected by the content of the frame at all; it's fully determined by the virtual circuit the frame was sent on. So the PE acts as a virtual circuit switch. 🔥
This type of L2VPN has been around for a long time over ATM and Frame Relay backbones. Providing it over MPLS and/or IP backbones is the current topic. 🌍
Requirements for this type of L2VPN are specified in [RFC4665]. 📝
3.1.2. Virtual Private LAN Service (VPLS) 🌊
In a VPLS, each CE device has one or more LAN interfaces that lead to a "virtual backbone". 🐚
Two CEs are connected to the same virtual backbone if and only if they are members of the same VPLS instance (i.e., same VPN). When a CE transmits a frame, the PE that receives it looks at the MAC Destination Address field to figure out how to forward the frame. So the PE functions as a bridge 🌉 As Figure 3 shows, if a set of PEs support a common VPLS instance, then there's an Emulated LAN for that VPLS instance, and each of those PE bridges attaches to it (via an emulated interface). From a CE's point of view, the virtual backbone is the set of PE bridges plus the Emulated LAN they live on. Basically, to a CE device, the LAN that attaches it to the PE gets stretched transparently over the routed MPLS and/or IP backbone. slay 💖
The PE bridge function treats the Emulated LAN like any other LAN it has an interface to. Forwarding decisions are made the normal bridge way, which is based on MAC Source Address learning. 🧠
VPLS is like VPWS in that forwarding happens without any consideration of the Layer 3 header. VPLS is unlike VPWS in these ways:
- VPLS lets the PE use addressing information in a frame's L2 header to decide how to forward the frame; and
- VPLS lets a single CE/PE connection be used for transmitting frames to multiple remote CEs. In this particular respect, VPLS is more like L3VPN than VPWS. 🫧
Requirements for this type of L2VPN are specified in [RFC4665]. 📝
3.1.3. IP-Only LAN-Like Service (IPLS) 🌙
An IPLS is very like a VPLS, except that:
- the CE devices are assumed to be hosts or routers, not switches; and
- the service is assumed to only carry IP packets and supporting packets such as ICMP and ARP (in the case of IPv4) or Neighbor Discovery (in the case of IPv6). Layer 2 packets that don't contain IP are not supported. 🚫
While this service is a functional subset of the VPLS service, it gets considered separately because it may be possible to provide it using different mechanisms, which may let it run on certain hardware platforms that can't support the full VPLS functionality. 🖥️🧚
3.2. Generic L2VPN Transport Functional Components ✨
okay bestie, every type of L2VPN has to carry "frames" across the core network that connects the PEs 🌐 so basically PE1 grabs a frame from CE1, zooms it over to PE2, and then PE2 delivers it to CE2 💌. this section is all about the building blocks you need to move L2 frames around in ANY kind of L2VPN service 🎀
3.2.1. Attachment Circuits 🔌
in any type of L2VPN, a CE device gets attached to a PE device through some sort of circuit or virtual circuit. we're calling this an "Attachment Circuit" (AC) 💅 and we're using the term super generally, so an Attachment Circuit could be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, etc. 🧚 the CE device can be a router, a switch, a host, or literally just about anything the customer needs hooked up to the VPN 💖 an AC carries a frame between CE and PE, or vice versa.
setting up and maintaining the ACs is out of scope for this architecture 🙈 those procedures usually get specified as part of the spec for the specific Attachment Circuit technology, so go check there if you want the deets 📚
any given frame will traverse an AC from a CE to a PE, and then on another AC from a PE to a CE 🦋 we call the first one the frame's "ingress AC" and the second one the frame's "egress AC" 💜 and this "ingress AC" and "egress AC" stuff is relative to a specific frame. it just tells you which direction the frame is traveling while it's on that AC, nothing more, nothing less ✨
3.2.2. Pseudowires 🌸
a "Pseudowire" (PW) is a relation between two PE devices 👯 so while an AC carries a frame from CE to PE, a PW carries a frame between two PEs. we're using the term "pseudowire" in the sense of [RFC3985] 📖
setting up and maintaining the PWs is the job of the PEs 💅 the state info for a particular PW lives at the two PEs that are its endpoints, but NOT at other PEs and NOT in the backbone routers (P routers) 🙅♀️ okay that's giving very clean separation energy ✨
pseudowires can be point-to-point, multipoint-to-point, or point-to-multipoint 🌈 in this framework, point-to-point PWs are always considered bidirectional, while multipoint-to-point and point-to-multipoint PWs are always considered unidirectional 💫 multipoint-to-point PWs can only be used when the PE receiving a frame doesn't need to infer, from the PW the frame came in on, the identity of the frame's ingress AC 🧠 and point-to-multipoint PWs may be useful when frames need to be multicast 📡
procedures for setting up and maintaining point-to-multipoint PWs aren't considered in this version of the framework 🙈 so that's a later problem bestie
any given frame travels first on its ingress AC, then on a PW, and then on its egress AC 🚀
multicast frames can get replicated by a PE, so of course the info carried in multicast frames may travel on more than one PW and more than one egress AC 🔥
so with respect to a given frame, a PW may be said to associate a number of ACs 💖 if those ACs are all the same technology (like, both ATM, both Ethernet, or both Frame Relay), the PW is said to provide "homogeneous transport" 🫶 otherwise it's said to provide "heterogeneous transport" 🌀 and heterogeneous transport requires some sort of interworking function to be applied. there are at least three different approaches to interworking, and this part is lowkey my favorite 😭
- one of the CEs may perform the interworking locally. for example, if CE1 attaches to PE1 via ATM but CE2 attaches to PE2 via Ethernet, then CE1 may decide to send/receive Ethernet frames over ATM, using RFC 2684, "LLC Encapsulation for Bridged Protocols" 🎀 in that case, PE1 would need to know that it's supposed to terminate the ATM VC locally, and only send/receive Ethernet frames over the PW 🧚
- one of the PEs may perform the interworking. for example, if CE1 attaches to PE1 via ATM but CE2 attaches to PE2 via Frame Relay, PE1 may provide the "ATM/FR Service Interworking" function 🌸 this would be transparent to the CEs, and the PW would only carry Frame Relay frames 🦋
- IPLS could be used 💜 in this case, the "frames" carried by the PW are IP datagrams, and the two PEs need to cooperate in order to spoof various L2-specific procedures used by IP (see Section 3.5) 🌈
if heterogeneous PWs are used, the setup protocol must ensure that each endpoint knows the MTU of the remote AC 📏 and if the two ACs don't have the same MTU, one of the following three procedures must be carried out 👑
- the PW is not allowed to come up.
- the endpoint at the AC with the larger MTU must reduce the AC's MTU so that it's the same as the MTU of the remote AC.
- the two endpoints must agree to use a specified fragmentation/reassembly procedure.
3.2.3. Forwarders 🧭
in all types of L2VPN, a PE (say, PE1) receives a frame over an AC and forwards it over a PW to another PE (say, PE2) 💌 then PE2 forwards the frame out on another AC. simple, but so iconic 💅
the case where PE1 and PE2 are the same device is an important one to handle correctly if you want the L2VPN service to work properly 🫶 but since this case doesn't require any protocol, this document doesn't address it any further 🙈
when PE1 receives a frame on a particular AC, it must determine the PW on which the frame must be forwarded 🧠 generally this is done by considering:
- the incoming AC;
- possibly the contents of the frame's Layer2 header; and
- possibly some forwarding information that may be statically or dynamically maintained.
if dynamic or static forwarding information gets considered, that info is specific to a particular L2VPN instance (i.e., to a particular VPN) 💜
similarly, when PE2 receives a frame on a particular PW, it must determine the AC on which the frame must be forwarded 🌀 this is done by considering:
- the incoming PW;
- possibly the contents of the frame's Layer2 header; and
- possibly some forwarding information that may be statically or dynamically maintained.
and yep, if dynamic or static forwarding info gets considered, it's specific to a particular L2VPN instance (i.e., to a particular VPN) ✨
the procedures used to make the forwarding decision are known as a "forwarder" 👑 we can think of a PW as being "bound", at each of its endpoints, to a forwarder 🎀 and the forwarder in turn "binds" the PWs to ACs 🔗 different types of L2VPN have different types of forwarders, so don't expect them all to look the same 😭
for instance, a forwarder may bind a single AC to a single PW, ignoring all frame contents and using no other forwarding info 🦋 or a forwarder may bind an AC to a set of PWs and ACs, moving individual frames from AC to PW, from PW to AC, or from AC to AC by comparing info from the frame's Layer2 header to info in a forwarding database 🧚 we'll get into this in more detail below as we go through the different L2VPN types 💖
3.2.4. Tunnels 🚇
a PW is carried in a "tunnel" from PE1 to PE2 🌈 we assume an arbitrary number of PWs can be carried in a single tunnel, and the only requirement is that the PWs all terminate at PE2 🫶
we don't even require that all the PWs in the tunnel originate at PE1, since the tunnels may be multipoint-to-point tunnels 🌸 and we don't require that all PWs between the same pair of PEs travel in the same tunnel either 💫 all we require is that when a frame traveling through such a tunnel arrives at PE2, PE2 will be able to associate it with a particular PW 🎯
(sure, you can imagine tunneling techniques that only allow one PW per tunnel, but they have evident scalability problems, so we're not considering them any further 🙅♀️)
a variety of different tunneling technologies may be used for the PE-PE tunnels 🌍 all that's really required is that the tunneling technologies allow proper demultiplexing of the contained PWs 🧩 the tunnels might be MPLS LSPs, L2TP tunnels, IPsec tunnels, MPLS-in-IP tunnels, etc. 💜 generally the tunneling technology will require an encapsulation that contains a demultiplexor field, and that field is used to identify a particular PW 🔍 procedures for setting up and maintaining the tunnels are not within the scope of this framework 🙈 (but see Section 3.2.6, "Pseudowire Signaling" 📚)
if there are multiple tunnels from PE1 to PE2, it may be desirable to assign a particular PE1-PE2 PW to a particular tunnel based on some characteristics of the PW and/or the tunnel 🎀 for example, different tunnels might be associated with different QoS characteristics, and different PWs might require different QoS 💅 procedures for specifying how to assign PWs to tunnels are out of scope of the current framework 🙈
even though point-to-point PWs are bidirectional, the tunnels they travel in don't need to be bidirectional or point-to-point 🌀 for example, a point-to-point PW may travel within a unidirectional multipoint-to-point MPLS LSP 🦋
3.2.5. Encapsulation 🎁
as L2VPN packets are carried in pseudowires, standard pseudowire encapsulation formats and techniques (as specified by the IETF's PWE3 WG) should be used wherever applicable 💖 that's the move, bestie
generally the PW encapsulations will themselves be encapsulated within a tunnel encapsulation, as determined by the specification of the tunneling protocol 🧁
it may be necessary to define additional PW encapsulations to cover areas that matter for L2VPN but may not be within the scope of PWE3 🌟 heterogeneous transport may be an instance of this 🔥
3.2.6. Pseudowire Signaling 🎀
okay bestie, setting up and maintaining the PWs themselves is totally in scope for this framework 💅 That includes how the demultiplexor field values get distributed, even though, strictly speaking, the demultiplexor field belongs to the tunneling protocol and not the PW 🤓 (I know, it's a lot 😭)
The signaling for a point-to-point pseudowire MUST perform the following functions:
- Distribution of the demultiplexor. Since many PWs MAY be carried in a single tunnel, the tunneling protocol MUST assign a demultiplexor value to each PW. These demultiplexors MUST be unique with respect to a given tunnel (or, with some tunneling technologies, unique at the egress PE) 🔑. Generally, the PE that is the egress of the tunnel will select the demultiplexor values and will distribute them to the PE(s) which is (are) the ingress(es) of the tunnel. This is the essential part of the PW setup procedure ✨.
Note that, as is usually the case in tunneling architectures, the demultiplexor field belongs to the tunneling protocol, not to the protocol being tunneled. For this reason, the PW setup protocols MAY be extensions of the control protocols for setting up the tunnels 🧚.
- Selection of the Forwarder at the remote PE. The signaling protocol MUST contain enough information to enable the remote PE to select the proper forwarder to which the PW is to be bound. We can call this information the "Remote Forwarder Selector" 👑. The information that is required will depend on the type of L2VPN being provided and on the provisioning model being used (see Sections 3.3.1 and 3.4.2). The Remote Forwarder Selector MAY uniquely identify a particular Forwarder, or it MAY identify an attribute of Forwarders. In the latter case, it would select whichever Forwarder has been provisioned with that attribute 🦋.
- Supporting pseudowire emulations. To the extent that a particular PW MUST emulate the signaling of a particular Layer2 technology, the PW signaling MUST provide the necessary functions 🌈.
- Distribution of state changes. Changes in the state of an AC MAY need to be reflected in changes to the state of the PW to which the AC is bound, and vice versa. The specification as to which changes need to be reflected in what way would generally be within the province of the PWE3 WG 💜.
- Establishing pseudowire characteristics. To the extent that one or more characteristics of a PW MUST be known to and/or agreed upon by both endpoints, the signaling MUST allow for the necessary interaction 🫶.
As specified above, signaling for point-to-point PWs MUST pass enough information to allow a remote PE to properly bind a PW to a Forwarder, and to associate a particular demultiplexor value with that PW. Once the two PEs have done the proper PW/Forwarder bindings, and have agreed on the demultiplexor values, the PW MAY be considered set up 🎉. If it is necessary to negotiate further characteristics or parameters of a particular PW, or to pass status information for a particular PW, the PW MAY be identified by the demultiplexor value.
Signaling procedures for point-to-point pseudowires are most commonly point-to-point procedures that are executed by the two PW endpoints. There are, however, proposals to use point-to-multipoint signaling for setting up point-to-point pseudowires, so this is included in the framework 👀. When PWs are themselves point-to-multipoint, it is also possible to use either point-to-point signaling or point-to-multipoint signaling to set them up. This is discussed in the remainder of this section 🌸.
3.2.6.1. Point-to-Point Signaling
There are several ways to do the necessary point-to-point signaling. Among them are:
- LDP
LDP [RFC3036] extensions can be defined for pseudowire signaling. This form of signaling can be used for pseudowires that are to be carried in MPLS "tunnels", or in MPLS-in-something-else tunnels 🍓.
- L2TP
L2TP [RFC2661] can be used for pseudowire signaling, resulting in pseudowires that are carried as "sessions" within L2TP tunnels. Pseudowire-specific extensions to L2TP MAY also be needed 💖.
Other methods MAY be possible as well ✨.
It is possible to have one control connection between a pair of PEs, which is used to control many PWs 🦋.
The use of point-to-point signaling for setting up point-to-point PWs is straightforward. Multipoint-to-point PWs can also be set up by point-to-point signaling, as the remote PEs do not necessarily need to know whether the PWs are multipoint-to-point or point-to-point. In some signaling procedures, the same demultiplexor value MAY be assigned to all the remote PEs 💅.
3.2.6.2. Point-to-Multipoint Signaling
Consider the following conditions:
- It is necessary to set up a set of PWs, all of which have the same characteristics.
- It is not necessary to use the PW signaling protocol to pass PW state changes.
- For each PW in the set, the same value of the Remote Forwarder Selector can be used.
Call these the "Environmental Conditions" 🌈.
Suppose also that there is some mechanism by which, given a range of demultiplexor values, each of a set of PEs can make a unique and deterministic selection of a single value from within that range. Call this the "Demultiplexor Condition". Alternatively, suppose that one is trying to set up a multipoint-to-point PW rather than to set up a point-to-point PW. Call this the "Multipoint Condition" 🧠.
If:
- The Environmental Conditions hold; and
- Either
- the Demultiplexor Condition holds, or
- the Multipoint Condition holds,
then for a given set of PWs that terminate at egress PE1, the information that PE1 needs to send to the ingress PE(s) of each pseudowire in the set is exactly the same. All the ingress PE(s) receive the same Forwarder Selector value. They all receive the same set of PW parameters (if any). And either they all receive the same demultiplexor value (if the PW is multipoint-to-point) or they all receive a range of demultiplexor values from which each can choose a unique demultiplexor value for itself 🫧.
Rather than connect to each ingress PE and replicate the same information, it MAY make sense either to multicast the information, or to send the information once to a "reflector", which will then take responsibility for distributing the information to the other PEs 📡.
We refer to this sort of technique as "point-to-multipoint" signaling. It would, for example, be possible to use BGP [RFC1771] to do the signaling, with PEs that are BGP peers not of each other, but of one or more BGP route reflectors [RFC2796] 🌟.
3.2.6.3. Inter-AS Considerations
Pseudowires MAY need to run from a PE in one Service Provider's network to a PE in another Service Provider's network. This has the following implications 🌍:
- The signaling protocol that sets up the PWs MUST be able to cross network boundaries. Of course, all IP-based protocols have this capability.
- The two PEs at the PW endpoints MUST be addressable and routable from each other.
- The signaling protocol needs to allow each PW endpoint to authenticate the other. To make use of the authentication capability, there would also need to be some method of key distribution that is acceptable to both administrations 🔐.
3.2.7. Service Quality 💎
Service Quality refers to the ability for the network to deliver a Service level Specification (SLS) for service attributes such as protection, security, and Quality of Service (QoS). The service quality provided depends on the subscriber's requirements and can be characterized by a number of performance metrics 📊.
The necessary Service Quality MUST be provided on the ACs, as well as on the PWs. Mechanisms for providing Service Quality on the PWs MAY be PW-specific or tunnel-specific; in the latter case, the assignment of a PW to a tunnel MAY depend on the Service Quality 🎀.
3.2.7.1. Quality of Service (QoS)
QoS describes the queuing behavior applied to a particular "flow", in order to achieve particular goals of precedence, throughput, delay, jitter, etc. 🏃♀️
Based on the customer Service Level Agreement (SLA), traffic from a customer can be prioritized, policed, and shaped for QoS requirements. The queuing and forwarding policies can preserve the packet order and QoS parameters of customer traffic. The class of services can be mapped from information in the customer frames, or it can be independent of the frame content 💜.
QoS functions can be listed as follows:
- Customer Traffic Prioritization: L2VPN services could be best effort or QoS guaranteed. Traffic from one customer might need to be prioritized over others when sharing same network resources. This requires capabilities within the L2VPN solution to classify and mark priority to QoS guaranteed customer traffic 👑.
- Proper queuing behavior would be needed at the egress AC, and possibly within the backbone network as well. If queuing behavior must be controlled within the backbone network, the control might be based on CoS information in the MPLS or IP header, or it might be achieved by nesting particular tunnels within particular traffic engineering tunnels 🛤️.
⚠️ Note: the sentence above says "must" in the original, so it is a MUST: if queuing behavior MUST be controlled within the backbone network, the control MAY be based on CoS information in the MPLS or IP header, or it MAY be achieved by nesting particular tunnels within particular traffic engineering tunnels.
- Policing: This ensures that a user of L2VPN services uses network resources within the limits of the agreed SLA. Any excess L2VPN traffic can be rejected or handled differently based on provider policy 🚦.
- Policing would generally be applied at the ingress AC.
- Shaping: Under some cases, the random nature of L2VPN traffic might lead to sub-optimal utilization of network resources. Through queuing and forwarding mechanisms, the traffic can be shaped without altering the packet order 🌊.
- Shaping would generally be applied at the ingress AC.
3.2.7.2. Resiliency ✨
okay so resiliency is basically the L2VPN's ability to keep a flow alive when something breaks 🛟 the whole point is that service stays up even when the network has a bad day 💖
L2VPN is just like any other service and can totally face failures: link failures, trunk failures, node failures 😭 these can happen in the SP's core network or out on the ACs
ideally the failure gets spotted immediately and protection kicks in fast enough that the L2VPN feels almost seamless to the customer 🦋 the restoration should happen before the CEs even notice something is wrong. the big pieces that make resiliency work are:
- Link/Node failure detection: the L2VPN mechanisms should catch link or node failures that affect the service, and they should catch them right away 👀
- Resiliency policy: how a detected failure gets handled depends on the restoration policy in the SLA for that L2VPN service 📜 it might need an immediate fix, or it might only get fixed if no other critical failure needs the protection resources, or it might be totally ignored if it fits inside the "acceptable downtime" the L2VPN service allows 🙈
- Restoration Mechanisms: L2VPN solutions can offer physical level protection, logical level protection, or both 🌈 for example, a customer can connect over redundant, physically separate ACs to different provider customer-facing devices. one AC stays active and the other is marked as a backup. when the primary AC fails, the backup can step up and become active 💅
to be honest, resiliency is mostly about having solid failure and recovery mechanisms in the network core 🧚 that means "ordinary" adaptive routing and also "fast reroute" capabilities. having redundant ACs between CEs and PEs also plays a part 🫶
3.2.8. Management 🛠️
an L2VPN solution can give you tools to manage and monitor its different components 👩💻 from a Service Level Agreement (SLA) point of view, L2VPN solutions can let you monitor the service characteristics and offer mechanisms that SPs use to report that monitored statistical data 📊 troubleshooting and verifying the operational and maintenance activities of L2VPN services are essential requirements for Service Providers, so this really matters 💀✨
3.3. VPWS 🎀
a VPWS is an L2VPN service where each forwarder binds exactly one AC to exactly one PW 💜 frames that come in on the AC get sent out on the PW, and frames that come in on the PW get sent out on the AC 🦋 the Layer2 header contents don't factor into the forwarding decision, except that the header can be used to match a frame to a particular AC (like how the DLCI field of a Frame Relay frame identifies the AC) 🧠
a particular combo of <AC, PW, AC> forms a "virtual circuit" between two CE devices 🔗
a particular VPN (VPWS instance) can be thought of as a bunch of these virtual circuits, or as an "overlay" of PWs on top of the MPLS or IP backbone 🌸 that makes an overlay topology that's basically the "virtual backbone" of that VPN 👑
whether two virtual circuits belong to the same VPN is an administrative matter, based on the agreements between the SPs and their customers 📝 this can affect the provisioning model (more on that below). it can also affect how particular PWs get assigned to tunnels, how QoS gets assigned to particular ACs and PWs, and so on ✨
note that VPWS uses point-to-point PWs exclusively 🫶
3.3.1. Provisioning and Auto-Discovery 🧚
provisioning a VPWS comes down to three things:
- Provisioning the ACs;
- Providing the PEs with the necessary information so they can set up PWs between ACs and get the overlay topology you want; and
- Configuring the PWs with any necessary characteristics.
3.3.1.1. Attachment Circuit Provisioning 💖
in lots of cases, the ACs have to be provisioned individually on the PE and/or CE 😤 this is definitely true if the CE/PE attachment technology is a switched network, like ATM or FR, and the VCs are PVCs instead of SVCs. it's also true whenever individual ACs need specific parameters (like QoS parameters or guaranteed bandwidth) that are different from circuit to circuit.
but there are also cases where ACs don't need to be individually provisioned 🙌 for example, if an AC is just an MPLS LSP running between a CE and a PE, it can be set up as the RESULT of setting up a PW, instead of having to be provisioned BEFORE the PW can be set up. the same can apply whenever the AC is any kind of Switched Virtual Circuit, though in that case you might need to provision some policy controls, like limiting how many ACs can be set up between a given CE and a given PE 🚦
whether ACs need individual provisioning, whether they're Switched or Permanent VCs, and what kinds of policy controls get applied are implementation and deployment issues, and they're considered out of scope for this framework 🙅♀️
3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies 🦋
to support arbitrary overlay topologies, you need to be able to provision individual PWs 💅 in this model, when a PW gets provisioned on a PE device, it's locally bound to a specific AC. it's also provisioned with info that identifies a specific AC at a remote PE 🌈
there are basically two versions of this provisioning model:
- Two-sided provisioning
with two-sided provisioning, each PE at the end of a PW gets provisioned with:
- the identifier of the Local AC the PW is bound to
- the PW type and parameters
- the IP address of the remote PE (the one that'll be at the far end of the PW)
- an identifier that means something to the remote PE and can be passed in the PW signaling protocol so the remote PE can bind the PW to the right AC 🎯 this can be an identifier of the PW or an identifier of the remote AC. if you use a PW identifier, it must be unique at each of the two PEs. if you use an AC identifier, it only needs to be unique at the remote PE.
this identifier then gets used as the Remote Forwarder Selector when signaling happens (see 3.2.6.1) 🔁
- Single-sided provisioning
with single-sided provisioning, a PE at one end of a PW gets provisioned with:
- the identifier of the Local AC the PW is bound to
- the PW type and parameters
- the globally unique identifier of the remote AC 🌍
this identifier then gets used as the Forwarder Selector when signaling happens (see section 3.2.6.1) ✨
in this model, the IP address of the remote PE is NOT provisioned 🙅♀️ instead, the assumption is that an auto-discovery scheme will map the globally unique identifier to the IP address of the remote PE, along with an identifier (maybe only unique at that latter PE) for an AC at that PE 🧭 then the PW signaling protocol can connect to the remote PE and pass along the AC identifier, so the remote PE binds the PW to the right AC 🫶
this scheme only requires provisioning the PW at one PE, but it doesn't get rid of the need (if there is one) to provision the ACs at both PEs 💀
these provisioning models fit really well with point-to-point signaling 💜 when each PW is individually provisioned, the conditions needed to use point-to-multipoint signaling just don't hold up 🙈
3.3.1.3. Colored Pools PW Provisioning Model 🎀
okay so bestie, picture this: at each PE, you gather ACs into "pools" 🫧 and every pool gets a "color" 🌈. For example, a pool could hold all and only the ACs from this PE to one particular CE. Now here's the golden rule 👑: whenever PE1 and PE2 have a pool of the same color, there will be a PW between them. That PW is bound at PE1 to an arbitrarily chosen AC from that pool, and at PE2 to an arbitrarily chosen AC from that pool too. And yes, a single PE can totally have multiple pools of one color 💅
Each pool at a PE could represent a specific CE device, with the ACs in that pool being the ones connecting that CE to that PE. The color could be a VPN-id 💜. Run this model and you get a full CE-to-CE mesh within the VPN, where every CE has a virtual circuit to every other CE in the VPN. Iconic, honestly 🦋
So to provision VPWS with this model, you set up a bunch of pools and configure each one with:
- The set of ACs that belong to the pool (no AC can be in more than one pool 🙅♀️)
- The color
- A pool identifier that is unique at least relative to the color
Then an auto-discovery procedure maps each color into a list of ordered pairs <IP address of PE, pool id>. If the pair <X, Y> shows up on that list, it means the PE at IP address X has a pool with pool id Y, and that pool is the specified color 🧚
There are a couple of signaling techniques that can use this info. The first one goes like this:
- A PE notices it has a pool of color C.
- Using auto-discovery, it grabs the set of ordered pairs
<X, Y>for color C. - For each such pair
<X, Y>, it:- removes an AC from the pool;
- binds that AC to a particular PW; and
- signals PE X via point-to-point signaling that the PW is to be bound to an AC from pool Y.
The second technique is a bit different, and honestly kind of clever ✨
- A PE notices it has a pool of color C, containing n ACs.
- It binds each AC to a PW, which creates a set of PWs. That set then gets organized into a sequence. (For instance, each PW might be associated with a demultiplexor field value, and the PWs can be sequenced by the numerical value of their demultiplexors 🔢)
- Using auto-discovery, it gets the list of PE routers that have one or more pools of color C.
- It signals each of those PE routers, specifying the sequence Q of PWs.
- If PE X gets that signal and PE X has a pool Y of the specified color, it:
- removes an AC from the pool; and
- binds the AC to the PW that is the "Yth" PW in the sequence Q.
Now, this does presume that the pool identifiers are, or can be, uniquely mapped into small ordinal numbers. Assigning pool identifiers that way becomes a requirement of the provisioning system, so plan ahead, bestie 📋
Also, since this second technique signals the same information to all the remote PEs, it can be supported via point-to-multipoint signaling 📡
This provisioning model can be used as long as all of these conditions hold:
- There is no need to provision different characteristics for the different PWs.
- It makes no difference which pairs of ACs get bound together by PWs, as long as both ACs in each pair come from like-colored pools; and
- It's possible to build the overlay topology you want just by assigning colors to the pools. (This is totally simple for a full mesh or a hub and spoke setup 🌸 But arbitrary topologies are less simple, and honestly might not always be possible 🙈)
3.3.2. Requirements on Auto-Discovery Procedures 🔍
Some of the requirements for auto-discovery procedures can be figured out from everything above.
To support the single-sided provisioning model, auto-discovery must be able to map a globally unique identifier (of a PW or of an Attachment Circuit) to an IP address of a PE.
To support the colored pools provisioning model, auto-discovery must enable a PE to determine the set of other PEs that contain pools of the same color.
These requirements let the auto-discovery scheme provide the info the PEs need to set up the PWs 🫶
There are also additional requirements on auto-discovery procedures that can't just be deduced from the provisioning model, so pay attention here:
- Particular signaling schemes may require additional information before they can proceed, and hence may impose additional requirements on the auto-discovery procedures.
- A given Service Provider may support several different types of signaling procedures, so the PEs may need to learn, via auto-discovery, which signaling procedures to use.
- Changes in the configuration of a PE should be reflected by the auto-discovery procedures in a timely manner, and without the need to explicitly reconfigure any other PE ⏱️
- The auto-configuration procedures must work across service provider boundaries. This rules out, for example, schemes that piggyback the auto-discovery information on the backbone's IGP 🚫
3.3.3. Heterogeneous Pseudowires 🦄
Sometimes it might be desirable to have a PW that binds two ACs using different technologies (say, one is ATM and one is Ethernet). There are a bunch of different ways to do this, depending on the AC types. For example:
- If one AC is ATM and one is FR, then standard ATM/FR Network Interworking can be used. In this case, the PW might be signaled for ATM, and the Interworking function happens between the PW and the FR AC 💫
- A common encapsulation can be used on both ACs. For example, if one AC is Ethernet and one is FR, an "Ethernet over FR" encapsulation can be used on the latter. In this case, the PW could be signaled for Ethernet, with the processing of the Ethernet over FR encapsulation staying local to the PE with the FR AC 🎁
- If it's known that the two ACs attach to IP routers or hosts and carry only IP traffic, then you could use a PW that carries the IP packets, and the respective Layer2 encapsulations would be local matters for the two PEs. However, if one of the ACs is a LAN and one is a point-to-point link, care would have to be taken to make sure procedures such as ARP and Inverse ARP are properly handled. This might require some signaling and some proxy functions 😵💫 Further, if the CEs use a routing algorithm with different procedures for LAN interfaces than for point-to-point interfaces, additional mechanisms may be required to ensure proper interworking 🔥
3.4. VPLS Emulated LANs 🎀
Okay bestie, so a VPLS is an L2VPN service where:
- the ACs attach CE devices to PE bridge modules; and
- each PE bridge module is attached via an "emulated LAN interface" to an "emulated LAN".
That's the whole setup, and you can see it in Figure 3 🦋
In this section we're going to break the VPLS Emulated LAN down into its functional pieces 🧩 An Emulated LAN's ACs are the "emulated LAN interfaces" that hook PE bridge modules up to the "VPLS Forwarder" modules (see Figure 3). The payload on the ACs is ethernet frames, with or without VLAN headers. Literally just ethernet, no cap 💅
A given VPLS Forwarder in a given PE only gets multiple ACs if there are multiple bridge modules in that PE attached to that Forwarder. This scenario is included in the Framework, but talking about whether it's useful is out of scope 🙈
Now, the set of VPLS Forwarders inside one VPLS are connected to each other via PWs. Two VPLS Forwarders only get a PW between them if they're part of the same VPLS. (There may be an extra restriction too: two VPLS Forwarders only get a PW between them if they belong to the same VLAN in the same VPN. Iykyk 👑) A particular set of interconnected VPLS Forwarders is what makes up a VPLS Emulated LAN ✨
Here's where it gets iconic 🔥 On a real LAN, any frame one entity sends gets received by all the others. A VPLS Emulated LAN, though, acts a little differently 🙃 When a VPLS Forwarder receives a unicast frame over one of its Emulated LAN interfaces, it does not necessarily send that frame to all the other Forwarders on that Emulated LAN. A unicast frame only needs to go to one other Forwarder to actually reach its destination MAC address. So if the transmitting Forwarder knows which other Forwarder needs that particular unicast frame, it sends the frame to just that one Forwarder. This forwarding optimization is a huge deal for any attempt to provide a VPLS service over a wide-area or metropolitan area network 🌍💜
So effectively, each Forwarder acts like a "Virtual Switch Instance" (VSI) 🧚 It keeps a forwarding table that maps MAC addresses to PWs. The VSI gets populated in pretty much the same way a standard bridge fills up its forwarding table. The VPLS Forwarders do MAC Source Address (SA) learning on frames they receive on PWs from other Forwarders, and they also have to do the related procedures, like aging out address entries. Frames with unknown DAs or multicast DAs have to be "broadcast" by one Forwarder to all the others (on the same emulated LAN). That said, there are a few important differences between the VPLS Forwarder VSI and the standard bridge forwarding function, so pay attention 👀
- A VPLS Forwarder never learns the MAC SAs of frames it receives on its ACs. It only learns the MAC SAs of frames received on PWs from other VPLS Forwarders; and
- The VPLS Forwarders of a particular emulated LAN do not take part in a spanning tree protocol with each other. Instead, a "split horizon" technique is used to prevent forwarding loops.
We'll dig into these points in the next section 💅
Note that the PE bridge modules on a given Emulated LAN may or may not run a spanning tree protocol with each other over the Emulated LAN. Whether they do is outside the scope of the VPLS specifications, so that's not on us 🙌 The PE bridge modules do MAC address learning on the ACs. They also do MAC address learning on the Emulated LAN interfaces, but they do not do MAC address learning on the PWs, because the PWs are "hidden" behind the Emulated LAN interface 🫶 Conceptually, the PE bridge module's forwarding table and the VPLS Forwarder's VSI are two distinct entities. (Of course, particular implementations might combine these into a single table, but that's beyond the scope of this document 🤷♀️)
Here's another thing to think about. If the PE bridges run bridge control protocols with each other over the Emulated LAN, things get a little spicy 🌶️ Bridge control protocols are generally designed to run over a real LAN, and they may assume certain LAN characteristics to work properly, like low latency and sequential delivery. If the Emulated LAN doesn't provide those characteristics, the control protocols may not perform as expected, unless special mechanisms are provided for carrying the control frames 😭
Also, changes in the spanning tree (if any) of a customer network, or in the spanning tree (if any) of the PE bridges, may cause certain MAC addresses to move their location from one PE to another. These changes may not be visible to the VPLS Forwarders, which means those MAC addresses might stay unreachable until they're aged out of the first PE's VSI. If that's not acceptable, some mechanism for communicating such changes to the VPLS Forwarders must be provided 🚨
3.4.1. VPLS Overlay Topologies and Forwarding 🌸
Within a single VPLS, the VPLS Forwarders are interconnected by PWs. The set of PWs thus forms an "overlay topology" 🕸️
The VPLS Forwarder VSIs get populated by means of MAC address learning. In other words, the VSI keeps track of which MAC SAs have been received over which PWs. The presumption, of course, is that if a particular MAC address shows up as the SA of a frame received over a particular PW, then frames carrying that MAC address in the DA field should be sent to the VSI at the remote end of that PW. For this presumption to actually hold, there must be a unique VSI at the remote end of the PW. That means VSIs cannot be interconnected by means of multipoint-to-point PWs. The PWs are necessarily either point-to-point or, possibly, point-to-multipoint 💖
MAC learning over a point-to-point PW is done via the standard techniques specified by IEEE, where the VPLS Forwarder treats the PW as a "bridge port" ✨ Of course, if a MAC address is learned from a point-to-multipoint PW, the VSI must indicate that packets to that address are to be sent over a point-to-point PW that leads to the root of that point-to-multipoint PW 🌈
The VSI forwarding decisions must be coordinated so that loop-free forwarding over the overlay topology is ensured. Very important, very serious 🥹
There are several possible types of overlay topologies:
- Full mesh
In a full mesh, every VSI in a given VPLS has exactly one point-to-point PW to every other VSI in that same VPLS.
In this topology, loop free forwarding of frames is ensured by the following rule: if a VSI receives a frame over a PW from another VSI, it MUST NOT forward that frame over ANY other PW to any other VSI. This ensures that once a frame traverses the Emulated LAN, it must be sent off the Emulated LAN. Rule of the mesh, periodt 🛑
If a VSI receives a unicast frame with a known DA on one of its Emulated LAN interfaces, the frame is sent on exactly one point-to-point PW.
If a VSI receives a multicast frame, or a unicast frame with an unknown DA, on one of its Emulated LAN interfaces, it sends a copy of the frame to each other VSI in the same Emulated LAN. This can be done by replicating the frame and sending a copy over each point-to-point PW. Alternatively, the full mesh of point-to-point PWs may be augmented with point-to-multipoint PWs, where each VSI in a VPLS is the transmitter on a single point-to-multipoint PW, and the receivers on that PW are all the other VSIs in that VPLS 🦋
- Tree structured
In a tree structured topology, every VSI in a particular VPLS is provisioned to be at a particular level in the tree. A given VSI has at most one pseudowire leading to a higher level. The root of the tree is considered the highest level 🌳
In this topology, loop free forwarding of frames is ensured by the following rule: if a frame is received over a pseudowire from a higher level, it may not be sent over a pseudowire that leads to a higher level. Simple, clean, iconic 💅
- Tree with Meshed Highest Level
In this variant of the tree-structured topology, there may be more than one VSI at the highest level, but the set of VSIs at the highest level must be fully meshed. To ensure loop free forwarding, we need to impose the rule that a frame can be sent on a pseudowire to the same or higher level only if it arrived over a pseudowire from a lower level. Frames arriving over PWs from the same level cannot be sent on PWs to the same level either 🍓
Other overlay topologies are also possible, e.g., an arbitrary partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could then be assured by, for example, running a spanning tree on the overlay. These topologies are not further considered in this framework, so we're leaving them alone for now 🧚
Note that loop freedom in the overlay topology does not necessarily ensure loop freedom in the overall customer LAN that contains the VPLS. It doesn't even ensure loop freedom among the PE bridge modules! What it does ensure is only that when a frame is sent on the Emulated LAN, the frame will not loop endlessly before (or instead of) leaving the Emulated LAN 🔁
Improper configuration of the customer LAN or PE bridge modules may cause frames to loop, and frames that fall into such loops may transit the overlay topology multiple times. Procedures that enable the PE to detect and/or prevent such loops may be advisable. Be careful out there, bestie 🚨
3.4.2. Provisioning and Auto-Discovery 🎀
Each VPLS must be assigned a globally unique identifier. This can be thought of as a VPN-id 🪪
The ACs attaching the CEs to the PEs must be provisioned on both the PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, and the local ACs of that VPLS must be associated with that VSI. The VSI must be provisioned with the identifier of the VPLS to which it belongs ✨
An auto-discovery scheme may be used by a PE to map a VPLS identifier into the set of remote PEs that have VSIs in that VPLS. Once this set is determined, the PE can use pseudowire signaling to set up a PW to each of those VSIs. The VPLS identifier would serve as the signaling protocol's Forwarder Selector. This would result in a full mesh of PWs among the VSIs in a particular VPLS 💖
If a single VPLS contains multiple VLANs, then it may be desirable to limit connectivity so that two VSIs are connected only if they have a VLAN in common 🌷
In this case, each VSI would need to be provisioned with one or more VLAN ids, and the auto-discovery scheme would need to map a VPLS identifier into pairs of <PE, VLAN id>. Ngl that's a lot of bookkeeping 📚
If a fully meshed topology of VSIs is not desired, then each VSI needs to be provisioned with additional information specifying its placement in the topology. This information would also need to be provided by the auto-discovery scheme 🗺️
Alternatively, the single-sided provisioning method discussed in Section 3.3.1.2 could be used. As this is more complicated, it would only be used if it were necessary to associate individual PWs with individual characteristics. For example, if different guaranteed bandwidths were needed between different pairs of sites within a VPLS, the PWs would have to be provisioned individually 🌟
3.4.3. Distributed PE 💖
Okay so, with VPLS the CE devices (the customer boxes) often plug into a provider-managed CPE device 📦. That one can serve CEs from several customers, especially when a few customers share the same building 🏢. Here's the tea: it's really part of the SP's network, so it may be considered a PE device ✨.
Sometimes the CE devices plug into a provider-managed intermediary device instead 🧚. It can also serve CEs from multiple customers in the same building. It's part of the SP's network too, so it may count as a PE device. In the simplest case, though, it's only doing aggregation and none of the VPLS stuff 💅.
For VPLS, there are three different possibilities for how to allocate functions to a device in that spot in the provider network 👑:
- It can do aggregation and pure Layer2 service only. Then it doesn't really play the role of a PE device in a VPLS service 🌸. The intermediary system has to connect to devices that do the VPLS PE functionality. The intermediary device itself isn't part of the VPLS architecture, so it hasn't been named in this architecture.
- It can do all the PE functions that matter for a VPLS. In that case, the device is called a VPLS-PE, see [RFC4026] 🔥. This type of device connects to the core (P) routers.
The PE functionality for a VPLS can be split between two devices 🦋. There's a "low-end" one closer to the customer that does things like MAC-address learning and forwarding decisions. Then there's a "high-end" one that handles the control functions, like setting up tunnels, PWs, and VCs. We call the low-end device the User-Facing PE (U-PE), and the high-end device the Network-Facing PE (N-PE) 🎀.
It's totally possible for the U-PE to sit really close to the customer, like in a building with more than one customer 🏢. The N-PE will presumably live on the SP's premises.
The distributed setup is potentially interesting for a few reasons 🤔:
- The N-PE might be a device that can't easily do the VSI functionality described above. Maybe it's a router that can't do the high-speed MAC learning needed to implement a VSI forwarder 💀. At the same time, the U-PE might need to be a low-cost device that can't do the full set of VPLS functions either.
This makes you want to dig into whether there are sensible ways to split the VPLS PE functionality between the U-PE and the N-PE 🧐.
- In the L2VPN architecture, PEs are expected to take part as peers in the backbone routing protocol. There are potentially way more U-PEs than N-PEs, so this could be undesirable when it comes to scaling the backbone routing protocol 📈.
- The U-PE might be a pretty cheap device that can't take part in the full range of signaling and/or auto-discovery procedures needed to provide the VPLS service 🥺.
The VPLS functionality can be split between U-PE and N-PE in a bunch of different ways, and a number of different proposals have been made 🌈. They all assume the U-PE will maintain a VSI forwarder, connected by PWs to the remote VSIs. So the N-PE doesn't need to do the VSI forwarding function. The proposals tend to differ on these questions 🫶:
- Should the U-PEs perform full PW signaling to set up the PWs to remote VSIs, or should the N-PEs do this signaling?
Since U-PEs need to send packets on PWs to remote VSIs and receive packets on PWs from remote VSIs, if the N-PE does the PW signaling there'd have to be some form of "lightweight" (presumably) signaling between N-PE and U-PE. That's what lets the PWs be extended from N-PE to U-PE ✨.
- Should the U-PEs do their own auto-discovery, or should the N-PEs handle it?
If the N-PEs do it, the U-PEs may need some way to tell the N-PEs which VPLSes they're interested in. The N-PEs also need some way to pass the results of the auto-discovery process down to the U-PE 📬.
Whether it makes sense to split auto-discovery like this might depend on which auto-discovery protocol is used. You wouldn't really expect U-PEs to participate in a BGP-based auto-discovery scheme 🙈. But they might be expected to participate in a RADIUS-based one 👀.
- If a U-PE doesn't participate in routing but is redundantly connected to two different N-PEs, can the U-PE still make a smart choice about which N-PE to use as the "next hop" for traffic going to a particular remote VSI? If not, can that choice come from some other kind of interaction between N-PE and U-PE? Or does it have to be set by provisioning? 🤷♀️
- If a U-PE doesn't participate in routing but does participate in full PW signaling, and MPLS is being used, how can an N-PE send the U-PE the labels it needs to send traffic to its signaling peers? If the U-PE did participate in routing, this would happen automatically 🧠.
- When a frame has to be multicast, should the replication be done by the N-PE or the U-PE? 🪩
These questions aren't all independent. How you answer some of them can influence how you answer others 💜.
3.4.4. Scaling Issues in VPLS Deployment 📈
In general, the PSN supports a VPLS solution with a tunnel from each VPLS-PE to every other VPLS-PE in the same VPLS instance 🛣️. Strictly speaking, VPLS-PEs that have more than one VPLS instance in common only need one tunnel. But for resource allocation reasons, it might be necessary to set up several tunnels.
For each VPLS service on a given VPLS-PE, it needs to set up one pseudowire to every other VPLS-PE in that VPLS service. In total, n*(n-1) pseudowires must be set up between the VPLS-PE routers. In a large-scale deployment, this obviously creates scaling problems 😭. One way to address the scaling problems is to use hierarchy 🪜.
3.5. IP-Only LAN-Like Service (IPLS) 🌷
If, instead of a general VPLS service, you only want a VPLS that connects IP routers or hosts (so the CE devices are all assumed to be IP routers or hosts), then you can make some simplifications 💖.
In this setup, all Ethernet frames sent from a particular CE to a particular PE on a particular Attachment Circuit have the same MAC Source Address. So instead of using data-plane address learning to learn the MAC addresses, the PE can use the control plane to learn them. This means the PE can be implemented on devices that can't do MAC address learning in the data plane 🙌.
To get rid of the need for MAC address learning on the PWs as well as on the ACs, the pseudowire signaling protocol would have to carry the MAC address from one pseudowire endpoint to the other. For IPv4, each PE would perform proxy ARP to its directly attached CEs. For IPv6, each PE would send proxy Neighbor and/or Router Advertisements 🦋.
Getting rid of MAC address learning on the PWs also gets rid of the need for the PWs to be point-to-point. Multipoint-to-point PWs could be used instead ✨.
Unlike a VPLS, not all the ACs in an IPLS have to carry Ethernet frames. Only the IP packets need to be passed across the network, not their Layer 2 wrappers 🎁. But if there are protocols that are specific to Layer 2 and that provide things like address resolution services for Layer 3, it may then be necessary to "translate" (or otherwise interwork) one of those Layer 2 protocols to the other 🔁. For example, if an IPLS instance has an ethernet AC and a Frame Relay AC, and IPv4 is running on both, interworking between ARP and Inverse ARP might be required.
The set of routing protocols that could be carried across the IPLS might also be restricted 🚧.
An IPLS instance must have a particular IPLS-wide MTU. If there are different kinds of AC in an IPLS instance, and those kinds support different MTUs, all ACs must enforce the IPLS-wide MTU. An AC that can't do this must not be allowed to join the IPLS instance 🚫.
4. Security Considerations 🔐
The security considerations section of the L2VPN requirements document [RFC4665] covers a number of areas that could be insecure aspects of the L2VPN 😱. These relate to both control plane and data plane security issues that may come up in the following areas:
- issues fully contained in the provider network
- issues fully contained in the customer network
- issues in the customer-provider interface network
These three areas are addressed below 🫶.
4.1. Provider Network Security Issues ✨
Okay bestie, this part is all about the security stuff that only the SP's own equipment has to worry about 🫶 It's giving drama, so let's go 💀
The control connections between PEs are the ones used on a PE-PE basis to set up and maintain the pseudowires, and they have their own security issues 🔐
A PE should not get into a control connection with another PE unless it has some confidence that the peer is really a PE it should be setting up PWs with. Otherwise, L2PVN traffic may end up in the wrong place 😭 If control packets get maliciously and undetectably altered while in flight, you could get denial of service, or the quality of service could change from what's expected 💀
If peers discover each other dynamically (through some auto-discovery procedure), that presupposes the auto-discovery procedures are themselves adequately trusted 🔍
PEs should not accept control connections from arbitrary entities 🙅♀️ A PE either should be configured with its peers or should learn them from a trusted auto-configuration procedure. If the peer is required to be within the same SP's network, then access control filters at the borders of that network can be used to prevent spoofing of the peer's source address. If the peer is from another SP's network, then setting up such filters may be difficult or even impossible, depending on the way in which the two SPs are connected. Even if the access filters can be set up, the level of assurance they provide will be lower 🫠
So for inter-SP control connections, it is advisable to use some sort of cryptographic authentication procedure 🔒 Control protocols which used TCP may use the TCP MD5 option to provide a measure of PE-PE authentication; this requires at least one shared secret between SPs. Using IPsec between PEs is also possible and provides a greater degree of assurance, though at a greater cost 💸
Any other security considerations that apply to the control protocol in general will also apply when the control protocol is used for setting up PWs. If the control protocol uses UDP messages, it may be advisable to have some protection against spoofed UDP messages that appear to be from a valid peer; this requires further study 🤔
To limit the effect of Denial of Service attacks on a PE, some means of limiting the rate of processing of control plane traffic may be desirable 🚦
Unlike authentication and integrity, privacy of the signaling messages is not usually considered very important. If it is needed, the signaling messages can be sent through an IPsec connection 🎀
If the PE cannot efficiently handle high volumes of multicast traffic for sustained periods, then it may be possible to launch a denial of service attack on a VPLS service by sending a PE a large number of frames that have either a multicast address or an unknown MAC address in their MAC Destination Address fields. A similar denial of service attack can be mounted by sending a PE a large number of frames with bogus MAC Source Address fields. The bogus addresses can fill the MAC address tables in the PEs, with the result that frames destined to the real MAC addresses always get flooded (i.e., multicast). Note that this flooding can remove the (weak) confidentiality property of this or any other bridged network 🙈
4.2. Provider-Customer Network Security Issues 🚪
There are a number of security issues related to the access network between the provider and the customer. It's also traditionally a network that's hard to protect physically 🧱
Typical security issues on the provider-customer interface include the following:
- Ensuring that the correct customer interface is configured
- Preventing unauthorized access to the PE
- Preventing unauthorized access to a specific PE port
- Ensuring correct service delimiting fields (VLAN, DLCI, etc.)
As the access network for an L2VPN service is necessarily a Layer 2 network, it is preferable to use authentication mechanisms that do not presuppose any IP capabilities on the CE device 💅
There are existing Layer 2 protocols and best current practices to guard against these security issues. For example, IEEE 802.1x defines authentication at the link level for access through an ethernet bridge, and the Frame Relay Forum defines LMI extensions for authentication (FRF.17) ✨
4.3. Customer Network Security Issues 👩💻
Even if all CE devices are properly authorized to attach to their PE devices, misconfiguration of the PE may interconnect CEs that are not supposed to be in the same L2VPN 😱
In a VPWS, the CEs may run IPsec to authenticate each other. Other Layer 3 or Layer 4 protocols may have their own authentication methods 🔑
In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not well support the multipoint configuration that is provided by the VPLS service 🙃
There may be alternative methods for achieving a degree of CE-to-CE authentication, if the L2VPN signaling protocol can carry opaque objects between the CEs, either inband (over the L2VPN) or out-of-band, through the participation of the signaling protocol. This is for further study 🔭
The L2VPN procedures do not provide authentication, integrity, or privacy for the customer's traffic. If this is needed, it becomes the responsibility of the customer. For customers who really need these features, or who do not trust their service providers to provide the level of security that they need, the L2VPN framework discussed in this document may not be satisfactory. Such customers may consider alternative L2VPN schemes that are based not on an overlay of PWs, but on an overlay of IPsec tunnels whose endpoints are at the customer sites. However, such alternatives are not discussed in this document 🛡️
If there is CE-to-CE control traffic (e.g., BPDUs) on whose integrity the customer's own Layer 2 network depends, it may be advisable to send the control traffic using some more secure mechanism than is used for the data traffic 🧠
In general, any means of mounting a denial of service attack on bridged networks can also be used to mount a denial of service attack on the VPLS service for a particular customer. We have discussed here only those attacks that rely on features of the VPLS service that are not shared by bridged networks in general 🌸
5. Acknowledgements 💜
This document is the outcome of discussions within a Layer 2 VPN design team, all of whose members could be considered co-authors 🫶 The co-authors are Loa Andersson, Waldemar Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile Radoaca, Eric Rosen, and Tissa Senevirathne.
The authors would like to thank Marco Carugi for cooperation in setting up context, working directions, and taking time for discussions in this space. They'd also like to thank Tove Madsen and Pekka Savola for valuable input and reviews, and Norm Finn, Matt Squires, and Ali Sajassi for valuable discussion of the VPLS issues 🙌
6. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4665] Augustyn, W., Ed. and Y. Serbest, Ed., "Service
Requirements for Layer 2 Provider-Provisioned Virtual
Private Networks (L2VPNs)", RFC 4665, September 2006.7. Informative References 📖
[IEEE8021D] IEEE 802.1D-2003, "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC)
Bridges"
[IEEE8021Q] IEEE 802.1Q-1998, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area
Networks"
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.Authors' Addresses ✍️
Loa Andersson
Acreo AB
EMail: loa@pi.se
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Waldemar Augustyn
EMail: waldemar@wdmsys.com
Marty Borden
EMail: mborden@acm.org
Juha Heinanen
Song Networks, Inc.
Hallituskatu 16
33200 Tampere, Finland
EMail: jh@song.fi
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Vach Kompella
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
EMail: vach.kompella@alcatel.com
Marc Lasserre
Riverstone Networks
5200 Great America Pkwy
Santa Clara, CA 95054
EMail: mlasserre@lucent.com
Pascal Menezies
EMail: pascalm1@yahoo.com
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7, Canada
EMail: hbrahim@nortelnetworks.com
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
EMail: radoaca@hotmail.com
Tissa Senevirathne
1567 Belleville Way
Sunnyvale CA 94087
EMail: tsenevir@hotmail.comFull Copyright Statement ⚖️
Okay, legal bit, but it still matters 🤓
Copyright (C) The Internet Society (2006).
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 💅
okay bestie, the legal part, but make it cute 🎀 the IETF is NOT taking a side on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this document are valid, or how far they reach, or whether anyone can get a license for them. it also hasn't gone out and checked for any of those rights itself 🙈 if you want the rules on rights in RFC docs, check out BCP 78 and BCP 79 📚
if you're an implementer or user and you want to see IPR disclosures that were sent to the IETF Secretariat, or any promises to license, or what happened when someone tried to get a general license or permission to use those proprietary rights, you can look at the IETF online IPR repository at http://www.ietf.org/ipr ✨
and if you spot a copyright, patent, patent application, or other proprietary right that might cover tech you'd need to build this standard, the IETF literally wants to hear about it 🫶 send it to ietf-ipr@ietf.org 💌
Acknowledgement 🫶
the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 💖 shoutout to the people keeping the lights on behind the scenes 🌈
📦 where this page comes from
- ietf: rfc4664 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms