The network management function may use a combination of SNMP
manager, directory service (e.g., LDAP [RFC3377]), or proprietary
network management system.
2.1.2. Relationship Between CE and PE
For robustness, a CE device may be connected to more than one PE
device, resulting in a multi-homing arrangement. Four distinct types
of multi-homing arrangements, shown in Figure 2.4, may be supported.
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
This type includes a CE device connected
to a PE device via two access connections.
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
Figure 2.4: Four types of double-homing arrangements.
2.1.3. Interworking Model
It is quite natural to assume that multiple different layer 3 VPN
approaches may be implemented, particularly if the VPN backbone
includes more than one SP network. For example, (1) each SP chooses
one or more layer 3 PE-based VPN approaches out of multiple vendor’s
implementations, implying that different SPs may choose different
approaches; and (2) an SP may deploy multiple networks of layer 3
PE-based VPNs (e.g., an old network and a new network). Thus it is
important to allow interworking of layer 3 PE-based VPNs making use
of multiple different layer 3 VPN approaches.
There are three scenarios that enable layer 3 PE-based VPN
interworking among different approaches.
o Interworking function
This scenario enables interworking using a PE that is located at
one or more points which are logically located between VPNs based
on different layer 3 VPN approaches. For example, this PE may be
located on the boundary between SP networks which make use of
different layer 3 VPN approaches [VPN-DISC]. A PE at one of these
points is called an interworking function (IWF), and an example
configuration is shown in Figure 2.5.
+------------------+ +------------------+
| | | |
+------+ VPN tunnel +------+ VPN tunnel +------+
| |==============| |==============| |
| | | | | |
| PE | | PE | | PE |
| | |device| | |
|device| |(IWF) | |device|
| | VPN tunnel | | VPN tunnel | |
| |==============| |==============| |
+------+ +------+ +------+
| | | |
+------------------+ +------------------+
|<-VPN approach 1->| |<-VPN approach 2->|
Figure 2.5: Interworking function.
o Interworking interface
This scenario enables interworking using tunnels between PEs
supporting by different layer 3 VPN approaches. As shown in Figure
2.6, interworking interface is defined as the interface which
exists between a pair of PEs and connects two SP networks
implemented with different approaches. This interface is similar
to the customer interface located between PE and CE, but the
interface is supported by tunnels to identify VPNs, while the
customer interface is supported by access connections.
+------------------+ +------------------+
| | : | |
+------+ VPN tunnel +------+Tunnel: +------+ VPN tunnel +------+
| |============| |======:======| |============| |
| | | | : | | | |
| PE | | PE | : | PE | | PE |
| | | | : | | | |
|device| |device| : |device| |device|
| | VPN tunnel | |Tunnel: | | VPN tunnel | |
| |============| |======:======| |============| |
+------+ +------+ : +------+ +------+
| | : | |
+------------------+ Interworking +------------------+
|<-VPN approach 1->| interface |<-VPN approach 2->|
Figure 2.6: Interworking interface.
o Customer-based interworking
If some customer site has a CE attached to one kind of VPN, and a
CE attached to another kind, communication between the two kinds of
VPN occurs automatically.
2.2. Reference Model for Layer 3 Provider-Provisioned CE-based VPN
This subsection describes functional components and their
relationship for implementing layer 3 provider-provisioned CE-based
VPN.
Figure 2.7 shows the reference model for layer 3 provider-provisioned
CE-based VPN. As shown in Figure 2.7, the customer interface is
defined as the interface which exists between CE and PE devices.
In this model, a CE device maintains one or more VPN tunnel
endpoints, and a PE device has no VPN-specific functionality. As a
result, the interworking issues of section 2.1.3 do not arise.
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel |router| |device| : | of |
| of |=:====================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | VPN tunnel +------+ : +------+
|device|=:====================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | | | network |
Figure 2.7: Reference model for layer 3
provider-provisioned CE-based VPN.
2.2.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 CE-based VPNs, a CE
device provides layer 3 connectivity to the customer site. It may
be a router, LSR, or host that maintains one or more VPN tunnel
endpoints. A CE device is attached via an access connection to a
PE device and usually located at the edge of a customer site or
co-located on an SP premises.
o P router (see section 2.1.1)
o Provider edge (PE) device
In the context of layer 3 provider-provisioned CE-based VPNs, a PE
device may be a router, LSR, or other device that has no
VPN-specific functionality. It is attached via an access
connection to one or more CE devices.
o Customer Site (see section 2.1.1)
o SP networks
An SP network is a network administrated by a single service
provider. It is an IP or MPLS network. In the context of layer 3
provider-provisioned CE-based VPNs, the SP network consists of the
SP’s network and the SP’s management functions that manage both its
own network and the customer’s VPN functions on the CE device.
o Access connection (see section 2.1.1)
o Access network (see section 2.1.1)
o VPN tunnel
A VPN tunnel is a logical link between two entities which is
created by encapsulating packets within an encapsulating header for
purpose of transmission between those two entities for support of
VPNs. In the context of layer 3 provider-provisioned CE-based
VPNs, a VPN tunnel is an IP tunnel (e.g., using GRE, IP-in-IP,
IPsec, or L2TP) or an MPLS tunnel between two CE devices over the
SP’s network.
o Customer management function (see section 2.1.1)
o Network management function
The network management function supports the provisioning and
monitoring of PE or CE device attributes and their relationships,
covering PE and CE devices that define the VPN connectivity of the
customer VPNs.
The network management function may use a combination of SNMP
manager, directory service (e.g., LDAP [RFC3377]), or proprietary
network management system.
3. Customer Interface
3.1. VPN Establishment at the Customer Interface
3.1.1. Layer 3 PE-based VPN
It is necessary for each PE device to know which CEs it is attached
to, and what VPNs each CE is associated with.
VPN membership refers to the association of VPNs, CEs, and PEs. A
given CE belongs to one or more VPNs. Each PE is therefore
associated with a set of VPNs, and a given VPN has a set of
associated PEs which are supporting that VPN. If a PE has at least
one attached CE belonging to a given VPN, then state information for
that VPN (e.g., the VPN routes) must exist on that PE. The set of
VPNs that exist on a PE may change over time as customer sites are
added to or removed from the VPNs.
In some layer 3 PE-based PPVPN schemes, VPN membership information
(i.e., information about which PEs are attached to which VPNs) is
explicitly distributed. In others, the membership information is
inferred from other information that is distributed. Different
schemes use the membership information in different ways, e.g., some
to determine what set of tunnels to set up, some to constrain the
distribution of VPN routing information.
A VPN site may be added or deleted as a result of a provisioning
operation carried out by the network administrator, or may be
dynamically added or deleted as a result of a subscriber initiated
operation; thus VPN membership information may be either static or
dynamic, as discussed below.
3.1.1.1. Static Binding
Static binding occurs when a provisioning action binds a particular
PE-CE access link to a particular VPN. For example, a network
administrator may set up a dedicated link layer connection, such as
an ATM VCC or a FR DLCI, between a PE device and a CE device. In
this case the binding between a PE-CE access connection and a
particular VPN to fixed at provisioning time, and remains the same
until another provisioning action changes the binding.
3.1.1.2. Dynamic Binding
Dynamic binding occurs when some real-time protocol interaction
causes a particular PE-CE access link to be temporarily bound to a
particular VPN. For example, a mobile user may dial up the provider
network and carry out user authentication and VPN selection
procedures. Then the PE to which the user is attached is not one
permanently associated with the user, but rather one that is
typically geographically close to where the mobile user happens to
be. Another example of dynamic binding is that of a permanent access
connection between a PE and a CE at a public facility such as a hotel
or conference center, where the link may be accessed by multiple
users in turn, each of which may wish to connect to a different VPN.
To support dynamically connected users, PPP and RADIUS are commonly
used, as these protocols provide for user identification,
authentication and VPN selection. Other mechanisms are also
possible. For example a user’s HTTP traffic may be initially
intercepted by a PE and diverted to a provider hosted web server.
After a dialogue that includes user authentication and VPN selection,
the user can then be connected to the required VPN. This is
sometimes referred to as a "captive portal".
Independent of the particular mechanisms used for user authentication
and VPN selection, an implication of dynamic binding is that a user
for a given VPN may appear at any PE at any time. Thus VPN
membership may change at any time as a result of user initiated
actions, rather than as a result of network provisioning actions.
This suggests that there needs to be a way to distribute membership
information rapidly and reliably when these user-initiated actions
take place.
3.1.2. Layer 3 Provider-Provisioned CE-based VPN
In layer 3 provider-provisioned CE-based VPNs, the PE devices have no
knowledge of the VPNs. A PE device attached to a particular VPN has
no knowledge of the addressing or routing information of that
specific VPN.
CE devices have IP or MPLS connectivity via a connection to a PE
device, which just provides ordinary connectivity to the global IP
address space or to an address space which is unique in a particular
SPs network. The IP connectivity may be via a static binding, or via
some kind of dynamic binding.
The establishment of the VPNs is done at each CE device, making use
of the IP or MPLS connectivity to the others. Therefore, it is
necessary for a given CE device to know which other CE devices belong
to the same VPN. In this context, VPN membership refers to the
association of VPNs and CE devices.
3.2. Data Exchange at the Customer Interface
3.2.1. Layer 3 PE-based VPN
For layer 3 PE-based VPNs, the exchange is normal IP packets,
transmitted in the same form which is available for interconnecting
routers in general. For example, IP packets may be exchanged over
Ethernet, SONET, T1, T3, dial-up lines, and any other link layer
available to the router. It is important to note that those link
layers are strictly local to the interface for the purpose of
carrying IP packets, and are terminated at each end of the customer
interface. The IP packets may contain addresses which, while unique
within the VPN, are not unique on the VPN backbone. Optionally, the
data exchange may use MPLS to carry the IP packets.
3.2.2. Layer 3 Provider-Provisioned CE-based VPN
The data exchanged at the customer interface are always normal IP
packets that are routable on the VPN backbone, and whose addresses
are unique on the VPN backbone. Optionally, MPLS frames can be used,
if the appropriate label-switched paths exist across the VPN
backbone. The PE device does not know whether these packets are VPN
packets or not. At the current time, MPLS is not commonly offered as
a customer-visible service, so that CE-based VPNs most commonly make
use of IP services.
3.3. Customer Visible Routing
Once VPN tunnels are set up between pairs of VPN edge devices, it is
necessary to set up mechanisms which ensure that packets from the
customer network get sent through the proper tunnels. This routing
function must be performed by the VPN edge device.
3.3.1. Customer View of Routing for Layer 3 PE-based VPNs
There is a PE-CE routing interaction which enables a PE to obtain
those addresses, from the customer network, that are reachable via
the CE. The PE-CE routing interaction also enables a CE device to
obtain those addresses, from the customer network, which are
reachable via the PE; these will generally be addresses that are at
other sites in the customer network.
The PE-CE routing interaction can make use of static routing, an IGP
(such as RIP, OSPF, IS-IS, etc.), or BGP.
If the PE-CE interaction is done via an IGP, the PE will generally
maintain at least several independent IGP instances; one for the
backbone routing, and one for each VPN. Thus the PE participates in
the IGP of the customer VPNs, but the CE does not participate in the
backbone’s IGP.
If the PE-CE interaction is done via BGP, the PE MAY support one
instance of BGP for each VPN, as well as an additional instance of
BGP for the public Internet routes. Alternatively, the PE might
support a single instance of BGP, using, e.g., different BGP Address
Families to distinguish the public Internet routes from the VPN
routes.
Routing information which a PE learns from a CE in a particular VPN
must be forwarded to the other PEs that are attached to the same VPN.
Those other PEs must then forward the information in turn to the
other CEs of that VPN.
The PE-PE routing distribution can be done as part of the same
routing instance to which the PE-CE interface belongs.
Alternatively, it can be done via a different routing instance,
possibly using a different routing algorithm. In this case, the PE
must redistribute VPN routes from one routing instance to another.
Note that VPN routing information is never distributed to the P
routers. VPN routing information is known at the edge of the VPN
backbone, but not in the core.
If the VPN’s IGP is different than the routing algorithm running on