idnits 2.17.1 draft-guo-armd-multistage-arp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 41 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 99 has weird spacing: '...s layer the a...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 5, 2012) is 4312 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 241, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 244, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ARMD Liang Guo 2 Internet Draft China CATR 3 Intended status: Informational Shihui Duan 4 Expires: January 5, 2013 China CATR 5 July 5, 2012 7 Multistage ARP to Reduce the ARP Broadcast in Layer 2 Network 8 draft-guo-armd-multistage-arp-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on Sep 11, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. 45 Abstract 47 This document proposes a method to reduce the ARP broadcast in L2 48 networks. There will be two MAC tables in the aggregation switches 49 which answer for the ARP responses and packet forwarding. Multicast 50 will take the place of broadcast for ARP request in this document 51 which will lead to the reduction of the numbers of ARP broadcast 52 packets in L2 networks. 54 Table of Contents 56 1. Introduction ................................................ 4 57 2. Conventions used in this document ............................ 4 58 3. Overview .................................................... 4 59 4. Modification of ARP ......................................... 5 60 5. Detailed Work Flow .......................................... 5 61 5.1. Building the Tables ..................................... 5 62 5.2. Update ................................................. 5 63 5.3. Request ................................................ 6 64 5.4. Reply .................................................. 6 65 6. Application of scene......................................... 7 66 7. Simulation .................................................. 7 67 8. Conclusions ................................................. 7 68 9. Security Consideration ....................................... 7 69 10. IANA Considerations......................................... 7 70 11. References ................................................. 7 71 12. Acknowledgments ............................................ 7 73 1. Introduction 75 It is well accepted that the virtualization should be a trend of the 76 data center and it will bring some positive things about energy 77 consumption and the utilization rate of the data center. But 78 unfortunately, the virtualization will aggravate the problems about 79 ARP. Though the technology about the VM movement is not well 80 established, the movement of VM in one L2 network would take place 81 definitely and the movement of VM between L2 networks would happen 82 probably. It is well known that the movement of VM introduces ARP 83 storm in L2 network in DC, so we need to resolve the ARP broadcast 84 storm. 86 We propose a modified ARP protocol named Multistage ARP in this 87 document. Multistage ARP will limit the ARP broadcast in one access 88 switch and unicast the ARP request to the aggregation switch. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC-2119 95 . 97 3. Overview 99 Generally, there are three layers (the access layer the aggregation 100 layer and the core layer) in the data center. 102 The performance of access switches is not good enough and the 103 capacity of MAC of access switches is not big enough which is 104 different from 2k to 32k. In the Multistage ARP, what they should do 105 is to turn off the ARP broadcast or limit it at a low level. 107 The switches of aggregation layer would play a critical role in the 108 Multistage ARP because they have better ability of process and much 109 bigger table of MAC (about 128k per board). 111 In the Multistage ARP, the access layer switch would not broadcast 112 the ARP request if the access switch does not answer it. Instead the 113 access switch would unicast this request to its aggregation switch. 114 There are two tables in the aggregation switch. Both of these two 115 tables are used for searching of the MAC entry. The difference 116 between them is that the local-table is generated through collecting 117 all the MAC entries of access switches attached to this aggregation 118 switch and the remote-table is generated through learning from other 119 aggregation switches. 121 The aggregation switch would look up the MAC entry in its local- 122 table and remote-table. The detail is described in section 5. 124 4. Modification of ARP 126 There are some differences between the current ARP and the 127 Multistage ARP. 129 1. The access switch should unicast the request to its aggregation 130 switch instead of broadcasting the ARP request if it does not find 131 the MAC entry. 133 2. There should be some protocol interactions between the access 134 switch and the aggregation switch which are related with the 135 concentration and updates of MAC entries and responsible for the ARP 136 request and forwarding. 138 We think some other types of protocol should be configured to make 139 sure that the Multistage ARP can work correctly. The detail of 140 changes will be discussed later. 142 5. Detailed Work Flow 144 5.1. Building the Tables 146 In this document, there would be two MAC entry tables in the 147 aggregation switches: local-MAC table and remote-MAC table. 149 The generation of local-MAC table is crucial for the proposal of 150 this document. We should do some configuration on all aggregation 151 switches to make them to obtain the MAC entries of all the access 152 switches of themselves. This operation will produce a local-MAC 153 table. It would response the incoming requests of local or remote 154 hosts. 156 When a multicast of ARP request is forwarded to all aggregation 157 switches, a response will be back from an aggregation switch if 158 there is a related MAC entry. So a remote-MAC table will be produced 159 in the local aggregation switch which would be responsible for the 160 packet forwarding. 162 5.2. Update 164 The down and up of the ports of the access switch will trigger the 165 update of the local-MAC table: 167 If the port is down, the access switch will clear all the MAC 168 entries of this port and then send messages to its aggregation 169 switch for update. 171 If the port is up, the access switch will refresh all the MAC 172 entries of this port actively and send messages to its aggregation 173 switch for update. 175 The update to the local-MAC table which generated before will be 176 finished by the unicast between the access switch and the 177 aggregation switch and the broadcast between the host and the access 178 switch. The broadcast is terminated by the access switch 180 For the remote-MAC table, the aggregation switch will update this 181 table if it received some response packets from other aggregation 182 switch. 184 5.3. Request 186 If both of the access and aggregation switch are enabled the 187 Multistage ARP protocol, the process of ARP request will take place 188 as described below: 190 1. The host will send out an ARP request if an application need. 192 2. When the access switch receives the request, it will look up in 193 the local-MAC table. If there is no such entry, the access switch 194 will unicast the request to its aggregation switch. 196 3. The aggregation switch will look up in the local-MAC table and 197 remote-MAC table. If there is no such entry again, the aggregation 198 switch will multicast the request to other aggregation switches in 199 this L2 network. 201 4. The other aggregation switches will look up in their local-MAC 202 table. If all of these switches do not have the entry, local 203 aggregation switch will send the gateway's MAC back to the host. The 204 ARP request failed. 206 5.4. Reply 208 If one of the local access switches, the local aggregation switches 209 or the remote aggregation switches finds the related entry, it will 210 reply the host by unicasting reply. 212 If it is the remote aggregation switch, the local aggregation switch 213 will learn from the reply and update the remote-MAC table for the 214 future forwarding. 216 6. Application of scene 218 TBD 220 7. Simulation 222 TBD 224 8. Conclusions 226 The advantage of the Multistage ARP is that it terminates the ARP 227 broadcast at the access switch which connects to the host directly. 228 The effect of the Multistage ARP should be verified by simulation 229 and implementation. 231 9. Security Consideration 233 None 235 10. IANA Considerations 237 None 239 11. References 241 [1] [ARP] D.C. Plummer, "An Ethernet address resolution 242 protocol." RFC826, Nov 1982. 244 [2] [ARMD-Problem] Narten, "draft-ietf-armd-problem-statement" in 245 progress, Oct 2011. 247 12. Acknowledgments 249 No acknowledgements at this time. 251 Authors' Addresses 253 Liang Guo 254 China CATR 255 Beijing 100191, China 256 Phone: 86-10-62300088 257 Email: guoliang1@catr.cn 259 Shihui Duan 260 China CATR 261 Beijing 100191, China 262 Phone: 86-10-62300068 263 Email: duanshihui@catr.cn