One document matched: draft-gu-nvo3-tes-nve-mechanism-00.txt
Network Working Group Y. Gu
Internet-Draft Huawei
Intended status: Standards Track July 6, 2012
Expires: January 7, 2013
The mechanism and protocol between VAP and TES to facilitate
NVO3
draft-gu-nvo3-tes-nve-mechanism-00
Abstract
This draft provide requirements and rationale for the mechanism
between Network Virtualization Edge (NVE) and Tenant End Systems
(TES). It also provides analysis on candidate mechanisms to fulfill
the requirements. These requirements is complementarity to the
control plane requirements. In the subsequent versions of this
draft, we will provide more technical details.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 7, 2013.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Gu Expires January 7, 2013 [Page 1]
Internet-Draft NVO3 TES to NVE mechanism July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4
3. Origin of Requirements . . . . . . . . . . . . . . . . . . . . 6
3.1. Basic Functionality . . . . . . . . . . . . . . . . . . . 8
3.1.1. Connectivity Notification . . . . . . . . . . . . . . 8
3.1.2. Inner Address Notification . . . . . . . . . . . . . . 10
3.1.3. Local Tag Feedback . . . . . . . . . . . . . . . . . . 10
3.2. Extension Functionality . . . . . . . . . . . . . . . . . 10
3.2.1. PCP notification . . . . . . . . . . . . . . . . . . . 11
4. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 11
4.2. Extension Requirements . . . . . . . . . . . . . . . . . . 12
5. Mechanism Classification . . . . . . . . . . . . . . . . . . . 12
5.1. Mechanism Classification . . . . . . . . . . . . . . . . . 12
5.2. IEEE 802.1Qbg . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Brief Introduction . . . . . . . . . . . . . . . . . . 12
5.3. External Controller . . . . . . . . . . . . . . . . . . . 15
5.4. Reuse existing protocols . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 15
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Gu Expires January 7, 2013 [Page 2]
Internet-Draft NVO3 TES to NVE mechanism July 2012
1. Introduction
This draft is not the first draft that discuss the requirements for a
mechanism and protocol between NVE and TES. To simplify the
description of this mechanism and protocol in this draft, we
temporarily call it TES to NVE Notification mechanism and Protocol
(TNP). The TNP is shown in the reference model in Fig1.
+------- L3 Network ------+
| |
| Tunnel Overlay |
+------------+--------+ +--------+------------+
| +----------+------+ | | +------+----------+ |
| | Overlay Module | | | | Overlay Module | |
| +--------+--------+ | | +--------+--------+ |
| |VN Context| | |VN Context|
| | | | | |
| +-------+-------+ | | +------+-------+ |
| | VNI | | | | VNI | |
NVE1 | +-+-----------+-+ | | +-+----------+-+ | NVE2
| | VAPs | | | | VAPs | |
+----+-----------+----+ +----+-----------+----+ /\
| | | | |
-------+-----------+-----------------+-----------+------- | TNP
| | Tenant | | |
| | Service IF | | \/
Tenant End Systems Tenant End Systems
Figure 1: Generic reference model for NV Edge
In Section 3 of , VN connect/disconnect notification have been
introduced, which is one requirement for TNP. Some characteristic
described in Section 4 of [overlay-cp]can also be extracted as
requirements on TNP. [overlay-cp]Also in , the author's consideration
on local VID issues makes us to think of how TNP can resolve this
problem. [mobility]
Before list the requirements for TNP, some necessary functionality
for network virtualization are introduced which are regarded, in this
draft, as origins of TNP. Then specific requirements are listed.
In the mail list discussion, at least three mechanisms are mentioned,
i.e. VDP (VSI Discovery and Configuration Protocol ), existing IETF
protocols, e.g. XMPP and OSPF, and centralized controller
assistance. It's hard to compare all the possible protocols in one
draft, so we classify the protocols and match each classification to
the requirements and analyze whether and how the different
classification can fulfill these requirements.
Gu Expires January 7, 2013 [Page 3]
Internet-Draft NVO3 TES to NVE mechanism July 2012
In the subsequent versions of this draft, we will provide more
technical details for respective mechanism. We expect to keep
updating the draft to reflect the relevant consensus made by working
group and will define the protocol and mechanism in detail.
2. Terminologies and concepts
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 [RFC2119].
The document uses terms defined in [framework]and [overlay-cp].
VN: Virtual Network. This is a virtual L2 or L3 domain that belongs
a tenant.
VNI: Virtual Network Instance. This is one instance of a virtual
overlay network. Two Virtual Networks are isolated from one another
and may use overlapping addresses.
Virtual Network Context or VN Context: Field that is part of the
overlay encapsulation header which allows the encapsulated frame to
be delivered to the appropriate virtual network endpoint by the
egress NVE. The egress NVE uses this field to determine the
appropriate virtual network context in which to process the packet.
This field MAY be an explicit, unique (to the administrative domain)
virtual network identifier (VNID) or MAY express the necessary
context information in other ways (e.g. a locally significant
identifier).
VNID: Virtual Network Identifier. In the case where the VN context
has global significance, this is the ID value that is carried in each
data packet in the overlay encapsulation that identifies the Virtual
Network the packet belongs to.
NVE: Network Virtualization Edge. It is a network entity that sits
on the edge of the NVO3 network. It implements network
virtualization functions that allow for L2 and/or L3 tenant
separation and for hiding tenant addressing information (MAC and IP
addresses). An NVE could be implemented as part of a virtual switch
within a hypervisor, a physical switch or router, a Network Service
Appliance or even be embedded within an End Station.
Underlay or Underlying Network: This is the network that provides the
connectivity between NVEs. The Underlying Network can be completely
unaware of the overlay packets. Addresses within the Underlying
Network are also referred to as "outer addresses" because they exist
Gu Expires January 7, 2013 [Page 4]
Internet-Draft NVO3 TES to NVE mechanism July 2012
in the outer encapsulation. The Underlying Network can use a
completely different protocol (and address family) from that of the
overlay.
Data Center (DC): A physical complex housing physical servers,
network switches and routers, Network Service Appliances and
networked storage. The purpose of a Data Center is to provide
application and/or compute and/or storage services. One such service
is virtualized data center services, also known as Infrastructure as
a Service.
VM: Virtual Machine. Several Virtual Machines can share the
resources of a single physical computer server using the services of
a Hypervisor (see below definition).
Hypervisor: Server virtualization software running on a physical
compute server that hosts Virtual Machines. The hypervisor provides
shared compute/memory/storage and network connectivity to the VMs
that it hosts. Hypervisors often embed a Virtual Switch (see below).
Virtual Switch: A function within a Hypervisor (typically implemented
in software) that provides similar services to a physical Ethernet
switch. It switches Ethernet frames between VMs' virtual NICs within
the same physical server, or between a VM and a physical NIC card
connecting the server to a physical Ethernet switch. It also
enforces network isolation between VMs that should not communicate
with each other.
Tenant: A customer who consumes virtualized data center services
offered by a cloud service provider. A single tenant may consume one
or more Virtual Data Centers hosted by the same cloud service
provider.
Tenant End System: It defines an end system of a particular tenant,
which can be for instance a virtual machine (VM), a non-virtualized
server, or a physical appliance.
Virtual Access Points (VAPs): Tenant End Systems are connected to the
Tenant Instance through Virtual Access Points (VAPs). The VAPs can
be in reality physical ports on a ToR or virtual ports identified
through logical interface identifiers (VLANs, internal VSwitch
Interface ID leading to a VM).
VN Name: A globally unique name for a VN. The VN Name is not carried
in data packets originating from End Stations, but must be mapped
into an appropriate VN-ID for a particular encapsulating technology.
Using VN Names rather than VN-IDs to identify VNs in configuration
files and control protocols increases the portability of a VDC and
Gu Expires January 7, 2013 [Page 5]
Internet-Draft NVO3 TES to NVE mechanism July 2012
its associated VNs when moving among different administrative domains
(e.g. switching to a different cloud service provider).
VSI: Virtual Station Interface. Typically, a VSI is a virtual NIC
connected directly with a VM. [Qbg]
3. Origin of Requirements
The main target of NVO3 working group is to define mechanisms to
support multi-tenancy in DC, including traffic isolation, address
independence, and support the placement and migration of VMs. The
NVE is the boundary between TES and VN, while VAP component in NVE is
the point that directly access to TES. TES can be either VM or
physical server, and NVE can be within external network entity or
within Hypervisor.
NVE Location Cases
o (NVE Location 1) Physical server connects to external NVE: In this
case, each physical server represents one end system of a tenant.
There is no protocol or external assistance required since NVE can
be notified by physical plugin and extraction. And no need to
consider server mobility.
+------- L3 Network ------+
| |
| Tunnel Overlay |
+-------------+--------+ +--------+-------------+
| +------------------+ | | +------------------+ |
| | Overlay Module | | | | Overlay Module | |
| +---------+--------+ | | +---------+--------+ |
| |VN context| | VN context| |
| | | | | |
| +--------+-------+ | | +--------+-------+ |
| | VNI | | | | VNI | |
NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2
| | VAPs | | | | VAPs | |
+----+------------+----+ +----+------------+----+
| | | |
-------+------------+-----------------+------------+-------
| | Tenant | |
| | Service IF | |
Tenant End Systems Tenant End Systems
Physical Server Physical Server
Figure 2: NVE Location1: Physical server connects to external NVE
Gu Expires January 7, 2013 [Page 6]
Internet-Draft NVO3 TES to NVE mechanism July 2012
o (NVE Location 2) VM connects to NVE on Hypervisor: In this case,
there should be some mechanism to assist Hypervisor know of VM
changes, including adding, deleting and migration. Both VM and
Hypervisor, as well as network service appliance, are controlled
by VM Manager. VM Manager are aware of any VM identity and
changes, hence can easily notify NVE about the information. So a
protocol is not necessary in this case.
+-------------+------------+
| +--------------------+ |
| | +--------------+ | |
| | |Overlay Module| | |
| | +----+---------+ | |
| | | VN context| |
| | +-----+-------+ | |
| | | VNI | | |
| | +-+---------+-+ | |
| | | VAPs | | |
| +----+---------+-----+ |
| | | |
| +--+---------+---+ |
| | VM | |
| +----------------+ |
| |
+--------------------------+
Tenant End Systems
Figure 3
o (NVE Location 3) VM connects to NVE on external network entity: VM
is controlled by VM Manager, while NVE is controlled by external
controller. There is more than one way to enable NVE know of VM
changes. One is enable protocol between TES and NVM, which
indicates VM identity and changes. The another way is to enable
NVE to get from or being notified by external controller that can
communicate with VM Manager.
Gu Expires January 7, 2013 [Page 7]
Internet-Draft NVO3 TES to NVE mechanism July 2012
+------- L3 Network --------+
| |
| Tunnel Overlay |
+------------+---------+ +---------+------------+
| +----------+-------+ | | +---------+--------+ |
| | Overlay Module | | | | Overlay Module | |
| +---------+--------+ | | +---------+--------+ |
| |VN context| | VN context| |
| | | | | |
| +--------+-------+ | | +--------+-------+ |
| | VNI | | | | VNI | |
NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2
| | VAPs | | | | VAPs | |
+----+------------+----+ +----+-----------+-----+
| | | |
-------+------------+-----------------+-----------+-------
| | Tenant | |
| | Service IF | |
+----+------------+--------+ +---+-----------+-------+
| +----------------+ | | +---------------+ |
| | Hypervisor | | | | Hypervisor | |
| +--------+-------+ | | +-------+-------+ |
| | | | | |
| +-------+------+ | | +------+------+ |
| | VM | | | | VM | |
| +--------------+ | | +-------------+ |
| | | |
+--------------------------+ +-----------------------+
Tenant End Systems Tenant End Systems
Figure 4: NVE Location3: VM connects to NVE on external network
entity
In this draft, we focus on the requirements on the the third case,
that is VM connects to NVE on external network entity.
3.1. Basic Functionality
3.1.1. Connectivity Notification
As described in , the basic functionality for VAP mechanism is
connectivity notification. [overlay-cp]
VM has several status, including Created, Start up, Running, Shut
Down, Removed, Emigration, Immigration.
Gu Expires January 7, 2013 [Page 8]
Internet-Draft NVO3 TES to NVE mechanism July 2012
o Created: A set of OS resources is assigned for a VM. The VM is
ready to work, but not yet, like a well composed physical server
with power off. The VM Manager has configured the VM-relevant
information on Hypervisor
o Start up: The VM begins to work, just like a physical server is
power on. The VM must be able to connect to the network and send
packets at any time it wants. The Hypervisor should be aware of
the VM's start up.
o Running: The VM is working, e.g. communicating with remote end
systems, processing local applications, etc.
o Shut down: The VM is power off and no more network connection at
this time, though the OS resources is still reserved for the VM,
just like a physical server is power off.
o Removed: The set of OS resources assigned for this VM is released,
which means the VM doesn't exist any more.
* (Usually a full life of VM will pass through the following
stages: Created--Start up--Running--Shut down--Removed.)
o Emigration: The VM is still alive. But the VM and the services
running on the VM, if there is, migrate to another TES within or
out of the DC. There is no Shut down and Remove stage for this VM
on the original TES.
o Immigration: The VM is migrated from another TES within or out of
the DC. It doesn't have to experience the stage of Created and
Start up. There two kinds of Immigration VM, one is VM clean
immigration which has no running service need to resume, and the
other is VM live migration which has running service on it and the
service should not be disrupted by the action of VM migration.
A Hypervisor is able to know every status of the VM, but the NVE
needn't know each of them. In order not to interrupt the VM's
network communication, NVE must be aware of these status: Start up,
Shut down, Emigration and Immigration. And NVE must be aware of
these status timely.
When it is notified of the VM's Start up and Immigration, NVE can get
the specific VNID that VM is associated with, by using any
information that can identify this VM and it's VN, e.g. VN Name, VSI
ID, MAC address, etc.. We call all the above information as VN Clue.
And then NVE can get the globally unique VNID and timely created
local mapping, and forwarding table. The way to get these table
information is discussed in dedicated drafts.
Gu Expires January 7, 2013 [Page 9]
Internet-Draft NVO3 TES to NVE mechanism July 2012
When it is notified of the VM's Shut down and Emigration, NVE can
timely remove the local mapping and forwarding information to reduce
the chance for mis-forwarding and to save the space on the NVE.
3.1.2. Inner Address Notification
One important feature of multi-tenant DC is to support overlapped IP
address among different Tenant. In , the requirements for inner to
outer address mapping is described. In order to make this mapping,
NVE must be aware of the inner address, e.g. the MAC address of VM's
virtual NIC or VM's IP address. [overlay-cp]
3.1.3. Local Tag Feedback
After NVE get the VNID associated with a VM, it needs to assign a
local tag for the VNID. The local tag could be an IEEE802.1Q tag if
the TES access to NVE via L2. In every data frame sent from TES to
NVE, the local tag is included and NVE can easily define which VNID
the data frame belong to. The data frame sent from VM is usually
untagged, and Hypervisor in TES will add the local tag to the data
frame. Since local tag is assigned by NVE, it's necessary to find a
way to notify Hypervisor of the local tag.
VM Hypervisor NVE Controller
| | |
|---Start up--->| |
|--Start up (with VN Clue)--->|-------Get VNID-->|
|<---VNID----------|
|<--------local tag-----------|
|-data frame--->|
|-data frame(with local tag)->|
|--encapsulated VN traffic->
Figure 5: Local Tag Feedback
But it's also possible that the data frame from VM is already tagged
with VID, then adjacent bridge, either virtual or physical, need to
conver this VID to local tag. In our case, i.e. NVE location 3, the
adjacent bridge is a virtual bridge on Hypervisor, and Hypervisor has
to convert the VID to the local tag provided by NVE.
NVE should also support untagged traffic from TES. In this case, NVE
should be able to get the specific VNID from its controller for
untagged data frames arriving at its Virtual Access Points.
3.2. Extension Functionality
Gu Expires January 7, 2013 [Page 10]
Internet-Draft NVO3 TES to NVE mechanism July 2012
3.2.1. PCP notification
In typical DC, where physical server connects to adjacent bridge, the
data frame from server can be tagged with PCP or untaggged. If a
data frame is untagged, it can be tagged with PCP on adjacent bridge.
While in virtualized DC, the adjacent bridge is Hypervisor. There
are two options to deal with PCP tag, 1) data frame is tagged with
PCP by VM, 2)data frame is tagged with PCP by Hypervisor and 3) data
frame is tagged with PCP by NVE.
In cloud service, the VM can be anybody and it may want a higher
priority than it should have. The VM can tag it's data frame with
higher PCP value and get better service. Based on the assumption
that PCP provided by VM is not reliable, it's more reasonable to let
the network to define the PCP value based on VM's priority, and
enable bridges to tag the PCP value, as 2) or 3).
This problem is similar to local VID, which can be tagged either by
Hypervisor or by NVE. The benefit to tag PCP by Hypervisor is to
reduce the load on NVE.
4. Requirement
4.1. Basic Requirements
REQUIREMENT-1: The TNP (TES to NVE notification mechanism and
protocol) MUST support TES to notify NVE about the VM's status,
including but not limited to Start up, Shut down, Emigration and
Immigration.
REQUIREMENT-2: The TNP MUST support TES to notify NVE about the VM's
VN Clue, which can be one identifier or a combination of several
indentifier.
REQUIREMENT-3: The TNP MUST support TES to notify NVE about the VM's
inner address. The inner address MUST include one or both of MAC
address of VM's virtual NIC and VM's IP address. And it SHOULD
be extensible to carry new address type.
REQUIREMENT-4: The TNP MUST support NVE to notify TES about the VM's
local tag. The local Tag type supported by TNP MUST include IEEE
802.1Q tag. And it SHOULD be extensible to carry other type of
local tag.
Gu Expires January 7, 2013 [Page 11]
Internet-Draft NVO3 TES to NVE mechanism July 2012
4.2. Extension Requirements
REQUIREMENT-5: The TNP SHOULD support NVE to notify TES about the
VM's traffic PCP value.
5. Mechanism Classification
5.1. Mechanism Classification
At least three kinds of mechanisms are discussed in the mail list.
o IEEE 802.1Qbg- VDP(VSI discovery and configuration protocol): VDP
is a new protocol defined in IEEE802.1, the original intention is
to enable adjacent bridge to discover the connection/remove/
migration of VM's. And it also enable configuration between
adjacent bridge and Hypervisors. We will disclose more in the
following sections.
o Assist by external controller: The external controller can
communicate with VM Manager, who is totally aware of the VM's
status and private information, including VSI ID, MAC address, IP
address and etc. The controller can get enough information from
the VM Manger and then configure and control NVE.
o Existing IETF protocols, e.g. XMPP, OSPF and BGP: The basic idea
is to reuse these protocol to transfer the VN Clue to NVE. It's
not necessary to implement the complete protocols. The usage of
these protocols doesn't belong to their original definitions, but
only utilize their ability to carry additional information.
In this section, we will analyze each mechanism classification, how
they match the requirements listed in previous section.
5.2. IEEE 802.1Qbg
5.2.1. Brief Introduction
VDP has four basic TLV types.
o Pre-Associate: Pre-Associate is used to pre-associate a VSI
instance with a bridge port. The bridge validates the request and
returns a failure Status in case of errors. Successful pre-
association does not imply that the indicated VSI Type will be
applied to any traffic flowing through the VSI. The pre-associate
enables faster response to an associate, by allowing the bridge to
obtain the VSI Type prior to an association.
Gu Expires January 7, 2013 [Page 12]
Internet-Draft NVO3 TES to NVE mechanism July 2012
o Pre-Associate with resource reservation: Pre-Associate with
Resource Reservation involves the same steps as Pre-Associate, but
on successful pre-association also reserves resources in the
Bridge to prepare for a subsequent Associate request.
o Associate: The Associate TLV Type creates and activates an
association between a VSI instance and a bridge port. The Bridge
allocates any required bridge resources for the referenced VSI.
The Bridge activates the configuration for the VSI Type ID. This
association is then applied to the traffic flow to/from the VSI
instance.
o Deassociate: The de-associate TLV Type is used to remove an
association between a VSI instance and a bridge port. Pre-
Associated and Associated VSIs can be de-associated. De-associate
releases any resources that were reserved as a result of prior
Associate or Pre-Associate operations for that VSI instance.
|1 |2 |3 |4 |7 |8 |9 |25 |26 |25+M
|---------+--------+--------+--------+--------+------+-------+-----------+------------|
|TLV type|TLV info | Status |VSI Type|VSI Type|VSIID |VSIID |Filter Info|Filter Infor|
|(7bits) |strlength|(1octet)| ID |version |format|(16oct)| format | (M octets) |
| | (9bits) | |(3oct) |(1oct) |(1oct)| | (1 octet)| |
|--------+---------+--------+--------+--------+------+-------+-----------+------------|
| |<-------VSI type&instance------>|<-------Filter----------|
| |<--------------------VSI attibutes---------------------->|
|<----TLV header--><--------------TLV information string = 23+Moctets---------------->|
Figure 6: VDP TLV definitions
Some important flag values in VDP request:
o M-bit (Bit 5): Indicates that the user of the VSI (e.g., the VM)
is migrating (M-bit = 1) or provides no guidance on the migration
of the user of the VSI (M-bit = 0). The M-bit is used as an
indicator relative to the VSI that the user is migrating to.
o S-bit (Bit 6): Indicates that the VSI user (e.g., the VM) is
suspended (S-bit = 1) or provides no guidance as to whether the
user of the VSI is suspended (S-bit = 0). A keep-alive Associate
request with S-bit = 1 can be sent when the VSI user is suspended.
The S-bit is used as an indicator relative to the VSI that the
user is migrating from.
The filter information field supports the following format:
o VID
Gu Expires January 7, 2013 [Page 13]
Internet-Draft NVO3 TES to NVE mechanism July 2012
+---------+------+-------+--------+
| #of | PS | PCP | VID |
|entries |(1bit)|(3bits)|(12bits)|
|(2octets)| | | |
+---------+------+-------+--------+
|<--Repeated per entry->|
Figure 7
o MAC/VID
+---------+--------------+------+-------+--------+
| #of | MAC address | PS | PCP | VID |
|entries | (6 octets) |(1bit)|(3bits)|(12bits)|
|(2octets)| | | | |
+---------+--------------+------+-------+--------+
|<--------Repeated per entry---------->|
Figure 8
o GroupID/VID
+---------+--------------+------+-------+--------+
| #of | GroupID | PS | PCP | VID |
|entries | (4 octets) |(1bit)|(3bits)|(12bits)|
|(2octets)| | | | |
+---------+--------------+------+-------+--------+
|<--------Repeated per entry---------->|
Figure 9
o GroupID/MAC/VID
+---------+-----------+-------------+------+-------+--------+
| #of | GroupID | MAC address | PS | PCP | VID |
|entries |(4 octets) | (6 octets) |(1bit)|(3bits)|(12bits)|
|(2octets)| | | | | |
+---------+-----------+-------------+------+-------+--------+
|<--------------Repeated per entry--------------->|
Figure 10
In each format, the null VID can be used in the VDP Request. In this
case, the Bridge is expected to supply the corresponding local VID
value in the VDP Response.
The VSIID in VDP request that identify a VM can be one of the
following format: IPV4 address, IPV6 address, MAC address, UUID or
locally defined.
Gu Expires January 7, 2013 [Page 14]
Internet-Draft NVO3 TES to NVE mechanism July 2012
+--------------------------------------------------+----------------+
| VDP features | Requirements |
| | Matching |
+--------------------------------------------------+----------------+
| Pre-Associate/ Pre-Associate with resource | Requirement-1 |
| reservation/ Associate/ Deassociate | |
| M-bit/S-bit | Requirement-1 |
| VSI type&instance in VDP request | Requirement-2 |
| Filter Infor | Requirement-3 |
| VID infor in VDP response | Requirement-4 |
| PCP in VDP response | Requirement-5 |
+--------------------------------------------------+----------------+
VDP TLV types
5.3. External Controller
5.4. Reuse existing protocols
6. Security Considerations
There are some considerations on security in . Most of the
considerations are about mechanism between NVE and external
controller, and the attack on underlying networks, which can not be
resolved only by the mechanism between TES and NVE. One security
issue related to the mechanism between TES and NVE is about the
authentication of VM who announces to associate with a particular VN.
There is a hypervisor between VMs and NVEs, and both VMs and
hypervisor are not always reliable. For example, a poisoned
hypervisor may modify the VN Name, or identification for similar
intention, in order to associate with a VN that it doesn't belong to.
[overlay-cp]
7. References
7.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[Qbg] "IEEE P802.1Qbg Edge Virtual Bridging".
7.2. Informative Reference
[framework]
Marc Lasserre, Marc., Balus, Florin., Morin, Thomas.,
Gu Expires January 7, 2013 [Page 15]
Internet-Draft NVO3 TES to NVE mechanism July 2012
Bitar, Nabil., and Yakov. Rekhter,
"draft-lasserre-nvo3-framework-02", June 2012.
[overlay-cp]
Kreeger, L., Dutt, D., Narten, T., Black, D., and M.
Sridharan, "draft-kreeger-nvo3-overlay-cp-00", Jan 2012.
[mobility]
Dunbar, L.,
"draft-dunbar-nvo3-overlay-mobility-issues-00", June 2012.
Author's Address
Gu Yingjie
Huawei
No. 101 Software Avenue
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-56625392
Email: guyingjie@huawei.com
Gu Expires January 7, 2013 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 17:41:10 |