One document matched: draft-wu-nvo3-nve2nve-01.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-nve2nve-01" 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="NVE2NVE">Signaling control/forward plane information
between network virtualization edges (NVEs)</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>This document discusses how to provide control plane and forward
plane information to the NVE associated with the tenant system for
enabling interconnect between Tenant Systems that belong to specific
tenant network.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>In [I.D-ietf-nvo3-framework],one control component is defined to
provide the capability for Address advertisement and tunnel mapping. In
[I.D-fw-nvo3-server2vcenter],the control interface between NVE and
interconnection functionality is defined to provide the capability:
<list style="symbols">
<t>Enforce the network policy for each VM in the path from the NVE
Edge associated with VM to the Tenant End System.</t>
<t>Populate forwarding table in the path from the NVE Edge
associated with VM to the Tenant End System in the data center.</t>
<t>Populate mapping table in each NVE Edge that is in the virtual
network across data centers under the control of the Director.</t>
</list></t>
<t>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 to provide control plane and forward plane information to the NVE
associated with the tenant system for enabling interconnect between
Tenant Systems that belong to specific tenant network.</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>
<t><list style="hanging">
<t hangText="Site : "><vspace blankLines="1" />If multiple tenant
systems connect to the VN through one NVE, the collection of these
tenant systems and the NVE associated with these tenant systems are
referred to as a site or virtualization network subnet.</t>
</list></t>
</section>
<section title="Solution Overview">
<t>This document addresses how to provide control plane and forward
plane information to the NVE associated with the tenant system for
enabling interconnect between Tenant Systems that belong to specific
tenant network.</t>
<t>Figure 1 shows the example architecture for interconnection between
tenant systems. This example architecture assumes that:<list
style="symbols">
<t>One tenant system or a NVE may belong to one tenant VN or several
tenant VNs, e.g., VMa and NVE Edge4 belong to both VN2 and VN3.</t>
<t>If one tenant system belongs to multiple tenant VNs, it may
connect to each tenant VN by being attached to one NVE or multiple
NVEs,e.g., VM1 connect to VN1 by being attached to NVE Edge 1.</t>
<t>One site may belong to one tenant VN or several tenant VN, e.g.,
Site 2 belong to both VN2 and VN3.</t>
<t>if one tenant system in one VN want to communicate with one
tenant system in another VN, the interconnection functionality
should get involved to setup tunnel between the interconnection
functionality and the NVEs associated with the tenant system.</t>
</list></t>
<figure anchor="fig1" title="Figure 1.">
<artwork>
+---------------+-------------+--------------+
| VN1 | +--------+ | +--------+ |
| | |VM1VM2VM3 | |VM4VM5VM6 |
| | +--------+ | +--------+ |
| | | | | | | |
| | | Server1| | | Server2| |
| | | | | | | |
| | +--------+ | +--------+ |
| | +---------+ | +---------+|
| -+-|NVE Edge1+-+---+NVE Edge2++-
| // | +---------+ | +---------+| \\
| | |Site1 | | |
| | +-------------+ +VN3--------+---+------------+
| |--+---+ +---+ | |+---+ +---|--+ |
| |VMd | | | | || | | |VMh |
| | | S | |NVE| | ||NVE| | S | | |
| | | e | | | | || | | e | | |
| |VMe r | | E | ,---------. | || E | | r |VMi |
| | | v | | d | Interconnection | || d | | v | | |
| | | e | | g |( )| || g | | e | | |
| |VMf r | | e | `Functionality' | || e | | r |VMj |
| | | 5 | | 5 | `---------' | || 6 | | 6 | | |
| |VMg | | | | || | | |VMk |
| |--|---+ ++--+ | |++--+ |---+--+ |
+-----------+--------------------+-----------+ | |
| | | |
| +VN2--------------+------------+ | |
. |... .............|Site2..... .| | |
.| | +---------+ .. |+---------+ |// |
. \\| |NVE Edge3+-----++NVE Edge4+-+ |
. | +---------+ |+---------+ | |
. | +--------+ .. | +--------+ | . |
. | | | .. | | | | . |
. | | Server3| .. | | Server4| | . |
. | | | .. | | | | . |
. | +--------+ .. | +--------+ | . |
. | |VM7VM8VM9 .. | |VMaVMbVMc | . |
....| ---------+......|.---------+ |.. |
+-----------------+------------+ |
+----------------------------+
</artwork>
</figure>
</section>
<section title="Mapping tables at the NVE">
<t>Every NVE pair( local NVE and remote NVE ) associated with the tenant
system MUST maintain a mapping table entry for each currently attached
tenant system. Each mapping table entry conceptually contains the
following fields:<list style="symbols">
<t>The tunnel interface identifier (tunnel-if-id) of the tunnel
between the remote NVE and the local NVE where the tenant system is
currently attached. The tunnel interface identifier is acquired
during the tunnel creation.</t>
<t>The MAC address of the attached tenant end system. This MAC
address is obtained from auto-discovery protocol between Tenant
System and its local NVE.</t>
<t>The IP address of the attached tenant system. This IP address is
obtained from auto-discovery protocol between Tenant System and its
local NVE.</t>
<t>The IP address of the local NVE associated with the tenant
system.</t>
<t>The Identifier of VN context-VNID. This Identifier is obtained
from auto-discovery protocol between Tenant System and its local
NVE.</t>
</list></t>
</section>
<section title="Key functions for signaling control/forwarding info to NVEs">
<section title="Create and Update tenant Virtual Network (VN)">
<t>The tenant virtualization network(VN) is a collection of tenant
systems, Network Virtualization Edges (NVE)(s) and end systems that
are interconnected with each other. The tenant VN also consists of a
set of sites where each can send traffic directly to the other.</t>
<t>In order to create or update a tenant VN, when a Tenant System is
attached to a local NVE, the tenant system should inform the attached
local NVE which VN the tenant system belong to. <list style="symbols">
<t>If the tenant system are the first participant in the VN
through the local NVE, the tenant system and associated local NVE
should be firstly added to the VN and the mapping table should be
setup at the local NVE for each attached tenant system.</t>
<t>If both the tenant system and the local NVE are not on the VN,
the tenant system and associated local should be firstly added to
the VN and then the mapping table associated with this tenant
system should be setup at the local NVE and distributed to the
other remote NVEs that belong to the same VN.</t>
<t>If the local NVE is on the same tenant VN as the tenant system
associated with the local NVE, only the tenant system needs to be
added into the VN, i.e., the local NVE only needs to distribute
mapping table at the local NVE to the other remote NVEs that
belong to the same tenant VN.</t>
<t>If the local NVE is not on the same tenant VN as the tenant
system associated with that local NVE, the local NVE should
firstly be added into the VN and then distributes the new mapping
table at the local NVE to the other remote NVEs that belong to the
same tenant VN.</t>
<t>If one tenant system is the last participant connecting to the
VN through local NVE, when this tenant system leave the VN, the
local NVE associated with this tenant system should be removed
from the VN.The mapping table associated with this tenant system
should be removed from the local NVE associated with this tenant
system.</t>
</list></t>
</section>
<section title="Associate the NVE and tenant system with VN context">
<t>The VN context includes a set of configuration attributes defining
access and tunnel policies and (L2 and/or L3) forwarding functions.
When a Tenant System is attached to a local NVE, a VN network instance
should be allocated to the local NVE. The tenant system should be
associated with the specific VN context using virtual Network
Instance(VNI). The tenant system should also inform the attached local
NVE which VN context the tenant system belong to. Therefore the VN
context can be bound with the data path from the tenant system to the
local NVE and the tunnel from local NVE associated with the tenant
system and all the remote NVEs that belong to the same VN as the local
NVE. For the data path from the tenant system and the local NVE, the
network policy can be installed on the underlying switched network and
forwarding tables also can be populated to each network elements in
the underlying network based on the specific VNI associated with the
tenant system. For the tunnel from local NVE to the remote NVEs, the
traffic engineering information can be applied to each tunnel based on
VNI associated with the tenant system.</t>
</section>
<section title="Populate mapping tables at the local NVE">
<t>In some cases, two tenant systems may be attached to the same local
NVE. In order to allow the NVE to locally route traffic between two
tenant systems that are attached to the same NVE, the mapping table
that maps a final destination address to the proper tunnel should be
populated at the local NVE.</t>
<t>In some cases, two tenant systems may connect to the different VNs
through the same interconnection functionality, in order to allow two
tenant systems communication between two VNs, the mapping table that
maps a final destination address to the proper tunnel should be
populated in both NVE associated with two communicated tenant system
and the interconnection functionality associated corresponding
NVE.</t>
</section>
<section title="Distribute the mapping table to remote NVEs in the VN">
<t>When the packet sent from one tenant system arrives at the ingress
NVE associated with that tenant system, in order to determine which
tunnel the packet needs to be sent to, the mapping table that maps a
final destination address to the proper tunnel should also be
distributed to all the remote NVEs in the VN using a control plane
protocol or dynamic data plane learning. The mapping table may be
advertised directly to other remote NVEs that belong to the same VN or
firstly advertised to the centralized controller that maintain global
view of NVEs that belong to the same VN and then let the centralized
controller distribute the mapping tables to all the relevant remote
NVEs that belong to the same VN.</t>
</section>
<section title="The mapping table update at the NVE when VM moves or connection fails">
<t>In some cases, one tenant system may be detached from one NVE and
move to another NVE. In such cases, the mapping table should be
removed from the NVE to which the tenant system was previously
attached and the new mapping table should be created at the new NVE to
which the tenant system is currently attached. Such mapping table
should be updated at each remote NVE associated with the tenant system
and the new NVE.</t>
<t>In some cases, one tenant system may fail to connect to the VN
through the NVE. In such cases, the mapping table should be removed
from the NVE to which the tenant system is currently attached. In
addition, the mapping table should be updated at each remote NVE in
the same VN through which the tenant system is communicating with the
destination tenant system.</t>
</section>
<section title="The VN context re-association at the NVE when VM moves">
<t>In some cases, one tenant system may be detached from one NVE and
move to another NVE. In such cases, the VN context should be moved
from the NVE to which the tenant system was previously attached to the
new NVE to which the tenant system is currently attached. In order to
achieve this, the per tenant system VN context can be maintained at
the centralized database and be retrieved at the new place based on
the VN Identifier (VNID).</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>
<references title="Informative References">
<reference anchor="I.D-fw-nvo3-server2vcenter">
<front>
<title>Network Virtualization Architecture</title>
<author fullname="Q.Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<author fullname="R.Scott" initials="R." surname="Scott">
<organization></organization>
</author>
<date month="January" year="2013" />
</front>
<seriesInfo name="ID" value="draft-fw-nvo3-server2vcenter-01" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:48 |