Provider Provisioned Virtual Private Network Services Terminology

Return to Internet Protocol

Source: IETF RFC 4026 – Not all terms listed below.

Layer 3 VPN (L3VPN)

An L3VPN interconnects sets of hosts and routers based on Layer 3 addresses

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).

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.

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].

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].

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.

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.

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.

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.

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.

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.

Classification of VPNs

The terminology used in [RFC3809] is defined based on the figure below.

              |                                   |
            Layer 2                             Layer 3
        ______|_____                        ______|______
       |            |                      |             |
      P2P          P2M                  PE-based      CE-based
    (VPWS)     _____|____            ______|____         |
              |          |          |           |        |
             VPLS      IPLS     BGP/MPLS     Virtual    IPsec
                                 IP VPNs      Router

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].


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

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.

Provider Router (P)

The P is defined as a router in the core network that does not have interfaces directly toward a customer. Therefore, a P router does not need to keep VPN state and is VPN unaware.

Route Distinguisher (RD)

A Route Distinguisher [RFC2547bis] is an 8-byte value that, together with a 4 byte IPv4 address, identifies a VPN-IPv4 address family. If two VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN.

Route Target (RT)

A Route Target attribute [RFC2547bis] can be thought of as identifying a set of sites or, more precisely, a set of VRFs (see Section 8.9).

Associating a particular Route Target with a route allows that route to be placed in all VRFs used for routing traffic received from the corresponding sites.

A Route Target attribute is also a BGP extended community used in [RFC2547] and [BGP-VPN]. A Route Target community is used to constrain VPN information distribution to the set of VRFs. A route target can be perceived as identifying a set of sites or, more precisely, a set of VRFs.


A tunnel is connectivity through a PSN that is used to send traffic across the network from one PE to another. The tunnel provides a means to transport packets from one PE to another. Separation of one customer’s traffic from another customer’s traffic is done based on tunnel multiplexers (see Section 8.5). How the tunnel is established depends on the tunnelling mechanisms provided by the PSN; e.g., the tunnel could be based on the IP-header, an MPLS label, the L2TP
Session ID, or the GRE Key field.

Tunnel Multiplexor

A tunnel multiplexor is an entity that is sent with the packets traversing the tunnel to make it possible to decide which instance of a service a packet belongs to and from which sender it was received. In [PPVPN-L2VPN], the tunnel multiplexor is formatted as an MPLS label.

VPN Routing and Forwarding (VRF)

In networks running 2547 VPN’s [RFC2547], PE routers maintain VRFs. A VRF is a per-site forwarding table. Every site to which the PE router is attached is associated with one of these tables. A particular packet’s IP destination address is looked up in a particular VRF only if that packet has arrived directly from a site that is associated with that table.

Virtual Router (VR)

A Virtual Router (VR) is software and hardware based emulation of a physical router. Virtual routers have independent IP routing and forwarding tables, and they are isolated from each other; see [L3VPN-VR].