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
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.
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 (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 (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.
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 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.
+--------+ +--------+ | 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.
The Core Router performs the following functions:
The edge Router performs the following functions:
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 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.
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.
As shown in Figure 2, ER1 and ER2 need to establish SA(security Alliance), and adopt IPSec as the security transport channel.
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.
+--------------------+ +-------------------+ | +------+ +------+ | | +------+ +------+ | | |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.
TBD
TBD
[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. |