One document matched: draft-wu-nvo3-mac-learning-arp-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-nvo3-mac-learning-arp-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="NVO3 MAC learning">MAC address learning in NVO3 using
ARP</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<date year="2013" />
<area>Internet Area</area>
<workgroup>Network Virtualization Overlays Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Network Virtualization Overlays</keyword>
<abstract>
<t>[I.D-ietf-nvo3-framework] discusses using Dynamic data plane learning
or control plane protocol to build and maintain the mapping tables and
deliver encapsulated packets to their proper destination. However, there
is no relevant work to discuss how those capabilities can be realized at
the NVEs. This document goes into details to discuss how MAC address
learning works through data plane and control plane.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>[I.D-ietf-nvo3-framework] discusses using Dynamic data plane learning
or control plane protocol to build and maintain the mapping tables and
deliver encapsulated packets to their proper destination. However, there
is no relevant work to discuss how those capability can be realized at
the NVEs. This document goes into details to discuss how MAC address
learning works through data plane and control plane.</t>
</section>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
</section>
<section title="Overview of MAC address learning using ARP">
<t>This document addresses how to build and maintain mapping table at
the NVE associated with the tenant system through data plane learning or
control plane.</t>
<t>Figure 1 shows the example architecture for MAC learning using ARP.
This example architecture assumes that:<list style="symbols">
<t>Tenant system A is connecting to VN by attaching to NVE X. Tenant
System A knows IP address of Tenant System B but does not know MAC
address of Tenant System B.</t>
<t>Tenant system B is connecting to VN by attaching to NVE Y. Tenant
System B knows IP address of Tenant System A but does not know MAC
address of Tenant System A.</t>
<t>NVE X associated with tenant system A doesn’t know IP address and
MAC address of tenant system B.</t>
<t>NVE Y associated with tenant system B doesn’t know IP address and
MAC address of tenant system A.</t>
</list></t>
<figure anchor="fig1" title="Figure 1 Example of MAC learning using ARP">
<artwork>
,---------.
,' Backend `.
( Oracle )
`. ,'
`-+------+'
+--+--+ +-+---+
|DC GW|+-+|DC GW|
+-+---+ +-----+
| |
.--..--. .--. ..
( ' '.--.
.-.' L3 '
( Underlay )
( '-'
MAP Table entry .'--'._.'.-._.'.-._) MAP Table entry
(TESID,MAC_X,IP_X) // \\ (TESID,MAC_Y,IP_Y)
+------+ +-------+
.-|NVE X | | NVE Y |
( +------+--. ( +-------+.--.
.-.' ' .-.' '
( DC Site X ) ( DC Site Y )
( .'-' ( .'-'
'--'._.'. ) '--'._.'. )
'--' / '--'
/ \ / \
__/_ \ /_ _\__
'--------' '--------' '--------' '--------'
: Tenant : : Tenant : : Tenant : : Tenant :
: SystemA: : SystemC: : SystemD: : SystemB:
'--------' '--------' '--------' '--------'
TESID= TESID=
(VNID,MAC_A,IP_A) (VNID,MAC_B,IP_B)
</artwork>
</figure>
</section>
<section title="MAC learning using ARP Resolution">
<t>MAC addresses of the Tenant systems also can be learnt by NVE through
data plane and control plane. The following section outlines several
examples for MAC learning using ARP resolution.</t>
<section title="MAC learning using flooding without MAC hiding">
<t>The packet flow and control plane operation for MAC learning are as
follows:<list style="symbols">
<t>Tenant system A sends a broadcast ARP message to discover the
MAC address of Tenant system B. The message contains IP_B in the
ARP message payload.</t>
<t>The ARP proxy in NVE X, receiving the ARP message, will flood
it on the overlay network for TESID = <VNID,IP_B,*>.</t>
<t>The ARP message will be intercepted by NVE (i.e., NVE Y) which
maintain mapping table matching TESID = <VNID,IP_B,*>. NVE
Y, will forward the ARP message to tenant system B. Tenant System
B send ARP reply to tenant system A containing the mapping
TESID=<VNID,IP_B,MAC_B>.</t>
<t>NVE X intercept ARP reply message and populates the map-table
with the received entry, then send it to Tenant System A that
includes MAC_B and IP_B of Tenant System B.</t>
<t>Tenant system A learns MAC_B from the ARP rely message and can
now send a packet to Tenant system B by including MAC_B, and IP_B,
as destination addresses.</t>
</list></t>
</section>
<section title="MAC learning using NVE-oracle interaction">
<t>The packet flow and control plane operation for MAC learning are as
follows:<list style="symbols">
<t>Tenant System A sends a broadcast ARP message to discover the
MAC address of Tenant system B. The message contains IP_B in the
ARP message payload.</t>
<t>NVE A, receiving the ARP message, but rather than flooding it
on the overlay network sends a Map-Request to the backend Oracle
that maintains mapping information for entire overlay network for
TESID = <VNID,IP_B,*>.</t>
<t>The Map-Request is routed by the backend Oracle to NVE Y, that
will send a Map-Reply back to NVE X containing the mapping
TESID=<VNID,IP_B,MAC_B>. Alternatively, depending on the
Backend Oracle configuration, the backend Oracle may send directly
a Map-Reply to NVE X.</t>
<t>NVE X populates the map-table with the received entry, and
sends an ARP-Agent Reply to Tenant System A that includes MAC_B
and IP_B.</t>
<t>Tenant system A learns MAC_B from the ARP message and can now
send a packet to Tenant system B by including MAC_B, and IP_B, as
destination addresses.</t>
</list></t>
</section>
<section title="MAC learning using control plane operation and MAC hiding">
<t>MAC addresses of the Tenant systems also can be learnt by NVE
through control plane.</t>
<t>When tenant system A is attached to NVE X, the mapping table
TESID=<VNID,IP_A,MAC_A> should be populated at the local NVE A.
In order to enable tenant system A to communicate with any tenant
system that is not under NVE X, the mapping table should be
distributed to all the remote NVEs that belong to the same VN even
through there is no tenant system which communicates with tenant
system A behind the remote NVE. In order to achieve this, NVE X should
know the list of remote NVE that belong to the same VN as NVE X and
distribute the mapping table to each remote NVE. Alternatively,
backend Oracle may know a list of tenant systems that is in
communication with tenant system A and which remote NVE these tenant
systems are attached to. So NVE X distribute the mapping table to the
backend Oracle which in turn determine which remote NVE should
populate mapping table and distribute mapping table to the
corresponding remote NVE. The packet flow for MAC learning in data
plane are as follows: <list style="symbols">
<t>Tenant system A sends a broadcast ARP message to discover the
MAC address of Tenant system B. The message contains IP_B in the
ARP message payload.</t>
<t>The ARP proxy in NVE X, will terminate the ARP message, and
create a ARP reply message, set the inner destination MAC address
in the inner Ethernet header and sender MAC address in the payload
of ARP reply message to NVE X’s MAC address then send it back to
tenant system A. Therefore ARP message is restricted within layer
2 network behind NVE X and will not be flooded to the entire
overlay network at the outsider of NVE X.</t>
<t>Tenant system A learns MAC_B from the ARP rely message and send
a packet to Tenant system B by including MAC_X, and IP_B, as
destination addresses.</t>
<t>NVE X, will intercept the packet from tenant system A and
perform a lookup operation in its map table for the destination
TESID=<VNID, IP_B> and determine which tunnel the packet
needs to be sent to. Then NVE X encapsulate the packet from tenant
system A into tunnel header with NVE Y IP_Y as the destination
address NVE X IP_X as the source address and transmit it across
overlay network.</t>
<t>NVE Y decapsulates the tunnel packet from NVE X and take out
the packet from tenant system A and send to the tenant system
B.</t>
</list></t>
</section>
<section title="MAC learning using control plane operation without MAC hiding">
<t>MAC addresses of the Tenant systems also can be learnt by NVE
through control plane.</t>
<t>When tenant system A is attached to NVE X, the mapping table
TESID=<VNID,IP_A,MAC_A> should be populated at the local NVE A.
In order to enable tenant system A to communicate with any tenant
system that is not under NVE X, the mapping table should be
distributed to all the remote NVEs that belong to the same VN even
through there is no tenant system which communicate with tenant system
A behind the remote NVE. In order to achieve this, NVE X should know
the list of remote NVE that belong to the same VN as NVE X and
distribute the mapping table to each remote NVE. Alternatively,
backend Oracle may know a list of tenant systems that is in
communication with tenant system A and which remote NVE these tenant
systems are attached to. So NVE X distribute the mapping table to the
backend Oracle which in turn determine which remote NVE should
populate mapping table and distribute mapping table to the
corresponding remote NVE. The packet flow for MAC learning in data
plane are as follows: <list style="symbols">
<t>Tenant system A sends a broadcast ARP message to discover the
MAC address of Tenant system B. The message contains IP_B in the
ARP message payload.</t>
<t>The ARP proxy in NVE X, will terminate the ARP message, and
look up the MAC_B in the local mapping table send the ARP reply
message to tenant system A that includes MAC_B and IP_B. Therefore
ARP message is restricted within layer 2 network behind NVE X and
will not be flooded to the entire overlay network at the outsider
of NVE X.</t>
<t>Tenant system A learns MAC_B from the ARP rely message and send
a packet to Tenant system B by including MAC_B, and IP_B, as
destination addresses.</t>
<t>NVE X, will intercept the packet from tenant system A and
perform a lookup operation in its map table for the destination
TESID=<VNID, IP_B> and determine which tunnel the packet
needs to be sent to. Then NVE X encapsulate the packet from tenant
system A into tunnel header with NVE Y IP_Y as the destination
address NVE X IP_X as the source address and transmit it across
overlay network.</t>
<t>NVE Y decapsulates the tunnel packet from NVE X and take out
the packet from tenant system A and send to the tenant system
B.</t>
</list></t>
</section>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Security Considerations">
<t>TBC.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>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.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="I.D-ietf-nvo3-framework">
<front>
<title>Framework for DC Network Virtualization</title>
<author fullname="M.Lasserre" initials="M." surname="Lasserre">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-nvo3-framework-00" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:01 |