1. Introduction
This document describes a method by which a Service Provider may use
an IP backbone to provide IP Virtual Private Networks (VPNs) for its
customers. This method uses a "peer model", in which the customers'
edge routers (CE routers) send their routes to the Service Provider's
edge routers (PE routers). Border Gateway Protocol (BGP)
[BGP,BGP-MP] is then used by the Service Provider to exchange the
routes of a particular VPN among the PE routers that are attached to
that VPN. This is done in a way that ensures that routes from
different VPNs remain distinct and separate, even if two VPNs have an
overlapping address space. The PE routers distribute, to the CE
routers in a particular VPN, the routes from other the CE routers in
that VPN. The CE routers do not peer with each other, hence there is
no "overlay" visible to the VPN's routing algorithm. The term "IP"
in "IP VPN" is used to indicate that the PE receives IP datagrams
from the CE, examines their IP headers, and routes them accordingly.
Each route within a VPN is assigned a Multiprotocol Label Switching
(MPLS) [MPLS-ARCH,MPLS-BGP,MPLS-ENCAPS] label; when BGP distributes
a VPN route, it also distributes an MPLS label for that route.
Before a customer data packet travels across the Service Provider's
backbone, it is encapsulated with the MPLS label that corresponds, in
the customer's VPN, to the route that is the best match to the
packet's destination address. This MPLS packet is further
encapsulated (e.g., with another MPLS label or with an IP or Generic
Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that
it gets tunneled across the backbone to the proper PE router. Thus,
the backbone core routers do not need to know the VPN routes.
The primary goal of this method is to support the case in which a
client obtains IP backbone services from a Service Provider or
Service Providers with which it maintains contractual relationships.
The client may be an enterprise, a group of enterprises that need an
extranet, an Internet Service Provider, an application service
provider, another VPN Service Provider that uses this same method to
offer VPNs to clients of its own, etc. The method makes it very
simple for the client to use the backbone services. It is also very
scalable and flexible for the Service Provider, and allows the
Service Provider to add value.
Consider a set of "sites" that are attached to a common network that
we call "the backbone". Now apply some policy to create a number of
subsets of that set, and impose the following rule: two sites may
have IP interconnectivity over that backbone only if at least one of
these subsets contains them both.
These subsets are Virtual Private Networks (VPNs). Two sites have IP
connectivity over the common backbone only if there is some VPN that
contains them both. Two sites that have no VPN in common have no
connectivity over that backbone.
If all the sites in a VPN are owned by the same enterprise, the VPN
may be thought of as a corporate "intranet". If the various sites in
a VPN are owned by different enterprises, the VPN may be thought of
as an "extranet". A site can be in more than one VPN; e.g., in an
intranet and in several extranets. In general, when we use the term
"VPN" we will not be distinguishing between intranets and extranets.
We refer to the owners of the sites as the "customers". We refer to
the owners/operators of the backbone as the "Service Providers"
(SPs). The customers obtain "VPN service" from the SPs.
A customer may be a single enterprise, a set of enterprises, an
Internet Service Provider, an Application Service Provider, another
SP that offers the same kind of VPN service to its own customers,
etc.
The policies that determine whether a particular collection of sites
is a VPN are the policies of the customers. Some customers will want
the implementation of these policies to be entirely the
responsibility of the SP. Other customers may want to share with the
SP the responsibility for implementing these policies. This document
specifies mechanisms that can be used to implement these policies.
The mechanisms we describe are general enough to allow these policies
to be implemented either by the SP alone or by a VPN customer
together with the SP. Most of the discussion is focused on the
former case, however.
The mechanisms discussed in this document allow the implementation of
a wide range of policies. For example, within a given VPN, one can
allow every site to have a direct route to every other site ("full
mesh"). Alternatively, one can force traffic between certain pairs
of sites to be routed via a third site. This can be useful, e.g., if
it is desired that traffic between a pair of sites be passed through
a firewall, and the firewall is located at the third site.
In this document, we restrict our discussion to the case in which the
customer is explicitly purchasing VPN service from an SP, or from a
set of SPs that have agreed to cooperate to provide the VPN service.
That is, the customer is not merely purchasing internet access from
an SP, and the VPN traffic does not pass through a random collection
of interconnected SP networks.
We also restrict our discussion to the case in which the backbone
provides an IP service to the customer, rather than, e.g., a layer 2
service such as Frame Relay, Asynchronous Transfer Mode (ATM),
ethernet, High Level Data Link Control (HDLC), or Point-to-Point
Protocol (PPP). The customer may attach to the backbone via one of
these (or other) layer 2 services, but the layer 2 service is
terminated at the "edge" of the backbone, where the customer's IP
datagrams are removed from any layer 2 encapsulation.
In the rest of this introduction, we specify some properties that
VPNs should have. The remainder of this document specifies a set of
mechanisms that can be deployed to provide a VPN model that has all
these properties. This section also introduces some of the technical
terminology used in the remainder of the document.
Routers can be attached to each other, or to end systems, in a
variety of different ways: PPP connections, ATM Virtual Circuits
(VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area
Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2
Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will use
the term "attachment circuit" to refer generally to some such means
of attaching to a router. An attachment circuit may be the sort of
connection that is usually thought of as a "data link", or it may be
a tunnel of some sort; what matters is that it be possible for two
devices to be network layer peers over the attachment circuit.
Each VPN site must contain one or more Customer Edge (CE) devices.
Each CE device is attached, via some sort of attachment circuit, to
one or more Provider Edge (PE) routers.
Routers in the SP's network that do not attach to CE devices are
known as "P routers".
CE devices can be hosts or routers. In a typical case, a site
contains one or more routers, some of which are attached to PE
routers. The site routers that attach to the PE routers would then
be the CE devices, or "CE routers". However, there is nothing to
prevent a non-routing host from attaching directly to a PE router, in
which case the host would be a CE device.
Sometimes, what is physically attached to a PE router is a layer 2
switch. In this case, we do NOT say that the layer 2 switch is a CE
device. Rather, the CE devices are the hosts and routers that
communicate with the PE router through the layer 2 switch; the layer
2 infrastructure is transparent. If the layer 2 infrastructure
provides a multipoint service, then multiple CE devices can be
attached to the PE router over the same attachment circuit.
CE devices are logically part of a customer's VPN. PE and P routers
are logically part of the SP's network.
The attachment circuit over which a packet travels when going from CE
to PE is known as that packet's "ingress attachment circuit", and the
PE as the packet's "ingress PE". The attachment circuit over which a
packet travels when going from PE to CE is known as that packet's
"egress attachment circuit", and the PE as the packet's "egress PE".
We will say that a PE router is attached to a particular VPN if it is
attached to a CE device that is in a site of that VPN. Similarly, we
will say that a PE router is attached to a particular site if it is
attached to a CE device that is in that site.
When the CE device is a router, it is a routing peer of the PE(s) to
which it is attached, but it is NOT a routing peer of CE routers at
other sites. Routers at different sites do not directly exchange
routing information with each other; in fact, they do not even need
to know of each other at all. As a consequence, the customer has no
backbone or "virtual backbone" to manage, and does not have to deal
with any inter-site routing issues. In other words, in the scheme
described in this document, a VPN is NOT an "overlay" on top of the
SP's network.
With respect to the management of the edge devices, clear
administrative boundaries are maintained between the SP and its
customers. Customers are not required to access the PE or P routers
for management purposes, nor is the SP required to access the CE
devices for management purposes.
If two VPNs have no sites in common, then they may have overlapping
address spaces. That is, a given address might be used in VPN V1 as
the address of system S1, but in VPN V2 as the address of a
completely different system S2. This is a common situation when the
VPNs each use an RFC 1918 private address space. Of course, within
each VPN, each address must be unambiguous.
Even two VPNs that do have sites in common may have overlapping
address spaces, as long as there is no need for any communication
between systems with such addresses and systems in the common sites.
1.4. VPNs with Different Routes to the Same System
Although a site may be in multiple VPNs, it is not necessarily the
case that the route to a given system at that site should be the same
in all the VPNs. Suppose, for example, we have an intranet
consisting of sites A, B, and C, and an extranet consisting of A, B,
C, and the "foreign" site D. Suppose that at site A there is a
server, and we want clients from B, C, or D to be able to use that
server. Suppose also that at site B there is a firewall. We want
all the traffic from site D to the server to pass through the
firewall, so that traffic from the extranet can be access controlled.
However, we don't want traffic from C to pass through the firewall on
the way to the server, since this is intranet traffic.
It is possible to set up two routes to the server. One route, used
by sites B and C, takes the traffic directly to site A. The second
route, used by site D, takes the traffic instead to the firewall at
site B. If the firewall allows the traffic to pass, it then appears
to be traffic coming from site B, and follows the route to site A.
The SP's backbone consists of the PE routers, as well as other
routers ("P routers") that do not attach to CE devices.
If every router in an SP's backbone had to maintain routing
information for all the VPNs supported by the SP, there would be
severe scalability problems; the number of sites that could be
supported would be limited by the amount of routing information that
could be held in a single router. It is important therefore that the
routing information about a particular VPN only needs to be present
in the PE routers that attach to that VPN. In particular, the P
routers do not need to have ANY per-VPN routing information
whatsoever. (This condition may need to be relaxed somewhat when
multicast routing is considered. This is not considered further in
this paper, but is examined in [VPN-MCAST].)
So just as the VPN owners do not have a backbone or "virtual
backbone" to administer, the SPs themselves do not have a separate
backbone or "virtual backbone" to administer for each VPN. Site-to-
site routing in the backbone is optimal (within the constraints of
the policies used to form the VPNs) and is not constrained in any way
by an artificial "virtual topology" of tunnels.
Section 10 discusses some of the special issues that arise when the
backbone spans several Service Providers.
VPNs of the sort being discussed here, even without making use of
cryptographic security measures, are intended to provide a level of
security equivalent to that obtainable when a layer 2 backbone (e.g.,
Frame Relay) is used. That is, in the absence of misconfiguration or
deliberate interconnection of different VPNs, it is not possible for
systems in one VPN to gain access to systems in another VPN. Of
course, the methods described herein do not by themselves encrypt the
data for privacy, nor do they provide a way to determine whether data
has been tampered with en route. If this is desired, cryptographic
measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec].)
Security is discussed in more detail in Section 13.
