One document matched: draft-ietf-l3vpn-vpn-vr-02.txt
Differences from draft-ietf-l3vpn-vpn-vr-01.txt
Network Working Group Paul Knight (editor)
Internet Draft Hamid Ould-Brahim
draft-ietf-l3vpn-vpn-vr-02.txt Nortel Networks
Expiration Date: October 2004
Bryan Gleeson
Nokia
April 2004
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.
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
This draft describes a network-based Virtual Private Network (VPN)
architecture using the virtual router (VR) concept. Multiple VRs can
exist in a single physical device. A VR emulates all the
functionality of a physical router, and therefore inherits all
existing mechanisms and tools for configuration, operation,
accounting, and maintenance. Any routing protocol can be used to
distribute VPN reachability information among VRs, and no VPN-
related modifications or extensions are needed to the routing
protocol for achieving VPN reachability. Direct VR-to-VR
connectivity may be configured through layer-2 links or through IP-
or MPLS-based tunnels. Traffic from VRs belonging to different VPNs
may be aggregated over a "backbone VR" network, which greatly
simplifies VPN provisioning. This architecture accommodates various
Ould-Brahim, et. al [Page 1]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
backbone deployment scenarios, both where the VPN service provider
owns the backbone, and where the VPN service provider obtains
backbone service from one or more other service providers.
Table of Contents
1 Introduction ........................................ 3
2 Virtual Router VPN Architecture Requirements ......... 4
2.1 Membership .......................................... 4
2.2 Scalability .......................................... 4
2.3 Quality of Service ................................... 4
2.4 Auto-Discovery ....................................... 4
2.5 Routing .............................................. 5
2.5.1 Routing between CE and PE ............................ 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 ............................................. 6
2.8 Tunneling ............................................ 6
2.9 Management ........................................... 6
2.10 General Requirements ................................. 6
3 Network Reference Model .............................. 7
3.1 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........ 9
5.2 VR to VR Connectivity through IP or MPLS Tunnels...... 9
5.3 Virtual Router Backbone Aggregation .................. 9
5.3.1 Tunneling ............................................ 11
5.3.1.1 MPLS Tunnels ...................................... 11
5.3.1.2 IPSec Tunnels ..................................... 12
5.3.2 Routing .............................................. 12
5.3.3 Relationship between the VRs and the Backbone VR ..... 12
5.3.4 Multiple Backbones Connected to a Single PE .......... 13
6 VPN Membership and Topology Auto-Discovery ........... 13
7 VRs and Extranets .................................... 14
8 VPNs across Domains .................................. 15
9 Internet Access ...................................... 15
10 Carrier's Carrier Case................................ 16
11 Operations and Management ............................ 16
11.1 Backbone Migration ................................... 17
11.2 Troubleshooting ...................................... 17
12 Quality of Service ................................... 17
13 Scalability .......................................... 17
14 Security Considerations .............................. 18
15 Document Change History .............................. 19
16 Normative References ................................. 20
17 Informative References ............................... 20
18 Acknowledgments ..................................... 21
19 Authors' Addresses .................................. 21
Ould-Brahim, et al. Expires October 2004 [Page 2]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
1. Introduction
Several solutions have been put forward to achieve various levels of
network privacy and traffic isolation 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 [RFC-2764], [RFC-2917], and [VPN-RFC2547bis].
This document describes a network-based VPN architecture using
virtual routers. The architecture complies with the IP VPN framework
described in [RFC-2764]. The objective is to provide per-VPN
routing, forwarding, quality of service, and service management
capabilities. The VPN service is based on the virtual router
concept. A VR has exactly the same mechanisms as a physical router,
and therefore can inherit all existing mechanisms and tools for
configuration, deployment, operation, troubleshooting, monitoring,
and accounting. Multiple VRs can exist in a single physical device.
Virtual routers can be deployed in various VPN configurations.
Direct VR to VR connectivity may be configured through layer-2 links
or through a variety of tunnel mechanisms, using IP- or MPLS-based
tunnels. Multiple VRs may be aggregated over a "backbone VR." This
architecture accommodates various backbone deployment scenarios,
including where the VPN service provider owns the backbone, and
where the VPN service provider obtains backbone service from one or
more other service providers.
An instance of routing is used to distribute VPN reachability
information among the VRs supporting each VPN. 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, between the VRs. That is, the routing
protocol between the VRs may be the same or it might be different
than the routing mechanism used between the CE and VR, or it may be
a different instance of the same protocol. Likewise, since the VR-
to-VR connectivity can use tunnels, the inter-VR routing protocol
can be independent of the routing used in the backbone network(s)
over which the VR-based VPN runs.
There are two fundamental architectures for implementing network-
based IP 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 for disseminating 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-
Ould-Brahim, et al. Expires October 2004 [Page 3]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
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., extended 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.
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.
2. Virtual Router VPN Architecture Requirements
2.1 Membership
All virtual routers that are members of a specific VPN MUST share
the same VPN identifier (VPN-ID). This SHOULD be the VPN-ID format
defined in [RFC-2685].
2.2 Scalability
In this architecture, the backbone internal nodes (e.g., P devices)
are not required to be VPN aware or VR aware, and therefore they
don't keep any VPN state within the backbone. Thus the VR
architecture avoids any significant contribution to problems of
backbone scalability.
The PE on which the VRs run (and the VRs themselves) SHOULD be able
to accommodate rapid growth in the number of routes per VR, since
this number can change suddenly as membership changes. The PE SHOULD
be able to accommodate substantial growth in the number of VRs and
CEs supported, to avoid reconfiguration that could disrupt existing
connectivity.
The OPTIONAL use of the "backbone VR" improves the scalability of
the VR approach, since multiple VRs on a PE may share a single
backbone VR connection to their peer VRs on another PE, rather than
establishing multiple separate per-VR or per-VPN connections between
PEs. The backbone VR is described in more detail in section 5.3.
2.3 Quality of Service
Existing quality of service mechanisms developed for physical
routers SHOULD all be available to be used on a per-VR basis.
Therefore, quality of service (policing, shaping, classification,
and scheduling) SHOULD be configurable on a per-VPN basis.
2.4 Auto-discovery
Ould-Brahim, et al. Expires October 2004 [Page 4]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
It SHOULD be possible for the VRs to automatically discover each
other, set up tunnels to each other, and exchange private routing
information across the backbone. The auto-discovery mechanism MUST
take into consideration the case where the VPNs are implemented
across administrative domains. We assume in this document that an
auto-discovery mechanism which provides services similar to BGP (as
described in [VPN-BGP]) is used as the mechanism to distribute
membership, topology, and tunnel information among VRs which are
members of the same VPN.
2.5 Routing
2.5.1 Routing between CE and PE
Any existing routing protocol MAY be used between the CE and the VR
running on the PE. Typically, the routing protocol of the specific
VPN site will be used. Static routes MAY be used. The routing
protocol between the CE and the VR running on the PE MAY be
independent of the PE-to-PE routing. That is, they MAY be different
routing protocols, or different instances of the same routing
protocol.
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 VRs in a VPN
Any existing routing protocol MAY be used between VRs in a VPN. The
routing protocol between the VRs MAY be independent of the CE-to-PE
routing.
VRs belonging to the same VPN MAY construct tunnels providing
connections to each other, using information from the backbone
routing protocol. They MAY then exchange routing information and VPN
traffic over these tunnels.
A backbone VR network MAY be constructed among some or all PEs. VRs
of customer VPNs MAY use the backbone VR for routing across the
backbone.
It is strongly RECOMMENDED that care be taken when multiple routing
protocols are used, due to differences in metrics, detail of
information, etc.
2.6 Security
The VR architecture MUST accommodate security for VPN data, routing,
and other control information. Different levels of security MUST be
Ould-Brahim, et al. Expires October 2004 [Page 5]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
possible. The architecture SHOULD provide authentication and
encryption services for VPNs requiring strong security capabilities.
2.7 Topology
VPN topologies such as a hub and spoke, and full mesh MUST be
supported. It SHOULD be possible to build arbitrary VPN topologies.
For example, a PE device with VRs supporting certain VPNs SHOULD be
able to act as a P (Provider backbone) device with respect to other
VPNs. This increases provisioning flexibility in many topologies.
2.8 Tunneling
The VR architecture SHOULD NOT be limited to a single tunneling
mechanism. It MAY allow the use of IPSec, GRE [RFC-2784], IP in IP,
and MPLS tunnels. It SHOULD also allow multiple VPNs to share a
tunnel across a backbone. Within a single VPN, different types of
tunnels SHOULD be allowed.
2.9 Management
The VR architecture SHOULD provide mechanisms to make it easy to
configure, deploy, operate and troubleshoot each VPN independently,
using existing mechanisms and tools. Tools used for operating,
managing and debugging IP networks SHOULD be able to be used without
any modification.
Most aspects of the management of the multiple VRs on the PE by the
Service Provider are implementation-specific, and beyond the scope
of this document.
2.10 General Requirements
The following are some general requirements for the VR architecture:
1) The architecture SHOULD accommodate different sizes of VPNs, and
one VPN should not impact other VPNs on the PE.
2) The architecture MUST support overlapping VPN address spaces in
separate VPNs.
3) 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.
4) The architecture MUST work over different deployment scenarios,
e.g. where the service provider owns its own backbone, and where
the service provider obtains backbone service from one or more
other service providers.
Ould-Brahim, et al. Expires October 2004 [Page 6]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
3. Network Reference Model
A VPN customer site is connected to the provider backbone by means
of a connection between a Customer Edge (CE) device, (which can be
one or more hosts and/or routers) and a virtual router (VR). CE
devices are preconfigured to connect to one or more VRs. Multiple VRs
may 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
In general the backbone is a shared network infrastructure, which
represents either:
1) A layer-2 ATM or frame relay network.
2) An IP network.
3) An MPLS network.
Not all VPNs existing on the same PE are necessarily connected via
the same backbone. A single PE can be connected to multiple
backbones. Individual VRs on the PE may also connect to multiple
backbones. Thus a single VPN can be built from multiple transport
technologies in the VR architecture.
4. Virtual Router Definition
A virtual router (VR) is an emulation of a physical router at the
software and/or hardware levels. Virtual routers have independent IP
routing and forwarding tables, and they are isolated from each
other. This means that two VRs on a PE can serve two different VPNs
Ould-Brahim, et al. Expires October 2004 [Page 7]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
which may have overlapping address space. The addresses need only be
unique within a VPN domain.
A virtual router has two main functions:
1) Constructing routing tables for 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 VR with the appearance of a dedicated
router that guarantees isolation from the traffic of other VPNs,
while running on shared forwarding and transmission resources.
Virtual routers belonging to the same VPN domain MUST have the same
Virtual Private Network Identifier (VPN-ID). The VPN-ID SHOULD use
the format described in [RFC-2685]. As noted in [VPN-BGP], when the
VRs in a given VPN use BGP as the backbone routing protocol, the
VPN-ID can be carried in the NLRI to make the addresses of VRs
globally unique. Since globally unique addresses are necessary if
BGP is used for auto-discovery, the use of a consistent VPN-ID is a
key element in supporting auto-discovery and improving scalability
of VR-based VPN services.
To the CE access device, the virtual router appears as a neighbor
router in the CE based network. The CE sends all traffic for non-
local VPN destinations to the VR, unless the specific VPN topology
provides alternate routes. 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 VR holds the routes only for the specific VPN of which that VR
is a member. Any routing protocol can be used between the VRs and
the CEs.
5. How VPNs are Built and Deployed using VRs
Three main VR deployment scenarios can be used for building VPNs:
1) VR to VR connectivity over a layer 2 connection.
2) VR to VR connectivity tunneled over an IP or MPLS network.
3) Aggregating multiple virtual routers over a "backbone virtual
router," which will provide connectivity over a layer 2, IP, or
MPLS network.
These VR deployment scenarios can coexist on a single PE or within a
single VPN.
Ould-Brahim, et al. Expires October 2004 [Page 8]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
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 on a per-VPN connection basis. The connections can be
statically configured or dynamically established.
5.2 VR to VR Connectivity through IP or MPLS tunnels
Virtual routers can connect over an IP or MPLS backbone. In a manner
analogous to layer-2 transport, they can use the backbone to support
tunneled connections among the VRs. The topology can be described
similar to that for layer-2 transport, as in figure 2.
VPN data and routing information is tunneled through the use of IP
or MPLS based tunnels (e.g., IPSec, GRE, IP in IP, MPLS). The use of
tunnels between VRs is addressed in more detail in the discussion of
backbone VRs in the following section of this document.
Although it is clearly possible to use a topology similar to the
layer-2 model over an IP or MPLS backbone, the VR capability also
provides a highly scalable alternative to the use of individual
tunnels between VRs. This alternative is the creation (on each
participating PE) of another VR facing into the backbone network,
which is used to build a kind of backbone VPN that may be shared
among multiple customer VPNs. This is described below as the
"backbone VR."
5.3 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 in each PE (figure 3). In the following sections we call this
single virtual router "the backbone virtual router" or "the backbone
Ould-Brahim, et al. Expires October 2004 [Page 9]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
VR". The backbone VR is a mechanism to enhance scalability. The use
of backbone VRs is OPTIONAL in VR-based VPNs. When backbone VRs are
used, they SHOULD be configured on all PEs which participate in VPNs
carried over the backbone VRs.
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.
The backbone VR connects each PE to a shared backbone
infrastructure. Backbone VRs can be deployed over ATM, FR, IP, or
MPLS networks. Since the backbone VR allows the aggregation of VRs
from multiple VPNs, backbone configuration can remain unaffected as
new VPNs or VPN sites are added. The relationship between the VRs
and the backbone VR is an overlay relationship.
PE-1 PE-2
+---------------+ +---------------+
| | | |
+-----+ | +----+ MPLS/IP based Tunnels +----+ | +-----+
|VPN-A| | |VR-A|........|<---------->|........|VR-A| | |VPN-A|
|sites|-|-|(1) | | | |(2) |-|-|sites|
+-----+ | +----+\+----+ | --------- | +----+/+----+ | +-----+
| |VR-1|-|-(IP/MPLS )-|-|VR-2| |
+-----+ | +----+/+----+ |(Backbones) | +----+\+----+ | +-----+
|VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B|
|sites| | |(1) | | | |(2) | | |sites|
+-----+ | +----+........|<---------->|........+----+ | +-----+
| | | |
+---------------+ +---------------+
Figure 3: VR-1 and VR-2 used as backbone VRs
The relationship between the "ordinary" VPN VRs and the backbone VRs
is conceptually similar to the relationship between separate
routers, even though they coexist in the same device. The individual
VRs in a PE, representing different VPNs, can relate to the backbone
VR as if they were the CEs of a single VPN, with the backbone VR
acting as a PE to them. Thus the VPNs can be multiplexed in a
hierarchical fashion, using IP encapsulation or stacked labels,
depending on the tunnel technology used between the backbone VRs.
The use of the backbone VR provides multiplexing across the backbone
for multiple VPNs, while still allowing individually-engineered
connections where desired. Note that Figure 3 depicts both a
backbone connection between backbone VRs (VR-1 to VR-2) and also
connections between the customer VPN VRs (VR-A(1) to VR-A(2) and VR-
B(1) to VR-B(2) ) which do not pass through the backbone VRs. Both
types of connections may be used simultaneously, e.g., to provide
differentiated services to different classes of traffic. Best-
effort traffic between VR-A(1) and VR-A(2) may be routed through the
Ould-Brahim, et al. Expires October 2004 [Page 10]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
shared backbone VRs, while high-priority traffic between these same
VRs might be routed through the direct connection, which could be
engineered with higher Quality-of-Service parameters. This
illustrates how a service provider can trade off greater scalability
offered by the backbone VR against higher value "personalized
service" for VPN customers.
Note that although the backbone VR concept is described above using
a single backbone VR per PE, there may be multiple backbone VRs per
PE.
5.3.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. This can provide an opportunity for service
differentiation, in which a service provider can offer a higher
level of service (at a higher price point) for individually mapped
VPN connections among a customer's 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 adjacent VRs in the VPN. Note that adjacency in this case is
determined by the overlay topology of the particular VPN, as
determined by configuration or discovery.
VPNs may use different type of tunnels for inter-VR connectivity.
Some sites may use MPLS as their tunnel technology of choice. Other
sites (which transit through non-secure domains) may choose to use
IPSec to encrypt their data.
The scalability and security of dynamic tunnel establishment between
VRs will be enhanced by the ability to exchange a VPN-ID. [VPN-BGP]
supports auto-discovery of the VPN-ID within BGP-based networks.
Further work beyond the scope of this document is needed to
determine the requirements and usage of the VPN-ID exchange within
most tunneling scenarios.
5.3.1.1 MPLS Tunnels
The VR architecture can use MPLS tunneling in various forwarding
scenarios. Individual VRs of some VPNs may be configured to
participate in BGP/MPLS IP VPNs as described in [VPN-RFC2547bis].
Ould-Brahim, et al. Expires October 2004 [Page 11]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
In some scenarios, a hierarchy of two labels can be used. One simple
forwarding scenario is where the inner label identifies the VR
intended to receive the private packet (to be forwarded to the CE).
Another forwarding scenario is to distribute the inner label on a
per-VPN basis across the tunnels, after the tunnel endpoints (VRs)
have been discovered. The label and reachability distribution is
done through the tunnels. In this case the inner label distribution
process can be achieved using BGP or an existing label distribution
protocol on a per-VPN basis. The inner label relates to the private
VPN prefixes. On the egress side traffic will be directed to the
egress interface by looking up the inner label.
5.3.1.2 IPSec Tunnels
IPSec is needed when there is a requirement for strong encryption or
strong authentication. It also supports multiplexing and a
signaling protocol - IKE. IPSec tunnels can be established between
two VPN sites across the backbone (originating from the backbone
VRs).
5.3.2 Routing
The backbone VR exchanges backbone routing information with other
backbone entities (P routers and possibly other backbone VRs). The
backbone routing is separated from the customer VPN routing.
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. The VRs of a given VPN exchange
routing information with adjacent VRs through the tunnels over the
backbone.
If a backdoor link is used between VPN sites 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.3.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.
Ould-Brahim, et al. Expires October 2004 [Page 12]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
5.3.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 types of backbones.
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A|-|-+----+ | | +----+-|-|VPN-A|
|sites| | |VR-A|\ | | |VR-A| | |sites|
+-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+
| |VR-1|-|-(Backbone )|-|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 Membership and Topology 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 (and the VRs on those PEs) that
have customers in a particular VPN. VPN topology represents the set
of VRs configured on PEs and their interconnectivity within the VPN.
The topology can be a full-mesh of VRs, 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 a variety of different
mechanisms, for example:
- Directory server approach, in which VRs query a server to
determine their neighbors.
- Explicit configuration via a management platform.
Ould-Brahim, et al. Expires October 2004 [Page 13]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
- Piggybacking VPN membership and topology information using
existing routing protocols (e.g., BGP) [VPN-BGP].
- Other VPN membership and topology auto-discovery approaches.
The above mechanisms can be combined on a single PE, with different
mechanisms used on a per-VPN basis. 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 protocols.
In this document it is assumed that a mechanism that provides
services similar to BGP is used to achieve auto-discovery of VPN
members. A robust auto-discovery mechanism provides the scalability
needed in large provider-provisioned VPNs. In the approach 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
protocols on a 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 VPN
control information between VRs and/or PEs. It is not intended for
piggybacking VPN private reachability information onto the backbone
routing instance, as is done in [VPN-RFC2547bis], for example.
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 [RFC-2764]. The
enforcement may be done via a firewall, a router with access list
functionality, or any device capable of applying policy decisions 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, with each VR locally imposing its own policy
controls, via a firewall or other enforcement mechanism, 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.
Ould-Brahim, et al. Expires October 2004 [Page 14]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
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-VPN connectivity across the backbones. The main
requirement for the service provider in order to achieve end-to-end
cross-domain VPN connectivity is the ability for both domains to
support a common tunnel technology, plus the ability to support a
common membership and topology discovery technology. 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 or isolation as that tunnel mechanism provides
when used within a single service provider network.
Another scenario for supporting VPNs with multiple service providers
is to use two virtual routers configured on PEs at the
interconnection points. Each VR will use policy decisions and
firewalling to control VPN traffic transiting from one domain to the
other. The two "gateway VRs" have some similarities to the "backbone
VRs," specifically with respect to being able to handle multiple
VPNs. The individual VPN traffic is not terminated on these
"gateway VRs". They provide ingress/egress filtering for any or all
the bidirectional tunneled VPN traffic crossing the boundary. The
VPN traffic will normally be opaque at the boundary, and typical
inter-provider agreements apply to all traffic within individual
VPNs, so the inter-provider VPN traffic is typically filtered all-
or-nothing (by VPN) based on the visible packet identifiers or
labels.
When there are VPN links crossing intervening domains which are not
VPN-aware, tunnels should be configured across the intervening
domains, and the "gateway VR" approach can be employed at the tunnel
endpoints to provide security services appropriate to the
circumstances. Some aspects of this are discussed in more detail in
the "Carrier's Carrier" section.
The ability to use a standard, globally-unique VPN-ID format also
supports the implementation of unambiguous VPN traffic
identification mechanisms across domains.
9. Internet Access
The same link attaching the CE to the VR can be used to provide
Internet access to the VPN sites. The VR operations can be decoupled
from the mechanisms used by the customer sites to access the
Internet.
There are a number of ways to provide Internet access to a VPN using
the VR model. One way of providing VPN Internet access is to
configure a "backbone VR" to steer private traffic to the VPN VR,
and Internet traffic to the normal backbone/Internet forwarding
table. The backbone VR can hold the Internet routes (so it will not
Ould-Brahim, et al. Expires October 2004 [Page 15]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
be necessary for the VPN VRs to handle them). Firewall functionality
should be used to secure the Internet backbone VR access. Network
address translation services can also be configured on the backbone
VR or on VPN VRs where needed for Internet access.
There are a number of other options, since the VR architecture
reflects the flexibility of router architecture. An additional
approach is to configure a particular VR to handle Internet access
only (rather than going to the backbone VR). Another approach is to
use a default route to an Internet gateway (which could be a VR).
10. Carrier's Carrier Case
In some cases, the customer of a VPN is a service provider or
carrier offering VPN services for its own customers. We can
describe this as a VPN hierarchy, with the "carrier's carrier"
providing backbone services to a "sub-carrier." This is sometimes
called "VPN wholesaling." The carrier's carrier may support multiple
sub-carriers within a single PE device. The VR model provides
several approaches to implement this VPN hierarchy.
In one approach, tunnels are built from the VRs of the carrier's
carrier to the CEs of the customers of the sub-carrier ("remote
CEs"). In this case, the VRs of the carrier's carrier provide VPN
service to the remote CEs. The sub-carrier provides transport but
does not participate in the VPN services. This can be particularly
useful in cases where the sub-carrier's PE or P devices are
themselves VRs (which may be instantiated within the same device as
the VRs of the carrier's carrier, handling the connections from the
remote CEs) and where the sub-carrier is outsourcing the management
of its customers' VPN services.
Another approach is where the sub-carrier's VPN services are
completely transparent to the VRs of the carrier's carrier. This is
the default case. It is up to the sub-carrier's VPN service to
distribute VPN reachability among the CEs of its customers.
11. Operations and Management
Each VR operates independently, and can be individually reconfigured
without affecting other VRs on the same PE. In some
implementations, it may be possible for a VR to be "rebooted"
without affecting other VRs. 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
Ould-Brahim, et al. Expires October 2004 [Page 16]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
up their VPN. It is also possible that the backbone VRs could be
managed by a separate entity.
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. Conversely, 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 on a per-VPN basis (e.g. ping and traceroute).
As an example, a VPN customer may be able to telnet to its own VR
and perform 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. This access may provide only the privilege to
monitor (with no privilege to change) the layer 3 status of the
customer's VPN, as seen by the VR. The service provider may be able
to offer VPN customers an SNMP-based method for read-only access to
information about their own VPN. However, backbone topology
information is completely hidden to the VPN VR, and therefore to the
service provider's customer.
12. Quality of Service
This architecture can utilize a variety of Quality of Service
mechanisms. QoS mechanisms developed for physical routers can be
used with VRs, on a per-VR basis, including 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
The VR VPN architecture shares the scalability advantages of other
provider-provisioned VPN architectures. 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 private 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 on a
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 to
Ould-Brahim, et al. Expires October 2004 [Page 17]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
establishing a wide range of priority schemes among the VPNs within
the PE, and contributes to the ability to support a wide range of
VPN scales (high traffic and/or many member sites) in the VR
architecture.
As noted earlier in this document, the use of the "backbone VR"
provides significant scalability advantages, allowing very
straightforward multiplexing of multiple VPNs across PE-PE tunnels
or connections. The individual VPNs and their VRs need not
participate in the discovery and maintenance of the topology of the
backbone network, essentially seeing the backbone as a single large
router to which they are all connected.
14. Security Considerations
From a security viewpoint, the virtual router VPN architecture is an
extension of existing router architectures in which multiple VRs,
each with the same mechanisms of a physical router, can be
configured in a PE device. Thus the VRs inherit the security
concerns and security capabilities of individual routers, which are
largely beyond the scope of this document. Many of those elements
are discussed in some detail in the routing protocol security
document [RP-SEC]. The provider-provisioned VPN framework in general
also has a number of security considerations due to the shared
infrastructure, which are addressed in the PPVPN security framework
document [VPN-SEC]. This section addresses security considerations
which are more specific to the VR architecture.
The VR architecture provides an inherently high level of security
against many types of attacks against individual VPNs, since
individual VPN routing information does not propagate throughout the
backbone network. The VRs usually do not exchange routing
information directly through the backbone routing protocol, but
through tunnels, through layer 2 connections, or (in the case of
backbone VRs supporting ordinary VRs) through communication internal
to the PE device. The tunnels can use the security mechanisms
available to the backbone network, such as IPsec in an IP backbone
network, to protect both the routing exchange and the VPN data.
Since the VR architecture concentrates multiple VRs in a single
device, there is a potential for disruption of one VR to affect
other VRs within the same device. Implementations MUST provide
mechanisms to isolate problems to a single VR within a PE, or to a
single VPN.
If physical or logical network links are shared among VRs, it is
possible that bandwidth depletion attacks against one VPN may affect
other VPNs. VR implementations SHOULD provide mechanisms to mitigate
the effect of excessive traffic being received for individual VPNs
on shared links. In addition, VR implementations SHOULD provide
mechanisms to control the bandwidth usage on a per-VPN basis for
traffic transmitted by the PE device. The VPN service provider
Ould-Brahim, et al. Expires October 2004 [Page 18]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
should ensure that both access networks and backbone networks are
engineered to reduce the likelihood of this kind of attack.
Since the backbone VR(s) may carry traffic from multiple VPNs, the
implementation of backbone VR mechanisms SHOULD provide redundancy
mechanisms. They should provide protection against hostile or
inadvertent resource exhaustion attacks, originating both within or
outside the VPNs.
If the auto-discovery mechanism used in determining membership to
the VPN is subverted, it could potentially be possible for an
attacker to join a VPN without authorization. Likewise, if the VPN-
ID of a VR is erroneously configured, a VPN site could potentially
be joined to the wrong VPN. These issues can both be addressed by
the use of tunnel mechanisms between VRs which include other means
of authentication, such as a shared secret. Other proposals for VPN
membership verification, such as [VPN-AUTH] and [MPLSVPN-AUTH],
offer mechanisms which may also be useful to mitigate this potential
issue.
Various levels of data, routing and configuration security can be
implemented in the VR architecture. Any existing security-related
mechanisms supported by existing routing protocols (e.g.
authentication) can be used unmodified. 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 is done within the virtual
router context. Direct layer-2 connections (ATM, FR), or specific
tunneling mechanisms can also provide various levels of data
security.
15. Document Change History
Version draft-ietf-ppvpn-vpn-vr-03:
Document change history section added.
References updated.
Author information updated.
Section 5.3.1 - Paragraph on VPN-ID exchange added.
Version draft-ietf-ppvpn-vpn-vr-04:
Separated Normative and Informative references.
Version draft-ietf-l3vpn-vpn-vr-00:
No changes. (renamed due to IETF working group reorganization)
Version draft-ietf-l3vpn-vpn-vr-01:
Abstract revised.
References updated.
Page 1 author list reduced to comply with guidelines; all authors
identified in Section 19.
Enhanced description of backbone VR (Section 5.3).
Ould-Brahim, et al. Expires October 2004 [Page 19]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
Changed "PE" to "VR" or "VR of a PE" in several places.
Clarified language (MUST, SHOULD, etc.) in Requirements (Section 2).
Security considerations expanded, with references to relevant work.
Version draft-ietf-l3vpn-vpn-vr-02:
Minor revisions in response to working group last-call comments.
Section 10 (Carrier's Carrier Case) revised extensively.
16. Normative References
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC-2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP",
RFC2661, August 1999.
[RFC-2685] Fox, B., et al, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[RFC-2764] Gleeson, B., et al., "A Framework for IP Based Virtual
Private Networks", RFC 2764, February 2000.
[RFC-2784] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 2784, March, 2000.
[RFC-2917] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN
Architecture", RFC 2917, September 2000.
17. Informative References
[MPLSVPN-AUTH] Behringer, M., Guichard, J., Marques, P. R., "Layer-3
VPN Import/Export Verification ", work in progress.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
[RP-SEC] Barbir, A., Murphy, S., and Yang, Y., "Generic Threats to
Routing Protocols", work in progress.
[VPN-AUTH] Bonica, R., et al., "CE-to-CE Member Verification for
Layer 3 VPNs", work in progress.
[VPN-BGP] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs", work in progress.
Ould-Brahim, et al. Expires October 2004 [Page 20]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
[VPN-RFC2547bis] Rosen, E., et al, "BGP/MPLS IP VPNs", work in
progress.
[VPN-GID] Ould-Brahim, H., Gleeson, B., and Rekhter, Y., "Global
Unique Identifiers (GID)", work in progress.
[VPN-SEC] Fang, L., et al., "Security Framework for Provider
Provisioned Virtual Private Networks", work in progress.
18. Acknowledgments
The full list of authors can be found in section 19. 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, Keerti Melkote, Ron
Bonica, Jerry Sydir, Mark Duffy, and Benson Schliesser.
19. Authors' Addresses
Document Editor (Please send comments to editor.)
Paul Knight
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
paul.knight/at/nortelnetworks.com (change /at/ to @ for email)
Phone: +1 (978) 288 6414
Hamid Ould-Brahim Bryan Gleeson
Nortel Networks Nokia
P O Box 3511 Station C 313 Fairchild Drive
Ottawa, ON K1Y 4H7 Canada Mountain View CA 94043 USA
Phone: +1 (613) 765 3418 bryan.gleeson/at/nokia.com
Email: hbrahim/at/nortelnetworks.com
Gregory Wright Timon Sloane
Nortel Networks Extreme Networks
P O Box 3511 Station C 3585 Monroe Street
Ottawa, ON K1Y 4H7 Canada Santa Clare, CA 95051 USA
Phone: +1 (613) 765 7912 Phone: +1 408-579-3340
gwright/at/nortelnetworks.com TSloane/at/extremenetworks.com
Rainer Bach Rick Bubenik,
T-Data SAVVIS Communications
Hans-Guenther-Sohl-Strasse7 717 Office Parkway
40235, Duesseldorf Germany St. Louis, Mo. 63141 USA
Phone: +49 211 694 2420 Phone: +1 (314) 468-7021
Email: Rainer.Bach/at/telekom.de rickb/at/savvis.net
Ould-Brahim, et al. Expires October 2004 [Page 21]
Internet-Draft draft-ietf-l3vpn-vpn-vr-02.txt April 2004
Abraham Young Isaac Negusse
Huawei Technologies Co., Ltd. Sprint
Kefa Road, Science Industrial Park 2002 Edmund Halley Drive
Nanshan Dst., Shenzhen 518057 China Reston, VA 20191 USA
Phone: +86-755-6540808 Phone: +1 (703) 295-5706
Email: abyoung/at/huawei.com isaac.negusse/at/mail.sprint.com
Chandru Sargor
Cosine Communications Jieyun Jessica Yu
1200 Bridge Parkway SingWave Consulting
Redwood City, CA 94065 USA Email: jyy_99/at/yahoo.com
Phone: +1 (650) 637-2416
Chandramouli.Sargor/at/cosinecom.com
Luyuan Fang Dr. Christian Weber
AT&T Arcor AG & Co.
200 Laurel Avenue Koelner Strasse 5
Middletown, NJ 07748 USA 65760 Eschborn Germany
Phone: +1 (732) 420-1921 Phone: +49(0)69-2169-3973
Email: Luyuanfang/at/att.com Christian-Weber/at/arcor.net
Full Copyright Statement
"Copyright (C) The Internet Society (2003). 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. Expires October 2004 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-21 13:03:30 |