Request for Comments: 4026 T. Madsen
Category: Informational Acreo AB
March 2005
Provider Provisioned Virtual Private Network (VPN) Terminology
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 (2005).
Abstract
The widespread interest in provider-provisioned Virtual Private
Network (VPN) solutions lead to memos proposing different and
overlapping solutions. The IETF working groups (first Provider
Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have
discussed these proposals and documented specifications. This has
lead to the development of a partially new set of concepts used to
describe the set of VPN services.
To a certain extent, more than one term covers the same concept, and
sometimes the same term covers more than one concept. This document
seeks to make the terminology in the area clearer and more intuitive.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. PPVPN Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Provider Provisioned Virtual Private Network Services . . . . 4
3.1. Layer 3 VPN (L3VPN) . . . . . . . . . . . . . . . . . . 4
3.2. Layer 2 VPN (L2VPN) . . . . . . . . . . . . . . . . . . 4
3.3. Virtual Private LAN Service (VPLS) . . . . . . . . . . . 4
3.4. Virtual Private Wire Service (VPWS) . . . . . . . . . . 4
3.5. IP-Only LAN-Like Service (IPLS) . . . . . . . . . . . . 5
3.6. Pseudo Wire (PW) . . . . . . . . . . . . . . . . . . . . 5
3.7. Transparent LAN Service (TLS) . . . . . . . . . . . . . 5
3.8. Virtual LAN (VLAN) . . . . . . . . . . . . . . . . . . . 6
3.9. Virtual Leased Line Service (VLLS) . . . . . . . . . . . 6
3.10. Virtual Private Network (VPN) . . . . . . . . . . . . . 6
3.11. Virtual Private Switched Network (VPSN) . . . . . . . . 6
4. Classification of VPNs . . . . . . . . . . . . . . . . . . . . 7
5. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Customer Edge Device (CE) . . . . . . . . . . . . . . . 8
5.1.1. Device Based CE Naming . . . . . . . . . . . . . 9
5.1.2. Service Based CE Naming . . . . . . . . . . . . 9
5.2. Provider Edge (PE) . . . . . . . . . . . . . . . . . . . 10
5.2.1. Device Based PE Naming . . . . . . . . . . . . . 10
5.2.2. Service Based PE Naming . . . . . . . . . . . . 10
5.2.3. Distribution Based PE Naming . . . . . . . . . . 11
5.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1 Provider Router (P) . . . . . . . . . . . . . . 11
5.4. Naming in Specific Internet Drafts . . . . . . . . . . . 11
5.4.1. Layer 2 PE (L2PE) . . . . . . . . . . . . . . . 11
5.4.2. Logical PE (LPE) . . . . . . . . . . . . . . . . 12
5.4.3. PE-CLE . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. PE-Core . . . . . . . . . . . . . . . . . . . . 12
5.4.5. PE-Edge . . . . . . . . . . . . . . . . . . . . 12
5.4.6. PE-POP . . . . . . . . . . . . . . . . . . . . . 12
5.4.7. VPLS Edge (VE) . . . . . . . . . . . . . . . . . 12
6. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Attachment Circuit (AC) . . . . . . . . . . . . . . . . 12
6.2. Backdoor Links . . . . . . . . . . . . . . . . . . . . . 13
6.3. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 13
6.4. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5. MAC Address Learning . . . . . . . . . . . . . . . . . . 13
6.5.1. Qualified Learning . . . . . . . . . . . . . . . 13
6.5.2. Unqualified Learning . . . . . . . . . . . . . . 13
6.6. Signalling . . . . . . . . . . . . . . . . . . . . . . . 13
7. ’Boxes’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Aggregation Box . . . . . . . . . . . . . . . . . . . . 14
7.2. Customer Premises Equipment (CPE) . . . . . . . . . . . 14
7.3. Multi-Tenant Unit (MTU) . . . . . . . . . . . . . . . . 14
8. Packet Switched Network (PSN) . . . . . . . . . . . . . . . . 14
8.1. Route Distinguisher (RD) . . . . . . . . . . . . . . . . 15
8.2. Route Reflector . . . . . . . . . . . . . . . . . . . . 15
8.3. Route Target (RT) . . . . . . . . . . . . . . . . . . . 15
8.4. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.5. Tunnel Multiplexor . . . . . . . . . . . . . . . . . . . 16
8.6. Virtual Channel (VC) . . . . . . . . . . . . . . . . . . 16
8.7. VC Label . . . . . . . . . . . . . . . . . . . . . . . . 16
8.8. Inner Label . . . . . . . . . . . . . . . . . . . . . . 16
8.9. VPN Routing and Forwarding (VRF) . . . . . . . . . . . . 16
8.10. VPN Forwarding Instance (VFI) . . . . . . . . . . . . . 16
8.11. Virtual Switch Instance (VSI) . . . . . . . . . . . . . 17
8.12. Virtual Router (VR) . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
A comparatively large number of memos have been submitted to the
former PPVPN working group, and to the L2VPN, L3VPN, and PWE3 working
groups, which all address the same problem space; provider
provisioned virtual private networking for end customers. The memos
address a wide range of services, but there is also a great deal of
commonality among the proposed solutions.
This has led to the development of a partial set of new concepts used
to describe this set of VPN services. To a certain extent, more than
one term covers the same concept, and sometimes the same term covers
more than one concept.
This document proposes a foundation for a unified terminology for the
L2VPN and L3VPN working groups. In some cases, the parallel concepts
within the PWE3 working group are used as references.
2. PPVPN Terminology
The concepts and terms in this list are gathered from Internet Drafts
sent to the L2VPN and L3VPN mailing lists (earlier the PPVPN mailing
list) and RFCs relevant to the L2VPN and L3VPN working groups. The
focus is on terminology and concepts that are specific to the PPVPN
area, but this is not strictly enforced; e.g., some concepts and
terms within the PWE3 and (Generalized) MPLS areas are closely
related. We’ve tried to find the earliest uses of terms and
concepts.
This document is intended to fully cover the concepts within the core
documents from the L2VPN and L3VPN working groups; i.e., [L3VPN-REQ],
[L2VPN-REQ], [L3VPN-FRAME], [L2VPN], and [RFC3809]. The intention is
to create a comprehensive and unified set of concepts for these
documents and, by extension, for the entire PPVPN area. To do so, it
is also necessary to give some of the development the concepts of the
area have been through.
The document is structured in four major sections. Section 4 lists
the different services that have been or will be specified Section 5
lists the building blocks that are used to specify those services
Section 6 lists the functions needed in those services. Section 7
lists some typical devices used in customer and provider networks.
3. Provider Provisioned Virtual Private Network Services
In this section, we define the terminology that relates the set of
services to solutions specified by the L2VPN and L3VPN working
groups. The "pseudo wire" concept, which belongs to the PWE3 working
group, is included for reference purposes. For requirements in
provider provisioned VPNs, see [L3VPN-REQ].
All terms and abbreviations are listed together with a brief
description of the service. The list is structured to give the more
general information first and the more specific later. The names of
services for which the IETF is working on solutions have been moved
to the top of the list. Older and more dated terminology has been
pushed toward the end of the list.
3.1. Layer 3 VPN (L3VPN)
An L3VPN interconnects sets of hosts and routers based on Layer 3
addresses; see [L3VPN-FRAME].
3.2. Layer 2 VPN (L2VPN)
Three types of L2VPNs are described in this document: Virtual Private
Wire Service (VPWS) (Section 3.4); Virtual Private LAN Service
(VPLS)(Section 3.3); and IP-only LAN-like Service
(IPLS)(Section 3.5).
3.3. Virtual Private LAN Service (VPLS)
A VPLS is a provider service that emulates the full functionality of
a traditional Local Area Network (LAN). A VPLS makes it possible to
interconnect several LAN segments over a packet switched network
(PSN) and makes the remote LAN segments behave as one single LAN.
For an early work on defining a solution and protocol for a VPLS, see
[L2VPN-REQ], [VPLS-LDP], and [VPLS].
In a VPLS, the provider network emulates a learning bridge, and
forwarding decisions are taken based on MAC addresses or MAC
addresses and VLAN tag.
3.4. Virtual Private Wire Service (VPWS)
A Virtual Private Wire Service (VPWS) is a point-to-point circuit
(link) connecting two Customer Edge devices. The link is established
as a logical through a packet switched network. The CE in the
customer network is connected to a PE in the provider network via an
Attachment Circuit (see Section 6.1); the Attachment Circuit is
either a physical or a logical circuit.
The PEs in the core network are connected via a PW.
The CE devices can be routers, bridges, switches, or hosts. In some
implementations, a set of VPWSs is used to create a multi-site L2VPN
network. An example of a VPWS solution is described in
[PPVPN-L2VPN].
A VPWS differs from a VPLS (Section 3.3) in that the VPLS is point to
multipoint, while the VPWS is point to point. See [L2VPN].
3.5. IP-Only LAN-Like Service (IPLS)
An IPLS is very like a VPLS (see Section 3.3), except that
o it is assumed that the CE devices (see Section 5.1) are hosts or
routers, not switches,
o it is assumed that the service will only have to carry IP packets,
and supporting packets such as ICMP and ARP (otherwise layer 2
packets that do not contain IP are not supported); and
o the assumption that only IP packets are carried by the service
applies equally to IPv4 and IPv6 packets.
While this service is a functional subset of the VPLS service, it is
considered separately because it may be possible to provide it by
using different mechanisms, which may allow it to run on certain
hardware platforms that cannot support the full VPLS functionality
[L2VPN].
3.6. Pseudo Wire (PW)
The PWE3 working group within the IETF specifies the pseudo wire
technology. A pseudo wire is an emulated point-to-point connection
over a packet switched network that allows the interconnection of two
nodes with any L2 technology. The PW shares some of the building
blocks and architecture constructs with the point-to-multipoint
solutions; e.g., PE (see Section 5.2) and CE (see Section 5.1). An
early solution for PWs is described in [TRANS-MPLS]. Encapsulation
formats readily used in VPWS, VPLS, and PWs are described in
[ENCAP-MPLS]. Requirements for PWs are found in [RFC3916], and
[PWE3-ARCH] presents an architectural framework for PWs.
3.7. Transparent LAN Service (TLS)
TLS was an early name used to describe the VPLS service. TLS has
been replaced by VPLS, which is the current term.
3.8. Virtual LAN (VLAN)
The term VLAN was specified by IEEE 802.1Q; it defines a method of
differentiating traffic on a LAN by tagging the Ethernet frames. By
extension, VLAN is used to mean the traffic separated by Ethernet
frame tagging or similar mechanisms.
3.9. Virtual Leased Line Service (VLLS)
The term VLLS has been replaced by term VPWS. VLLS was used in a now
dated document intended to create metrics by which it should have
been possible to compare different L2VPN solutions. This document
has now expired, and the work has been terminated.
3.10. Virtual Private Network (VPN)
VPN is a generic term that covers the use of public or private
networks to create groups of users that are separated from other
network users and that may communicate among them as if they were on
a private network. It is possible to enhance the level of separation
(e.g., by end-to-end encryption), but this is outside the scope of
IETF VPN working group charters. This VPN definition is from
[RFC2764].
In the [L3VPN-FRAME], the term VPN is used to refer to a specific set
of sites as either an intranet or an extranet that have been
configured to allow communication. Note that a site is a member of
at least one VPN and may be a member of many.
In this document, "VPN" is also used as a generic name for all
services listed in Section 3.
3.11. Virtual Private Switched Network (VPSN)
The term VPSN has been replaced by the term VPLS. The requirements
have been merged into the L3VPN [L3VPN-REQ] and L2VPN [L2VPN-REQ]
requirements.
4. Classification of VPNs
The terminology used in [RFC3809] is defined based on the figure
below.
PPVPN
________________|__________________
| |
Layer 2 Layer 3
______|_____ ______|______
| | | |
P2P P2M PE-based CE-based
(VPWS) _____|____ ______|____ |
| | | | |
VPLS IPLS BGP/MPLS Virtual IPsec
IP VPNs Router
Figure 1
The figure above presents a taxonomy of PPVPN technologies. Some of
the definitions are given below:
CE-based VPN: A VPN approach in which the shared service provider
network does not have any knowledge of the customer VPN. This
information is limited to CE equipment. All the VPN-specific
procedures are performed in the CE devices, and the PE devices are
not aware in any way that some of the traffic they are processing is
VPN traffic (see also [L3VPN-FRAME]).
PE-Based VPNs: A Layer 3 VPN approach in which a service provider
network is used to interconnect customer sites using shared
resources. Specifically, the PE device maintains VPN state,
isolating users of one VPN from users of another. Because the PE
device maintains all required VPN states, the CE device may behave as
if it were connected to a private network. Specifically, the CE in a
PE-based VPN must not require any changes or additional functionality
to be connected to a PPVPN instead of a private network.
The PE devices know that certain traffic is VPN traffic. They
forward the traffic (through tunnels) based on the destination IP
address of the packet, and optionally based on other information in
the IP header of the packet. The PE devices are themselves the
tunnel endpoints. The tunnels may make use of various encapsulations
to send traffic over the SP network (such as, but not restricted to,
GRE, IP-in-IP, IPsec, or MPLS tunnels) [L3VPN-FRAME].
Virtual Router (VR) style: A PE-based VPN approach in which the PE
router maintains a complete logical router for each VPN that it
supports. Each logical router maintains a unique forwarding table
and executes a unique instance of the routing protocols. These VPNs
are described in [L3VPN-VR].
BGP/MPLS IP VPNs: A PE-based VPN approach in which the PE router
maintains a separate forwarding environment and a separate forwarding
table for each VPN. In order to maintain multiple forwarding table
instances while running only a single BGP instance, BGP/MPLS IP VPNs
mark route advertisements with attributes that identify their VPN
context. These VPNs are based on the approach described in
[RFC2547bis].
RFC 2547 Style: The term has been used by the L3VPN to describe the
extensions of the VPNs defined in the informational RFC 2547
[RFC2547]. This term has now been replaced by the term BGP/MPLS IP
VPNs.
5. Building Blocks
Starting with specifications of L3VPNs (e.g., the 2547 specification
[RFC2547] and [RFC2547bis] and Virtual Routers [L3VPN-VR]), a way of
describing the building blocks and allocation of functions in VPN
solutions was developed. The building blocks are often used in
day-to-day talk as if they were physical boxes, common for all
services.
However, for different reasons, this is an oversimplification. Any
of the building blocks could be implemented across more than one
physical box. How common the use of such implementations will be is
beyond the scope of this document.
5.1. Customer Edge Device (CE)
A CE is the name of the device with the functionality needed on the
customer premises to access the services specified by the former
PPVPN working group in relation to the work done on L3VPNs
[L3VPN-FRAME]. The concept has been modified; e.g., when L2VPNs and
CE-based VPNs were defined. This is addressed further in the
sub-sections of this section.
There are two different aspects that have to be considered in naming
CE devices. One could start with the type of device that is used to
implement the CE (see Section 5.1.1). It is also possible to use the
service the CE provides whereby the result will be a set of "prefixed
CEs", (see Section 5.1.2).
It is common practice to use "CE" to indicate any of these boxes, as
it is very often unambiguous in the specific context.
5.1.1. Device Based CE Naming
5.1.1.1. Customer Edge Router (CE-R)
A CE-R is a router in the customer network interfacing the provider
network. There are many reasons to use a router in the customer
network; e.g., in an L3VPN using private IP addressing, this is the
router that is able to do forwarding based on the private addresses.
Another reason to require the use of a CE-R on the customer side is
that one wants to limit the number of MAC-addresses that need to be
learned in the provider network.
A CE-R could be used to access both L2 and L3 services.
5.1.1.2. Customer Edge Switch (CE-S)
A CE-S is a service aware L2 switch in the customer network
interfacing the provider network. In a VPWS or a VPLS, it is not
strictly necessary to use a router in the customer network; a layer 2
switch might very well do the job.
5.1.2. Service Based CE Naming
The list below contains examples of how different functionality has
been used to name CEs. There are many examples of this type of
naming, and we only cover the most frequently used functional names.
As these are functional names, it is quite possible that on a single
piece of equipment there are platforms for more than one type of
function. For example, a router might at the same time be both a
L2VPN-CE and a L3VPN-CE. It might also be that the functions needed
for a L2VPN-CE or L3VPN-CE are distributed over more than one
platform.
5.1.2.1. L3VPN-CE
An L3VPN-CE is the device or set of devices on the customer premises
that attaches to a provider provisioned L3VPN; e.g., a 2547bis
implementation.
5.1.2.2. VPLS-CE
A VPLS-CE is the device or set of devices on the customer premises
that attaches to a provider provisioned VPLS.
5.1.2.3. VPWS-CE
A VPWS-CE is the device or set of devices on the customer premises
that attaches to a provider provisioned VPWS.
5.2. Provider Edge (PE)
A PE is the name of the device or set of devices at the edge of the
provider network with the functionality that is needed to interface
with the customer. Without further qualifications, PE is very often
used for naming the devices since it is made unambiguous by the
context.
In naming PEs there are three aspects that we need to consider, the
service they support, whether the functionality needed for service is
distributed across more than one device and the type of device they
are build on.
5.2.1. Device Based PE Naming
Both routers and switches may be used to implement PEs; however, the