Request for Comments: 4664 Acreo AB
Category: Informational E. Rosen, Ed.
Cisco Systems, Inc.
September 2006
Framework for Layer 2 Virtual Private Networks (L2VPNs)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides a framework for Layer 2 Provider Provisioned
Virtual Private Networks (L2VPNs). This framework is intended to aid
in standardizing protocols and mechanisms to support interoperable
L2VPNs.
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 .........................................41
1. Introduction
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Objectives and Scope of the Document
This document provides a framework for Layer 2 Provider Provisioned
Virtual Private Networks (L2VPNs). This framework is intended to aid
in standardizing protocols and mechanisms to support interoperable
L2VPNs.
The term "provider provisioned VPNs" refers to Virtual Private
Networks (VPNs) for which the Service Provider (SP) participates in
management and provisioning of the VPN.
Requirements for L2VPNs can be found in [RFC4665].
This document provides reference models for L2VPNs and discusses the
functional components of L2VPNs. Specifically, this includes
discussion of the technical issues that are important in the design
of standards and mechanisms for L2VPNs, including those standards and
mechanisms needed for interworking and security.
This document discusses a number of different technical approaches to
L2VPNs. It tries to show how the different approaches are related,
and to clarify the issues that may lead one to select one approach
instead of another. However, this document does not attempt to
select any particular approach.
1.3. Layer 2 Virtual Private Networks
There are two fundamentally different kinds of Layer 2 VPN service
that a service provider could offer to a customer: Virtual Private
Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is
also the possibility of an IP-only LAN-like Service (IPLS).
A VPWS is a VPN service that supplies an L2 point-to-point service.
As this is a point-to-point service, there are very few scaling
issues with the service as such. Scaling issues might arise from the
number of end-points that can be supported on a particular PE.
A VPLS is an L2 service that emulates LAN service across a Wide Area
Network (WAN). With regard to the amount of state information that
must be kept at the edges in order to support the forwarding
function, it has the scaling characteristics of a LAN. Other scaling
issues might arise from the number of end-points that can be
supported on a particular PE. (See Section 3.4.4.)
Note that VPLS uses a service that does not have native multicast
capability to emulate a service that does have native multicast
capability. As a result, there will be scalability issues with
regard to the handling of multicast traffic in VPLS.
A VPLS service may also impose longer delays and provide less
reliable transport than would a native LAN service. The standard LAN
control protocols may not have been designed for such an environment
and may experience scaling problems when run in that environment.
1.4. Terminology
The list of the technical terms used when discussing L2VPNs may be
found in the companion document [RFC4026].
2. Models
2.1. Reference Model for VPWS
The VPWS reference model is shown in Figure 1.
Attachment PSN Attachment
Circuits tunnel Circuits
+
+-----+ pseudo +-----+
| | wire | |
| CE1 |--+ +--| CE2 |
| | | +-----+ +-----+ +-----+ | | |
+-----+ +----|---- | | P | | ----+----+ +-----+
|VPWS\---|-----|-----|/VPWS|
| PE1 |===|=====|=====| PE2 |
| /|---|-----|-----|\\ |
+-----+ +----|---- | | | | ----|----+ +-----+
| | | +-----+ +-----+ +-----+ | | |
| CE3 |--+ +--| CE4 |
| | | |
+-----+ +-----+
Figure 1
2.1.1. Entities in the VPWS Reference Model
The P, PE (VPWS-PE), and CE devices and the PSN tunnel are defined in
[RFC4026]. The attachment circuit and pseudowire are discussed in
Section 3. The PE does a simple mapping between the PW and
attachment circuit based on local information; i.e., the PW
demultiplexor and incoming/outgoing logical/physical port.
2.2. Reference Model for VPLS
The following diagram shows a VPLS reference model where PE devices
that are VPLS-capable provide a logical interconnect such that CE
devices belonging to a specific VPLS appear to be on a single bridged
Ethernet. A VPLS can contain 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 3
From Figure 3, we see that in VPLS, a CE device attaches, possibly
through an access network, to a "bridge" module of a VPLS-PE. Within
the VPLS-PE, the bridge module attaches, through an "Emulated LAN
Interface", to an Emulated LAN. For each VPLS, there is an Emulated
LAN instance. Figure 3 shows some internal structure to the Emulated
LAN: it consists of "VPLS Forwarder" modules connected by
pseudowires, where the pseudowires may be traveling through PSN
tunnels over a routed backbone.
A "VPLS instance" consists of a set of VPLS Forwarders (no more than
one per PE) connected by pseudowires.
The functionality that the bridge module must support depends on the
service that is being offered by the SP to its customers, as well as
on various details of the SP’s network. At a minimum, the bridge
module must be able to learn MAC addresses, and to "age them out", in
the standard manner. However, if the PE devices have backdoor
connections with each other via a Layer 2 network, they may need to
be full IEEE bridges ([IEEE8021D]), running a spanning tree with each
other. Specification of the precise functionality that the bridge
modules must have in particular circumstances is, however, out of
scope of the current document.
This framework specifies that each "bridge module" have a single
"Emulated LAN interface". It does not specify the number of bridge
modules that a VPLS-PE may contain, nor does it specify the number of
VPLS instances that may attach to a bridge module over a single
"Emulated LAN interface".
Thus the framework is compatible with at least the following 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, in that they
both use forwarders to map attachment circuits to pseudowires. The
only difference is that while the forwarder in a VPWS-PE does a one-
to-one mapping between the attachment circuit and pseudowire, the
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 specifies a functional model for L2VPN, which allows one
to break an L2VPN architecture down into its functional components.
This exhibits the roles played by the various protocols and
mechanisms, and thus makes it easier to understand the differences
and similarities between various proposed L2VPN architectures.
Section 3.1 contains an overview of some different types of L2VPNs.
In Section 3.2, functional components that are common to the
different types are discussed. Then, there is a section for each of
the L2VPN service types being considered. The latter sections
discuss functional components, which may be specific to particular
L2VPN types, and type-specific features of the generic components.
3.1. Types of L2VPN
The types of L2VPN are distinguished by the characteristics of the
service that they offer to the customers of the Service Provider
(SP).
3.1.1. Virtual Private Wire Service (VPWS)
In a VPWS, each CE device is presented with a set of point-to-point
virtual circuits.
The other end of each virtual circuit is another CE device. Frames
transmitted by a CE on such a virtual circuit are received by the CE
device at the other end-point of the virtual circuit. Forwarding
from one CE device to another is not affected by the content of the
frame, but is fully determined by the virtual circuit on which the
frame is transmitted. The PE thus acts as a virtual circuit switch.
This type of L2VPN has long been available over ATM and Frame Relay
backbones. Providing this type of L2VPN 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 examines the MAC
Destination Address field in order to determine how to forward the
frame. Thus, the PE functions as a bridge. As Figure 3 indicates,
if a set of PEs support a common VPLS instance, then there is an
Emulated LAN, corresponding to that VPLS instance, to which each of
those PE bridges attaches (via an emulated interface). From the
perspective of a CE device, the virtual backbone is the set of PE
bridges and the Emulated LAN on which they reside. Thus to a CE
device, the LAN that attaches it to the PE is extended transparently
over the routed MPLS and/or IP backbone.
The PE bridge function treats the Emulated LAN as it would any other
LAN to which it has an interface. Forwarding decisions are made in
the manner that is normal for bridges, which is based on MAC Source
Address learning.
VPLS is like VPWS in that forwarding is done without any
consideration of the Layer3 header. VPLS is unlike VPWS in that: