Internet DRAFT - draft-guo-armd-multistage-arp

draft-guo-armd-multistage-arp



ARMD                                                        Liang Guo
Internet Draft                                             China CATR
 Intended status: Informational                              Shihui Duan
Expires: January 5, 2013                                   China CATR
                                                            July 5, 2012



       Multistage ARP to Reduce the ARP Broadcast in Layer 2 Network
                   draft-guo-armd-multistage-arp-00.txt


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), 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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on Sep 11, 2012.

Copyright Notice

   Copyright (c) 2012 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.





Guo                     Expires Jan 5, 2013                  [Page 1]

   Internet-Draft           multistage arp       July 5, 2012



Abstract

   This document proposes a method to reduce the ARP broadcast in L2
   networks. There will be two MAC tables in the aggregation switches
   which answer for the ARP responses and packet forwarding. Multicast
   will take the place of broadcast for ARP request in this document
   which will lead to the reduction of the numbers of ARP broadcast
   packets in L2 networks.





































Guo                     Expires Jan 5, 2013                  [Page 2]

   Internet-Draft           multistage arp       July 5, 2012

Table of Contents


   1. Introduction ................................................ 4
   2. Conventions used in this document                                            ............................ 4
   3. Overview .................................................... 4
   4. Modification of ARP ......................................... 5
   5. Detailed Work Flow .......................................... 5
      5.1. Building the Tables                                   ..................................... 5
      5.2. Update ................................................. 5
      5.3. Request ................................................ 6
      5.4. Reply .................................................. 6
   6. Application of scene......................................... 7
   7. Simulation .................................................. 7
   8. Conclusions ................................................. 7
   9. Security Consideration                                 ....................................... 7
   10. IANA Considerations......................................... 7
   11. References ................................................. 7
   12. Acknowledgments ............................................ 7































Guo                     Expires Jan 5, 2013                  [Page 3]

   Internet-Draft           multistage arp       July 5, 2012

1. Introduction

   It is well accepted that the virtualization should be a trend of the
   data center and it will bring some positive things about energy
   consumption and the utilization rate of the data center. But
   unfortunately, the virtualization will aggravate the problems about
   ARP. Though the technology about the VM movement is not well
   established, the movement of VM in one L2 network would take place
   definitely and the movement of VM between L2 networks would happen
   probably. It is well known that the movement of VM introduces ARP
   storm in L2 network in DC, so we need to resolve the ARP broadcast
   storm.

   We propose a modified ARP protocol named Multistage ARP in this
   document. Multistage ARP will limit the ARP broadcast in one access
   switch and unicast the ARP request to the aggregation switch.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119
        .

3. Overview

   Generally, there are three layers (the access layer  the aggregation
   layer and the core layer) in the data center.

   The performance of access switches is not good enough and the
   capacity of MAC of access switches is not big enough which is
   different from 2k to 32k. In the Multistage ARP, what they should do
   is to turn off the ARP broadcast or limit it at a low level.

   The switches of aggregation layer would play a critical role in the
   Multistage ARP because they have better ability of process and much
   bigger table of MAC (about 128k per board).

   In the Multistage ARP, the access layer switch would not broadcast
   the ARP request if the access switch does not answer it. Instead the
   access switch would unicast this request to its aggregation switch.
   There are two tables in the aggregation switch. Both of these two
   tables are used for searching of the MAC entry. The difference
   between them is that the local-table is generated through collecting
   all the MAC entries of access switches attached to this aggregation
   switch and the remote-table is generated through learning from other
   aggregation switches.



Guo                     Expires Jan 5, 2013                  [Page 4]

   Internet-Draft           multistage arp       July 5, 2012

   The aggregation switch would look up the MAC entry in its local-
   table and remote-table. The detail is described in section 5.

4. Modification of ARP

   There are some differences between the current ARP and the
   Multistage ARP.

   1. The access switch should unicast the request to its aggregation
   switch instead of broadcasting the ARP request if it does not find
   the MAC entry.

   2. There should be some protocol interactions between the access
   switch and the aggregation switch which are related with the
   concentration and updates of MAC entries and responsible for the ARP
   request and forwarding.

   We think some other types of protocol should be configured to make
   sure that the Multistage ARP can work correctly. The detail of
   changes will be discussed later.

5. Detailed Work Flow

5.1. Building the Tables

   In this document, there would be two MAC entry tables in the
   aggregation switches: local-MAC table and remote-MAC table.

   The generation of local-MAC table is crucial for the proposal of
   this document. We should do some configuration on all aggregation
   switches to make them to obtain the MAC entries of all the access
   switches of themselves. This operation will produce a local-MAC
   table. It would response the incoming requests of local or remote
   hosts.

   When a multicast of ARP request is forwarded to all aggregation
   switches, a response will be back from an aggregation switch if
   there is a related MAC entry. So a remote-MAC table will be produced
   in the local aggregation switch which would be responsible for the
   packet forwarding.

5.2. Update

   The down and up of the ports of the access switch will trigger the
   update of the local-MAC table:





Guo                     Expires Jan 5, 2013                  [Page 5]

   Internet-Draft           multistage arp       July 5, 2012

   If the port is down, the access switch will clear all the MAC
   entries of this port and then send messages to its aggregation
   switch for update.

   If the port is up, the access switch will refresh all the MAC
   entries of this port actively and send messages to its aggregation
   switch for update.

   The update to the local-MAC table which generated before will be
   finished by the unicast between the access switch and the
   aggregation switch and the broadcast between the host and the access
   switch. The broadcast is terminated by the access switch

   For the remote-MAC table, the aggregation switch will update this
   table if it received some response packets from other aggregation
   switch.

5.3. Request

   If both of the access and aggregation switch are enabled the
   Multistage ARP protocol, the process of ARP request will take place
   as described below:

   1. The host will send out an ARP request if an application need.

   2. When the access switch receives the request, it will look up in
   the local-MAC table. If there is no such entry, the access switch
   will unicast the request to its aggregation switch.

   3. The aggregation switch will look up in the local-MAC table and
   remote-MAC table. If there is no such entry again, the aggregation
   switch will multicast the request to other aggregation switches in
   this L2 network.

   4. The other aggregation switches will look up in their local-MAC
   table. If all of these switches do not have the entry, local
   aggregation switch will send the gateway's MAC back to the host. The
   ARP request failed.

5.4. Reply

   If one of the local access switches, the local aggregation switches
   or the remote aggregation switches finds the related entry, it will
   reply the host by unicasting reply.

   If it is the remote aggregation switch, the local aggregation switch
   will learn from the reply and update the remote-MAC table for the
   future forwarding.


Guo                     Expires Jan 5, 2013                  [Page 6]

   Internet-Draft           multistage arp       July 5, 2012

6. Application of scene

   TBD

7. Simulation

   TBD

8. Conclusions

   The advantage of the Multistage ARP is that it terminates the ARP
   broadcast at the access switch which connects to the host directly.
   The effect of the Multistage ARP should be verified by simulation
   and implementation.

9. Security Consideration

   None

10. IANA Considerations

   None

11. References

   [1]  [ARP]   D.C. Plummer, "An Ethernet address resolution
         protocol."   RFC826, Nov 1982.

   [2]  [ARMD-Problem] Narten, "draft-ietf-armd-problem-statement" in
         progress, Oct 2011.



12. Acknowledgments

   No acknowledgements at this time.













Guo                     Expires Jan 5, 2013                  [Page 7]

   Internet-Draft           multistage arp       July 5, 2012

   Authors' Addresses

   Liang Guo
   China CATR
   Beijing 100191, China
   Phone: 86-10-62300088
   Email: guoliang1@catr.cn


   Shihui Duan
   China CATR
   Beijing 100191, China
   Phone: 86-10-62300068
   Email: duanshihui@catr.cn



































Guo                     Expires Jan 5, 2013                  [Page 8]