One document matched: draft-hu-i2rs-overlay-use-case-05.xml


<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-hu-i2rs-overlay-use-case-05.txt"
     ipr="trust200902">

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="I2RS Overlay">I2RS overlay use case</title>

    <author fullname="Fangwei Hu" initials="F." surname="Hu">
      <organization>ZTE</organization>

      <address>
        <postal>
          <street>No.889 Bibo Rd</street>
          
          <city>Shanghai</city>
          
          <region></region>
  
          <code>201203</code>

          <country>China</country>
        </postal>

        <phone>+86 21 68896273</phone>

        <email>hu.fangwei@zte.com.cn</email>
      </address>
    </author>

<author fullname="Bhumip Khasnabish" initials="B." surname="Khasnabish">
<organization> ZTE (TX) Inc.</organization>
<address>
<postal>
	<street>55 Madison Ave, Suite 302</street>  
	<!-- Reorder these if your country does things differently  -->	<city>Morristown</city>  
	<region>NJ</region>  
	<code>07960</code>  
	<country>USA</country>
</postal>
<phone>+001-781-752-8003</phone>
<email>vumip1@gmail.com, bhumip.khasnabish@ztetx.com</email>
<uri>http://tinyurl.com/bhumip/</uri>
</address>
</author>

    <author fullname="Chunming Wu" initials="C." surname="Wu">
      <organization>Zhejiang University</organization>

      <address>
        <postal>
          <street></street>
     
          <city>Hangzhou</city>

          <region>Zhejiang</region>

          <code></code>

          <country>China</country>
        </postal>
        <phone></phone>
		
        <email>wuchunming@zju.edu.cn</email>
      </address>
    </author>
	
    <date year='2015'/>
	
    <area>Route</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>I2RS, overlay</keyword>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section title="Introduction">
      <t>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.</t>
	  
	  <t>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
	  (<xref target="I2RS-FRM"></xref>) 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.</t> 
	  
     <t>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. </t>	  
     </section>
	  
	  <section title="Overlay Network Structure">
	   <section title="Overview">
	       <figure  align="center">
            <artwork align="center"><![CDATA[
           +--------+                                     +--------+ 
           | 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.
            ]]></artwork>

         <postamble></postamble>
        </figure>
		
	    <t>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.</t>
		
		<t>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. </t>
	  </section>
	
      <section title="The Benefit of Overlay Network Structure">
	   <t>
       <list style="format (%d)">
		<t>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.</t>
		
	    <t>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.</t>
		
	    <t>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.</t>
	   </list>
	   </t>
	  </section>
	  
	  <section title="Core Router Requirements">
	    <t>The Core Router performs the following functions:
		 <list style="format (%d)">
		 <t>Core Routers mainly focus on fast forwarding 
		 encapsulated data.</t>
		 
		 <t>The control plane is very simple. It announces
		 and floods the topology information.</t>
		 
		 <t>For compatibility reasons, Route computation may be needed, 
		  but is not absolutely necessary.</t>
		 </list>
		</t>
		</section>
		
		<section title="Edge Router Requirement">
		 <t>The edge Router performs the following functions:
		  <list style="format (%d)">
		   <t>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. </t>
		   
		   <t>Encapsulation data and tunnel type decision: Edge Router
		   negotiates with the peer Edge router based on the service 
		   traffic through controller, and encapsulates the original data 
		   traffic. </t>

		   <t>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.</t>
		   
		   <t>Policy management: Edge Router identifies the
		   policy from The I2RS Commissioner(<xref target="I2RS-FRM"></xref>).</t>
		   
		   <t>Service management: Edge Routers should identify the services
		   and perform the appropriate encapsulation.</t>
		   
		   <t>Route and signal protocol management: Edge Router computes route 
		   based on the topology information received from other edge 
		   router and core router.</t>
		   
		   <t>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.</t>
		   
		   <t>Traffic analysis and reporting: Edge router monitors the 
		   data traffic, and reports the traffic updates/changes.</t>
		  </list>
		  </t>
         </section>	
	   </section>
		
		<section title="MPLS Tunnel automatic configuration">
         <t>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. </t>
		 
		 <t> 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.</t>
		 
		 <t> 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).</t>
		 
		 <t>VPN identifier is used to identify the unique global
		 VPN in the area. </t>
		 
		 <t>VPN Table ID is the index of VPN user information item. </t>
		 
		 <t>VPN forwarding identifier is used to identify the 
		 forwarding data plane packet. Generally, it is the 
		 MPLS label. </t>
		 
		 <t>Master/salve flag indicates the optimal and backup path,
		 which could be used as path protection or traffic engineering.</t>
		 
		 <t>Load balance flag indicates multiple next hop for the
		 forwarding identifier, which is used for load balance. </t>
		 
		 <t>Keep alive time indicates the alive time for the item.</t>
		 
		 <t>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.</t>
		 
		</section>
		 
		<section title = "Security Alliance among ER">
		 <t> 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.</t>


		 <t>As an example, let us consider the following figure(Figure 2).</t>
		 <figure  align="center">
            <artwork align="center"><![CDATA[ 
			
                       +--------------+
                       |              |
                     . | Controller   |.
                    /  |              | \  
                   .   +--------------+  .
     =============/=======================\==================
                 .     ...........         . 
                /      .         .          \
        +------+       . Overlay .        +------+
        |      +-------.         .--------|      |
        | ER1  |       . Tunnel  .        | ER2  |
        +------+       ...........        +------+
		
Figure 2: Controlled Security Alliance among Edge Routers in a Virtualized  Network Environment.
           ]]></artwork>

         <postamble></postamble>
        </figure>
		
		 
		 <t>As shown in Figure 2, ER1 and ER2 need to establish SA(security Alliance), 
		 and adopt IPSec as the security transport channel. </t>
		 <t>
		 <list style="format (%d)">
		 
		 <t>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.</t>
		 
		 <t>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.</t>
		 
		 <t>The controller downloads the necessary parameters to 
		 the ERs through network routing protocol(such as BGP) or
		 Netconf protocol.</t>
		 
		 <t> ERs receives the packets with required parameters from
		 the controller(I2RS Client), and decryption the packets, then
		 write the IPSec parameters to SD table.</t>
		 
		 <t> The Security alliance between ER1 and ER2 is thereby established.</t>
		 
		 <t> 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.</t>
         </list>
		</t>
	   </section>
		 
	   <section title="Network Virtualization(NV)">
	     <section title="Benefits of Network Virtualization">
		  <t>
		  <list style="format (%d)">

		   <t>NV reduces ER complexity and equipment costs.</t>

		   <t>NV allows flexibility and rapid deployment of new services; services
		   can also be quickly scaled up/down based on demands.</t>

		   <t>NV offers seamless support of scalability and reliability</t>

		   <t>NV allows flexibility and simplicity of function combination, for co-existence with hardware based network platform. An ER could be utilized both as BRAS, Firewall, or NAT equipment on the same hardware platform.</t>

		  </list>
		  </t>

		  </section>
		  
		  <section title="Applications and Requirements">
		   <t>
		   <list style="format (%d)">
		    <t>Tunnel gateway elements: IPSec/SSL VPN gateway.</t>
			<t>Traffic analytics: DPI, QoS measurement, SLA agent.</t>
			<t>Converged and network-wide functions: AAA Server, 
			policy control and charging platform.</t>
			<t>Security function: Firewalls, virus scanners, 
			instruction detection and prevention systems.</t>
		   </list>
		   </t>
		   </section>

		  <section title="Network Virtualization"> 
		   <t>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. </t>
	       <figure  align="center">
            <artwork align="center"><![CDATA[
+--------------------+                        +-------------------+
| +------+  +------+ |                        | +------+ +------+ |
| |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. 
      ]]></artwork>

         <postamble></postamble>
        </figure>
	   </section>
	  </section>
	  
    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
     </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
  
    <references title="Normative References">
	
	<reference anchor="I2RS-FRM">
	    <front>	
		  <title>An Architecture for the Interface to the Routing System</title>

	      <author surname="Atlas" initials="A."><organization/></author>
		  <author surname="Halpern" initials="J."><organization/></author> 
		  <author surname="Hares" initials="S."><organization/></author>
		  <author surname="Ward" initials="D."><organization/></author> 
		  
          <date day="28" month="June" year="2013"/>
	    </front>
		<seriesInfo name="draft-atlas-i2rs-architecture-00"
         value="(work in process)"		/>
	  </reference>
   	
	 
	 </references>
	   
  </back>
</rfc>

PAFTECH AB 2003-20262026-04-23 04:51:01