be common between multiple approaches.
1.3.1. CE- vs PE-based VPNs
The term "CE-based VPN" (or Customer Edge-based Virtual Private
Network) refers to an approach in which the PE devices do not know
anything about the routing or the addressing of the customer
networks. The PE devices offer a simple IP service, and expect to
receive IP packets whose headers contain only globally unique IP
addresses. What makes a CE-based VPN into a Provider-Provisioned VPN
is that the SP takes on the task of managing and provisioning the CE
devices [VPN-CE].
In CE-based VPNs, the backbone of the customer network is a set of
tunnels whose endpoints are the CE devices. Various kinds of tunnels
may be used (e.g., GRE, IP-in-IP, IPsec, L2TP, MPLS), the only
overall requirement being that sending a packet through the tunnel
requires encapsulating it with a new IP header whose addresses are
globally unique.
For customer provisioned CE-based VPNs, provisioning and management
of the tunnels is the responsibility of the customer network
administration. Typically, this makes use of manual configuration of
the tunnels. In this case the customer is also responsible for
operation of the routing protocol between CE devices. (Note that
discussion of customer provisioned CE-based VPNs is out of scope of
the document).
For provider-provisioned CE-based VPNs, provisioning and management
of the tunnels is the responsibility of the SP. In this case the
provider may also configure routing protocols on the CE devices.
This implies that routing in the private network is partially under
the control of the customer, and partially under the control of the
SP.
For CE-based VPNs (whether customer or provider-provisioned) routing
in the customer network treats the tunnels as layer 2 links.
In a PE-based VPN (or Provider Edge-based Virtual Private Network),
customer packets are carried through the SP networks in tunnels, just
as they are in CE-based VPNs. However, in a PE-based VPN, the tunnel
endpoints are the PE devices, and the PE devices must know how to
route the customer packets, based on the IP addresses that they
carry. In this case, the CE devices themselves do not have to have
any special VPN capabilities, and do not even have to know that they
are part of a VPN.
In this document we will use the generic term "VPN Edge Device" to
refer to the device, attached to both the customer network and the
VPN backbone, that performs the VPN-specific functions. In the case
of CE-based VPNs, the VPN Edge Device is a CE device. In the case of
PE-based VPNs, the VPN Edge Device is a PE device.
1.3.2. Types of PE-based VPNs
Different types of PE-based VPNs may be distinguished by the service
offered.
o Layer 3 service
When a PE receives a packet from a CE, it determines how to forward
the packet by considering both the packet’s incoming link, and the
layer 3 information in the packet’s header.
o Layer 2 service
When a PE receives a frame from a CE, it determines how to forward
the packet by considering both the packet’s incoming link, and the
layer 2 information in the frame header (such as FR, ATM, or MAC
header). (Note that discussion of layer 2 service is out of scope
of the document).
1.3.3. Layer 3 PE-based VPNs
A layer 3 PE-based VPN is one in which the SP takes part in IP level
forwarding based on the customer network’s IP address space. In
general, the customer network is likely to make use of private and/or
non-unique IP addresses. This implies that at least some devices in
the provider network needs to understand the IP address space as used
in the customer network. Typically this knowledge is limited to the
PE devices which are directly attached to the customer.
In a layer 3 PE-based VPN, the provider will need to participate in
some aspects of management and provisioning of the VPNs, such as
ensuring that the PE devices are configured to support the correct
VPNs. This implies that layer 3 PE-based VPNs are by definition
provider-provisioned VPNs.
Layer 3 PE-based VPNs have the advantage that they offload some
aspects of VPN management from the customer network. From the
perspective of the customer network, it looks as if there is just a
normal network; specific VPN functionality is hidden from the
customer network. Scaling of the customer network’s routing might
also be improved, since some layer 3 PE-based VPN approaches avoid
the need for the customer’s routing algorithm to see "N squared"
(actually N*(N-1)/2) point to point duplex links between N customer
sites.
However, these advantages come along with other consequences.
Specifically, the PE devices must have some knowledge of the routing,
addressing, and layer 3 protocols of the customer networks to which
they attach. One consequence is that the set of layer 3 protocols
which can be supported by the VPN is limited to those supported by
the PE (which in practice means, limited to IP). Another consequence
is that the PE devices have more to do, and the SP has more
per-customer management to do.
An SP may offer a range of layer 3 PE-based VPN services. At one end
of the range is a service limited to simply providing connectivity
(optionally including QoS support) between specific customer network
sites. This is referred to as "Network Connectivity Service". There
is a spectrum of other possible services, such as firewalls, user or
site of origin authentication, and address assignment (e.g., using
Radius or DHCP).
1.4. Scope of the Document
This framework document will discuss methods for providing layer 3
PE-based VPNs and layer 3 provider-provisioned CE-based VPNs. This
may include mechanisms which will can be used to constrain
connectivity between sites, including the use and placement of
firewalls, based on administrative requirements [PPVPN-REQ]
[L3VPN-REQ]. Similarly the use and placement of NAT functionality is
discussed. However, this framework document will not discuss methods
for additional services such as firewall administration and address
assignment. A discussion of specific firewall mechanisms and
policies, and detailed discussion of NAT functionality, are outside
of the scope of this document.
This document does not discuss those forms of VPNs that are outside
of the scope of the IETF Provider-Provisioned VPN working group.
Specifically, this document excludes discussion of PPVPNs using VPN
native (non-IP, non-MPLS) protocols as the base technology used to
provide the VPN service (e.g., native ATM service provided using ATM
switches with ATM signaling). However, this does not mean to exclude
multiprotocol access to the PPVPN by customers.
1.5. Terminology
Backdoor Links: Links between CE devices that are provided by the end
customer rather than the SP; may be used to interconnect CE devices
in multiple-homing arrangements.
CE-based VPN: An approach in which 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.
Customer: A single organization, corporation, or enterprise that
administratively controls a set of sites belonging to a VPN.
Customer Edge (CE) Device: The equipment on the customer side of the
SP-customer boundary (the customer interface).
IP Router: A device which forwards IP packets, and runs associated IP
routing protocols (such as OSPF, IS-IS, RIP, BGP, or similar
protocols). An IP router might optionally also be an LSR. The term
"IP router" is often abbreviated as "router".
Label Switching Router: A device which forwards MPLS packets and runs
associated IP routing and signaling protocols (such as LDP, RSVP-TE,
CR-LDP, OSPF, IS-IS, or similar protocols). A label switching router
is also an IP router.
PE-Based VPNs: 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 on 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).
Private Network: A network which allows communication between a
restricted set of sites, over an IP backbone that is used only to
carry traffic to and from those sites.
Provider Edge (PE) Device: The equipment on the SP side of the
SP-customer boundary (the customer interface).
Provider-Provisioned VPNs (PPVPNs): VPNs, whether CE-based or
PE-based, that are actively managed by the SP rather than by the end
customer.
Route Reflectors: An SP-owned network element that is used to
distribute BGP routes to the SP’s BGP-enabled routers.
Virtual Private Network (VPN): Restricted communication between a set
of sites, making use of an IP backbone which is shared by traffic
that is not going to or coming from those sites.
Virtual Router (VR): An instance of one of a number of logical
routers located within a single physical router. Each logical router
emulates a physical router using existing mechanisms and tools for
configuration, operation, accounting, and maintenance.
VPN Forwarding Instance (VFI): A logical entity that resides in a PE
that includes the router information base and forwarding information
base for a VPN.
VPN Backbone: IP and/or MPLS network which is used to carry VPN
traffic between the customer sites of a particular VPN.
VPN Edge Device: Device, attached to both the VPN backbone and the
customer network, which performs VPN-specific functions. For
PE-based VPNs, this is the PE device; for CE-based VPNs, this is the
CE device.
VPN Routing: Routing that is specific to a particular VPN.
VPN Tunnel: A logical link between two PE or two CE entities, used to
carry VPN traffic, and implemented by encapsulating packets that are
transmitted between those two entities.
1.6. Acronyms
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
CE Customer Edge
CLI Command Line Interface
CR-LDP Constraint-based Routing Label Distribution Protocol
EBGP External Border Gateway Protocol
FR Frame Relay
GRE Generic Routing Encapsulation
IBGP Internal Border Gateway Protocol
IKE Internet Key Exchange
IGP Interior Gateway Protocol
(e.g., RIP, IS-IS and OSPF are all IGPs)
IP Internet Protocol (same as IPv4)
IPsec Internet Protocol Security protocol
IPv4 Internet Protocol version 4 (same as IP)
IPv6 Internet Protocol version 6
IS-IS Intermediate System to Intermediate System routing
protocol
L2TP Layer 2 Tunneling Protocol
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LDP Label Distribution Protocol
LSP Label Switched Path
LSR Label Switching Router
MIB Management Information Base
MPLS Multi Protocol Label Switching
NBMA Non-Broadcast Multi-Access
NMS Network Management System
OSPF Open Shortest Path First routing protocol
P Provider equipment
PE Provider Edge
PPVPN Provider-Provisioned VPN
QoS Quality of Service
RFC Request For Comments
RIP Routing Information Protocol
RSVP Resource Reservation Protocol
RSVP-TE Resource Reservation Protocol with Traffic
Engineering Extensions
SNMP Simple Network Management Protocol
SP Service Provider
VFI VPN Forwarding Instance
VPN Virtual Private Network
VR Virtual Router
2. Reference Models
This section describes PPVPN reference models. The purpose of
discussing reference models is to clarify the common components and
pieces that are needed to build and deploy a PPVPN. Two types of
VPNs, layer 3 PE-based VPN and layer 3 provider-provisioned CE-based
VPN are covered in separated sections below.
2.1. Reference Model for Layer 3 PE-based VPN
This subsection describes functional components and their
relationship for implementing layer 3 PE-based VPN.
Figure 2.1 shows the reference model for layer 3 PE-based VPNs and
Figures 2.2 and 2.3 show relationship between entities in the
reference model.
As shown in Figure 2.1, the customer interface is defined as the
interface which exists between CE and PE devices, and the network
interface is defined as the interface which exists between a pair of
PE devices.
Figure 2.2 illustrates a single logical tunnel between each pair of
VFIs supporting the same VPN. Other options are possible. For
example, a single tunnel might occur between two PEs, with multiple
per-VFI tunnels multiplexed over the PE to PE tunnel. Similarly,
there may be multiple tunnels between two VFIs, for example to
optimize forwarding within the VFI. Other possibilities will be
discussed later in this framework document.
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel : |router| |device| : | of |
| of |-:--| |================:===============| |--:-|VPN A|
|VPN A| : | | : +------+ +------+ : +------+
+------+ : | PE | : | | : |
+------+ : |device| Network interface | | : |
| CE | : | | : +------+ : +------+
|device|-:--| |================:===============| |--:-| CE |
| of | : +------+ : VPN tunnel | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | single or multiple SP domains | | network |
Figure 2.1: Reference model for layer 3 PE-based VPN.
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |======================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
| CE | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |======================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 2.2: Relationship between entities in reference model (1).
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==================< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 2.3: Relationship between entities in reference model (2).
2.1.1. Entities in the Reference Model
The entities in the reference model are described below.
o Customer edge (CE) device
In the context of layer 3 provider-provisioned PE-based VPNs, a CE
device may be a router, LSR, or host that has no VPN-specific
functionality. It is attached via an access connection to a PE
device.
o P router
A router within a provider network which is used to interconnect PE
devices, but which does not have any VPN state and does not have
any direct attachment to CE devices.
o Provider edge (PE) device
In the context of layer 3 provider-provisioned PE-based VPNs, a PE
device implements one or more VFIs and maintains per-VPN state for
the support of one or more VPNs. It may be a router, LSR, or other
device that includes VFIs and provider edge VPN functionality such
as provisioning, management, and traffic classification and
separation. (Note that access connections are terminated by VFIs
from the functional point of view). A PE device is attached via an
access connection to one or more CE devices.
o Customer site
A customer site is a set of users that have mutual IP reachability
without use of a VPN backbone that goes beyond the site.
o SP networks
An SP network is an IP or MPLS network administered by a single
service provider.
o Access connection
An access connection represents an isolated layer 2 connectivity
between a CE device and a PE device. Access connections can be,
e.g., dedicated physical circuits, logical circuits (such as FR,
ATM, and MAC), or IP tunnels (e.g., using IPsec, L2TP, or MPLS).
o Access network
An access network provides access connections between CE and PE
devices. It may be a TDM network, layer 2 network (e.g., FR, ATM,
and Ethernet), or IP network over which access is tunneled (e.g.,
using L2TP [RFC2661] or MPLS).
o VPN tunnel
A VPN tunnel is a logical link between two VPN edge devices. A VPN
packet is carried on a tunnel by encapsulating it before
transmitting it over the VPN backbone.
Multiple VPN tunnels at one level may be hierarchically multiplexed
into a single tunnel at another level. For example, multiple per-
VPN tunnels may be multiplexed into a single PE to PE tunnel (e.g.,
GRE, IP-in-IP, IPsec, or MPLS tunnel). This is illustrated in
Figure 2.3. See section 4.3 for details.
o VPN forwarding instance (VFI)
A single PE device is likely to be connected to a number of CE
devices. The CE devices are unlikely to all be in the same VPN.
The PE device must therefore maintain a separate forwarding
instances for each VPN to which it is connected. A VFI is a
logical entity, residing in a PE, that contains the router
information base and forwarding information base for a VPN. The
interaction between routing and VFIs is discussed in section 4.4.2.
o Customer management function
The customer management function supports the provisioning of
customer specific attributes, such as customer ID, personal
information (e.g., name, address, phone number, credit card number,
and etc.), subscription services and parameters, access control
policy information, billing and statistical information, and etc.
The customer management function may use a combination of SNMP
manager, directory service (e.g., LDAP [RFC3377]), or proprietary
network management system.
o Network management function
The network management function supports the provisioning and
monitoring of PE or CE device attributes and their relationships.