One document matched: draft-muthukrishnan-corevpn-arch-00.txt
Internet Engineering Task Force Karthik Muthukrishnan
INTERNET-DRAFT Andrew Malis
Expires April 5, 1999 Ascend Communications
<draft-muthukrishnan-corevpn-arch-00.txt> October 5 1998
Core IP VPN Architecture
1. Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
2. Acronyms
LSP Label Switched Path
PNA Private Network Administrator
SP Service Provider
SPED Service Provider Edge Device
SPNA SP Network Administrator
VMA VPN Multicast Address
VPNID VPN Identifier
VR Virtual Router
VRC Virtual Router Console
3. Abstract
This draft presents an approach for building core VPN services in
the service provider backbone, as described in [Heinanen]. This
approach does not depend on MPLS running in the backbone but will
benefit from it. The central vision is for the service provider to
provide a virtual router service to their customers. Ease of
configuration, dynamic neighbor discovery, scaling and the use of
existing routing protocols as they exist today without any
modifications are the keystones of this architecture.
Muthukrishnan, Malis Expires March, 1999 [Page 1]
INTERNET-DRAFT Core VPNs October 2, 1998
4. Introduction
This draft describes how VPN services in the backbone of the SP's
network could be built. The predominant emphasis is on providing a
virtual router service and every effort has been made to make the
virtual router as equivalent to a physical router as possible. The
aspects of a router that a virtual router needs to emulate are
configuration of any combination of routing protocols, monitoring
of the network and troubleshooting. Providing a logically
independent routing domain to every VPN enhances the SP's ability
to offer a fully flexible virtual router service that can fully
serve the SP's customer without requiring physical per-VPN
routers.
The approach presented here meets most of the requirements set
forth in [Heinanen] but differs significantly in that we have
strived to not require or depend on any modifications of any
existing routing protocols. Neighbor discovery is aided by the use
of an emulated LAN and is achieved by the use of ARP. This draft
has made a concerted effort to draw the line between the SP and
the PNA: layer 1 and layer 2 services belong and are managed by
the SP while layer 3 services belong to and are managed by the
PNA. By the provisioning of fully logically independent routing
domains the PNA has been given the flexibility to use private and
unregistered addresses. Data security is not an issue given the
use of private LSPs and the use of VPNID encapsulation when
forwarding on shared LSPs.
The approach espoused in this draft differs from that described in
[Jamieson] in the following ways: No routing protocol is modified
or used to aid in the neighbor discovery mechanism. No VPN subnet
from the SP's address space is required to be allocated. No PNL to
PNL direct peering is used. It is not required for the CPE gear to
be also MPLS compliant, thus allowing existing enterprise routers
to not have to be upgraded.
5. Objectives
1. Easy, scalable configuration of VPN endpoints in the service
provider network.
2. No use of globally unique SP IP resources such as IP subnets.
3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud.
4. Virtual Routers fully configured and monitored by network
administrator of the VPN.
Muthukrishnan, Malis Expires March, 1999 [Page 2]
INTERNET-DRAFT Core VPNs October 2, 1998
5. Forwarding quality fully configurable; at the lowest end best
effort internet LSP.
6. Differentiated services on a VPN by VPN basis based on private
LSPs.
7. Security of internet routers extended to Virtual Routers.
8. Specific routing protocols not mandated between Virtual
Routers.
9. No special extensions to existing routing protocols such as
BGP, RIP, OSPF, ISIS etc.
6. Requirements
The service provider network must run some form of multicast
routing to all nodes that will have VPN connections and to nodes
that have to forward Virtual Router discovery multicast datagrams.
7. Architectural Outline
1. Every VPN is assigned a 16 bit VPNID which is unique within the
SP's network. The choice of 16 bits for VPNID (rather than 32
bits) allows 65k VPNs to be built in a SP's network and
simultaneously keeps this ID small enough to be transmitted in
encapsulation headers.
2. The VPN service is offered in the form of a Virtual Router
service. These VRs reside in the SPED and are as such confined to
the edge of the SP's cloud. The VRs will use the SP's network for
data and control packet forwarding but are otherwise invisible
outside the SPEDs.
3. The "size" of the VR contracted to the VPN in a given SPED is
the quantity of IP resources such as routing interfaces, route
filters, routing entries etc. This is entirely under the control
of the SP and provides the fine granularity required to empower
the SP to offer virtually infinite grades of VR service on a per-
SPED level. [Example: one SPED may be the aggregating point (say
headquarters of the corporation) for a given VPN and a number of
other SPEDs may be access points (branch offices). In this case,
the SPED connected to the headquarters may be contracted to
provide a large VR while the SPEDs connected to the branch offices
may house small, perhaps stub VRs].
4. One of the indicators of the size of the VPN is the number of
Muthukrishnan, Malis Expires March, 1999 [Page 3]
INTERNET-DRAFT Core VPNs October 2, 1998
SPEDs in the SP’s network that have connections to CPE routers. As
globally unique IP resources do not have to be dedicated/assigned
to VPNs, the number of SPEDs is not limited by any artificial
configuration limits.
5. Layer 1 and Layer 2 entities belong to and are managed by the
SP. To be specific, physical switches/routers, physical links,
logical layer 2 connections (such as DLCI in Frame Relay and
VPI/VCI in ATM) and LSPs (and their assignment to specific VPNs)
are under the control of the SP. In the context of VPNs, it is the
SP's responsibility to contract and assign layer 2 entities to
specific VPNs.
6. Layer 3 entities belong to and are managed by the PNA. Examples
of these entities include IP interfaces, choice of dynamic routing
protocols or static routes, and routing interfaces. This provides
a virtual routing domain to the PNA and empowers the PNA to design
the network to achieve intranet, extranet and traffic engineering
goals.
7. The PNA can manage and monitor the VPN using the methods that
would have been used if physical routers rather than VRs were
used. Therefore, management may be performed using SNMP or other
similar methods or directly at the console, the VR console (VRC).
Monitoring and troubleshooting may be performed using SNMP or
similar, but may also include the use of standard tools such as
ping, traceroute etc. Again, the VRC may be used for these
purposes just like any physical router.
8. The VRs in the SPEDs form the VPN in the SP's network.
Together, they represent a virtual routing domain. They
dynamically discover each other by utilizing an emulated LAN
resident in the SP's network. Each VPN in the SP's network is
assigned a multicast address. Subscription to this multicast
address allows a VR to discover and be discovered by other VRs.
9. Data forwarding may be done in one of several ways: hop-by-hop
using some form of tunneling SPED-to-SPED, a public LSP with
best-effort characteristics or a traffic engineered private LSP
with differentiated characteristics. The choice of which LSP is
configurable by the SP. The default is the public LSP with best-
effort characteristics. The hop-by-hop mechanism is available to
route packets during periods of LSP establishment and failure.
8. Scalable Configuration
A VPN is expected to have 100s to 1000s of endpoints within the SP
cloud. Configuration should therefore scale at most linearly with
Muthukrishnan, Malis Expires March, 1999 [Page 4]
INTERNET-DRAFT Core VPNs October 2, 1998
the number of end points. Anything worse will make this task too
daunting for the service provider. To this end, all that the
service provider needs to allocate/assign are physical/logical
links from the private network to the service provider edge
device.
9. Dynamic Neighbor Discovery
The VRs in a given VPN reside in a number of SPEDs in the network.
The problem is that these VRs need to be connected together. One
way to do this is to require the configuration of tunnels between
these VRs in a fully meshed fashion. This is obviously not
scalable from a configuration and network resource standpoint.
Hence the need arises to allow these VRs to dynamically discover
each other. Neighbor discovery is facilitated as follows: each
VPN is given a limited emulated LAN. This emulated LAN is used in
several ways:
1. Address resolution uses this LAN to resolve next-hop (private)
IP addresses associated with the other VRs.
2. Routing protocols such as RIP and OSPF use this limited
emulated LAN for neighbor discovery and to send routing updates.
The per-VPN LAN is emulated using an IP multicast address. In the
interest of conserving public address space and because this
multicast address needs to be visible only in the SP network
space, we would use an address from the Organizationally scoped
multicast addresses (239.192/14) as described in [Meyer]. Each VPN
is allocated an address from this range. To completely eliminate
configuration in this regard, this address could be computed given
the VPNID.
10. Virtual Router Configuration
Muthukrishnan, Malis Expires March, 1999 [Page 5]
INTERNET-DRAFT Core VPNs October 2, 1998
172.150/18 172.150.128/18
----------------------- ---------------------------|
| | |
| | 172.150.128.1
| | Parts DB
| --------------- |
| OSPF | | OSPF |
------------| VR - A |--------------
|-------------|
) ( RIP
RIP ) (
) (
|--------------| -----------------|
| | | |
| VR - B | | VR - C |
|--------------- |-----------------
| | Extranet
------------------------- |
172.150.64/18 V
Vendors
Figure 1
Each Virtual Router is configurable by the PNA as though it were a
private physical router. The resources that this Virtual Router may
consume is of course limited by the bounds set by the SP on a SPED by
SPED basis. Each VPN has a number of physical connections (to CPE
routers) and a number of logical connections (to the emulated LAN).
Each of these connections is IP capable and can be configured to
utilize any combination of the standard routing protocols and routing
policies to achieve specific corporate network goals.
To illustrate, in Figure 1, there are 3 VRs on 3 SPEDs. VR-C and VR-B
have a physical connection each to CPE equipment while VR-A has 2
physical connections. Each of the VRs has a fully IP capable logical
connection to the emulated LAN. VR-A has the (physical) connections
to the headquarters of the company and runs OSPF over those
connections. It can therefore route packets to 172.150/18 and
172.150.128/18. VR-B runs RIP in the branch office(over the physical
connection) and uses RIP (over the logical connection) to export
172.150.64/18 to VR-A. VR-A advertises a default route to VR-B over
the logical connection. VR-C is the extranet connection for vendors
to use to connect to the parts database at 172.150.128.1. Hence VR-C
advertises a default route to VR-A over the logical connection. VR-A
exports only 175.150.128.1 to VR-C. This keeps the rest of the
corporate network from being subjected to a security problem.
The network administrator will configure the following:
Muthukrishnan, Malis Expires March, 1999 [Page 6]
INTERNET-DRAFT Core VPNs October 2, 1998
1. OSPF connections to the 172.150/18 and 172.150.128/18 network in
VR-A.
2. RIP connections to VR-B and VR-C on VR-A.
3. Route policies on VR-A to advertise only the default route to VR-
B.
4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C.
5. RIP on VR-B to VR-A.
6. RIP on VR-C to advertise a default route to VR-A.
11. Forwarding
As mentioned in the architectural outline, data forwarding may be
done in one of four ways. The actual method in all but the first
outlined here is configurable. At the high end the private LSP is
preferred for data forwarding and at the other end hop-by-hop
forwarding is used. The order of forwarding preference is therefore:
optionally configured private LSP, best effort public LSP and lastly,
hop-by-hop.
11.1 Private LSP
This LSP is optionally configured on a per-VPN basis. This LSP is
usually associated with non-zero bandwidth reservation and/or a
specific differentiated service or QOS class. If this LSP is
available it is used for user data and for VPN private control data
forwarding.
11.2 Best Effort Public LSP
VPN data packets are forwarded using this LSP if a private LSP with
specified bandwidth and/or QOS characteristics is either not
configured or not presently available. The LSP that is used is that
destined for the egress router in VPN 0. The VPNID in the shim header
is used to de-multiplex data packets from various VPNs at the egress
router.
11.3 Hop-by-hop
This method of forwarding is used when no LSP is currently available
to carry the traffic. This could happen when the LSP is going through
a down transient. To confine the VPN routing tables to the edges of
the SP network, the VPNID and the egress SPED's ID need to carried
Muthukrishnan, Malis Expires March, 1999 [Page 7]
INTERNET-DRAFT Core VPNs October 2, 1998
all the way. An approach is to tunnel the packet to the egress SPED
with the IP protocol set to IPVPN (protocol number to be allocated
by IANA) and with a label pushed to represent the VPNID [TBD].
12. Differentiated Services
The configuration of private LSPs for VPNs allows the SP to offer
differentiated services to paying customers. These private LSPs could
be associated with any available QOS class. Multiple private LSPs
with different QOS classes could be configured in a VPN with flow
profiles used to sort the packets among the LSPs. This feature
together with the ability to size the virtual routers allows the SP
to offer truly differentiated services to the VPN customer.
13. Virtual Router Security Considerations
13.1 Data Security
This allows the SP to assure the VPN customer that data packets in
one VPN never has the opportunity wander into another. From a routing
standpoint, this is achieved by maintaining separate instances of
routing protocols and routing tables for each virtual router. From a
data forwarding standpoint, the use of VPN encapsulation headers (in
the case of shared LSPs or hop-by-hop forwarding) or the use of
private LSPs guarantees data privacy.
13.2 Configuration Security
Virtual routers appear as real routers to the PNA. This means that
they may be configured by the PNA to achieve connectivity between
offices of a corporation. Obviously, the SP has to guarantee that the
PNA and the PNA's designees are the only ones to have access to the
VRs on the SPEDs the private network has connections to. Since the
virtual router console is functionally equivalent to a physical
router, all of the authentication methods available on a physical
console such as password, RADIUS, etc. are available to the PNA. By
allowing only authenticated PNAs to access the VR console, the SP
guarantees that the VPN is in full control of its destiny.
14. Physical Network Security
When a PNA logs in to a SPED to configure or monitor the VPN, the PNA
is logged into the VR for the VPN. The PNA has layer 3 configuration
and monitoring privileges for the VR. Specifically the PNA has no
configuration privileges for the physical network. This provides the
guarantee to the SP that a VPN administrator will not be able to
inadvertently or otherwise adversely affect the SP's network.
Muthukrishnan, Malis Expires March, 1999 [Page 8]
INTERNET-DRAFT Core VPNs October 2, 1998
15. Virtual Router Monitoring
All of the router monitoring features available on a physical router
is available on the virtual router. This includes utilities such as
"ping" and "traceroute". In addition, the ability to display private
routing tables, link state databases, etc. are available.
16. Acknowledgements
Thanks to Sridhar Komandur and Peter Fetterolf of Ascend
Communications for their helpful review and feedback.
17. References
[Callon] Callon R., et al, "A framework for Multiprotocol Label
Switching, draft-ietf-mpls-framework-02.txt".
[Rosen] Rosen E., et al, "Multiprotocol Label Switching
Architecture", draft-ietf-mpls-arch-02.txt.
[Heinanen] Heinanen J., et al, "MPLS Mappings of generic VPN
mechanisms", draft-heinanen-generic-vpn-mpls-00.txt.
[Jamieson] Jamieson D., et al, "MPLS VPN Architecture", draft-
jamieson-mpls-vpn-00.txt.
[Meyer] Meyer D., "Administratively Scoped IP Multicast". RFC 2365.
18. Authors' addresses
Karthik Muthukrishnan
Ascend Communications
1 Robbins Road
Phone: (978) 952-1368
Westford, MA 01886
Email: karthikm@ascend.com
Andrew Malis
Ascend Communications
1 Robbins Road
Westford, MA 01886
Phone: (978)-952-7414
Email: malis@ascend.com
Muthukrishnan, Malis Expires March, 1999 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 07:11:38 |