Internet DRAFT - draft-li-l3vpn-instant-vpn-arch
draft-li-l3vpn-instant-vpn-arch
Network Working Group Z. Li
Internet-Draft Y. Yin
Intended status: Informational Huawei Technologies
Expires: April 23, 2014 October 20, 2013
An Architecture of Instant VPN
draft-li-l3vpn-instant-vpn-arch-00
Abstract
With the wide application of cloud computing technology, more and
more enterprises will hire public cloud data center resources, reduce
their own costs. Providers need to enterprise data center rental
network and enterprise own network connected together, provide
enterprise lease line services. L3VPN is most providers provide this
service selection. New VPN line business needs to rapidly deploy,
but the current technology cannot meet this requirement. This
document introduces the architecture to deploy L3VPN rapidly which
can satisfy the requirement for service provision.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RE
COMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 23, 2014.
Copyright Notice
Li & Yin Expires April 23, 2014 [Page 1]
Internet-Draft An Architecture of Instant VPN October 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. VPN Controller . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. VPN User Interface . . . . . . . . . . . . . . . . . 6
4.1.2. VPN Authentication . . . . . . . . . . . . . . . . . 6
4.1.3. VPN User Management . . . . . . . . . . . . . . . . . 6
4.1.4. VPN Route Management . . . . . . . . . . . . . . . . 7
4.2. PE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. VPN User Management . . . . . . . . . . . . . . . . . 7
4.2.2. VRF Instance Automatically Create . . . . . . . . . . 7
4.2.3. Access Side Configure Automatically . . . . . . . . . 7
4.2.4. VPN Tunnel Automatically Setup . . . . . . . . . . . 8
4.3. CE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. VPN User Information Input . . . . . . . . . . . . . . . 8
5.2. VPN User Authentication Process . . . . . . . . . . . . . 9
5.3. VRF Instance Configuration . . . . . . . . . . . . . . . 9
5.4. Route Protocol Configuration Between PE and CE . . . . . 9
5.5. VRF Route Distribution . . . . . . . . . . . . . . . . . 10
5.6. VPN Tunnel Establishment . . . . . . . . . . . . . . . . 10
6. Protocol Extension Requirements . . . . . . . . . . . . . . . 11
6.1. Authentication Between CE and PE . . . . . . . . . . . . 11
6.2. Authentication Between PE and VPN Controller . . . . . . 11
6.3. Configuration Distributed from VPN Controller to PE . . . 11
6.4. Tunnel Information Distributed from VPN Controller to PE 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Li & Yin Expires April 23, 2014 [Page 2]
Internet-Draft An Architecture of Instant VPN October 2013
1. Introduction
Enterprise leased line is one of the provider's principal business.
Many providers are currently using L3VPN technology to provide this
type of service, and with the development of cloud computing, the
public cloud data centers will provide network service for a large
number of enterprises and the provider's network need deploy massive
L3VPNs in a short time. But the current L3VPN deployment has
following problems to be unable to meet fast deployment requirements.
1. The deployment of an L3VPN need to configure the VPN instance and
tunnel on PE nodes. If an L3VPN has a lot of access points, many PE
nodes need to be configured and creation of tunnels will become
complicated. For data centers to support massive tenants, the PE
nodes need to configure massive VPNs. The configuration work will be
huge and error-prone.
2. The L3VPN deployment need to configure RD, RT, etc. which need
complex unified planning and design.
3. For enterprise lease line services , providers and enterprises
need to plan ahead between CE and PE IP address and routing
protocols, and enterprise CE position changes, need to reconfigure
the corresponding PE.
This document defines an architecture of instant L3VPN to deploy
L3VPN fast which is achieved by central control.
2. Terminology
VPN: Virtual Private Network
CE: Customer Edge Router
PE: Provider Edge Router
MP-BGP: Multiprotocol BGP
RT: Route Target
RD: Route Distinguisher
EAP: Extensible Authentication Protocol
RADIUS: Remote Authentication Dial In User Service
I2RS: Interface to The Internet Routing System
Li & Yin Expires April 23, 2014 [Page 3]
Internet-Draft An Architecture of Instant VPN October 2013
3. Requirement
This chapter describe requirements of rapid deployment of L3VPN for
cloud computing scenarios from the point of view of the enterprise
and the provider:
For enterprises:
Requirement 1: Enterprise users can apply for VPN services from
providers through web pages.
Requirement 2: Enterprise users can have access to the VPN network at
any position.
Requirement 3: When the position of the enterprise's CE can be
changed, configuration after migration need not to be changed and CE
can still access L3VPN network real time.
Requirement 4: Enterprises can define access strategy between any two
CEs.
Requirement 5: Enterprises can define the bandwidth and other
constraints between any two CEs.
Requirement 6: Enterprises can apply for virtual machine resources
from provider data center, and the virtual machine can quickly access
the enterprise L3VPN networks.
For providers:
Requirement 1: Providers can deploy VPN service rapidly according to
business requirements of the enterprise.
Requirement 2: Providers can do for enterprise user authentication,
authorization, and accounting functions.
Requirement 3: Providers can manage all VPN, including viewing each
VPN's CE ID, PE address which CE access to, the tunnel state
information between PEs, etc., and can provide enterprises with a VPN
SLA reports.
4. Architecture
The architecture of Instant VPN is shown in the following figure.
There is a VPN controller in the network to directly control all PE
devices. This document focuses on the VPN deployment in one AS. The
central control architecture for the inter-AS VPN will be described
in the future version.
Li & Yin Expires April 23, 2014 [Page 4]
Internet-Draft An Architecture of Instant VPN October 2013
+---------------------------------------------+
| |
| +----------------+ +----------------+ |
| | VPN | | VPN USER | |
| | AUTHENTICATION | | INTERFACE | |
| +----------------+ +----------------+ |
| VPN Controller |
| +----------------+ +----------------+ |
| | VPN USER | | VPN ROUTE | |
| | MANAGEMENT | | MANAGEMENT | |
| +----------------+ +----------------+ |
| |
+---------------------------------------------+
| | |
| | |
+-----|-----------------|----------------|------+
| | | | |
| | +---------+ | |
| | | PE | | |
| | | NODE 1 | | |
| | /| BGP |\ | |
| | / | CLIENT | \ | |
| | / +---------+ \ | |
| | / \ | |
+----+ | +--------+ / \ +--------+ | +----+
| | | | PE | / \ | PE | | | |
| CE |----| NODE 2 |/ \| NODE n |----| CE |
| | | | BGP | ...... | BGP | | | |
+----+ | | CLIENT | | CLIENT | | +----+
| +--------+ +--------+ |
| |
+-----------------------------------------------+
Figure 1 An Architecture of Instant VPN
4.1. VPN Controller
There are four main function modules in the VPN Controller which
controls all PE devices:
-- VPN User Interface
-- VPN Authentication
-- VPN User Management
-- VPN Route Management
Li & Yin Expires April 23, 2014 [Page 5]
Internet-Draft An Architecture of Instant VPN October 2013
4.1.1. VPN User Interface
1. Provides the interface for the enterprise VPN user to input VPN
information which will be saved to the VPN User Management module.
2. Provide VPN information query interface to view the VPN
information through the interface, such as the current on-line of CE
ID, PE address which CE accessed to, VPN tunnel information, VPN SLA
etc.
4.1.2. VPN Authentication
1. Receive the authentication request message of CE from PE.
2. Being responsible for the authentication of VPN users on-line by
examining the VPN ID+CE ID and CE password.
3. Reply message with VPN information for the users that pass the
authentication successfully .
4.1.3. VPN User Management
1. Being responsible for the management of all providers of VPN user
information, including:
VPN ID: unique ID of enterprise VPN users.
CE ID: unique ID of CE, which should be guaranteed to be unique
within an enterprise VPN user.
CE password: CE access authentication password.
Access strategy between CEs: definition of strategy which defines how
two different CEs in the same VPN access to each other.
Routing protocol between CE and PE: choice of routing protocol which
runs between CE and PE. If BGP is chosen, the private network AS
number should be provided.
IP address and mask connected between CE and PE: IP address and
subnet mask of the PE's interface which accessed to CE, the IP
address and subnet mask of the CE's interface which accessed to PE.
All above Information should be provided by the enterprises when they
apply for VPN service.
2. Automatic generating of configuration for each access CE,
including VRF name, RD, RT information.
Li & Yin Expires April 23, 2014 [Page 6]
Internet-Draft An Architecture of Instant VPN October 2013
3. Management of all on-line VPN users, including all CE IDs, PE
addresses which CE accessed to, etc.
4.1.4. VPN Route Management
1. Receives all VPN routes from all PEs. Calculate routes for each
VRF based on each VRF's IRT.
2. Send the VRF routes to PE based on the strategy of center
control.
3. Apply the route policy centrally to control the route
distribution.
4.2. PE
There are four main function modules in PE devices: VPN user
management function, VRF instance automatically create function,
Access side configuration automatically function, VPN tunnel
automatically set up function.
4.2.1. VPN User Management
1. Receive authentication request message from CE, including VPN ID,
CE ID, CE password, and send authentication request to VPN
controller.
2. Receive authentication response message from VPN controller,
including authentication result, VPN ID, CE ID, the routing protocol
running with CE, the CE interface IP address and mask which access to
PE, the PE interface IP address and mask which access to CE, the CE
AS number and PE AS number if route protocol is BGP, and send the
authentication response message to CE.
3. Manage all CE users, recording VPN ID, CE ID, the CE access
interface, accounting for VPN user.
4.2.2. VRF Instance Automatically Create
1. Create VRF instance based on the configuration which VPN
controller sent, configure the RD and RT automatically
2. Bind the CE access interface with VRF automatically.
4.2.3. Access Side Configure Automatically
1. Configure the IP address and subnet mask of the interface which
access to CE based on the authentication response message.
Li & Yin Expires April 23, 2014 [Page 7]
Internet-Draft An Architecture of Instant VPN October 2013
2. Configure the route protocol based on the message which VPN
controller sent.
4.2.4. VPN Tunnel Automatically Setup
1. For each VRF, receive the following information which VPN
controller sent:
---The PE IP address list which can access to the VPN.
---The tunnel information including tunnel type, tunnel bandwidth and
other constraints if MPLS TE tunnel is used.
2. Set up the tunnel automatically with each PE.
4.3. CE
1. Automatically initiate VPN user authentication request to PE.
2. Receive VPN user authentication response message including the CE
IP address and mask, the route protocol between CE and PE, the PE IP
address and AS number if protocol is BGP.
3. Configure the interface IP address, mask and route protocol
automatically.
5. Procedures
5.1. VPN User Information Input
Step 1: Enterprise users input following information based on the VPN
User interface which VPN controller provided:
-- VPN ID
-- CE ID
-- CE password
-- access strategy between CEs
-- routing protocol between CE and PE
-- IP address and mask connected between the CE and the PE.
Step 2: VPN Controller saves the VPN information to the VPN User
Management.
Li & Yin Expires April 23, 2014 [Page 8]
Internet-Draft An Architecture of Instant VPN October 2013
5.2. VPN User Authentication Process
Step 1: CE initiates VPN service request to PE automatically ,
carrying the VPN ID, CE ID, CE password.
Step 2: PE receives the authentication request and sends the
authentication request to VPN Controller.
Step 3: VPN Controller receives and processes the authentication
request through the VPN Authentication module based on the
information input by the enterprise users.
Step 4: If the authentication passes, VPN Controller sends
authentication success message to PE, carrying information: VPN ID,
CE ID, the routing protocol between CE and PE, the CE IP address and
mask, the PE IP address and mask, the CE AS number and PE AS number
if routing protocol is BGP.
Step 5: PE decapsulates authentication success message. If the
routing protocol between CE and PE is BGP, PE's own AS number and IP
address will be encapsulated in an authentication success message and
sent to CE.
5.3. VRF Instance Configuration
Step 1: After the CE authentication passes, VPN Authentication module
informs VPN User Management module.
Step 2: VPN User Management module creates an VRF instance for the CE
user, automatically generating VRF RD, import RT and export RT
information.
Step 3: VPN User Management module sends VRF configuration
information to the corresponding PE.
Step 4: PE receive the VRF configuration from VPN controller, and
create VRF automatically, binding VRF with the interface which CE
access to.
5.4. Route Protocol Configuration Between PE and CE
Step 1: After the CE user authentication passes, VPN User Management
gets the routing protocol information between CE and PE and
automatically generates the routing protocol configuration of the PE.
If the BGP protocol runs between the CE and the PE, the CE's IP
address and AS number are also required. If the enterprise define
the access strategy, also generates the route policy configuration.
Li & Yin Expires April 23, 2014 [Page 9]
Internet-Draft An Architecture of Instant VPN October 2013
Step 2: VPN User Management sends the configuration to PE to compete
the configuration automatically.
Step 3: After the CE receives the authentication success message from
PE, it can get the route protocol type between CE and PE. If the
protocol is BGP, it can also get the PE's IP address and AS number
from the message. Then the CE can complete the routing configuration
automatically.
5.5. VRF Route Distribution
Step 1: BGP peers establish automatically between the PE and the VPN
Controller.
Step 2: CE advertises its routes to PE.
Step 3: PE advertises the routes which are received from CE to the
VPN controller. VPN controller processes the routes through VPN
Route Management module.
Step 4: VPN Route Management module receives VRN routes of all on-
line CE and calculate routes for each VRF according to the VRF RT
value.
Step 5: In the controller the enterprise users can configure specific
policy for each CE or PE to control the route distribution, such as
the removal of specific routing prefixes.
Step 6: VPN Controller advertises the VRF routes to the corresponding
PE.
Step 7: PE receives and installs the VRF routes. Then the PE sends
routes to CE.
5.6. VPN Tunnel Establishment
If the enterprise user does not define the bandwidth and other
constraints between CEs, the tunnel for the VPN can use LDP or GRE,
VXLAN and other types of tunnels. If the enterprise users define the
bandwidth or other constraints between CEs, MPLS TE tunnel can be
used.
Based on VRF RT information of PEs, VPN controller determine the
tunnels which should be set up among these PEs of the VPN.
When a new CE is online, VPN Controller will send the PE lists to a
specific PE. The PE lists determines the tunnels which the specific
PE need to set up to these PEs. In addition, the tunnel type can
Li & Yin Expires April 23, 2014 [Page 10]
Internet-Draft An Architecture of Instant VPN October 2013
also be advertised to the PE. If MPLS TE tunnel is used, the MPLS TE
constraint for the tunnel can also be advertised. When the PE
received the PE list, it should establish the tunnel with the other
PE members specified by the PE list.
6. Protocol Extension Requirements
6.1. Authentication Between CE and PE
Needs to be extended as follows:
1. The authentication request message need carry the VPN ID
information, CE ID, CE password information.
2. The authentication response message need carry the route protocol
between CE and PE, the IP address and mask of CE, if route protocol
is BGP, also need carry the IP address PE, the CE AS number and the
PE AS number.
6.2. Authentication Between PE and VPN Controller
Needs to be extended as follows:
1. The authentication request message need carry the VPN ID
information, CE ID, CE password information.
2. The authentication response message need carry the route protocol
between CE and PE, the IP address and mask of CE, the IP address and
mask of PE, if route protocol is BGP, also need carry the CE AS
number and the PE AS number.
6.3. Configuration Distributed from VPN Controller to PE
Needs to be extended as follows:
1. VRF configuration, including VRF name, VRF RD, VRF RT.
2. The route protocol configuration, including protocol process
number, route policy etc.
6.4. Tunnel Information Distributed from VPN Controller to PE
Needs to be extended as follows:
1. PE members list information which VRF accessed to.
2. The tunnel type, tunnel constraint information if MPLS TE is
used.
Li & Yin Expires April 23, 2014 [Page 11]
Internet-Draft An Architecture of Instant VPN October 2013
7. IANA Considerations
This document makes no request of IANA.
8. Security Considerations
In this solution, the main need to consider the security between CE
and PE communication, PE and VPN Controller, in the existing protocol
already has good mechanism, this paper does not introduce in detail.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
Authors' Addresses
Li & Yin Expires April 23, 2014 [Page 12]
Internet-Draft An Architecture of Instant VPN October 2013
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Yuanbin Yin
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: yinyuanbin@huawei.com
Li & Yin Expires April 23, 2014 [Page 13]