scaling properties will be radically different depending on which
type of equipment 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 for example a switched
Ethernet taking forwarding decision packets based on L2 address
information.
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, in the VPLS/VPWS cases sometimes it is desired
to distribute the functions in the VPLS/VPWS-PE across more than one
device. For example, is it feasible to allocate MAC address learning
on a comparatively small and inexpensive device close to the customer
site, while participation in the PSN signalling and setup 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
forwarding or switching decisions at the ingress of the provider
network.
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 toward a customer. Therefore, a P router does
not need to keep VPN state and is VPN unaware.
5.4. Naming in Specific Internet Drafts
5.4.1. 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.2. Logical PE (LPE)
The term Logical PE (LPE) originates from a dated Internet Draft,
"VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE
Architecture", and was 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 or uplinks. The LPE will appear to the core network as a
single PE. In this document, the devices that constitutes, the LPE
are called N-PE and U-PE.
5.4.3. PE-CLE
An alternative name for the U-PE suggested in the expired Internet
Draft, "VPLS architectures".
5.4.4. PE-Core
See the origins and use of this concept in Section 5.4.2.
5.4.5. PE-Edge
See the origins and use of this concept in Section 5.4.2.
5.4.6. PE-POP
An alternative name for the U-PE suggested in the expired Internet
Draft, "VPLS architectures".
5.4.7. VPLS Edge (VE)
The term VE originates from a dated Internet Draft on a distributed
transparent LAN service and was 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 is dated.
6. Functions
In this section, we have grouped a number of concepts and terms that
have 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. Backdoor Links
Backdoor Links are links between CE devices that are provided by the
end customer rather than by the SP; they may be used to interconnect
CE devices in multiple-homing arrangements [L3VPN-FRAME].
6.3. 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 [L3VPN-REQ]. It was also the topic in a now dated Internet Draft
reporting from a design team activity on VPN discovery.
6.4. Flooding
Flooding is a function related to L2 services; when a PE receives a
frame with an unknown destination MAC address, that frame is send out
over (flooded) every other interface.
6.5. 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 learned for future
forwarding purposes. In a layer 2 VPN solution from the L2VPN WG,
this function is allocated to the VPLS-PE.
6.5.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.5.2. Unqualified Learning
In unqualified learning, learning is based on a customer Ethernet
frame’s MAC address only.
6.6. Signalling
Signalling is the process by which the PEs that have VPNs behind them
exchange information to set up PWs, PSN tunnels, and tunnel
multiplexers. This process might be automated through a protocol or
done by manual configuration. Different protocols may be used to
establish the PSN tunnels and exchange the tunnel multiplexers.
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
specifying organisations.
7.1. Aggregation Box
The aggregation box is typically an L2 switch that is service unaware
and is used only to aggregate traffic to more function rich points in
the network.
7.2. Customer Premises Equipment (CPE)
The CPE equipment is the box that a provider places with the
customer. 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 limited functionality and, in most cases, is 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 it is part of the provider network and is 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 is typically an L2 switch placed by a service provider in a
building where several customers of that service provider are
located. The term was introduced in an Internet Draft specifying a
VPLS solution with function distributed between the MTU and the PE in
the context of a [VPLS].
The MTU device name is used primarily in network operation and
deployment contexts and should not be used in protocol
specifications, as it is also an abbreviation used 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 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.
8.2. Route Reflector
A route reflector is a network element owned by a Service Provider
(SP) that is used to distribute BGP routes to the SP’s BGP-enabled
routers [L3VPN-FRAME].
8.3. 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.
8.4. 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
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.
8.5. 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.
8.6. Virtual Channel (VC)
A VC is transported within a tunnel and identified by its tunnel
multiplexer. A virtual channel is identified by a VCI (Virtual
Channel Identifier). In the PPVPN context, a VCI is a VC label or
tunnel multiplexer, and in the Martini case, it is equal to the VCID.
8.7. 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 multiplexer in networks that use
MPLS labels.
8.8. Inner Label
"Inner label" is another name for VC label (see Section 8.6).
8.9. 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.
8.10. 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
information base for a VPN instance [L3VPN-FRAME].
8.11. Virtual Switch Instance (VSI)
In a layer 2 context, a VSI is a virtual switching instance that
serves one single VPLS [L2VPN]. 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 on 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.12. 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].
9. Security Considerations
This is a terminology document and as such doesn’t have direct
security implications. Security considerations will be specific to
solutions, frameworks, and specification documents whose terminology
is collected and discussed in this document.
10. Acknowledgements
Much of the content in this document is based on discussion in the
PPVPN design teams for "auto discovery" and "l2vpn".
Dave McDysan, Adrian Farrel, and Thomas Narten have carefully
reviewed the document and given many useful suggestions.
Thomas Narten converted an almost final version of this document into
XML, after extracting an acceptable version from Word became too
painful. Avri Doria has been very helpful in guiding us in the use
of XML.
11. Informative References
[L2VPN] Andersson, L. and E. Rosen, "Framework for Layer 2
Virtual Private Networks (L2VPNs)", Work in Progress,
June 2004.
[L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider Provisioned Virtual Private
Networks", Work in Progress, October 2004.
[VPLS] Kompella, K., "Virtual Private LAN Service", Work in
Progress, January 2005.
[VPLS-LDP] Lasserre, M. and V. Kompella, "Virtual Private LAN
Services over MPLS", Work in Progress, September 2004.
[BGP-VPN] Ould-Brahim, H., Rosen, E., and Y. Rekhter, "Using BGP
as an Auto-Discovery Mechanism for Layer-3 and Layer-2
VPNs", Work in Progress, May 2004.
[L3VPN-FRAME] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider Provisioned Virtual Private Networks", Work in
Progress, July 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC
3809, June 2004.
[L3VPN-REQ] Carugi, M. and D. McDysan, "Service requirements for
Layer 3 Virtual Private Networks", Work in Progress,
July 2004.
[RFC2547bis] Rosen, E., "BGP/MPLS IP VPNs", Work in Progress,
October 2004.
[L3VPN-VR] Knight, P., Ould-Brahim, H. and B. Gleeson, "Network
based IP VPN Architecture using Virtual Routers", Work
in Progress, April 2004.
[PWE3-ARCH] Bryant, S. and P. Pate, "PWE3 Architecture", Work in
Progress, March 2004.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[PPVPN-L2VPN] Kompella, K., "Layer 2 VPNs Over Tunnels", Work in
Progress, June 2002.
[ENCAP-MPLS] Martini, L., "Encapsulation Methods for Transport of
Layer 2 Frames Over IP and MPLS Networks", Work in
Progress, September 2004.
[TRANS-MPLS] Martini, L. and N. El-Aawar, "Transport of Layer 2
Frames Over MPLS", Work in Progress, June 2004.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
A. Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
Authors’ Addresses
Loa Anderson
Acreo AB
EMail: loa@pi.se
Tove Madsen
Acreo AB
EMail: tove.madsen@acreo.se
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.