inherits whatever capabilities exist in the delivery protocol (IP).
Additional mechanisms, such as Diffserv or RSVP extensions
[RFC2746], can be applied.
o Tunnel setup and maintenance
There is no standard signaling protocol for setting up and
maintaining GRE tunnels.
o Large MTUs and minimization of tunnel overhead
When GRE encapsulation is used, the resulting packet consists of a
delivery protocol header, followed by a GRE header, followed by the
payload packet. When the delivery protocol is IPv4, and if the key
field is not present, GRE encapsulation adds at least 28 bytes of
overhead (36 bytes if key field extension is used.)
o Security
GRE encapsulation does not provide any significant security. The
optional key field can be used as a clear text password to aid in
the detection of misconfigurations, but it does not provide
integrity or authentication. An SP network which supports VPNs
must do extensive IP address filtering at its borders to prevent
spoofed packets from penetrating the VPNs. If multi-provider VPNs
are being supported, it may be difficult to set up these filters.
4.3.6.2. IP-in-IP Encapsulation [RFC2003] [RFC2473]
IP-in-IP specifies the format and procedures for IP-in-IP
encapsulation. This allows an IP datagram to be encapsulated within
another IP datagram. That is, the resulting packet consists of an
outer IP header, followed immediately by the payload packet. There
is no intermediate header as in GRE. [RFC2003] and [RFC2473] specify
IPv4 and IPv6 encapsulations respectively. Once the encapsulated
datagram arrives at the intermediate destination (as specified in the
outer IP header), it is decapsulated, yielding the original IP
datagram, which is then delivered to the destination indicated by the
original destination address field.
o Multiplexing
The IP-in-IP specifications don’t explicitly support multiplexing.
But if a different IP address is used for every VPN then the IP
address field can be used for this purpose. (See section 4.3.2 for
detail).
o QoS/SLA
IP-in-IP itself does not have intrinsic QoS/SLA capabilities, but
of course it inherits whatever capabilities exist for IP.
Additional mechanisms, such as RSVP extensions [RFC2764] or
DiffServ extensions [RFC2983], may be used with it.
o Tunnel setup and maintenance
There is no standard setup and maintenance protocol for IP-in-IP.
o Large MTUs and minimization of tunnel overhead
When the delivery protocol is IPv4, IP-in-IP adds at least 20 bytes
of overhead.
o Security
IP-in-IP encapsulation does not provide any significant security.
An SP network which supports VPNs must do extensive IP address
filtering at its borders to prevent spoofed packets from
penetrating the VPNs. If multi-provider VPNs are being supported,
it may be difficult to set up these filters.
4.3.6.3. IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2409]
IP Security (IPsec) provides security services at the IP layer
[RFC2401]. It comprises authentication header (AH) protocol
[RFC2402], encapsulating security payload (ESP) protocol [RFC2406],
and Internet key exchange (IKE) protocol [RFC2409]. AH protocol
provides data integrity, data origin authentication, and an
anti-replay service. ESP protocol provides data confidentiality and
limited traffic flow confidentiality. It may also provide data
integrity, data origin authentication, and an anti-replay service.
AH and ESP may be used in combination.
IPsec may be employed in either transport or tunnel mode. In
transport mode, either an AH or ESP header is inserted immediately
after the payload packet’s IP header. In tunnel mode, an IP packet
is encapsulated with an outer IP packet header. Either an AH or ESP
header is inserted between them. AH and ESP establish a
unidirectional secure communication path between two endpoints, which
is called a security association. In tunnel mode, PE-PE tunnel (or a
CE-CE tunnel) consists of a pair of unidirectional security
associations. The IPsec and IKE protocols are used for setting up
IPsec tunnels.
o Multiplexing
The SPI field of AH and ESP is used to multiplex security
associations (or tunnels) between two peer devices.
o QoS/SLA
IPsec itself does not have intrinsic QoS/SLA capabilities, but it
inherits whatever mechanisms exist for IP. Other mechanisms such
as "RSVP Extensions for IPsec Data Flows" [RFC2207] or DiffServ
extensions [RFC2983] may be used with it.
o Tunnel setup and maintenance
The IPsec and IKE protocols are used for the setup and maintenance
of tunnels.
o Large MTUs and minimization of tunnel overhead
IPsec transport mode adds at least 8 bytes of overhead. IPsec
tunnel mode adds at least 28 bytes of overhead. IPsec transport
mode adds minimal overhead. In PE-based PPVPNs, the processing
overhead of IPsec (due to its cryptography) may limit the PE’s
performance, especially if privacy is being provided; this is not
generally an issue in CE-based PPVPNs.
o Security
When IPsec tunneling is used in conjunction with IPsec’s
cryptographic capabilities, excellent authentication and integrity
functions can be provided. Privacy can also be optionally
provided.
4.3.6.4. MPLS [RFC3031] [RFC3032] [RFC3035]
Multiprotocol Label Switching (MPLS) is a method for forwarding
packets through a network. Routers at the edge of a network apply
simple labels to packets. A label may be inserted between the data
link and network headers, or may be carried in the data link header
(e.g., the VPI/VCI field in an ATM header). Routers in the network
switch packets according to the labels, with minimal lookup overhead.
A path, or a tunnel in the PPVPN, is called a "label switched path
(LSP)".
o Multiplexing
LSPs may be multiplexed within other LSPs.
o QoS/SLA
MPLS does not have intrinsic QoS or SLA management mechanisms, but
bandwidth may be allocated to LSPs, and their routing may be
explicitly controlled. Additional techniques such as DiffServ and
DiffServ aware traffic engineering may be used with it [RFC3270]
[MPLS-DIFF-TE]. QoS capabilities from IP may be inherited.
o Tunnel setup and maintenance
LSPs are set up and maintained by LDP (Label Distribution
Protocol), RSVP (Resource Reservation Protocol) [RFC3209], or BGP.
o Large MTUs and minimization of tunnel overhead.
MPLS encapsulation adds four bytes per label. VPN-2547BIS’s
[VPN-2547BIS] approach uses at least two labels for encapsulation
and adds minimal overhead.
o Encapsulation
MPLS packets may optionally be encapsulated in IP or GRE, for cases
where it is desirable to carry MPLS packets over an IP-only
infrastructure.
o Security
MPLS encapsulation does not provide any significant security. An
SP which is providing VPN service can refuse to accept MPLS packets
from outside its borders. This provides the same level of
assurance as would be obtained via IP address filtering when
IP-based encapsulations are used. If a VPN is jointly provided by
multiple SPs, care should be taken to ensure that a labeled packet
is accepted from a neighboring router in another SP only if its top
label is one which was actually distributed to that router.
o Applicability
MPLS is the only one of the encapsulation techniques that cannot be
guaranteed to run over any IP network. Hence it would not be
applicable when transparency to the Internet is a requirement.
If the VPN backbone consists of several cooperating SP networks
which support MPLS, then the adjacent networks may support MPLS at
their interconnects. If two cooperating SP networks which support
MPLS are separated by a third which does not support MPLS, then
MPLS-in-IP or MPLS-in-IPsec tunneling may be done between them.
4.4. PE-PE Distribution of VPN Routing Information
In layer 3 PE-based VPNs, PE devices examine the IP headers of
packets they receive from the customer networks. Forwarding is based
on routing information received from the customer network. This
implies that the PE devices need to participate in some manner in
routing for the customer network. Section 3.3 discussed how routing
would be done in the customer network, including the customer
interface. In this section, we discuss ways in which the routing
information from a particular VPN may be passed, over the shared VPN
backbone, among the set of PEs attaching to that VPN.
The PEs needs to distribute two types of routing information to each
other: (i) Public Routing: routing information which specifies how to
reach addresses on the VPN backbone (i.e., "public addresses"); call
this "public routing information" (ii) VPN Routing: routing
information obtained from the CEs, which specifies how to reach
addresses ("private addresses") that are in the VPNs.
The way in which routing information in the first category is
distributed is outside the scope of this document; we discuss only
the distribution of routing information in the second category. Of
course, one of the requirements for distributing VPN routing
information is that it be kept separate and distinct from the public
information. Another requirement is that the distribution of VPN
routing information not destabilize or otherwise interfere with the
distribution of public routing information.
Similarly, distribution of VPN routing information associated with
one VPN should not destabilize or otherwise interfere with the
operation of other VPNs. These requirements are, for example,
relevant in the case that a private network might be suffering from
instability or other problems with its internal routing, which might
be propagated to the VPN used to support that private network.
Note that this issue does not arise in CE-based VPNs, as in CE-based
VPNs, the PE devices do not see packets from the VPN until after the
packets haven been encapsulated in an outer header that has only
public addresses.
4.4.1. Options for VPN Routing in the SP
The following technologies can be used for exchanging VPN routing
information discussed in sections 3.3.1.3 and 4.1.
o Static routing
o RIP [RFC2453]
o OSPF [RFC2328]
o BGP-4 [RFC1771]
4.4.2. VPN Forwarding Instances (VFIs)
In layer 3 PE-based VPNs, the PE devices receive unencapsulated IP
packets from the CE devices, and the PE devices use the IP
destination addresses in these packets to help make their forwarding
decisions. In order to do this properly, the PE devices must obtain
routing information from the customer networks. This implies that
the PE device participates in some manner in the customer network’s
routing.
In layer 3 PE-based VPNs, a single PE device connected to several CE
devices that are in the same VPN, and it may also be connected to CE
devices of different VPNs. The route which the PE chooses for a
given IP destination address in a given packet will depend on the VPN
from which the packet was received. A PE device must therefore have
a separate forwarding table for each VPN to which it is attached. We
refer to these forwarding tables as "VPN Forwarding Instances"
(VFIs), as defined in section 2.1.
A VFI contains routes to locally attached VPN sites, as well as
routes to remote VPN sites. Section 4.4 discusses the way in which
routes to remote sites are obtained.
Routes to local sites may be obtained in several ways. One way is to
explicitly configure static routes into the VFI. This can be useful
in simple deployments, but it requires that one or more devices in
the customer’s network be configured with static routes (perhaps just
a default route), so that traffic will be directed from the site to
the PE device.
Another way is to have the PE device be a routing peer of the CE
device, in a routing algorithm such as RIP, OSPF, or BGP. Depending
on the deployment scenario, the PE might need to advertise a large
number of routes to each CE (e.g., all the routes which the PE
obtained from remote sites in the CE’s VPN), or it might just need to
advertise a single default route to the CE.
A PE device uses some resources in proportion to the number of VFIs
that it has, particularly if a distinct dynamic routing protocol
instance is associated with each VFI. A PE device also uses some
resources in proportion to the total number of routes it supports,
where the total number of routes includes all the routes in all its
VFIs, and all the public routes. These scaling factors will limit
the number of VPNs which a single PE device can support.
When dynamic routing is used between a PE and a CE, it is not
necessarily the case that each VFI is associated with a single
routing protocol instance. A single routing protocol instance may
provide routing information for multiple VFIs, and/or multiple
routing protocol instances might provide information for a single
VFI. See sections 4.4.3, 4.4.4, 3.3.1, and 3.3.1.3 for details.
There are several options for how VPN routes are carried between the
PEs, as discussed below.
4.4.3. Per-VPN Routing
One option is to operate separate instances of routing protocols
between the PEs, one instance for each VPN. When this is done,
routing protocol packets for each customer network need to be
tunneled between PEs. This uses the same tunneling method, and
optionally the same tunnels, as is used for transporting VPN user
data traffic between PEs.
With per-VPN routing, a distinct routing instance corresponding to
each VPN exists within the corresponding PE device. VPN-specific
tunnels are set up between PE devices (using the control mechanisms
that were discussed in sections 3 and 4). Logically these tunnels
are between the VFIs which are within the PE devices. The tunnels
then used as if they were normal links between normal routers.
Routing protocols for each VPN operate between VFIs and the routers
within the customer network.
This approach establishes, for each VPN, a distinct "control plane"
operating across the VPN backbone. There is no sharing of control
plane by any two VPNs, nor is there any sharing of control plane by
the VPN routing and the public routing. With this approach each PE
device can logically be thought of as consisting of multiple
independent routers.
The multiple routing instances within the PE device may be separate
processes, or may be in the same process with different data
structures. Similarly, there may be mechanisms internal to the PE
devices to partition memory and other resources between routing
instances. The mechanisms for implementing multiple routing
instances within a single physical PE are outside of the scope of
this framework document, and are also outside of the scope of other
standards documents.
This approach tends to minimize the explicit interactions between
different VPNs, as well as between VPN routing and public routing.
However, as long as the independent logical routers share the same
hardware, there is some sharing of resources, and interactions are
still possible. Also, each independent control plane has its
associated overheads, and this can raise issues of scale. For
example, the PE device must run a potentially large number of
independent routing "decision processes," and must also maintain a
potentially very large number of routing adjacencies.
4.4.4. Aggregated Routing Model
Another option is to use one single instance of a routing protocol
for carrying VPN routing information between the PEs. In this
method, the routing information for multiple different VPNs is
aggregated into a single routing protocol.
This approach greatly reduces the number of routing adjacencies which
the PEs must maintain, since there is no longer any need to maintain
more than one such adjacency between a given pair of PEs. If the
single routing protocol supports a hierarchical route distribution
mechanism (such as BGP’s "route reflectors"), the PE-PE adjacencies
can be completely eliminated, and the number of backbone adjacencies
can be made into a small constant which is independent of the number
of PE devices. This improves the scaling properties.
Additional routing instances may still be needed to support the
exchange of routing information between the PE and its locally
attached CEs. These can be eliminated, with a consequent further
improvement in scalability, by using static routing on the PE-CE
interfaces, or possibly by having the PE-CE routing interaction use
the same protocol instance that is used to distribute VPN routes
across the VPN backbone (see section 4.4.4.2 for a way to do this).
With this approach, the number of routing protocol instances in a PE
device does not depend on the number of CEs supported by the PE
device, if the routing between PE and CE devices is static or BGP-4.
However, CE and PE devices in a VPN exchange route information inside
a VPN using a routing protocol except for BGP-4, the number of
routing protocol entities in a PE device depends on the number of CEs
supported by the PE device.
In principle it is possible for routing to be aggregated using either
BGP or on an IGP.
4.4.4.1. Aggregated Routing with OSPF or IS-IS
When supporting VPNs, it is likely that there can be a large number
of VPNs supported within any given SP network. In general only a
small number of PE devices will be interested in the operation of any
one VPN. Thus while the total amount of routing information related
to the various customer networks will be very large, any one PE needs
to know about only a small number of such networks.
Generally SP networks use OSPF or IS-IS for interior routing within
the SP network. There are very good reasons for this choice, which
are outside of the scope of this document.
Both OSPF and IS-IS are link state routing protocols. In link state
routing, routing information is distributed via a flooding protocol.
The set of routing peers is in general not fully meshed, but there is
a path from any router in the set to any other. Flooding ensures
that routing information from any one router reaches all the others.
This requires all routers in the set to maintain the same routing
information. One couldn’t withhold any routing information from a
particular peer unless it is known that none of the peers further
downstream will need that information, and in general this cannot be
known.
As a result, if one tried to do aggregated routing by using OSPF,
with all the PEs in the set of routing peers, all the PEs would end
up with the exact same routing information; there is no way to
constrain the distribution of routing information to a subset of the
PEs. Given the potential magnitude of the total routing information
required for supporting a large number of VPNs, this would have
unfortunate scaling implications.
In some cases VPNs may span multiple areas within a provider, or span
multiple providers. If VPN routing information were aggregated into
the IGP used within the provider, then some method would need to be
used to extend the reach of IGP routing information between areas and
between SPs.
4.4.4.2. Aggregated Routing with BGP
In order to use BGP for aggregated routing, the VPN routing
information must be clearly distinguished from the public Internet
routing information. This is typically done by making use of BGP’s
capability of handling multiple address families, and treating the
VPN routes as being in a different address family than the public
Internet routes. Typically a VPN route also carries attributes which
depend on the particular VPN or VPNs to which that route belongs.
When BGP is used for carrying VPN information, the total amount of
information carried in BGP (including the Internet routes and VPN
routes) may be quite large. As noted above, there may be a large
number of VPNs which are supported by any particular provider, and
the total amount of routing information associated with all VPNs may
be quite large. However, any one PE will in general only need to be
aware of a small number of VPNs. This implies that where VPN routing
information is aggregated into BGP, it is desirable to be able to
limit which VPN information is distributed to which PEs.
In "Interior BGP" (IBGP), routing information is not flooded; it is
sent directly, over a TCP connection, to the peer routers (or to a
route reflector). These peer routers (unless they are route
reflectors) are then not even allowed to redistribute the information
to each other. BGP also has a comprehensive set of mechanisms for
constraining the routing information that any one peer sends to
another, based on policies established by the network administration.
Thus IBGP satisfies one of the requirements for aggregated routing
within a single SP network - it makes it possible to ensure that
routing information relevant to a particular VPN is processed only by
the PE devices that attach to that VPN. All that is necessary is
that each VPN route be distributed with one or more attributes which
identify the distribution policies. Then distribution can be
constrained by filtering against these attributes.
In "Exterior BGP" (EBGP), routing peers do redistribute routing
information to each other. However, it is very common to constrain
the distribution of particular items of routing information so that
they only go to those exterior peers who have a "need to know,"
although this does require a priori knowledge of which paths may
validly lead to which addresses. In the case of VPN routing, if a
VPN is provided by a small set of cooperating SPs, such constraints
can be applied to ensure that the routing information relevant to
that VPN does not get distributed anywhere it doesn’t need to be. To
the extent that a particular VPN is supported by a small number of
cooperating SPs with private peering arrangements, this is
particularly straightforward, as the set of EBGP neighbors which need
to know the routing information from a particular VPN is easier to
determine.
BGP also has mechanisms (such as "Outbound Route Filtering," ORF)
which enable the proper set of VPN routing distribution constraints
to be dynamically distributed. This reduces the management burden of
setting up the constraints, and hence improves scalability.
Within a single routing domain (in the layer 3 VPN context, this
typically means within a single SP’s network), it is common to have
the IBGP routers peer directly with one or two route reflectors,
rather than having them peer directly with each other. This greatly
reduces the number of IBGP adjacencies which any one router must
support. Further, a route reflector does not merely redistribute
routing information, it "digests" the information first, by running
its own decision processes. Only routes which survive the decision
process are redistributed.
As a result, when route reflectors are used, the amount of routing
information carried around the network, and in particular, the amount
of routing information which any given router must receive and
process, is greatly reduced. This greatly increases the scalability
of the routing distribution system.
It has already been stated that a given PE has VPN routing
information only for those PEs to which it is directly attached. It
is similarly important, for scalability, to ensure that no single
route reflector should have to have all the routing information for
all VPNs. It is after all possible for the total number of VPN
routes (across all VPNs supported by an SP) to exceed the number
which can be supported by a single route reflector. Therefore, the
VPN routes may themselves be partitioned, with some route reflectors
carrying one subset of the VPN routes and other route reflectors
carrying a different subset. The route reflectors which carry the
public Internet routes can also be completely separate from the route
reflectors that carry the VPN routes.