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]