DUMMY LINE
PPVPN Working Group Loa Andersson
Tove Madsen
Internet-Draft
Expiration Date: September, 2003
April 9 2003
PPVPN Terminology
<draft-andersson-ppvpn-terminology-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
The provider provisioned VPN solutions has attracted a great deal of
interest. Memos proposing different and overlapping solution have
been discussed on the PPVPN mailing list and in the Working Group
meetings. This has lead to a development of a partly new set of
concepts used to describe the set of VPN services. To a certain
extent there are more than one term covering the same concept and
sometimes the same term covers more than on concept. The terminology
needs to be made clearer and more intuitive. This document seeks to
fill at least part of that need.
Conventions used in this document
Andersson & Madsen [Page 1]
Internet-Draft PPVPN Terminology March 2003
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].
Andersson & Madsen [Page 2]
Internet-Draft PPVPN Terminology March 2003
Table oc contents
1 Introduction .......................................... 4
2 PPVPN Terminology ..................................... 5
3 Provider Provisioned Virtual Private Network services . 5
3.1 IP-only LAN-like Service (IPLS) ....................... 6
3.2 Layer 2 VPN (L2VPN) ................................... 6
3.3 Layer 3 VPN (L3VPN) ................................... 6
3.4 Pseudo Wire (PW) ...................................... 6
3.5 Transparent LAN Service (TLS) ......................... 7
3.6 Virtual LAN (VLAN) .................................... 7
3.7 Virtual Leased Line Service (VLLS) .................... 7
3.8 Virtual Private Network (VPN) ......................... 7
3.9 Virtual Private Switched Network (VPSN) ............... 8
3.10 Virtual Private Wire Service (VPWS) ................... 8
4 Classification of VPNs ................................ 8
5 Building blocks ....................................... 9
5.1 Customer Edge device (CE) ............................. 10
5.1.1 Device based CE naming ................................ 10
5.1.1.1 Customer Edge Router (CE-R) ........................... 10
5.1.1.2 Customer Edge Switch (CE-S) ........................... 10
5.1.2 Service based CE naming ............................... 10
5.1.2.1 L3VPN-CE .............................................. 11
5.1.2.2 VPWS-CE ............................................... 11
5.2 Provider Edge (PE) .................................... 11
5.2.1 Device based PE naming ................................ 11
5.2.1.1 Provider Edge Router (PE-R) ........................... 11
5.2.1.2 Provider Edge Switch (PE-S) ........................... 11
5.2.2 Service based PE naming ............................... 12
5.2.2.1 L3VPN-PE .............................................. 12
5.2.2.2 VPWS-PE ............................................... 12
5.2.2.3 VPLS-PE ............................................... 12
5.2.3 Distribution based PE naming .......................... 12
5.2.3.1 Network facing PE (N-PE) .............................. 12
5.2.3.2 User facing PE (U-PE) ................................. 12
5.3 Core .................................................. 13
5.3.1 Provider router (P) ................................... 13
5.4 Naming in specific Internet drafts .................... 13
5.4.1 Logical PE (LPE) ...................................... 13
5.4.2 PE-CLE ................................................ 13
5.4.3 PE-Core ............................................... 13
5.4.4 PE-Edge ............................................... 13
5.4.5 PE-POP ................................................ 14
5.4.6 VPLS Edge (VE) ........................................ 14
6 Functions ............................................. 14
6.1 Attachment Circuit (AC) ............................... 14
6.2 Endpoint discovery .................................... 14
Andersson & Madsen [Page 3]
Internet-Draft PPVPN Terminology March 2003
6.3 Flooding .............................................. 14
6.4 MAC address learning .................................. 15
6.4.1 Qualified learning .................................... 15
6.4.2 Unqualified learning .................................. 15
6.5 Signaling ............................................. 15
7 'Boxes' ............................................... 15
7.1 Aggregation box ....................................... 15
7.2 Customer Premises Equipment (CPE) ..................... 16
7.3 Multi Tenant Unit (MTU) ............................... 16
8 Packet Switched Network (PSN) ......................... 16
8.1 Route Distinguisher (RD) .............................. 16
8.2 Route Target (RT) ..................................... 17
8.3 Tunnel ................................................ 17
8.4 Tunnel multiplexor .................................... 17
8.5 Virtual Channel (VC) .................................. 17
8.6 VC label .............................................. 18
8.7 Inner label ........................................... 18
8.8 VPN Routing and Forwarding (VRF) ...................... 18
8.9 VPN Forwarding Instance (VFI) ......................... 18
8.10 Virtual Router (VR) ................................... 18
9 Acknowledgements ..................................... 19
10 Authors' Contact ...................................... 19
11 Normative References .................................. 19
12 Non-Normative References .............................. 20
1. Introduction
There are a comparatively large number of memos being submitted to
the PPVPN and PWE3 working groups that all addresses the same problem
space, provider provisioned virtual private networking for end cus-
tomers. The memos address a wide range of services, but there is also
a great deal of commonality among the proposed solutions.
This has lead to a development of a partly new set of concepts used
to describe this set of VPN services. To a certain extent there are
more than one term covering the same concept and sometimes the same
term covers more than one concept. The terminology needs to be made
clearer and more intuitive.
This document seeks to fill at least part of the need and proposes a
foundation for a unified terminology for the PPVPN working group; in
some cases the parallel concepts within the PWE3 working groups is
used as references.
Andersson & Madsen [Page 4]
Internet-Draft PPVPN Terminology March 2003
2. PPVPN Terminology
Terminology in the IETF VPN work has been and is confusing. This doc-
ument could be compared to the Stone of Rosetta. The Stone of Rosetta
was found in the town of Rosetta in northern Egypt year 1799. It was
inscribed with the same text in three different languages Greek, com-
mon Egyptian and hieroglyphs. Thus making it possible to solve the
riddle of the hieroglyphs. In analogy with the Stone of Rosetta this
document will give you a key to your future reading and writing PPVPN
texts.
The concepts and terms in this list are gathered from Internet Drafts
sent to the PPVPN mailing list and RFCs relevant to PPVPN working
group. The focus is on terminology and concepts that are specific to
the PPVPN area, but this is not strictly enforced, e.g. there are
concepts and terms within the PWE3 and (Generalized) MPLS areas that
are closely related. We've tried to find the earliest use of terms
and concepts.
This document intends to fully cover the concepts within five core
documents from the PPVPN working group the "Generic Requirements for
Provider Provisioned VPN" [GENERIC], the "A Framework for Layer 3
Provider Provisioned Virtual Private Networks" [L3VPN-frmwrk], the
"Service requirements for Layer 3 Provider Provisioned Virtual Pri-
vate Networks" [PPVPN-req], the "L2VPN Framework [L2-frmwrk] and
"Service Requirements for Layer 2 Provider Provisioned Virtual Pri-
vate Networks" [L2VPN-req]. The intention is to create a comprehen-
sive and unified set of concepts for these documents, and by exten-
tion for the entire PPVPN area. To do so it is also necessary to give
some of the development the concepts of the area has been through -
"The Rosetta stone" aspect.
The document is structured in four major sections. Section 4 lists
the different services that has been/will be specified, Section 5
lists the building blocks that is used to specify those services,
section 6 lists the functions needed in those services and section 7
list 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 PPVPN working group. The con-
cept "pseudo wire" that belongs to the PWE3 working group is included
for reference purposes. For requirements in provider provisioned VPNs
see [PPVPN-req].
In this section all abbreviations are listed in alphabetic order.
Andersson & Madsen [Page 5]
Internet-Draft PPVPN Terminology March 2003
3.1. IP-only LAN-like Service (IPLS)
An IPLS is very like a VPLS (see 4.8), except that:
- it is assumed that the CE devices (see 5.1) are hosts or
routers, not switches
- it is assumed that the service will only need to carry IP pack-
ets,
and supporting packets such as ICMP and ARP; otherwise layer 2
packets which do not contain IP are not supported.
While this service is a functional subset of the VPLS service, it is
considered separately because it may be possible to provide it using
different mechanisms, which may allow it to run on certain hardware
platforms that cannot support the full VPLS functionality. [PPVPN-L2-
frmwrk]
3.2. Layer 2 VPN (L2VPN)
Three types of L2VPNs are described in this document, Virtual Private
Wire Service (VPWS) (section 3.3), VPLS Virtual Private LAN Service
(VPLS)(section 4.8), and IP-only LAN-like Service (IPLS).
3.3. Layer 3 VPN (L3VPN)
An L3VPN is a solution, that interconnects several sets of hosts and
routers and allows them to communicate based on L3 addresses, see
[PPVPN-frmwrk].
3.4. Pseudo Wire (PW)
The PWE3 working group within IETF specifies the pseudo wire technol-
ogy. A pseudo wire is an emulated point-to-point connectivity over a
packet switched network that gives the possibility to interconnect
two nodes with any L2 technology. The PW shares some of the building
blocks and architecture constructs with the point to multipoint solu-
tions, e.g. PE (see 5.2) and CE (see 5.1). An early solution for PWs
is described in [martini-tran]. Encapsulation formats readily used in
VPWS, VPLS and PWs are described in [martini-encap]. Requirements for
PWs are found in [PWE3-req] and [PWE3-frmwrk] present an architec-
tural framework for PWs.
Andersson & Madsen [Page 6]
Internet-Draft PPVPN Terminology March 2003
3.5. Transparent LAN Service (TLS)
TLS was the first name used to describe the VPLS service, it was used
e.g. in the now dated draft-lasserre-tls-mpls-00.txt. It has been
replaced by VPLS, which is now the current term.
3.6. Virtual LAN (VLAN)
A VLAN is a way of separating traffic on a LAN, e.g. between differ-
ent departments within a company. This acronym is not defined by
PPVPN working group, but is defined by IEEE 802.1Q. The VLANID is
used to mark an Ethernet frame with a tag to create user groups on a
LAN.
3.7. Virtual Leased Line Service (VLLS)
The VLLS has been replaced by VPWS. It was used in now dated draft-
ppvpn-metrics.00.txt.
3.8 Virtual Private LAN Service (VPLS)
A VPLS is a provider service that emulates the full functionality of
a traditional Local Area Network. A VPLS makes it possible to inter-
connect several LAN segments over a packet switched network (PSN) and
makes the remote LAN segments behave as one single LAN. For early
work on defining a solution and protocol for a VPLS see [VPLS-req],
[Lasserre-vkompella], and [Kompella-VPLS].
In a VPLS the provider network emulates a learning bridge and for-
warding decisions are taken based on MAC addresses or MAC addresses
and VLAN tag.
3.8. Virtual Private Network (VPN)
VPN is a generic term that covers the use of a public or private net-
works to create groups of users that is separated from other network
users and may communicate among them as if they were on a private
network. The level of separation is possible to enhance e.g. by end-
to- end encryption, this is however outside the scope of PPVPN work-
ing group charter. This VPN definition is from [RFC2764].
In the [L3VPN-frmwrk] the term VPN is used to refer to a specific set
of sites as either an intranet or an extranet that have been config-
ured to allow communication. Note that a site is a member of at least
one VPN, and may be a member of many VPNs.
Andersson & Madsen [Page 7]
Internet-Draft PPVPN Terminology March 2003
In this document "VPN" is also used as a generic name for all ser-
vices listed in section 3.
3.9. Virtual Private Switched Network (VPSN)
A VPSN is replaced by VPLS. The VPSN abbreviation was used e.g. in
the now dated draft-vkompella-ppvpn-vpsn.reqmts-00.txt.
3.10. Virtual Private Wire Service (VPWS)
s.p A Virtual Private Wire Service (VPWS) is a point-to-point circuit
(link) connecting two Customer Edge devices. The CE in the customer
network is connected to a PE in the provider network via an Attach-
ment Circuit (see 6.1); the Attachment Circuit is either a physical
or a logical circuit.
The PE's in the core network is 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 [L2VPN].
A VPWS differs from a VPLS (section4.8) in that the VPLS is point to
multipoint, while the VPWS is point to point. See [L2-frmwrk].
4. Classification of VPNs
The terminology used in [GENERIC] is defined based on the figure
below.
PPVPN
________________|__________________
| |
Layer 2 Layer 3
______|_____ ______|________
| | | |
P2P P2M PE-based CE-based
(VPWS) ____|____ ______|____ |
| | | | |
VPLS IPLS RFC2547 Virtual IPsec
Style Router
The figure above presents a taxonomy of PPVPN technologies. Some of
the definitions are given below:
Andersson & Madsen [Page 8]
Internet-Draft PPVPN Terminology March 2003
CE-based VPN: A VPN approach in which the shared service provider
network does not have any knowledge of the customer VPN. This infor-
mation is limited to CE equipment.
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 VPN. Because the PE device
maintains all required VPN state, 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.
Virtual Router (VR) style: A PE-based VPN approach in which the PE
router maintains a complete logical router for each VPN that it sup-
ports. Each logical router maintains a unique forwarding table and
executes a unique instance of the routing protocols. These VPNs are
described in [PPVPN-VR].
RFC 2547 Style: A PE-based VPN approach in which the PE router main-
tains separate forwarding environment for each VPN and a separate
forwarding table for each VPN. In order to maintain multiple forward-
ing table instances while running only a single routing protocol
instance, RFC 2547 style VPNs mark route advertisements with
attributes that identify their VPN context. These VPNs are based on
the approach described in [RFC2547bis].
5. Building blocks
Starting with specifications of L3VPNs, e.g. the 2547 specification
[RFC2547] and [RFC2547bis] and Virtual Routers [PPVPN-VR], a way of
describing the building blocks and allocation of functions in VPN
solutions was developed. The building blocks are often in day-to-day
talk treated as if it were physical boxes, common for all services.
However, for different reasons this is to over-simplify. 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.
Andersson & Madsen [Page 9]
Internet-Draft PPVPN Terminology March 2003
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 PPVPN work-
ing group.
There are two different aspects that need to be considered in naming
CE devices. One could start with the type of device that is used to
implement the CE (see section 4.1.1). It is also possible to use the
service the CE provides and with the result will be a set of "pre-
fixed CEs", (see section 4.1.2).
It is common practice to use "CE" to indicate any of these boxes,
since 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 net-
work, 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
want to limit the number on MAC-addresses that needs to be learnt 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 interfac-
ing the provider network. In a VPWS or a VPLS it is not strictly nec-
essary 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 is just examples and it will be extended as the number
of services increases.
Andersson & Madsen [Page 10]
Internet-Draft PPVPN Terminology March 2003
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 imple-
mentation.
Ps "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.2. 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
the customer. PE, without further qualifications, 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
scaling properties will be radically different depending which type
of equipment that is chosen.
5.2.1.1. Provider Edge Router (PE-R)
A PE-R is a L3 device that participates in the PSN (see section 8)
routing and forwards packets based on the routing information.
5.2.1.2. Provider Edge Switch (PE-S)
A PE-S is a L2 device that participates in e.g. a switched Ethernet
taking forwarding decision packets based on L2 address information.
Andersson & Madsen [Page 11]
Internet-Draft PPVPN Terminology March 2003
5.2.2. Service based PE naming
5.2.2.1. L3VPN-PE
An L3VPN-PE is a device or set of devices at the edge of the provider
network interfacing the customer network, with the functionality
needed for an L3VPN.
5.2.2.2. VPWS-PE
A VPWS-PE is a device or set of devices at the edge of the provider
network interfacing the customer network, with the functionality
needed for a VPWS.
5.2.2.3. VPLS-PE
A VPLS-PE is a device or set of devices at the edge of the provider
network interfacing the customer network, with the functionality
needed for a VPLS.
5.2.3. Distribution based PE naming
For scaling reasons it is in the VPLS/VPWS cases sometimes desired to
distribute the functions in the VPLS/VPWS-PE across more than one
device, e.g. is it feasible to allocate MAC address learning on a
comparatively small and in-expensive device close to the customer
site, while participation in the PSN signalling and set up of PE to
PE tunnels are done by routers closer to the network core.
When distributing functionality across devices a protocol is needed
to exchange information between the Network facing PE (N-PE) (see
section 5.2.3.1) and the User facing PE (U-PE) (see section 5.2.3.2).
5.2.3.1. Network facing PE (N-PE)
The N-PE is the device to which the signalling and control functions
are allocated when a VPLS-PE is distributed across more than one box.
5.2.3.2. User facing PE (U-PE)
The U-PE is the device to which the functions needed to take forward-
ing or switching decision at the ingress of the provider network.
Andersson & Madsen [Page 12]
Internet-Draft PPVPN Terminology March 2003
5.3. Core
5.3.1. Provider router (P)
The P is defined as a router in the core network that does not have
interfaces directly towards a customer. Hence a P router does not
need to keep VPN state and is VPN un-aware.
5.4. Naming in specific Internet drafts
Pc "Layer 2 PE (L2PE)"
L2PE is the joint name of the devices in the provider network that
implement L2 functions needed for a VPLS or a VPWS.
5.4.1. Logical PE (LPE)
The term Logical PE (LPE) originates from [LPE] and is used to
describe a set of devices used in a provider network to implement a
VPLS. In a LPE VPLS functions are distributed across small devices
(PE-Edges/U-PE) and devices attached to a network core (PE-Core/N-
PE). In an LPE solution the PE-edge and PE-Core can be interconnected
by a switched Ethernet transport network(s) or uplinks. The LPE will
appear to the core network as a single PE. In this document the
devices that constitutes the LPE is called N-PE and U-PE.
5.4.2. PE-CLE
Name for the U-PE in [sajassi].
5.4.3. PE-Core
See use in section 5.4.2.
5.4.4. PE-Edge
See use in section 5.4.2.
Andersson & Madsen [Page 13]
Internet-Draft PPVPN Terminology March 2003
5.4.5. PE-POP
Name for the N-PE in [sajassi].
5.4.6. VPLS Edge (VE)
The term VE originates from [DTLS] and is used to describe the device
used by a provider network to hand off a VPLS to a customer. In this
document the VE is called a VPLS-PE.
This name has dated.
6. Functions
In this section we have grouped a number of concepts and terms that
has to be performed to make the VPN services work.
6.1. Attachment Circuit (AC)
In a Layer 2 VPN the CE is attached to PE via an Attachment Circuit
(AC). The AC may be a physical or logical link.
6.2. Endpoint discovery
Endpoint discovery is the process by which the devices that are aware
of a specific VPN service will find all customer facing ports that
belong to the same service.
The requirements on endpoint discovery and signalling are discussed
in [VPN-discov] and [PPVPN-req].
6.3. Flooding
Flooding is a function related to L2 and L3 services; when a PE
receives a frame with an unknown destination MAC-address, that frame
is send out over (flooded) every other interface.
Andersson & Madsen [Page 14]
Internet-Draft PPVPN Terminology March 2003
6.4. MAC address learning
MAC address learning is a function related to L2 services; when PE
receives a frame with an unknown source MAC-address the relationship
between that MAC-address and interface is learnt for future forward-
ing purposes. In a layer 2 VPN solution from the PPVPN WG, this func-
tion is allocated to the VPLS-PE.
6.4.1. Qualified learning
In qualified learning, the learning decisions at the U-PE are based
on the customer Ethernet frame's MAC address and VLAN tag, if a VLAN
tag exists. If no VLAN tag exists, the default VLAN is assumed.
6.4.2. Unqualified learning
In unqualified learning, learning is based on a customer Ethernet
frame's MAC address only.
6.5. Signaling
Signalling is the process by which the PEs that have VPNs behind them
exchange information to set up PWs, PSN tunnels and tunnel multiplex-
ors. This process might be automated through a protocol or the done
by manual configuration. Different protocols may be used to establish
the PSN tunnels and exchange the tunnel multiplexors.
7. 'Boxes'
We list a set of boxes that will typically be used in an environment
that supports different kinds of VPN services. We have chosen to
include some names of boxes that originate outside the protocol spec-
ifying organisations.
7.1. Aggregation box
The aggregation box is typically an L2 switch that is service un-
aware and is used only to aggregate traffic to more function rich
points in the network.
Andersson & Madsen [Page 15]
Internet-Draft PPVPN Terminology March 2003
7.2. Customer Premises Equipment (CPE)
The CPE equipment is the box that a provider places with the cus-
tomer. It serves two purposes , giving the customer ports to plug in
to and making it possible for a provider to monitor the connectivity
to the customer site. The CPE is typically a low cost box with lim-
ited functionality and in most cases not aware of the VPN services
offered by the provider network.
The CPE equipment is not necessarily the equipment to which the CE
functions are allocated, but is part of the provider network and used
for monitoring purposes.
The CPE name is used primarily in network operation and deployment
contexts, and should not be used in protocol specifications.
7.3. Multi Tenant Unit (MTU)
An MTU [DTLS] is typically an L2 switch placed by a service provider
in a building where customers of that service provider are located.
The MTU device name is used primarily in network operation and
deployment contexts, and should not be used in protocol specifica-
tions, as it is also a used abbreviation for Maximum Transmit Units.
8. Packet Switched Network (PSN)
A PSN is the network through which the tunnels supporting the VPN
services are set up.
8.1. Route Distinguisher (RD)
A Route Distinguisher [RFC2547bis] is an 8-byte value that together
with a 4 byte IPv4 address identifies a VPN-Ipv4 address family. If
two VPNs use the same Ipv4 address prefix, the PEs translates 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.
Andersson & Madsen [Page 16]
Internet-Draft PPVPN Terminology March 2003
8.2. Route Target (RT)
A Route Target attribute [RFC2547bis] can be thought of as identify-
ing a set of sites, or more precisely a set of VRFs (see section8.8).
Associating a particular Route Target with a route, allows that route
to be placed in all VRFs that are used for routing traffic received
from the corresponding sites.
A Route Target attribute is also a BGP extended community used in
[RFC2547], and [BGPVPN-auto]. 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 pre-
cisely a set of VRFs.
8.3. Tunnel
A tunnel is connectivity through a PSN that is used to send traffic
across the network from one PE to another. The tunnel provides a
mechanism to transport packets from one PE to another, separation of
one customer's traffic from another customer's traffic is done based
on tunnel multiplexors (see section 8.4). How the tunnel is estab-
lished depends on the tunnelling mechanisms provided by the PSN, i.e.
the tunnel could be based on e.g. the IP-header, an MPLS label, the
L2TP Session ID, or on the GRE Key field.
8.4. Tunnel multiplexor
A tunnel multiplexor is an entity that is sent with the packets
traversing the tunnel to make possible to decide to which instance of
a service a packet belongs and from which sender it was received. In
[L2VPN] the tunnel multiplexor is formatted as an MPLS label.
8.5. Virtual Channel (VC)
A VC is transported within a tunnel and identified by its tunnel mul-
tiplexor. A virtual channel is identified by a VCI (Virtual Channel
Identifier). In the PPVPN context a VCI is a VC label or tunnel mul-
tiplexor and in the Martini case it is equal to the VCID.
Andersson & Madsen [Page 17]
Internet-Draft PPVPN Terminology March 2003
8.6. VC label
In an MPLS enabled IP network a VC label is an MPLS label, used to
identify traffic within a tunnel that belongs to a particular VPN,
i.e. the VC label is the tunnel multiplexor in networks that uses
MPLS labels.
8.7. Inner label
"Inner label" is another name for VC label (see section 8.6).
8.8. VPN Routing and Forwarding (VRF)
In networks running 2547 VPN's [RFC2547], PE routers maintain VRF's.
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 particu-
lar packet's IP destination address is looked up in a particular VRF
only if that packet has arrived directly from a site, which is asso-
ciated with that table.
8.9. VPN Forwarding Instance (VFI)
VPN Forwarding Instance (VFI) is a logical entity that resides in a
PE that includes the router information base and forwarding informa-
tion base for a VPN instance [PPVPN-frmwrk].
8.10 Virtual Switch Instance (VSI)
In a layer 2 context a VSI is a virtual switching instance that
serves one single VPLS [L2-frmwrk]. A VSI performs standard LAN
(i.e., Ethernet) bridging functions. Forwarding done by a VSI is
based on MAC addresses and VLAN tags, and possibly other relevant
information on a per VPLS basis. The VSI is allocated to VPLS-PE or
in the distributed case to the U-PE.
8.10. Virtual Router (VR)
A Virtual Router (VR) is software and hardware based emulation of a
physical router. Virtual routers have independent IP routing and for-
warding tables and they are isolated from each other, see [PPVPN-VR].
Andersson & Madsen [Page 18]
Internet-Draft PPVPN Terminology March 2003
9. Acknowledgements
Much of the content in this document is based on discussion in the
PPVPN design teams for "auto discovery" and "l2vpn".
10. Authors' Contact
Loa Andersson
loa@pi.se
Tove Madsen
tove@nibelungen.net
11. Normative References
[GENERIC]
Nagarajan, A (ed), "Generic Requirements for Provider Provisioned
VPN", draft-nagarajan-ppvpn-generic-reqts- 01.txt, Work in Progress,
Internet Draft, Oct 2002
[L2-frmwrk]
Andersson, L and Rosen, E "L2VPN Framework", draft-andersson-ppvpn-
l2-framework-02.txt, Work in Progress, Internet Draft, Jan
2003
[L3VPN-frmwrk]
Callon, R., et.al. "A Framework for Layer 3 Provider Provisioned Vir-
tual Private Networks", draft-ietf-ppvpn-
framework-07.txt, Work in Progress, Internet Draft, Jan
2003
[PPVPN-req]
Carugi, M., et.al. "Service requirements for Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn- requirements-05.txt,
Work in Progress, Internet Draft, Oct 2002
[L2VPN-req]
Waldemar Augustyn and Serbest, Y "Service Requirements for Layer 2
Provider Provisioned Virtual Private Networks", draft-augustyn-ppvpn-
l2vpn-requirements- 02.txt, Work in Progress, Internet Draft, Febru-
ary 2003.
Andersson & Madsen [Page 19]
Internet-Draft PPVPN Terminology March 2003
12. Non-Normative References
[BGPVPN-auto]
Ould-Brahim, H. et.al. "Using BGP as an auto-discovery mechanism for
network-based VPNs", draft-ietf-ppvpn-bgpvpn- auto-02.txt, Work in
progress, Internet Draft, February 2002
[DTLS]
Kompella, K., et.al. draft-kompella-ppvpn-dtls-01.txt, Work in
progress, Internet Draft, November 2001
[kompella-VPLS]
Kompella, K. "Virtual Private LAN Service", draft-kompella- ppvpn-
vpls-01.txt, Work in Progress, Internet Draft, March 2002
[L2VPN]
Kompella, K., et.al. "MPLS-based Layer 2 VPNs" draft- kompella-ppvpn-
l2vpn-02.txt, Work in Progress, June 2002
[lasserre-vkompella]
Kompella, V., Lasserre, M., et.al. "Transparent VLAN Services over
MPLS" draft-lassere-vkompella-ppvpn-vpls- 01.txt, Work in progress,
Mar 2002
[LPE]
Ould-Brahim, H., et.al. "VPLS/LPE L2VPNs: Virtual Private LAN Ser-
vices using Logical PE Architecture", draft- ouldbrahim-l2vpn-
lpe-02.txt, Work in Progress, Internet Draft, March 2002
[martini-encap]
Martini, L., et.al. "draft-martini-l2circuit-encap-mpls- 04.txt",
Work in Progress, Internet Draft, November 2001
[martini-tran]
Martini, L., et.al. "draft-martini-l2circuit-trans-mpls- 09.txt",
Work in progress, Internet Draft, April 2002
[PPVPN-req]
Carugi, M., et.al. "Service requirements for Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn- requirements-04.txt,
Work in Progress, Internet Draft, April 2002
[PPVPN-VR]
Ould-Brahim, H., et.al. "Network-based IP VPN using Virtual Routers",
draft-ietf-ppvpn-vpn-vr-02.txt, Work in Progress, Internet Draft,
February 2002
[PWE3-frmwrk]
Andersson & Madsen [Page 20]
Internet-Draft PPVPN Terminology March 2003
Prayson, P., et.al. "Framework for Pseudo Wire Emulation Edge-to-Edge
(PWE3)", draft-ietf-pwe3-framework-01.txt, Work in Progress, Internet
Draft, June 2002
[PWE3-req]
XiPeng Xiao, et.al. "Requirements for Pseudo-Wire Emulation Edge-to-
Edge (PWE3)", draft-ietf-pwe3-requirements-02.txt
[RFC2547]
Rosen, E., et.al. "BGP/MPLS VPNs", rfc2547, March 1999
[RFC2547bis]
Rosen, E., et.al. "BGP/MPLS VPNs", draft-ietf-ppvpn-
rfc2547bis-01.txt, Work in Progress, Internet Draft, January 2002
[RFC2764]
Gleeson, B., et.al. "A Framework for IP Based Virtual Private Net-
works", rfc2764, February 2000
[sajassi]
Sajassi, A. "VPLS Architectures", draft-sajassi-vpls- architec-
tures-00.txt, Work in Progress, Internet Draft, February 2002
[VPN-discov]
Squire, M. "VPN Discovery Discussions and Options" draft- squire-
ppvpn-vpn-discovery-reqts-00.txt, Work in Progress,
Nov 2001
This document expires on September 1, 2003.
Andersson & Madsen [Page 21]