Provider Provisioned VPN WG Hamid Ould-Brahim
Internet Draft Bryan Gleeson
draft-ouldbrahim-vpn-vr-03.txt Gregory Wright
Expiration Date: September 2001 Nortel Networks
Timon Sloane
Webstacks
Rainer Bach
T-Data
Rick Bubenik
SAVVIS Communications
Abraham Young
Huawei Technologies
Jieyun Jessica Yu
Chandru Sargor
Cosine Communications
Luyuan Fang
AT&T
March 2001
Network based IP VPN Architecture
using Virtual Routers
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Ould-Brahim, et. al [Page 1]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
This draft describes a network based VPN architecture using virtual
routers. The VPN service is built based on the virtual router (VR)
concept, which has exactly the same mechanisms as a physical router,
and therefore inherits all existing mechanisms and tools for
configuration, operation, accounting, and maintenance. Within a VPN
domain, an instance of routing is used to distribute VPN
reachability information among VR routers. Any routing protocol can
be used, and no VPN-related modifications or extensions are needed
to the routing protocol for achieving VPN reachability. Virtual
routers can be deployed in different VPN configurations, direct VR
to VR connectivity through layer-2 or by aggregating multiple VRs
into a single VR combined with IP or MPLS based tunnels. This
architecture accommodates different backbone deployment scenarios,
e.g. where the VPN service provider owns the backbone, and where the
VPN service provider obtains backbone service from one or more other
service providers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
Table of Contents
1 Introduction ........................................ 3
2 Virtual Router Architecture Requirements ............. 4
2.1 Membership .......................................... 4
2.2 Scalability .......................................... 4
2.3 Quality of Service ................................... 4
2.4 Auto-Discovery ....................................... 5
2.5 Routing .............................................. 5
2.5.1 Routing between PE and CE ............................ 5
2.5.2 Routing in the Service Provider Network .............. 5
2.5.3 Routing between PEs................................... 5
2.6 Security ............................................. 5
2.7 Topology ............................................. 5
2.8 Tunneling ............................................ 5
2.9 Management ........................................... 5
2.10 General Requirements ................................. 5
3 Network Reference Model .............................. 6
3.1 The Backbone ........................................ 7
4 Virtual Router Definition ............................ 7
5 How VPNs are built and deployed using VRs?............ 8
5.1 VR to VR Connectivity over layer-2 Connections........ 8
5.2 Virtual Router Backbone Aggregation .................. 8
5.2.1 Tunneling ............................................ 9
5.2.1.1 MPLS Tunnels ...................................... 9
5.2.1.2 IPSec Tunnels ..................................... 9
5.2.2 Routing .............................................. 10
5.2.3 Relationship between the VRs and the Backbone VR ..... 10
5.2.4 Multiple Backbones connected to a single PE .......... 10
6 VPN Auto-Discovery ................................... 11
Ould-Brahim, et al. March 2001 [Page 2]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
7 VRs and Extranets .................................... 12
8 VPNs across Domains .................................. 12
9 Internet Access ...................................... 13
10 Carrier's Carrier Case................................ 13
11 Operations and Management ............................ 13
11.1 Backbone Migration ................................... 14
11.2 Troubleshooting ...................................... 14
12 Quality of Service ................................... 14
13 Scalability .......................................... 15
14 Security Considerations .............................. 15
15 References............................................ 15
16 Acknowledgments ..................................... 16
17 Authors' Addresses .................................. 16
1. Introduction
Several solutions have been put forward to achieve different levels
of network privacy when building VPNs across a shared IP backbone.
Most of these solutions require separate per VPN forwarding
capabilities and make use of IP or MPLS based tunnels across the
backbone [VPN-RFC2764], [VPN-CORE], and [VPN-RFC2547].
This document describes a network based VPN architecture using
virtual routers. The architecture complies with the IP VPN framework
described in [VPN-RFC2764]. The objective is to provide per VPN
based routing, forwarding, quality of service, and service
management capabilities. The VPN service is built based on the
virtual router concept, which has exactly the same mechanisms as a
physical router, and therefore inherits all existing mechanisms and
tools for configuration, deployment, operation, troubleshooting,
monitoring, and accounting. Virtual routers can be deployed in
different VPN configurations, direct VR to VR connectivity through
layer-2 links/tunnels or by aggregating multiple VRs into a single
VR combined with IP or MPLS based tunnels. This architecture
accommodates different backbone deployment scenarios, e.g. where the
VPN service provider owns the backbone, and where the VPN service
provider obtains backbone service from one or more other service
providers.
Within a VPN domain, an instance of routing is used to distribute
VPN reachability information among VR routers. Any routing protocol
can be used, and no VPN-related modifications or extensions are
needed to the routing protocol for achieving VPN reachability.
VPN reachability information to and from customer sites can be
dynamically learned from the CE using standard routing protocols or
it can be statically provisioned on the VR. The routing protocol
between the virtual routers and CEs is independent of the routing
used in the VPN backbone. The routing protocol between the VRs maybe
the same or it might be different than the routing mechanism used
between the CE and VR.
Ould-Brahim, et al. March 2001 [Page 3]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
There are two fundamental architectures for implementing network
based VPNs, virtual routers (VR) and piggybacking. The main
difference between the two architectures resides in the model used
to achieve VPN reachability and membership functions. In the VR
model, each VR in the VPN domain is running an instance of routing
protocol responsible to disseminate VPN reachability information
between VRs. Therefore, VPN membership and VPN reachability are
treated as separate functions, and separate mechanisms are used to
implement these functions. VPN reachability is carried out by a per-
VPN instance of routing, and a range of mechanisms is possible for
determining membership (see section 6.0). In the piggyback model the
VPN network layer is terminated at the edge of the backbone, and a
backbone routing protocol (i.e. BGP-4) is responsible for
disseminating the VPN membership and reachability information
between provider edge routers (PE) for all the VPNs configured on
the PE. [VPN-RFC2547bis] is an example of a piggyback VPN
architecture.
2. Virtual Router Architecture Requirements
This section lists some requirements addressed by the proposed VR
architecture.
2.1 Membership
All virtual routers that are members of a specific VPN MUST share
the same VPN-ID. A recommended VPN identifier (VPN-ID) format to be
used is defined in the standard RFC2685.
2.2 Scalability
In this architecture, the backbone internal nodes are not required
to be VPN aware or VR aware, and therefore they don't keep any VPN
state within the backbone. However, in the case where the internal
nodes are also VR aware then it is possible to have either tunnels
from the PE or the CE connecting to the internal VRs. This type of
VPN deployment can be useful when the internal nodes are
geographically suitable to be the VPN hub.
2.3 Quality of Service
Existing quality of service mechanisms developed for physical
routers should all be available to be used per VR basis. Therefore,
quality of service (policing/shaping/classification/scheduling)
SHOULD be configurable per VPN basis.
2.4 Auto-discovery
It should be possible for the VRs to automatically discover each
other, setup tunnels to each other, and exchange private routing
information across the backbone. It is required that the auto-
discovery mechanism take into consideration of the case where the
Ould-Brahim, et al. March 2001 [Page 4]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
VPNs are implemented across domains. We assume in this document that
BGP as described in [VPN-BGP] is used as the mechanism to distribute
membership, topology, and tunnel information among VRs members of
the same VPN.
2.5 Routing
2.5.1 Routing between PE and CE
Any existing routing protocol in the VPN domain can be used between
PE and the CE.
2.5.2 Routing in the Service Provider Network (Backbone)
The choice of the backbone routing protocol should not be
constrained by the VPNs.
2.5.3 Routing between PEs
Any existing routing protocol in the VPN domain can be used between
PEs.
2.6 Security
The architecture MUST accommodate different levels of data and
routing security. The architecture must provide authentication and
encryption services for VPNs requiring strong security capabilities.
2.7 Topology
VPN topologies like a hub and spoke, and full mesh MUST be
supported. Furthermore, it should be possible to build arbitrary VPN
topologies.
2.8 Tunneling
The architecture should not be limited to a single tunneling
mechanism. It should be possible to use per VPN basis, IPSec, GRE,
IP in IP, and MPLS tunnels, as it should also be possible to support
shared tunnels between VPNs. Therefore within a single VPN,
different type of tunnels can be used.
2.9 Management
It should be easy to configure, deploy, operate and troubleshoot
each VPN independently using existing mechanisms and tools. Tools
used for operating, managing and debugging IP networks can continue
to be used without any modification.
2.10 General Requirements
Ould-Brahim, et al. March 2001 [Page 5]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
The followings are some general requirements for the VR
architecture:
(a) The architecture should accommodate different sizes of VPNs,
and one VPN should not impact other VPNs on the PE.
(b) The architecture MUST support overlapping VPN address spaces
in separate VPNs.
(c) The architecture should support direct paths between VPN
sites that bypass the service provider backbone (backdoor
links). Traffic can be directed to the backdoor link, or
injected to the backbone with the flexibility of using both
the backbone access, and the backdoor link as internal or
external paths.
(d) The architecture MUST work over different deployment
scenarios, e.g. where the service provider owns their own
backbone, and where the service provider obtains backbone
service from one or more other service providers.
3. Network Reference Model
A VPN customer site is connected to the provider backbone by means
of a connection between a CE device, (which can either be a bridge
or a router) and a virtual router. CE devices are preconfigured to
connect to one (or more) VR(s).Multiple virtual routers
coexist on the same service provider edge device (PE).
CE devices can be attached to VRs over any type of access link (e.g.
ATM, frame relay, ethernet, PPP or IP tunneling mechanism such as
IPSec, L2TP or GRE tunnels).
+---+ +---+
| P |....| P |
+---+ +---+
PE / \ PE
+----+ +------+ +------+ +---+
| CEs|--|-{VRs}| |{VRs}-|--|CEs|
+----+ +------+ +------+ +---+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Network Reference Model
CE sites can be statically connected to the provider network via
dedicated circuits, or can use dial-up links. Routing tables
associated with each virtual router define the site-to-site
reachability for each VPN. The internal backbone provider routers
(P) are not VPN aware and do not keep VPN state.
3.1 Backbone
Ould-Brahim, et al. March 2001 [Page 6]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
In general the backbone is a shared network infrastructure, which
represents:
(a) A layer-2 ATM or frame relay network.
(b) An IP network.
(c) An MPLS network.
Not all VPNs existing on the same PE are necessarily connected to
the same backbone. The same backbone can be built from multiple
transport technologies.
4. Virtual Router Definition
A virtual router (VR) is an emulation of a physical router at the
software and hardware levels. Virtual routers have independent IP
routing and forwarding tables and they are isolated from each other.
This means that a VPN's addressing space can overlap with another
VPN's address space. The addresses need only be unique within a VPN
domain.
A virtual router has two main functions:
1. Constructing routing tables describing the paths between VPN
sites using any routing technologies (e.g., static, OSPF, RIP,
or BGP).
2. Forwarding packets to the next hops within the VPN domain.
From the VPN user point of view, a virtual router provides the same
functionality as a physical router. Separate routing, and forwarding
capabilities provide each VPN CE link with the appearance of a
dedicated router that guarantees isolation from other VPN traffic
while running on shared forwarding and transmission resources.
Virtual routers belonging to the same VPN domain must have the same
Virtual Private Network Identifier (VPNID). An example of VPNID
format is described in [VPN-RFC2685]. To the CE access device, the
virtual router appears as a neighbor router in the CE based network,
to which it sends all traffic for non-local VPN destinations. Each
CE access device must learn the set of destinations reachable
through its connection to the virtual router; this may be as simple
as a default route. Virtual routers participating in a single VPN
domain are responsible for learning and disseminating VPN
reachability information among themselves. A given virtual router
holds the routes only for the specific VPNs configured for that VR.
Any routing protocol can be used between the VRs and the CEs.
5. How VPNs are built and deployed using VRs?
Two main VR deployment scenarios can be used for building virtual
private networks:
- VR to VR connectivity over a layer 2 connections.
- Aggregating multiple virtual routers over a single virtual router.
Ould-Brahim, et al. March 2001 [Page 7]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
The above VR deployment scenarios can coexist on a single PE and
they are not mutually exclusive.
5.1 VR to VR Connectivity over Layer 2 Connections
As illustrated in figure 2, virtual routers can be deployed over
direct layer-2 frame relay or ATM connections or other layer-2
transport technology.
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A| | +----+ Layer-2 connections +----+ | |VPN-A|
|sites| | |VR-A|<---------------------------->|VR-A| | |sites|
+-----+ | +----+ | -------- | +----+ | +-----+
| |-( Layer-2)-| |
+-----+ | +----+ | (Backbone) | +----+ | +-----+
|VPN-B|-|-|VR-B| | -------- | |VR-B|-|-|VPN-B|
|sites| | +----+<--------------------|------->+----+ | |sites|
+-----+ | | | | +-----+
+---------------+ +---------------+
Figure 2: VR to VR connectivity over a layer-2 backbone
This type of VR deployment allows direct quality of service
engineering per VPN connection basis. The connections can be
statically configured or dynamically established.
5.2 Virtual Router Backbone Aggregation
Another typical VPN configuration consists of connecting multiple
virtual routers to the backbone through the use of a single virtual
router (figure 3). For easy reference in the following sections
let's call this single virtual router "the backbone virtual router"
or "the backbone VR".
The backbone virtual router is not functionally different than other
virtual routers. It is only a virtual router that is configured and
deployed in a special configuration.
Ould-Brahim, et al. March 2001 [Page 8]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A| | +----+ MPLS/IP based Tunnels +----+ | |VPN-A|
|sites|-|-|VR-A|\.......|<---------->|........|VR-A|-|-|sites|
+-----+ | +----+ +----+ --------- | +----+/+----+ | +-----+
| |VR-1|-|-(IP/MPLS )-|-|VR-2| |
+-----+ | +----+/+----+ |(Backbones) | +----+\+----+ | +-----+
|VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B|
|sites| | +----+........|<---------->|........+----+ | |sites|
+-----+ | MPLS/IP based Tunnels | +-----+
| | | |
+---------------+ +---------------+
Figure 3: VR-1 and VR-2 used as backbone VRs
The backbone virtual router connects each PE to a shared backbone
infrastructure. Backbone virtual routers can be deployed over ATM,
FR, IP, or MPLS networks. Since the backbone VR allows the
aggregation of VPN VRs, backbone configuration remains unaffected as
new VPN sites are added. The relationship between the VRs and the
backbone VR is an overlay relationship.
5.2.1 Tunneling
VPN data and routing information is tunneled through the use of IP
or MPLS based tunnels (e.g., IPSec, GRE, IP in IP, MPLS). Depending
on the tunnel technology used, the tunnels can be statically
configured or dynamically established. The tunnel appears to VRs as
a point-to-point link. Traffic sent through the tunnel, and
forwarded by the backbone VR is opaque to the underlying backbone
technology used.
A tunnel can be established per VPN or shared among many VPNs (VRs).
The tunnel can originate from the backbone virtual router or from
the VRs.
The backbone VR makes it appear as if each VR within a VPN is
directly connected (full and partial mesh configurations supported).
Each VR within the VPN exchanges routing information directly with
the other VRs in the VPN.
VPNs may use different type of tunnels for inter-VR connectivity.
Indeed, Two sites may use MPLS as their tunnel technology of choice.
Other sites (which transit through not fully secured domains) may
choose to use IPSec.
5.2.1.1 MPLS Tunnels
MPLS tunneling can be used in different forwarding scenarios. Two
labels hierarchy can be used. One simple forwarding scenario is the
inner label identifies the VR intended to receive the private packet
Ould-Brahim, et al. March 2001 [Page 9]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
(to be forwarded to the CE). Another forwarding scenario is to
distribute the inner label per VPN basis across the tunnel. In this
case the label distribution process can be achieved using BGP or
existing label distribution protocol per VPN basis. The inner label
relates to the private VPN prefix. The label and reachability
distribution is done through the tunnels. On the egress side traffic
will be directed to the egress interface by looking up the inner
label.
5.2.1.2 IPSec Tunnels
IPSec is needed when there is a requirement for strong encryption or
strong authentication. It also supports multiplexing and a
signalling protocol - IKE. IPSec tunnels can be established between
two VPNs across the backbone (originating from the backbone VRs).
5.2.2 Routing
The backbone VR exchanges routing information with other backbone
entities (P routers and possibly other backbone VRs).
Virtual routers can run any routing protocol on their local VPN
domain. Both static routes and dynamic routing protocols such as
RIP, OSPF, and BGP-4 can be used. VPN sites exchange routing
information through the tunnels over the backbone.
If a backdoor link is used between private CE based network running
any IGP, then by adjusting the backdoor link costs appropriately,
the backbone link can be favored for forwarding VPN traffic. By
lowering the weight, the backdoor link can be used as a backup link
in case the backbone path fails.
5.2.3 Relationship between the VRs and the Backbone VR
The routing domain of a set of VRs participating in a single VPN has
no relation to the routing domain of the backbone VR. The backbone
VR is not necessarily aware of the routing instances running on each
private virtual router. However, because the backbone VR is also a
virtual router, it can build routing relationships with other VRs if
needed.
5.2.4 Multiple Backbones connected to a single PE
Figure 4 illustrates an example where multiple backbones are
connected to the same PE. This type of configuration can be used
when the PE is connected to multiple service provider backbones, or
when the service provider offers different VPN services for
different type of backbones.
Ould-Brahim, et al. March 2001 [Page 10]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A| | +----+ | | +----+ | |VPN-A|
|sites| | |VR-A|\ | | |VR-A| | |sites|
+-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+
| |VR-1|-|-(Backbones)|-|VR-2| |
+-----+ | +----+/+----+ | ( 1 )| +----+\+----+ |
|VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B|
|sites| | +----+ | | +----+ | |sites|
+-----+ | | | | +-----+
| | | |
+-----+ | | | | +-----+
|VPN-C| | +----+ | | +----+ | |VPN-C|
|sites|-|-|VR C| | | |VR-C|-|-|sites|
+-----+ | +----+\+----+ | -------- | +----+/+----+ | +-----+
| |VR-3|-|-(Backbone)-|-|VR-4| |
+-----+ | +----+/+----+ | ( 2 & 3 ) | +----+\+----+ | +-----+
|VPN-D|-|-|VR-D| | -------- | |VR-D|-|-|VPN-D|
|sites| | +----+ | | +----+ | |sites|
+-----+ | | | | +-----+
+---------------+ +---------------+
Figure 4: Multiple Backbones connected to a single PE
6. VPN Auto-Discovery
The virtual router approach explicitly separates the mechanisms used
for distributing reachability information from mechanisms used for
distributing VPN topology and membership information. VPN membership
information refers to the set of PEs that have customers in a
particular VPN. VPN topology represents the set of PEs and their
interconnectivity within the VPN. The topology can be a full-mesh of
PEs, a hub and spoke, or anything in between. Dynamic topology can
also be handled due to on-demand VPN customers.
VPN discovery can be achieved through different mechanisms, for
example:
- Directory server approach, which VRs query a server to determine
their neighbors.
- Explicit configuration via a management platform.
- Piggybacking VPN membership and topology information using
existing routing protocols (e.g., BGP) [VPN-BGP].
The above mechanisms can be combined on a single PE. As an example,
for some VPNs topology discovery is done only through a management
platform. For others, dynamic topology discovery is achieved using
existing routing protocol.
Ould-Brahim, et al. March 2001 [Page 11]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
In this document it is assumed that BGP is used as the mechanism for
achieving auto-discovery of VPN members. As described in [VPN-BGP],
VR addresses are exchanged, along with the information needed to
enable the PEs to determine which VRs are in the same VPN
("membership"), and which of those VRs are to have VPN connectivity
("topology"). Once the VRs are reachable through the tunnels, routes
("reachability") are then exchanged by running existing routing
protocol per VPN basis (across the tunnels).
It is important to note that, for the VR architecture, the auto-
discovery mechanism is only used to automatically exchange control
VPN information between VRs. It is not intended for piggybacking vpn
private reachability information onto the backbone routing instance.
7. VRs and Extranets
Extranets are commonly used to refer to a scenario whereby two or
more companies have network access to a limited amount of each
other's corporate data. An important feature of extranets is the
control of who can access what data, and this is essentially a
policy decision. Policy decisions are enforced at the
interconnection points between different domains [VPN-RFC2764]. The
enforcement may be done via a firewall, router with access list
functionality, or any device capable of applying policy decision to
transit traffic.
In the VR architecture, policy can be enforced between two VPNs, or
between a VPN and the Internet, in exactly the same manner as is
done today without VPNs. For example, two VRs (VPNs) could be
interconnected, which each VR locally imposing its own policy
controls, via a firewall, on all traffic that enters its VPN from
the outside (whether from another VR or from the Internet).
Combining firewalls and exchanging private routes between VRs
(members of different VPNs) provide a flexible mechanism to build
different flavors of extranets.
8. VPNs across Domains
It is possible that a VPN may cross multiple domains administered by
different service providers. In the VR model, tunnels are used to
provide intra-VR connectivity across the backbones. The main
requirement on the service provider in order to achieve end-to-end
across domains VPN connectivity is the ability for both domains to
support a common tunnel technology to be used. Once the tunnel is
established, private data (e.g., routing information, and private
customer data) can flow from one domain to the other with the same
level of security as provided in a single service provider network.
Another possible scenario is to use two virtual routers configured
on each PE at the interconnection point. Each VR will use policy
decisions and firewalling to control VPN traffic transiting from one
domain to the other.
Ould-Brahim, et al. March 2001 [Page 12]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
The ability to use the standard VPN-ID format allows also
unambiguous VPN identification across domains.
9. Internet Access
The same link attaching to the VR can be used to provide the
internet access to the VPN sites. The VR operations are decoupled
from the mechanisms used by the customer sites to access the
internet.
One way of providing VPN internet access is to have the PE/backbone-
VR steering private traffic to the VR, and internet to normal
backbone/internet forwarding table. PE/backbone VR can hold the
internet routes (not necessarily the VRs). Firewalls need to be used
to secure the access (with the ability to use NAT).
Other options are also valid. One may want to have a particular VR
handling internet access only (rather than going to the backbone
VR), or a default route to the internet gateway can be used.
10. Carrier's Carriers Case
It is possible that a VPN service is also a network of a service
provider offering VPN services. Different options can be used to
implement the VPN hierarchy. Either tunnels are built from the VPN
edges to the CEs, and the VRs are transparently providing VPN
service to the remote CEs. This can be useful in the case where the
CEs are themselves VRs and the service provider is also outsourcing
the management of his customer VPN services. Another case is the
remote VPN services are completely transparent to the VRs (on the
PEs). This is the default case. It is up to the VPN network to
distribute VPN reachability across the CEs. Another option is for
the VPN service to implement the VR architecture. In this option,
the VPN Backbone VRs appear as CEs to the VRs configured on the PEs.
11. Operations and Management
One of the greatest strengths of the VR approach to VPN creation is
that all the existing tools for operating, managing and debugging IP
networks can continue to be used without modification. All the
standard MIBs, such as the forwarding/route table and interface MIBs
are available.
In case of PE failure (e.g. migration, upgrades, etc.), the service
provider may want to control and decide what VPN services gets
reestablished first. This particular point is important when a large
number of VPNs is supported on the PE where each VPN service has
different service availability requirements.
Since each VR operates as an independent router, it is possible for
the management of the VRs to be outsourced. VPN customers may
choose to configure (or perhaps only to monitor) the VRs that make
up their VPN. It is also possible that the backbone VRs could be
Ould-Brahim, et al. March 2001 [Page 13]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
managed by a separate entity. Each VR operates independently, and
can be individually reconfigured without effecting other VRs on the
same PE. In some implementations, it may even be possible for a VR
to be "rebooted" by a customer without affecting other VRs. It is
not required for a given VR implementation to support all management
capabilities described in this section.
11.1 Backbone Migration
One benefit in using multiple backbone virtual routers is the
ability for the backbone network administrator to migrate its
backbone from one core technology to another with minimal disruption
to VPN services. Indeed a VPN configuration change or a VPN-software
upgrade is totally transparent to the backbone protocol and policies
(this is due to decoupling the VPN routing protocol from the
provider backbone routing protocol).
11.2 Troubleshooting
The service provider or the VPN customer can use all existing
troubleshooting tools per VPN basis (e.g. ping and traceroute). As
an example a VPN customer can telnet to its own VR and performs some
troubleshooting operations. In this particular case, the service
provider can configure for each VPN customer restricted privileges
over the virtual router associated with the customer VPN network.
However, backbone topology information is completely hidden to the
VPN VR, and therefore to the service provider customer.
12. Quality of Service
This architecture can utilize different quality of service
mechanisms. QoS mechanisms developed for physical routers can be
used with VRs, on a per-VR basis. e.g. classification, policing,
drop policies, traffic shaping and scheduling/bandwidth reservation.
The architecture allows separate quality of service engineering of
the VPNs and the backbone.
13. Scalability
Only the PEs are handling the VPN type information. The internal
backbone routers (the P routers) are not VPN aware. Furthermore,
virtual routers allow multiple privates CE based networks to connect
to a single PE.
One advantage of the ability to contain the VPN address space and
VPN routing and forwarding capabilities within the virtual router
entity is the possibility to distribute PE system resources per VPN
basis. Indeed, as an example, different scheduling mechanisms can be
used for processing each VPN activity within the PE. This type of
per VPN resource management contributes in establishing a wide range
of priority schemes among VPNs within the PE.
Ould-Brahim, et al. March 2001 [Page 14]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
14. Security Considerations
Different levels of data, routing and configuration security can be
implemented. Any existing security related mechanisms supported by
existing routing protocols (e.g. authentication) can be used
unmodified in the VR architecture. If IPSec tunneling is used as the
tunneling protocol, then both the control and data traffic that
travels over the tunnel can be secured; so that routing specific
security enhancements are not needed. Any private routing,
forwarding and addressing manipulation are done within the virtual
router context. Direct layer-2 connections (ATM, FR), or specific
tunneling mechanisms can also provide different levels of data
security.
15. References
[GRE-RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[CR-LDP] Jamoussi, B., et al, "Constraint-based LSP Setup using
LDP", Work in Progress.
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
[RFC-2401] Kent S., Atkinson R., "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[RFC-2411] Thayer, R., et al, "IP Security Document Roadmap", RFC
2411, November 1998.
[RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP",
RFC2661, August 1999.
[RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[VPN-CORE] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN
Architecture", Work in Progress
[VPN-BGP] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs", work in progress, November
2000.
[VPN-INW] Sumimoto, J., et al, "MPLS VPN Interworking", Work in
Progress.
Ould-Brahim, et al. March 2001 [Page 15]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
[VPN-ITU] "Draft Recommendation Y.IPVPN", Study Group 13, Q20/13,
May 2000.
[VPN-RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress.
[VPN-RFC2685] Fox B., et al, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[VPN-RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual
Private Networks", RFC 2764, February 2000.
16. Acknowledgments
The authors would like to acknowledge the following individuals for
their helpful comments and suggestions: Bilel Jamoussi, David
Hudson, David Drynan, Ru Wadasinghe, Scott Larrigan, Peter Ashwood-
Smith, Martin Pepin, Ahmad Khalid, Don Fedyk, Keereti Melkote, Ron
Bonica, Jerry Sydir, and Mark Duffy.
17. Author's Addresses
Hamid Ould-Brahim Bryan Gleeson
Nortel Networks Nortel Networks
P O Box 3511 Station C 2305 Mission College Blvd
Ottawa, ON K1Y 4H7 Santa Clara CA 95054
Canada USA
Phone: +1 (613) 765 3418 Phone: +1 (408) 565 2625
Email: hbrahim@nortelnetworks.com Email:bgleeson@shastanets.com
Gregory Wright Timon Sloane
Nortel Networks Webstacks
P O Box 3511 Station C 444 Oakmead Parkway
Ottawa, ON K1Y 4H7 Sunnyvale, CA 94085
Canada USA
Phone: +1 (613) 765 7912 Phone: +1 408-524-8484
Email: gwright@nortelnetworks.com Email:timon@webstacksinc.com
Rainer Bach Rick Bubenik,
T-Data SAVVIS Communications
Hans-Guenther-Sohl-Strasse7 717 Office Parkway
40235, Duesseldorf St. Louis, Mo. 63141
Germany USA
Phone: 49 211 694 2420 Phone: +1 (314) 468-7021
Ould-Brahim, et al. March 2001 [Page 16]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
Email: Rainer.Bach@telekom.de rickb@savvis.net
Abraham Young Jieyun Jessica Yu
HUAWEI Technologies Co., LTD. Cosine Communications
Kefa Road 1200 Bridge Parkway
Science-Based Industrial Park Redwood City CA 94065
Nanshan District, Shenzhen 518057 CA 94065
China USA
Phone: +86-755-6543662 Phone: +1 (650) 628-4881
Email: abyoung@huawei.com.cn Email: jyy@cosinecom.com
Chandru Sargor
Cosine Communications
1200 Bridge Parkway
Redwood City
CA 94065
USA
Phone: +1 (650) 637-2416
Email: Chandramouli.Sargor@cosinecom.com
Luyuan Fang
AT&T
200 Laurel Avenue
Middletown, NJ 07748
Phone: +1 (732) 420-1921
Email: Luyuanfang@att.com
Ould-Brahim, et al. March 2001 [Page 17]
Internet-Draft draft-ouldbrahim-vpn-vr-03.txt September 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ould-Brahim, et al. March 2001 [Page 18]