the CE-PE link, then the CE must support two routing instances, and
must redistribute the VPN’s routes from one instance to the other
(e.g., [VPN-BGP-OSPF]).
In the case of layer 3 PE-based VPNs a single PE device is likely to
provide service for several different VPNs. Since different VPNs may
have address spaces which are not mutually unique, a PE device must
have several forwarding tables, in general one for each VPN to which
it is attached. These will be referred to as VPN Forwarding
Instances (VFIs). Each VFI is a logical entity internal to the PE
device. VFIs are defined in section 2.1.1, and discussed in more
detail in section 4.4.2.
The scaling and management of the customer network (as well as the
operation of the VPN) will depend upon the implementation approach
and the manner in which routing is done.
3.3.1.1. Routing for Intranets
In the intranet case all of the sites to be interconnected belong to
the same administration (for example, the same company). The options
for routing within a single customer network include:
o A single IGP area (using OSPF, IS-IS, or RIP)
o Multiple areas within a single IGP
o A separate IGP within each site, with routes redistributed from
each site to backbone routing (i.e., to a backbone as seen by the
customer network).
Note that these options look at routing from the perspective of the
overall routing in the customer network. This list does not specify
whether PE device is considered to be in a site or not. This issue
is discussed below.
A single IGP area (such as a single OSPF area, a single IS-IS area,
or a single instance of RIP between routers) may be used. One could
have, all routers within the customer network (including the PEs, or
more precisely, including a VFI within each PE) appear within a
single area. Tunnels between the PEs could also appear as normal
links.
In some cases the multi-level hierarchy of OSPF or IS-IS may be used.
One way to apply this to VPNs would be to have each site be a single
OSPF or IS-IS area. The VFIs will participate in routing within each
site as part of that area. The VFIs may then be interconnected as
the backbone (OSPF area 0 or IS-IS level 2). If OSPF is used, the
VFIs therefore appear to the customer network as area border routers.
If IS-IS is used, the VFIs therefore participate in level 1 routing
within the local area, and appear to the customer network as if they
are level 2 routers in the backbone.
Where an IGP is used across the entire network, it is straightforward
for VPN tunnels, access connections, and backdoor links to be mixed
in a network. Given that OSPF or IS-IS metrics will be assigned to
all links, paths via alternate links can be compared and the shortest
cost path will be used regardless of whether it is via VPN tunnels,
access connections, or backdoor links. If multiple sites of a VPN do
not use a common IGP, or if the backbone does not use the same common
IGP as the sites, then special procedures may be needed to ensure
that routes to/from other sites are treated as intra-area routes,
rather than as external routes (depending upon the VPN approach
taken).
Another option is to operate each site as a separate routing domain.
For example each site could operate as a single OSPF area, a single
IS-IS area, or a RIP domain. In this case the per-site routing
domains will need to redistribute routes into a backbone routing
domain (Note: in this context the "backbone routing domain" refers to
a backbone as viewed by the customer network). In this case it is
optional whether or not the VFIs participate in the routing within
each site.
3.3.1.2. Routing for Extranets
In the extranet case the sites to be interconnected belong to
multiple different administrations. In this case IGPs (such as OSPF,
IS-IS, or RIP) are normally not used across the interface between
organizations. Either static routes or BGP may be used between
sites. If the customer network administration wishes to maintain
control of routing between its site and other networks, then either
static routing or BGP may be used across the customer interface. If
the customer wants to outsource all such control to the provider,
then an IGP or static routes may be used at this interface.
The use of BGP between sites allows for policy based routing between
sites. This is particularly useful in the extranet case. Note that
private IP addresses or non-unique IP address (e.g., unregistered
addresses) should not be used for extranet communication.
3.3.1.3. CE and PE Devices for Layer 3 PE-based VPNs
When using a single IGP area across an intranet, the entire customer
network participates in a single area of an IGP. In this case, for
layer 3 PE-based VPNs both CE and PE devices participate as normal
routers within the area.
The other options make a distinction between routing within a site,
and routing between sites. In this case, a CE device would normally
be considered as part of the site where it is located. However,
there is an option regarding how the PE devices should be considered.
In some cases, from the perspective of routing within the customer
network, a PE device (or more precisely a VFI within a PE device) may
be considered to be internal to the same area or routing domain as
the site to which it is attached. This simplifies the management
responsibilities of the customer network administration, since
inter-area routing would be handled by the provider.
For example, from the perspective of routing within the customer
network, the CE devices may be the area border or AS boundary routers
of the IGP area. In this case, static routing, BGP, or whatever
routing is used in the backbone, may be used across the customer
interface.
3.3.2. Customer View of Routing for Layer 3 Provider-Provisioned
CE-based VPNs
For layer 3 provider-provisioned CE-based VPNs, the PE devices are
not aware of the set of addresses which are reachable at particular
customer sites. The CE and PE devices do not exchange the customer’s
routing information.
Customer sites that belong to the same VPN may exchange routing
information through the CE-CE VPN tunnels that appear, to the
customers IGP, as router adjacencies. Alternatively, instead of
exchanging routing information through the VPN tunnels, the SP’s
management system may take care of the configuration of the static
route information of one site towards the other sites in the VPN.
Routing within the customer site may be done in any possible way,
using any kind of routing protocols (see section 3.3.3).
As the CE device receives an IP or MPLS service from the SP, the CE
and PE devices may exchange routing information that is meaningful
within the SP routing realm.
Moreover, as the forwarding of tunneled customer packets in the SP
network will be based on global IP forwarding, the routes to the
various CE devices must be known in the entire SP’s network.
This means that a CE device may need to participate in two different
routing processes:
o routing in its own private network (VPN routing), within its own
site and with the other VPN sites through the VPN tunnels, possibly
using private addresses.
o routing in the SP network (global routing), as such peering with
its PE.
However, in many scenarios, the use of static/default routes at the
CE-PE interface might be all the global routing that is required.
3.3.3. Options for Customer Visible Routing
The following technologies are available for the exchange of routing
information.
o Static routing
Routing tables may be configured through a management system.
o RIP (Routing Information Protocol) [RFC2453]
RIP is an interior gateway protocol and is used within an
autonomous system. It sends out routing updates at regular
intervals and whenever the network topology changes. Routing
information is then propagated by the adjacent routers to their
neighbors and thus to the entire network. A route from a source to
a destination is the path with the least number of routers. This
number is called the "hop count" and its maximum value is 15. This
implies that RIP is suitable for a small- or medium-sized networks.
o OSPF (Open Shortest Path First) [RFC2328]
OSPF is an interior gateway protocol and is applied to a single
autonomous system. Each router distributes the state of its
interfaces and neighboring routers as a link state advertisement,
and maintains a database describing the autonomous system’s
topology. A link state is advertised every 30 minutes or when the
topology is reconfigured.
Each router maintains an identical topological database, from which
it constructs a tree of shortest paths with itself as the root.
The algorithm is known as the Shortest Path First or SPF. The
router generates a routing table from the tree of shortest paths.
OSPF supports a variable length subnet mask, which enables
effective use of the IP address space.
OSPF allows sets of networks to be grouped together into an area.
Each area has its own topological database. The topology of the
area is invisible from outside its area. The areas are
interconnected via a "backbone" network. The backbone network
distributes routing information between the areas. The area
routing scheme can reduce the routing traffic and compute the
shortest path trees and is indispensable for larger scale networks.
Each multi-access network with multiple routers attached has a
designated router. The designated router generates a link state
advertisement for the multi-access network and synchronizes the
topological database with other adjacent routers in the area. The
concept of designated router can thus reduce the routing traffic
and compute shortest path trees. To achieve high availability, a
backup designated router is used.
o IS-IS (intermediate system to intermediate system) [RFC1195]
IS-IS is a routing protocol designed for the OSI (Open Systems
Interconnection) protocol suites. Integrated IS-IS is derived from
IS-IS in order to support the IP protocol. In the Internet
community, IS-IS means integrated IS-IS. In this, a link state is
advertised over a connectionless network service. IS-IS has the
same basic features as OSPF. They include: link state
advertisement and maintenance of a topological database within an
area, calculation of a tree of shortest paths, generation of a
routing table from a tree of shortest paths, the area routing
scheme, a designated router, and a variable length subnet mask.
o BGP-4 (Border Gateway Protocol version 4) [RFC1771]
BGP-4 is an exterior gateway protocol and is applied to the routing
of inter-autonomous systems. A BGP speaker establishes a session
with other BGP speakers and advertises routing information to them.
A session may be an External BGP (EBGP) that connects two BGP
speakers within different autonomous systems, or an internal BGP
(IBGP) that connects two BGP speakers within a single autonomous
system. Routing information is qualified with path attributes,
which differentiate routes for the purpose of selecting an
appropriate one from possible routes. Also, routes are grouped by
the community attribute [RFC1997] [BGP-COM].
The IBGP mesh size tends to increase dramatically with the number
of BGP speakers in an autonomous system. BGP can reduce the number
of IBGP sessions by dividing the autonomous system into smaller
autonomous systems and grouping them into a single confederation
[RFC3065]. Route reflection is another way to reduce the number of
IBGP sessions [RFC1966]. BGP divides the autonomous system into
clusters. Each cluster establishes the IBGP full mesh within
itself, and designates one or more BGP speakers as "route
reflectors," which communicate with other clusters via their route
reflectors. Route reflectors in each cluster maintain path and
attribute information across the autonomous system. The autonomous
system still functions like a fully meshed autonomous system. On
the other hand, confederations provide finer control of routing
within the autonomous system by allowing for policy changes across
confederation boundaries, while route reflection requires the use
of identical policies.
BGP-4 has been extended to support IPv6, IPX, and others as well as
IPv4 [RFC2858]. Multiprotocol BGP-4 carries routes from multiple
"address families".
4. Network Interface and SP Support of VPNs
4.1. Functional Components of a VPN
The basic functional components of an implementation of a VPN are:
o A mechanism to acquire VPN membership/capability information
o A mechanism to tunnel traffic between VPN sites
o For layer 3 PE-based VPNs, a means to learn customer routes,
distribute them between the PEs, and to advertise reachable
destinations to customer sites.
Based on the actual implementation, these functions could be
implemented on a per-VPN basis or could be accomplished via a common
mechanism shared by all VPNs. For instance, a single process could
handle the routing information for all the VPNs or a separate process
may be created for each VPN.
Logically, the establishment of a VPN can be thought of as composed
of the following three stages. In the first stage, the VPN edge
devices learn of each other. In the second stage, they establish
tunnels to each other. In the third stage, they exchange routing
information with each other. However, not all VPN solutions need be
decomposed into these three stages. For example, in some VPN
solutions, tunnels are not established after learning membership
information; rather, pre-existing tunnels are selected and used.
Also, in some VPN solutions, the membership information and the
routing information are combined.
In the membership/capability discovery stage, membership and
capability information needs to be acquired to determine whether two
particular VPN edge devices support any VPNs in common. This can be
accomplished, for instance, by exchanging VPN identifiers of the
configured VPNs at each VPN edge device. The capabilities of the VPN
edge devices need to be determined, in order to be able to agree on a
common mechanism for tunneling and/or routing. For instance, if site
A supports both IPsec and MPLS as tunneling mechanisms and site B
supports only MPLS, they can both agree to use MPLS for tunneling.
In some cases the capability information may be determined
implicitly, for example some SPs may implement a single VPN solution.
Likewise, the routing information for VPNs can be distributed using
the methods discussed in section 4.4.
In the tunnel establishment stage, mechanisms may need to be invoked
to actually set up the tunnels. With IPsec, for instance, this could
involve the use of IKE to exchange keys and policies for securing the
data traffic. However, if IP tunneling, e.g., is used, there may not
be any need to explicitly set up tunnels; if MPLS tunnels are used,
they may be pre-established as part of normal MPLS functioning.
In the VPN routing stage, routing information for the VPN sites must
be exchanged before data transfer between the sites can take place.
Based on the VPN model, this could involve the use of static routes,
IGPs such as OSPF/ISIS/RIP, or an EGP such as BGP.
VPN membership and capability information can be distributed from a
central management system, using protocols such as, e.g., LDAP.
Alternatively, it can be distributed manually. However, as manual
configuration does not scale and is error prone, its use is
discouraged. As a third alternative, VPN information can be
distributed via protocols that ensure automatic and consistent
distribution of information in a timely manner, much as routing
protocols do for routing information. This may suggest that the
information be carried in routing protocols themselves, though only
if this can be done without negatively impacting the essential
routing functions.
It can be seen that quite a lot of information needs to be exchanged
in order to establish and maintain a VPN. The scaling and stability
consequences need to be analyzed for any VPN approach.
While every VPN solution must address the functionality of all three
components, the combinations of mechanisms used to provide the needed
functionality, and the order in which different pieces of
functionality are carried out, may differ.
For layer 3 provider-provisioned CE-based VPNs, the VPN service is
offering tunnels between CE devices. IP routing for the VPN is done
by the customer network. With these solutions, the SP is involved in
the operation of the membership/capability discovery stage and the
tunnel establishment stage. The IP routing functional component may
be entirely up to the customer network, or alternatively, the SP’s
management system may be responsible for the distribution of the
reachability information of the VPN sites to the other sites of the
same VPN.
4.2. VPN Establishment and Maintenance
For a layer 3 provider-provisioned VPN the SP is responsible for the
establishment and maintenance of the VPNs. Many different approaches
and schemes are possible in order to provide layer 3 PPVPNs, however
there are some generic problems that any VPN solution must address,
including:
o For PE-based VPNs, when a new site is added to a PE, how do the
other PEs find out about it? When a PE first gets attached to a
given VPN, how does it determine which other PEs are attached to
the same VPN. For CE-based VPNs, when a new site is added, how
does its CE find out about all the other CEs at other sites of the
same VPN?
o In order for layer 3 PE-based VPNs to scale, all routes for all
VPNs cannot reside on all PEs. How is the distribution of VPN
routing information constrained so that it is distributed to only
those devices that need it?
o An administrator may wish to provision different topologies for
different VPNs (e.g., a full mesh or a hub & spoke topology). How
is this achieved?
This section looks at some of these generic problems and at some of
the mechanisms that can be used to solve them.
4.2.1. VPN Discovery
Mechanisms are needed to acquire information that allows the
establishment and maintenance of VPNs. This may include, for
example, information on VPN membership, topology, and VPN device
capabilities. This information may be statically configured, or
distributed by an automated protocol. As a result of the operation
of these mechanisms and protocols, a device is able to determine
where to set up tunnels, and where to advertise the VPN routes for
each VPN.
With a physical network, the equivalent problem can by solved by the
control of the physical interconnection of links, and by having a
router run a discovery/hello protocol over its locally connected
links. With VPNs both the routers and the links (tunnels) may be
logical entities, and thus some other mechanisms are needed.
A number of different approaches are possible for VPN discovery. One
scheme uses the network management system to configure and provision
the VPN edge devices. This approach can also be used to distribute
VPN discovery information, either using proprietary protocols or
using standard management protocols and MIBs. Another approach is
where the VPN edge devices act as clients of a centralized directory
or database server that contains VPN discovery information. Another
possibility is where VPN discovery information is piggybacked onto a
routing protocol running between the VPN edge devices [VPN-DISC].
4.2.1.1. Network Management for Membership Information
SPs use network management extensively to configure and monitor the
various devices that are spread throughout their networks. This
approach could be also used for distributing VPN related information.
A network management system (either centralized or distributed) could
be used by the SP to configure and provision VPNs on the VPN edge
devices at various locations. VPN configuration information could be
entered into a network management application and distributed to the
remote sites via the same means used to distribute other network
management information. This approach is most natural when all the
devices that must be provisioned are within a single SP’s network,
since the SP has access to all VPN edge devices in its domain.
Security and access control are important, and could be achieved for
example using SNMPv3, SSH, or IPsec tunnels.
4.2.1.2. Directory Servers
An SP typically needs to maintain a database of VPN
configuration/membership information, regardless of the mechanisms
used to distribute it. LDAPv3 [RFC3377] is a standard directory
protocol which makes it possible to use a common mechanism for both
storing such information and distributing it.
To facilitate interoperability between different implementations, as
well as between the management systems of different SPs, a standard
schema for representing VPN membership and configuration information
would have to be developed.
LDAPv3 supports authentication of messages and associated access
control, which can be used to limit access to VPN information to
authorized entities.
4.2.1.3. Augmented Routing for Membership Information
Extensions to the use of existing BGP mechanisms, for distribution of
VPN membership information, are proposed in [VPN-2547BIS]. In that
scheme, BGP is used to distribute VPN routes, and each route carries
a set of attributes which indicate the VPN (or VPNs) to which the
route belongs. This allows the VPN discovery information and routing
information to be combined in a single protocol. Information needed
to establish per-VPN tunnels can also be carried as attributes of the
routes. This makes use of the BGP protocol’s ability to effectively
carry large amounts of routing information.
It is also possible to use BGP to distribute just the
membership/capability information, while using a different technique
to distribute the routing. BGP’s update message would be used to
indicate that a PE is attached to a particular VPN; BGP’s withdraw
message would be used to indicate that a PE has ceased to be attached
to a particular VPN. This makes use of the BGP protocol’s ability to
dynamically distribute real-time changes in a reliable and fairly
rapid manner. In addition, if a BGP route reflector is used, PEs
never have to be provisioned with each other’s IP addresses at all.
Both cases make use of BGP’s mechanisms, such as route filters, for
constraining the distribution of information.
Augmented routing may be done in combination with aggregated routing,
as discussed in section 4.4.4. Of course, when using BGP for
distributing any kind of VPN-specific information, one must ensure
that one is not disrupting the classical use of BGP for distributing
public Internet routing information. For further discussion of this,
see the discussion of aggregated routing, section 4.4.4.
4.2.1.4. VPN Discovery for Inter-SP VPNs
When two sites of a VPN are connected to different SP networks, the
SPs must support a common mechanism for exchanging
membership/capability information. This might make use of manual
configuration or automated exchange of information between the SPs.
Automated exchange may be facilitated if one or more mechanisms for
VPN discovery are standardized and supported across the multiple SPs.
Inter-SP trust relationships will need to be established, for example
to determine which information and how much information about the
VPNs may be exchanged between SPs.
In some cases different service providers may deploy different
approaches for VPN discovery. Where this occurs, this implies that
for multi-SP VPNs, some manual coordination and configuration may be
necessary.
The amount of information which needs to be shared between SPs may
vary greatly depending upon the number of size of the multi-SP VPNs.