Internet DRAFT - draft-hu-i2rs-overlay-use-case
draft-hu-i2rs-overlay-use-case
Network Working Group F. Hu
Internet-Draft ZTE
Intended status: Standards Track B. Khasnabish
Expires: July 30, 2015 ZTE (TX) Inc.
C. Wu
Zhejiang University
January 26, 2015
I2RS overlay use case
draft-hu-i2rs-overlay-use-case-05.txt
Abstract
This document proposes an overlay network use case for interface to
routing system (I2RS). The forwarding routers network is assumed to
be an overlay structure. There are two types of forwarding routers:
Edge Router(ER) and Core Routers(CR). Edge Router encapsulates
format data based on the tunnel type, which are established among
Edge Routers. Core Router would be very simple and cheap. CRs focus
on the encapsulation data forwarding. In order to reduce the overall
ER costs, the use of network virtualization is proposed in this
document.
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 July 30, 2015.
Copyright Notice
Copyright (c) 2015 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
Hu, et al. Expires July 30, 2015 [Page 1]
Internet-Draft I2RS Overlay January 2015
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overlay Network Structure . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. The Benefit of Overlay Network Structure . . . . . . . . 5
2.3. Core Router Requirements . . . . . . . . . . . . . . . . 5
2.4. Edge Router Requirement . . . . . . . . . . . . . . . . . 5
3. MPLS Tunnel automatic configuration . . . . . . . . . . . . . 6
4. Security Alliance among ER . . . . . . . . . . . . . . . . . 7
5. Network Virtualization(NV) . . . . . . . . . . . . . . . . . 8
5.1. Benefits of Network Virtualization . . . . . . . . . . . 8
5.2. Applications and Requirements . . . . . . . . . . . . . . 9
5.3. Network Virtualization . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The hierarchical structure of current Internet core has remained
largely unchanged since its invention. In the face of growing
traffic, service providers must keep investing in larger and faster
routers and links, especially in the core part of Internet, even
though revenues are growing relatively slowly in that segment.
It is necessary to develop and deploy new structure in order to
maintain a steady growth of the core without significantly increasing
the expenses. In addition, as modern networks grow in scale and
complexity, the need for rapid and dynamic control increases. I2RS
([I2RS-FRM]) provides a new routing system framework to meet these
requirements. There is a programmable interface for the forwarding
router. All the forwarding routers should support the I2RS agent to
communicate with controllers. The forwarding routers gather the
traffic and topology information, report to the controllers, and
receive the forwarding policy from controllers.
Besides the idea of programmable and open interface, another key
feature is forwarding plane and control plane separation in the I2RS
Hu, et al. Expires July 30, 2015 [Page 2]
Internet-Draft I2RS Overlay January 2015
in addition to using the concept of software defined networking.
Some of the control and computing function could be separation from
traditional routers. By this way, We could reduce the cost of core
forwarding device. This document proposes an overlay network
structure based on the I2RS framework. We hope that the service and
data encapsulation are all done in the routers of the edge of
network, and the routers in the core part are only focus on MPLS data
forwarding. The RIB table of the routers in core part could only
store very few IP routing record for management. In this way, the
expensive TCAM chip for routers in the core part could be replaced by
cheap ASIC chip, and the cost would be reduced significantly. The
full mesh tunnel is required for the edge Routers. The forwarding
routers in the overlay network are divided into two types based on
the roles in the network: CR(Core Router) and ER(Edge Router). The
Edge Routers encapsulate the forwarding data based on the tunnel
type, gather topology information, and report traffic to the
controller, while Core Routers would be MPLS switches actually, and
focus on fast MPLS data forwarding and receive only policy related
information(metadata)from the controller.
2. Overlay Network Structure
2.1. Overview
Hu, et al. Expires July 30, 2015 [Page 3]
Internet-Draft I2RS Overlay January 2015
+--------+ +--------+
| Edge +--+ +---| Edge |
| Router | | | | Router |
+--------+ | | +--------+
| +------+ +------+ |
| | Core | |Core | |
+--|Router|---------- |Router|-+
+------+ +------+
/ \
/ \
+--------+ / physical topology \ +--------+
| Edge |--+ +----| Edge |
| Router | | Router |
+--------+ +--------+
===================================================================
+--------+ +--------+
| Edge |--+ +----| Edge |
| Router | | | | Router |
+--------+ | ................... | +--------+
| . . |
| . * * . |
+----. * * .-----+
/. * * .
/ . * * .
/ .Overlay * Tunnel .
+--------+ / . * * .-----+ +--------+
| Edge +--+ . * * . | | Edge |
| Router | . * * . +----| Router |
+--------+ ...*............*.. +--------+
Logical Tunnel
Figure 1: An Overlay Structure.
The overlay structure is as shown in Figure 1. The upper half part
of the Figure shows a physical network. The Edge Routers are located
in the edge of the overlay network, and are logically connected
through Core Routers. The services and data encapsulation are done
in the edge routers. The Core Routers(MPLS Switches) are very simple
and focus on the MPLS data forwarding according to the label
forwarding table, and may not perceive any distinction among the
tunnels to/from Edge Routers.
The lower half of the Figure shows a logical tunnel network. All the
Edge Routers are connected via a logical-full mesh tunnel-based
connection among them. The tunnel could be an MPLS tunnel. Edge
Router encapsulates/decapsulates MPLS data.
Hu, et al. Expires July 30, 2015 [Page 4]
Internet-Draft I2RS Overlay January 2015
2.2. The Benefit of Overlay Network Structure
(1) Lower cost for Core Routers: For the Core Router, it is not
required to compute route, and distribute protocol signal. The
Core Routers only store the equipment IP prefix, and do not
store user IP prefix any more. The RIB and FIB table for core
Router are very small. The size routing tables in the Core
Routers does not increase and remains stable with the growth of
the numbers of users.
(2) Improved network security: The overlay network structure
improves network security by splitting(and hence isolating)the
provider equipment and user station. The attacks from hacker to
core routers would therefore be separated by the edge routers.
(3) Support of network virtualization: Some of the control and
computing function could be separated from Edge Router and be
done by the controller. The edge router in the future could be
a simple hardware platform. The service, policy, and other
control functions, such as route computing, signal distribution
can be furnished by physical/virtual servers. The network
virtualization for Edge Router is discussed in section 3.
2.3. Core Router Requirements
The Core Router performs the following functions:
(1) Core Routers mainly focus on fast forwarding encapsulated data.
(2) The control plane is very simple. It announces and floods the
topology information.
(3) For compatibility reasons, Route computation may be needed, but
is not absolutely necessary.
2.4. Edge Router Requirement
The edge Router performs the following functions:
(1) Access and resources management: Edge Routers support user
Access authentication, authorization, and resource control and
management. When there is new user access network, the edge
router support user access authentication, authorization. If
the subscriber is legal and registered, he/she should should
pass the access authentication and authorization tests.
(2) Encapsulation data and tunnel type decision: Edge Router
negotiates with the peer Edge router based on the service
Hu, et al. Expires July 30, 2015 [Page 5]
Internet-Draft I2RS Overlay January 2015
traffic through controller, and encapsulates the original data
traffic.
(3) Topology management:Edge Router gathers the network topology
information and reports the topology to the controller. When
the topology changes, the edge router reports the changes as
well.
(4) Policy management: Edge Router identifies the policy from The
I2RS Commissioner([I2RS-FRM]).
(5) Service management: Edge Routers should identify the services
and perform the appropriate encapsulation.
(6) Route and signal protocol management: Edge Router computes route
based on the topology information received from other edge
router and core router.
(7) Tunnel control and management: Edge Routers manage and maintain
tunnel information. All of the edge routers are connected over
logical full-mesh based tunnel network.
(8) Traffic analysis and reporting: Edge router monitors the data
traffic, and reports the traffic updates/changes.
3. MPLS Tunnel automatic configuration
The MPLS tunnel among the ERs(Edge Routers) could be automatically
configured and established according to the clients' requirements and
information. The procedure is as following: The controller (I2RS
clients) receives the VPN information from Edge Router through the
programmable interface of I2RS Agent. The VPN information includes
VPN Table ID, and table item. The table item is composed of the
following parameters: item key value, exit interface, VPN identifies,
VPN forwarding identifies, Master/Slave flag, load balance flag, keep
alive time, etc.
The item key value is the packet destination address. For example,
if the packet is encapsulated as L2VPN, the item key value is MAC
address, while if the packet is encapsulated as L3VPN,the item key
value is IP address.
Exit interface is the VPN binding interface or local device
identifier when it is the VPN information sent from I2RS Agent to
I2RS Client. If the VPN information is sent from I2RS Client to SR/
CR through I2RS agent interface, the exit interface is the remote SR/
CR identifier or the local tunnel ID, which indicates the end to end
Hu, et al. Expires July 30, 2015 [Page 6]
Internet-Draft I2RS Overlay January 2015
connection from network management (I2RS Client) to CR/ER(I2RS
Agent).
VPN identifier is used to identify the unique global VPN in the area.
VPN Table ID is the index of VPN user information item.
VPN forwarding identifier is used to identify the forwarding data
plane packet. Generally, it is the MPLS label.
Master/salve flag indicates the optimal and backup path, which could
be used as path protection or traffic engineering.
Load balance flag indicates multiple next hop for the forwarding
identifier, which is used for load balance.
Keep alive time indicates the alive time for the item.
Network management collects all of the VPN user information, and
computes the forwarding path and Unified policy based on it. Then it
downloads the forwarding information to each ER/SR through I2RS Agent
interface.
4. Security Alliance among ER
In the overlay network structure, the ER are full mesh. This session
provides a solution to setup SA(security Alliance) among ERs. The
security parameter negotiation could be finished through I2RS Client.
As an example, let us consider the following figure(Figure 2).
+--------------+
| |
. | Controller |.
/ | | \
. +--------------+ .
=============/=======================\==================
. ........... .
/ . . \
+------+ . Overlay . +------+
| +-------. .--------| |
| ER1 | . Tunnel . | ER2 |
+------+ ........... +------+
Figure 2: Controlled Security Alliance among Edge Routers in a Virtualized Network Environment.
Hu, et al. Expires July 30, 2015 [Page 7]
Internet-Draft I2RS Overlay January 2015
As shown in Figure 2, ER1 and ER2 need to establish SA(security
Alliance), and adopt IPSec as the security transport channel.
(1) ER1 and ER2 connect to the controller(I2RS Client) via logical
tunnels, and the controller download the IPSec SA parameters to
them. The parameters include: VPN Type(for example IPSec, L2VPN
etc.), direction of AS(export or import), address family(IPv4 or
IPv6), encapsulation mode, encapsulation protocol(AH or ESP),
authentication algorithm (MD5 or SHA), ESP algorithm
mode(Encryption or compression algorithm), Encryption mode, SA
lifetime type, SA index, destination IP address of IPSec, Source
IP address of IPSec, Secret key, Security parameter index
information(SPI), and Access control list(ACL) configuration.
(2) ER1 and ER2 then establish IPSec security channel respectively.
They negotiate the IPSec parameter with controller through IKE
protocol. By this way, the ERs and controller establish a
security and reliable connection link.
(3) The controller downloads the necessary parameters to the ERs
through network routing protocol(such as BGP) or Netconf
protocol.
(4) ERs receives the packets with required parameters from the
controller(I2RS Client), and decryption the packets, then write
the IPSec parameters to SD table.
(5) The Security alliance between ER1 and ER2 is thereby
established.
(6) When the Security alliance is expired, controller re-computes
the secret key, and restarts the above steps in order to re-
establish the security alliance.
5. Network Virtualization(NV)
5.1. Benefits of Network Virtualization
(1) NV reduces ER complexity and equipment costs.
(2) NV allows flexibility and rapid deployment of new services;
services can also be quickly scaled up/down based on demands.
(3) NV offers seamless support of scalability and reliability
(4) NV allows flexibility and simplicity of function combination,
for co-existence with hardware based network platform. An ER
Hu, et al. Expires July 30, 2015 [Page 8]
Internet-Draft I2RS Overlay January 2015
could be utilized both as BRAS, Firewall, or NAT equipment on
the same hardware platform.
5.2. Applications and Requirements
(1) Tunnel gateway elements: IPSec/SSL VPN gateway.
(2) Traffic analytics: DPI, QoS measurement, SLA agent.
(3) Converged and network-wide functions: AAA Server, policy control
and charging platform.
(4) Security function: Firewalls, virus scanners, instruction
detection and prevention systems.
5.3. Network Virtualization
Edge routers can support network virtualization. An ER can be a
hardware based platform, and the other necessary adjunct functions
can be supported via separate servers. A programmable interface
between functional server and edge router can be used to support this
paradigm. When there is new service, it is required to add a new
server to support that service, and there may only be minimal or no
changes required to the edge routers, as shown in Figure 3.
Hu, et al. Expires July 30, 2015 [Page 9]
Internet-Draft I2RS Overlay January 2015
+--------------------+ +-------------------+
| +------+ +------+ | | +------+ +------+ |
| |DPI | |NAT | | | |DPI | |NAT | |
| |Server| |Server| | | |Server| |Server| |
| +------+ +------+ | | +------+ +------+ |
| +------+ | | +------+ |
| | QOS | | | | QOS | |
| |Server| | | |Server| |
| +------+ | | +------+ |
+-----+--------------+ virtualization +---------------+---+
======|=======================================================|====
. .
| +------------------------------------------------+ .
. | +--------+ +-------+ | |
|- +-->| Edge | | Edge |<--+---.
. | | Router | | Router| | |
| | +--------+ +-------+ | .
. | Overlay Network | |
| | +-------+ +-------+ | .
. | | Core |-----| Core | | |
| | | Router| | Router| | .
. | +-------+ +-------+ | |
| | | .
. | +--------+ +-------+ | |
+--+->| Edge + | Edge |<--+---+
| | Router | | Router| |
| +--------+ +-------+ |
+------------------------------------------------+
Figure 3: Network Virtualization Example.
6. Security Considerations
TBD
7. IANA Considerations
TBD
8. Normative References
[I2RS-FRM]
Atlas, A., Halpern, J., Hares, S., and D. Ward, "An
Architecture for the Interface to the Routing System",
draft-atlas-i2rs-architecture-00 (work in process), June
2013.
Hu, et al. Expires July 30, 2015 [Page 10]
Internet-Draft I2RS Overlay January 2015
Authors' Addresses
Fangwei Hu
ZTE
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Bhumip Khasnabish
ZTE (TX) Inc.
55 Madison Ave, Suite 302
Morristown, NJ 07960
USA
Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/
Chunming Wu
Zhejiang University
Hangzhou, Zhejiang
China
Email: wuchunming@zju.edu.cn
Hu, et al. Expires July 30, 2015 [Page 11]
