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]
