One document matched: draft-wu-nvo3-nve2nve-03.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-03" 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 focuses on control plane aspect related to both tenant
system to NVE control interface and NVE to Oracle control interface NVE
use to enable communication between tenant systems, which is
complementary to [draft-kreeger-nvo3-hypervisor-nve-cp] that describes
the high level control plane requirements related to the interaction
between tenant system and NVE when the two entities are not co-located
on the same physical device.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>In [I.D-ietf-nvo3-overlay-problem-statement], two control planes are
identified to realize an overlay solution:<list style="symbols">
<t>NVE to Oracle control plane.</t>
<t>Tenant system to NVE control plane.</t>
</list>Where NVE to Oracle Control plane is used to deal with address
mapping dissemination and Tenant System to NVE control plane is used to
deal with VM attachment and detachment.</t>
<t>In [I.D-ietf-nvo3-framework], three control plane components are
defined to build these two control planes and provide the following
capabilities:<list style="symbols">
<t>Auto-provision/service discovery</t>
<t>Address advertisement</t>
<t>Tunnel Managment</t>
</list></t>
<t>In [I.D-fw-nvo3-server2vcenter],the control interface between NVE and
the Oracle backend system or Network Virtualization Authority (NVA) 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>This document focuses on control plane aspect related to both tenant
system to NVE control interface and NVE to Oracle control interface NVE
use to enable communication between tenant systems, which is
complementary to [draft-kreeger-nvo3-hypervisor-nve-cp] that describes
the high level control plane requirements related to the interaction
between tenant system and NVE when the two entities are not co-located
on the same physical device.</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>
<t hangText="Tenant System:"><vspace blankLines="1" />A physical or
virtual system that can play the role of a host, or a forwarding
element such as a router, switch, firewall, etc. It belongs to a
single tenant and connects to one or more VNs of that tenant.</t>
<t hangText="vNIC:"><vspace blankLines="1" />A vNIC is similar to a
physical NIC. Each virtual machine has one or more vNIC adapters
that it uses to communicate with both the virtual and physical
networks. Each vNIC has its own MAC address and can be assigned one
or more IP address just like a NIC found in a non virtualized
machine.</t>
</list></t>
</section>
<section title="NVO3 Control plane Overview">
<t>Figure 1 shows the example NVO3 Networking architecture to give an
overview of NVO3 control plane for interconnection between VNs or
between VN and Non-VN. There are 4 basic network components that make up
networking architecture: Tenant system, local NVE, remote NVE and
Network Virtualization Authority. This example NVO3 networking
architecture assumes that: </t>
<t><list style="symbols">
<t>Each server or server blade that is running hypervisor hosts
multiple virtual machines.</t>
<t>Each tenant system is corresponding to one virtual machine vNIC.
Each virtual machine has one or more vNIC adapters that it uses to
communicate with both the virtual and physical networks.The vNIC
adapters each virtual machine has belong to a single tenant. </t>
<t>One tenant system or a NVE may belong to one tenant VN or several
tenant VNs, e.g., TS4 and NVE Edge4 belong to both VN2 and VN3.</t>
<t>If one tenant system belongs to multiple tenant VNs, it may have
one VM with multiple vNICs and connect to each tenant VN by using
each of vNICs being attached to one or multiple NVEs,e.g., VM1
connect to VN1 by being attached to NVE Edge 1.</t>
<t>If one tenant system belongs to multiple tenant VNs, it may have
multiple VM with each having one vNIC and connect to each tenant VN
by using each VM vNIC being attached to one or multiple NVEs.</t>
<t>One NVE only belongs to one site. 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 or
Network Virtualization Authority or Network Virtualization
controller may get involved to help establish interconnection
between VN or setup tunnel between NVEs associated with the tenant
system. </t>
</list></t>
<figure anchor="fig1" title="Example NVO3 control plane Overview">
<artwork>
+---------------+-------------+--------------+
| VN1 | +--------+ | +--------+ |
| | |VM1VM2VM3 | |VM4VM5VM6 |
| | +--------+ | +--------+ |
| | | | | | | |
| | |Server1 | | |Server2 | |
| | | | | | | |
| | +--------+ | +--------+ |
| | +---------+ | +---------+|
| -+-|NVE Edge1+-+---+NVE Edge2++-
| // | +---------+ | +---------+| \\
| | |Site1 | | |
| | +-------------+ +VN3--------+---+------------+
| |--+---+ +---+ | |+---+ +---|--+ |
| |VMd S | | | | || | | S |VMh |
| | | e | |NVE| | ||NVE| | e | | |
| | | r | | | | || | | r | | |
| |VMe v | | E | ,---------. | || E | | v |VMi |
| | | e | | d | Interconnection | || d | | e | | |
| | | r | | g |( )| || g | | r | | |
| |VMf | | e | `Functionality' | || e | | |VMj |
| | | 5 | | 5 | `---------' | || 6 | | 6 | | |
| |VMg | | | | || | | |VMk |
| |--|---+ ++--+ | |++--+ |---+--+ |
+-----------+--------------------+-----------+ | |
| | | |
| +VN2--------------+------------+ | |
. |... .............|Site2..... .| | |
.| | +---------+ .. |+---------+ |// |
. \\| |NVE Edge3+-----++NVE Edge4+-+ |
. | +---------+ |+---------+ | |
. | +--------+ .. | +--------+ | . |
. | | | .. | | | | . |
. | |Server3 | .. | |Server4 | | . |
. | | | .. | | | | . |
. | +--------+ .. | +--------+ | . |
. | |VM7VM8VM9 .. | |VMaVMbVMc | . |
....| ---------+......|.---------+ |.. |
+-----------------+------------+ |
+----------------------------+
</artwork>
</figure>
</section>
<section title="Mapping table entry at the NVE and Network Virtualization Authority">
<t>Suppose a VM has multiple vNICs, each VM vNIC is corresponding to a
tenant system. Tenant system should be able to directly connect to
multiple VNs without needing to traverse a NVE or gateway. Therefore
every NVE pair( local NVE and remote NVE ) associated with the tenant
system MUST maintain at least one mapping table entry for each currently
attached tenant system (In TS multihoming case, there may have multiple
mapping table entry corresponding to one TS). Each mapping table entry
corresponds to the Tenant system connection to each VN and conceptually
may contain all or a sub set of 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 TS. This MAC address is obtained
from auto-discovery protocol between Tenant System and its local
NVE.</t>
<t>The IP address of the attached TS. This IP address is obtained
from auto-discovery protocol between Tenant System and its local
NVE.</t>
<t>The logical interface identifier (e.g., VLAN ID, internal vSwitch
Interface ID connected to a Tenant System) of the access link
between the tenant system and the local NVE. This field is required
to associate Tenant System with local NVE if local NVE is an
external NVE to Tenant system. It is internal to the local NVE and
is also used to associate the tunnel to the access link where the
tenant system is attached. </t>
<t>The MAC address of the local NVE associated with the tenant
system.</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>
<t>In addition, the Network Virtualization Authority or Oracle backend
system may also maintain a mapping table entry for each currently
attached tenant systemor each newly joined NVE. Each mapping table entry
corresponds to the Tenant system connection to each VN and and
conceptually may contain all or a sub set of the following fields: <list
style="symbols">
<t>The MAC address of the attached TS. This MAC address is obtained
from auto-discovery protocol between Tenant System and its local
NVE.(Optional)</t>
<t>The IP address of the attached TS. This IP address is obtained
from auto-discovery protocol between Tenant System and its local
NVE. (Optional)</t>
<t>The logical interface identifier (e.g., VLAN ID, internal vSwitch
Interface ID connected to a Tenant System) of the access link
between the tenant system and the local NVE. This field is required
to associate with Tenant System if local NVE is an external NVE to
Tenant system. It is internal to the local NVE and is also used to
associate the tunnel to the access link where the tenant system is
attached. </t>
<t>The MAC address of the local NVE associated with the tenant
system.</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 title="Mapping table Entry Fields relationship">
<t>One Tenant system is corresponding to one VM vNIC. Each VM belongs
to a single tenant. Each VM may have one or more vNIC adapters that it
uses to communicate with both the virtual and physical networks. Each
vNIC must have one and only one unique MAC address. In addition, each
vNIC have at least one IP address. When a VM using one vNIC connects
to multiple VNs,the vNIC should be assigned with multiple IP addresses
with each connecting to different VN. In this case, VM may create
multiple binding cache entries with each associating one of multiple
IP addresses to the same unique vNIC MAC address. vNIC MAC address may
be modified or assigned with a new MAC address at any time. However
vNIC should not use more than one MAC addresses to connect to multiple
VNs at the same time. When multiple vNICs hosted in the same VM
connect to multiple VNs, it is allowed that some of these vNICs may
connect to different VNs through the same NVE. </t>
<figure>
<artwork>
A Server running hypervisor
|
+--------------+--------------+
| | |
| |
VM1 VM2 ..... VMx
| | |
|---------+--------+ vNIC vNIC
| | |
| | |
vNIC1 vNIC2 ... vNICx
|
|
+------+------+
| | |
VN1 VN2 ...VNx
Figure 2. VM information Hierarchy
VM1(Tenant Systems)
|
|---------+--------+
| | |
| | |
vNIC1(TS1) vNIC2(TS2) ..vNICx(TSx)
|
|
|
NVE
|
+-------+------+
| | |
VN1 VN2 VN3
Binding Cache Database
VM1 vNIC1's Binding
binding[VNIC1 MAC addr, IP1 addr, BID1]
binding[vNIC1 MAC addr, IP2 addr, BID2]
binding[vNIC1 MAC addr, IP3 addr, BID3]
Figure 3 Simultaneous multiple connections
for Layer 3 Virtual Network Service
VM1 (Tenant Systems)
|
|---------+--------+
| | |
| | |
vNIC1(TS1) vNIC2(TS2) ..vNICx(TSx)
|
|
|
NVE
|
+-------+------+
| | |
VN1 VN2 VN3
Binding Cache Database
VM1 vNIC1's Binding
binding[VNIC1 MAC addr, VLAN ID1, BID1]
binding[vNIC1 MAC addr, VLAN ID2, BID2]
binding[vNIC1 MAC addr, VLAN ID3, BID3]
Figure 4. Simultaneous multiple connections
for Layer 2 Virtual Network Service
</artwork>
</figure>
</section>
<section title="Multihoming support using one TS or vNIC">
<t>If tenant system are allocated with multiple IP address, Tenant
System may use several IP addresses to connect to multiple VNs. Each
IP address corresponding to each connection to VN. In order to support
connecting to multiple VNs using a single vNIC, Tenant system may
create a Binding Identifier (BID) to each IP address that is used to
connect to VN. The BID should be unique for a given Tenant System.If
the tenant system has only one IP address, the assignment of a BID is
not needed until it has multiple IP addresses, at which time all of
the IP addresses of TS MUST be mapped to BIDs. BID is suggested to be
stored in the mapping table entry at the NVE and Network
Virtualization Authority(NVA). </t>
</section>
<section title="Interconnection functionality">
<t>Suppose one VM only hasone vNIC and is corresponding to the tenant
system A, when the tenant system A plays the role of interconnection
functionality to connect two VNs, the following three cases should be
considered. <list>
<t>(a) Both two VNs support Layer 3 forwarding;</t>
<t>(b) Both two VNs support layer 2 forwarding;</t>
<t>(c) One VN supports Layer3 forwarding and the other VN supports
layer 2 forwarding; </t>
</list></t>
<t>For (a), tenant system A or external system that is close to tenant
system A should support layer 3 forwarding functionality. When source
tenant system in one VN communicates with destination tenant system in
another VN through the tenant system A, if tenant system A support
layer 3 forwarding, the tenant system A should forward IP packets on
the behalf of source Tenant System and destination tenant system
irrespective of data plane encapsulation format(e.g., VXLAN or NVGREW,
MPLS over GRE). If two VNs use different data plane encapsulation
format, the tenant system A should also support converting one data
plane encapsulation format into another. If tenant system A doesn't
support layer 3 forwarding,the external system that is close to tenant
system A should associate vNIC to local NVE using TS MAC address and
VLAN tag information and forward IP packets on the behalf of source
tenant system and destination tenant system. </t>
<t>For (b), tenant system A vNIC or external system that is close to
tenant system A should support layer 2 forwarding functionality. When
source tenant system in one VN communicates with destination tenant
system in another VN through the tenant system A, if tenant system A
support layer 2 forwarding, the tenant system A should know which
tenant systems connecting to itself are allowed for layer 2 forwarding
and then forward layer 2 frames on the behalf of source Tenant System
and destination tenant system based on forwarding allowed list. If two
layer 2 VNs support different data plane encapsulation format, the
tenant system A should also support converting one data plane
encapsulation format to another. If tenant system A doesn't support
layer 2 forwarding, the external system that is close to tenant system
A should associate vNIC to local NVE using TS MAC address and VLAN tag
information and forward layer 2 frames on the behalf of source tenant
system and destination tenant system. </t>
<t>For (c), tenant system A or external system that is close to tenant
system A should support both layer 2 forwarding and layer 3
forwarding. When source tenant systems in layer 2 VN communicates with
destination tenant system in layer 3 VN through the tenant system A,
if tenant system A support both layer 2 and layer 3 forwarding the
tenant system A should support translating layer 2 frame into layer 3
packet and forward traffic between layer 2 VN and layer 3 VN. If two
VNs support different data plane encapsulation format, the tenant
system A should also support converting one data plane encapsulation
format to another. If tenant system A doesn't support layer 2
forwarding or layer3 forwarding, the external system that is close to
tenant system A should associate vNIC to local NVE using TS MAC
address and VLAN tag information and forward traffic on the behalf of
source tenant system and destination tenant system. </t>
<t>When the tenant system A plays the role of interconnection
functionality to connect between VN and Non-VN, suppose source tenant
system in one VN communicates with destination end device in Non-VN
environment through the tenant system A, the tenant system A acts as
NVO3 GW between VN and Non-VN in this case peering with other Gateways
and should be explicitly configured with a list of destination MAC
addresses that allows passed to the Non-VN environment and perform
translation between VNID and Non-VN label when forwarding traffic
between VN interface and Non-VN interface. For outgoing frames on VN
connected interface, the tenant system A decapsulates NVO3 outer
header and forwards the inner frame to Non-VN environment based on
configured allowed list. For incoming frames on non-VN connected
interface(e.g.,WAN interface), the tenant system A should map the
incoming frames from end device to specific VN based on inner Ethernet
frame information (e.g., VLAN ID). The mapping table is setup at the
tenant system A to perform VNID lookup in VN and label lookup in the
Non-VN environment. </t>
</section>
</section>
<section title="NVE to Oracle Control plane protocol functionality">
<t>The core functional entities for NVE to Oracle Control plane
infrastructure are the NVE and Oracle backend system. The Oracle backend
system is responsible for maintaining the tenant system reachability
state and is the topological anchor point for the Tenant system MAC
address or Tenant System Name (i.e.,vNIC name). The NVE is the entity
that performs the address mapping management on behalf of tenant system,
and it resides on the access link where the tenant system is anchored.
The NVE is responsible for detecting the VM's movements to and from the
access link and for initiating location binding registrations to the
tenant system's Oracle backend system. There can be multiple Oracle
backend system in a VN each serving a different group of tenant system.
</t>
<section title="NVE connect/disconnect notification">
<t>When a tenant system connects to one VN by attaching to a local
NVE, the local NVE should also be added into VN context together with
tenant system information. This helps Network Virtualization Authority
or Oracle Backend System know with which NVE a group of the tenant
systems are attached or current location of these tenant systems. When
the last tenant system is disconnected to one VN through one local
NVE, this local NVE should also be removed from VN context. This
should also be updated to Network Virtualization Authority or Oracle
Backend system and let Oracle backend system know that there are no
tenant system associated with that NVE. </t>
</section>
<section title="VN membership Registration and Query">
<t>In order to enable tenant system A to communicate with any tenant
system that is not under the same local NVE, the mapping table should
be distributed to all the remote NVEs that belong to the same VN even
though there is no tenant system which communicates with tenant system
A behind that remote NVE. However how should local NVE know a list of
remote NVEs that belong to the same VN as local NVE? In order to
tackle this, when a tenant system connects to one VN by attaching to a
local NVE, VN membership (e.g., VNID, VN Name, a list of NVE that
belong to VN) should be registered to the Network Virtualization
Authority or Oracle Backend system. When local NVE needs to know which
remote NVEs it should forward a data packet, Network Virtualization
Authority or Oracle backend system can be queried by the local NVE.
The Network Virtualization Authority or Oracle backend system can
redirect the query from local NVE to the remote NVEs based on VN
membership registration and obtain answer from the right remote NVE.
In addition, VM membership may contain detailed mapping between tenant
system, NVE and VN in the form of TESID=<VNID, NVE_ID,TS_ID>. In
this case, The Network Virtualization Authority or Oracle backend
system can directly supply answer for the request from the local NVE.
</t>
</section>
<section title="Address Mapping information reflection/distribution">
<t>Data plane learning can be used to build mapping table without need
for control plane protocol. However it requires each data packet to be
flooded to the whole VN. In order to eliminate flooding introduced by
data plane learning, a control protocol is needed to provide both MAC
address and IP address in the form of mapping information. When VN
membership registration complete, the NVE can forward such address
mapping information directly to all the remote NVEs based on VN
membership, alternatively, the NVE also can forward such address
mapping information indirectly to the Network Virtualization Authority
or Oracle backend system and let the Network Virtualization Authority
or Oracle backend system to reflect the address mapping information to
all the relevant remote NVEs based on VN membership. </t>
</section>
<section title="VN context moving">
<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 including VN profile
can be maintained at the Network Virtualization Authority or Oracle
backend system and be retrieved at the new place based on the VN
Identifier (VNID). </t>
</section>
</section>
<section title="Hypervisor-to-NVE Control Plane Protocol Functionality">
<section title="Multiple addresses association of one TS">
<t>Typically, a TS or vNIC is assigned a single MAC address and a
single IP address. However, a TS may be assigned multiple IP addresses
with each to connect to one VN. In such case, BID may be assigned for
each IP address of TS when tenant system wants to register multiple IP
address with its MAC address simultaneously to the local NVE. If a
tenant system has only one IP address, the assignment of a BID is not
needed until it has multiple IP addresses to register with, at which
time all of the IP addresses of TS MUST be mapped to BIDs. When a
tenant system registers a given BID for the first time it MUST send
BID together with the IP address. For any subsequent registrations
that either re-register or de-register the same BID, the TS only need
send BID and does not need to send IP address associated with BID.
</t>
</section>
</section>
<section title="Key functions aspect 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 other 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 information 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 information 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 information 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 centralized controller,e.g., the Network Virtualization
Authority or Oracle Backend system. </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-overlay-problem-statement">
<front>
<title>Problem Statement: Overlays for Network
Virtualization</title>
<author fullname="T.Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<date month="Feburary" year="2013" />
</front>
<seriesInfo name="ID"
value="draft-ietf-nvo3-overlay-problem-statement-02" />
</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>
<reference anchor="I.D-kreeger-nvo3-hypervisor-nve-cp">
<front>
<title>Network Virtualization Hypervisor-to-NVE Overlay Control
Protocol Requirements</title>
<author fullname="L.Kreeger" initials="L." surname="Kreeger">
<organization></organization>
</author>
<date month="Feburary" year="2013" />
</front>
<seriesInfo name="ID" value="draft-kreeger-nvo3-hypervisor-nve-cp-01" />
</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:18:55 |