The use of outbound route filters allows any one PE and any one route
reflector to exchange information about only those VPNs which the PE
and route reflector are both interested in. This in turn ensures
that each PE and each route reflector receives routing information
only about the VPNs which it is directly supporting. Large SPs which
support a large number of VPNs therefore can partition the
information which is required for support of those VPNs.
Generally a PE device will be restricted in the total number of
routes it can support, whether those are public Internet routes or
VPN routes. As a result, a PE device may be able to be attached to a
larger number of VPNs if it does not also need to support Internet
routes.
The way in which VPN routes are partitioned among PEs and/or route
reflectors is a deployment issue. With suitable deployment
procedures, the limited capacity of these devices will not limit the
number of VPNs that can be supported.
Similarly, whether a given PE and/or route reflector contains
Internet routes as well as VPN routes is a deployment issue. If the
customer networks served by a particular PE do not need the Internet
access, then that PE does not need to be aware of the Internet
routes. If some or all of the VPNs served by a particular PE do need
the Internet access, but the PE does not contain Internet routes,
then the PE can maintain a default route that routes all the Internet
traffic from that PE to a different router within the SP network,
where that other router holds the full the Internet routing table.
With this approach the PE device needs only a single default route
for all the Internet routes.
For the reasons given above, the BGP protocol seems to be a
reasonable protocol to use for distributing VPN routing information.
Additional reasons for the use of BGP are:
o BGP has been proven to be useful for distributing very large
amounts of routing information; there isn’t any routing
distribution protocol which is known to scale any better.
o The same BGP instance that is used for PE-PE distribution of VPN
routes can be used for PE-CE route distribution, if CE-PE routing
is static or BGP. PEs and CEs are really parts of distinct
Autonomous Systems, and BGP is particularly well-suited for
carrying routing information between Autonomous Systems.
On the other hand, BGP is also used for distributing public Internet
routes, and it is crucially important that VPN route distributing not
compromise the distribution of public Internet routes in any way.
This issue is discussed in the following section.
4.4.5. Scalability and Stability of Routing with Layer 3 PE-based VPNs
For layer 3 PE-based VPNs, there are likely to be cases where a
service provider supports Internet access over the same link that is
used for VPN service. Thus, a particular CE to PE link may carry
both private network IP packets (for transmission between sites of
the private network using VPN services) as well as public Internet
traffic (for transmission from the private site to the Internet, and
for transmission to the private site from the Internet). This
section looks at the scalability and stability of routing in this
case. It is worth noting that this sort of issue may be applicable
where per-VPN routing is used, as well as where aggregated routing is
used.
For layer 3 PE-based VPNs, it is necessary for the PE devices to be
able to forward IP packets using the addresses spaces of the
supported private networks, as well as using the full Internet
address space. This implies that PE devices might in some cases
participate in routing for the private networks, as well as for the
public Internet.
In some cases the routing demand on the PE might be low enough, and
the capabilities of the PE, might be great enough, that it is
reasonable for the PE to participate fully in routing for both
private networks and the public Internet. For example, the PE device
might participate in normal operation of BGP as part of the global
Internet. The PE device might also operate routing protocols (or in
some cases use static routing) to exchange routes with CE devices.
For large installations, or where PE capabilities are more limited,
it may be undesirable for the PE to fully participate in routing for
both VPNs as well as the public Internet. For example, suppose that
the total volume of routes and routing instances supported by one PE
across multiple VPNs is very large. Suppose furthermore that one or
more of the private networks suffers from routing instabilities, for
example resulting in a large number of routing updates being
transmitted to the PE device. In this case it is important to
prevent such routing from causing any instability in the routing used
in the global Internet.
In these cases it may be necessary to partition routing, so that the
PE does not need to maintain as large a collection of routes, and so
that the PE is not able to adversely effect Internet routing. Also,
given that the total number of route prefixes and the total number of
routing instances which the PE needs to maintain might be very large,
it may be desirable to limit the participation in Internet routing
for those PEs which are supporting a large number of VPNs or which
are supporting large VPNs.
Consider a case where a PE is supporting a very large number of VPNs,
some of which have a large number of sites. To pick a VERY large
example, let’s suppose 1000 VPNs, with an average of 100 sites each,
plus 10 prefixes per site on average. Consider that the PE also
needs to be able to route traffic to the Internet in general. In
this example the PE might need to support approximately 1,000,000
prefixes for the VPNs, plus more than 100,000 prefixes for the
Internet. If augmented and aggregated routing is used, then this
implies a large number of routes which may be advertised in a single
routing protocol (most likely BGP). If the VR approach is used, then
there are also 100,000 neighbor adjacencies in the various per-VPN
routing protocol instances. In some cases this number of routing
prefixes and/or this number of adjacencies might be difficult to
support in one device.
In this case, an alternate approach is to limit the PE’s
participation in Internet routing to the absolute minimum required:
Specifically the PE will need to know which Internet address prefixes
are reachable via directly attached CE devices. All other Internet
routes may be summarized into a single default route pointing to one
or more P routers. In many cases the P routers to which the default
routes are directed may be the P routers to which the PE device is
directly attached (which are the ones which it needs to use for
forwarding most Internet traffic). Thus if there are M CE devices
directly connected to the PE, and if these M CE devices are the next
hop for a total of N globally addressable Internet address prefixes,
then the PE device would maintain N+1 routes corresponding to
globally routable Internet addresses.
In this example, those PE devices which provide VPN service run
routing to compute routes for the VPNs, but don’t operate Internet
routing, and instead use only a default route to route traffic to all
Internet destinations (not counting the addresses which are reachable
via directly attached CE devices). The P routers need to maintain
Internet routes, and therefore take part in Internet routing
protocols. However, the P routers don’t know anything about the VPN
routes.
In some cases the maximum number of routes and/or routing instances
supportable via a single PE device may limit the number of VPNs which
can be supported by that PE. For example, in some cases this might
require that two different PE devices be used to support VPN services
for a set of multiple CEs, even if one PE might have had sufficient
throughput to handle the data traffic from the full set of CEs.
Similarly, the amount of resources which any one VPN is permitted to
use in a single PE might be restricted.
There will be cases where it is not necessary to partition the
routing, since the PEs will be able to maintain all VPN routes and
all Internet routes without a problem. However, it is important that
VPN approaches allow partitioning to be used where needed in order to
prevent future scaling problems. Again, making the system scalable
is a matter of proper deployment.
It may be wondered whether it is ever desirable to have both Internet
routing and VPN routing running in a single PE device or route
reflector. In fact, if there is even a single system running both
Internet routing and VPN routing, doesn’t that raise the possibility
that a disruption within the VPN routing system will cause a
disruption within the Internet routing system?
Certainly this possibility exists in theory. To minimize that
possibility, BGP implementations which support multiple address
families should be organized so as to minimize the degree to which
the processing and distribution of one address family affects the
processing and distribution of another. This could be done, for
example, by suitable partitioning of resources. This partitioning
may be helpful both to protect Internet routing from VPN routing, and
to protect well behaved VPN customers from "mis-behaving" VPNs. Or
one could try to protect the Internet routing system from the VPN
routing system by giving preference to the Internet routing. Such
implementation issues are outside the scope of this document. If one
has inadequate confidence in an implementation, deployment procedures
can be used, as explained above, to separate the Internet routing
from the VPN routing.
4.5. Quality of Service, SLAs, and IP Differentiated Services
The following technologies for QoS/SLA may be applicable to PPVPNs.
4.5.1. IntServ/RSVP [RFC2205] [RFC2208] [RFC2210] [RFC2211] [RFC2212]
Integrated services, or IntServ for short, is a mechanism for
providing QoS/SLA by admission control. RSVP is used to reserve
network resources. The network needs to maintain a state for each
reservation. The number of states in the network increases in
proportion to the number of concurrent reservations.
In some cases, IntServ on the edge of a network (e.g., over the
customer interface) may be mapped to DiffServ in the SP network.
4.5.2. DiffServ [RFC2474] [RFC2475]
IP differentiated service, or DiffServ for short, is a mechanism for
providing QoS/SLA by differentiating traffic. Traffic entering a
network is classified into several behavior aggregates at the network
edge and each is assigned a corresponding DiffServ codepoint. Within
the network, traffic is treated according to its DiffServ codepoint.
Some behavior aggregates have already been defined. Expedited
forwarding behavior [RFC3246] guarantees the QoS, whereas assured
forwarding behavior [RFC2597] differentiates traffic packet
precedence values.
When DiffServ is used, network provisioning is done on a
per-traffic-class basis. This ensures a specific class of service
can be achieved for a class (assuming that the traffic load is
controlled). All packets within a class are then treated equally
within an SP network. Policing is done at input to prevent any one
user from exceeding their allocation and therefore defeating the
provisioning for the class as a whole. If a user exceeds their
traffic contract, then the excess packets may optionally be
discarded, or may be marked as "over contract". Routers throughout
the network can then preferentially discard over contract packets in
response to congestion, in order to ensure that such packets do not
defeat the service guarantees intended for in contract traffic.
4.6. Concurrent Access to VPNs and the Internet
In some scenarios, customers will need to concurrently have access to
their VPN network and to the public Internet.
Two potential problems are identified in this scenario: the use of
private addresses and the potential security threads.
o The use of private addresses
The IP addresses used in the customer’s sites will possibly belong
to a private routing realm, and as such be unusable in the public
Internet. This means that a network address translation function
(e.g., NAT) will need to be implemented to allow VPN customers to
access the Public Internet.
In the case of layer 3 PE-based VPNs, this translation function
will be implemented in the PE to which the CE device is connected.
In the case of layer 3 provider-provisioned CE-based VPNs, this
translation function will be implemented on the CE device itself.
o Potential security threat
As portions of the traffic that flow to and from the public
Internet are not necessarily under the SP’s nor the customer’s
control, some traffic analyzing function (e.g., a firewall
function) will be implemented to control the traffic entering and
leaving the VPN.
In the case of layer 3 PE-based VPNs, this traffic analyzing
function will be implemented in the PE device (or in the VFI
supporting a specific VPN), while in the case of layer 3 provider
provisioned CE-based VPNs, this function will be implemented in the
CE device.
o Handling of a customer IP packet destined for the Internet
In the case of layer 3 PE-based VPNs, an IP packet coming from a
customer site will be handled in the corresponding VFI. If the IP
destination address in the packet’s IP header belongs to the
Internet, multiple scenarios are possible, based on the adapted
policy. As a first possibility, when Internet access is not
allowed, the packet will be dropped. As a second possibility, when
(controlled) Internet access is allowed, the IP packet will go
through the translation function and eventually through the traffic
analyzing function before further processing in the PE’s global
Internet forwarding table.
Note that different implementation choices are possible. One can
choose to implement the translation and/or the traffic analyzing
function in every VFI (or CE device in the context of layer 3
provider-provisioned CE-based VPNs), or alternatively in a subset or
even in only one VPN network element. This would mean that the
traffic to/from the Internet from/to any VPN site needs to be routed
through that single network element (this is what happens in a hub
and spoke topology for example).
4.7. Network and Customer Management of VPNs
4.7.1. Network and Customer Management
Network and customer management systems responsible for managing VPN
networks have several challenges depending on the type of VPN network
or networks they are required to manage.
For any type of provider-provisioned VPN it is useful to have one
place where the VPN can be viewed and optionally managed as a whole.
The NMS may therefore be a place where the collective instances of a
VPN are brought together into a cohesive picture to form a VPN. To
be more precise, the instances of a VPN on their own do not form the
VPN; rather, the collection of disparate VPN sites together forms the
VPN. This is important because VPNs are typically configured at the
edges of the network (i.e., PEs) either through manual configuration
or auto-configuration. This results in no state information being
kept in within the "core" of the network. Sometimes little or no
information about other PEs is configured at any particular PE.
Support of any one VPN may span a wide range of network equipment,
potentially including equipment from multiple implementors. Allowing
a unified network management view of the VPN therefore is simplified
through use of standard management interfaces and models. This will
also facilitate customer self-managed (monitored) network devices or
systems.
In cases where significant configuration is required whenever a new
service is provisioned, it is important for scalability reasons that
the NMS provide a largely automated mechanism for this operation.
Manual configuration of VPN services (i.e., new sites, or
re-provisioning existing ones), could lead to scalability issues, and
should be avoided. It is thus important for network operators to
maintain visibility of the complete picture of the VPN through the
NMS system. This must be achieved using standard protocols such as
SNMP, XML, or LDAP. Use of proprietary command-line interfaces has
the disadvantage that proprietary interfaces do not lend themselves
to standard representations of managed objects.
To achieve the goals outlined above for network and customer
management, device implementors should employ standard management
interfaces to expose the information required to manage VPNs. To
this end, devices should utilize standards-based mechanisms such as
SNMP, XML, or LDAP to achieve this goal.
4.7.2. Segregated Access of VPN Information
Segregated access of VPNs information is important in that customers
sometimes require access to information in several ways. First, it
is important for some customers (or operators) to access PEs, CEs or
P devices within the context of a particular VPN on a per-VPN-basis
in order to access statistics, configuration or status information.
This can either be under the guise of general management,
operator-initiated provisioning, or SLA verification (SP, customer or
operator).
Where users outside of the SP have access to information from PE or P
devices, managed objects within the managed devices must be
accessible on a per-VPN basis in order to provide the customer, the
SP or the third party SLA verification agent with a high degree of
security and convenience.
Security may require authentication or encryption of network
management commands and information. Information hiding may use
encryption or may isolate information through a mechanism that
provides per-VPN access. Authentication or encryption of both
requests and responses for managed objects within a device may be
employed. Examples of how this can be achieved include IPsec
tunnels, SNMPv3 encryption for SNMP-based management, or encrypted
telnet sessions for CLI-based management.
In the case of information isolation, any one customer should only be
able to view information pertaining to its own VPN or VPNs.
Information isolation can also be used to partition the space of
managed objects on a device in such a way as to make it more
convenient for the SP to manage the device. In certain deployments,
it is also important for the SP to have access to information
pertaining to all VPNs, thus it may be important for the SP to create
virtual VPNs within the management domain which overlap across
existing VPNs.
If the user is allowed to change the configuration of their VPN, then
in some cases customers may make unanticipated changes or even
mistakes, thereby causing their VPN to mis-behave. This in turn may
require an audit trail to allow determination of what went wrong and
some way to inform the carrier of the cause.
The segregation and security access of information on a per-VPN basis
is also important when the carrier of carrier’s paradigm is employed.
In this case it may be desirable for customers (i.e., sub-carriers or
VPN wholesalers) to manage and provision services within their VPNs
on their respective devices in order to reduce the management
overhead cost to the carrier of carrier’s SP. In this case, it is
important to observe the guidelines detailed above with regard to
information hiding, isolation and encryption. It should be noted
that there may be many flavors of information hiding and isolation
employed by the carrier of carrier’s SP. If the carrier of carriers
SP does not want to grant the sub-carrier open access to all of the
managed objects within their PEs or P routers, it is necessary for
devices to provide network operators with secure and scalable per-VPN
network management access to their devices. For the reasons outlined
above, it therefore is desirable to provide standard mechanisms for
achieving these goals.
5. Interworking Interface
This section describes interworking between different layer 3 VPN
approaches. This may occur either within a single SP network, or at
an interface between SP networks.
5.1. Interworking Function
Figure 2.5 (see section 2.1.3) illustrates a case where one or more
PE devices sits at the logical interface between two different layer
3 VPN approaches. With this approach the interworking function
occurs at a PE device which participates in two or more layer 3 VPN
approaches. This might be physically located at the boundary between
service providers, or might occur at the logical interface between
different approaches within a service provider.
With layer 3 VPNs, the PE devices are in general layer 3 routers, and
are able to forward layer 3 packets on behalf of one or more private
networks. For example, it may be common for a PE device supporting
layer 3 VPNs to contain multiple logical VFIs (sections 1, 2, 3.3.1,
4.4.2) each of which supports forwarding and routing for a private
network.
The PE which implements an interworking function needs to participate
in the normal manner in the operation of multiple approaches for
supporting layer 3 VPNs. This involves the functions discussed
elsewhere in this document, such as VPN establishment and
maintenance, VPN tunneling, routing for the VPNs, and QoS
maintenance.
VPN establishment and maintenance information, as well as VPN routing
information will need to be passed between VPN approaches. This
might involve passing of information between approaches as part of
the interworking function. Optionally this might involve manual
configuration so that, for example, all of the participants in the
VPN on one side of the interworking function considers the PE
performing the interworking function to be the point to use to
contact a large number of systems (comprising all systems supported
by the VPN located on the other side of the interworking function).
5.2. Interworking Interface
Figure 2.6 (see section 2.1.3) illustrates a case where interworking
is performed by use of tunnels between PE devices. In this case each
PE device participates in the operation of one layer 3 VPN approach.
Interworking between approaches makes use of per-VPN tunnels set up
between PE. Each PEs operates as if it is a normal PEs, and
considers each tunnel to be associated with a particular VPN.
Information can then be transmitted over the interworking interface
in the same manner that it is transmitted over a CE to PE interface.
In some cases establishment of the interworking interfaces may
require manual configuration, for example to allow each PE to
determine which tunnels should be set up, and which private network
is associated with each tunnel.
5.2.1. Tunnels at the Interworking Interface
In order to implement an interworking interface between two SP
networks for supporting one or more PPVPN spanning both SP networks,
a mechanism for exchanging customer data as well as associated
control data (e.g., routing data) should be provided.
Since PEs of SP networks to be interworked may only communicate over
a network cloud, an appropriate tunnel established through the
network cloud will be used for exchanging data associated with the
PPVPN realized by interworked SP networks.
In this way, each interworking tunnel is assigned to an associated
layer 3 PE-based VPN; in other words, a tunnel is terminated by a VFI
(associated with the PPVPN) in a PE device. This scenario results in
implementation of traffic isolation for PPVPNs supported by an
Interworking Interface and spanning multiple SP networks (in each SP
network, there is no restriction in applied technology for providing
PPVPN so that both sides may adopt different technologies). The way
of the assignment of each tunnel for a PE-based VPN is specific to
implementation technology used by the SP network that is
inter-connected to the tunnel at the PE device.
The identifier of layer 3 PE-based VPN at each end is meaningful only
in the context of the specific technology of an SP network and need
not be understood by another SP network interworking through the
tunnel.
The following tunneling mechanisms may be used at the interworking