Internet Engineering Task Force L. Kreeger
Internet-Draft Cisco
Intended status: Informational T. Narten
Expires: April 19, 2013 IBM
D. Black
EMC
October 16, 2012
Network Virtualization Hypervisor-to-NVE Overlay Control Protocol
Requirements
draft-kreeger-nvo3-hypervisor-nve-cp-00
Abstract
The document "Problem Statement: Overlays for Network Virtualization"
discusses the needs for network virtualization using overlay networks
in highly virtualized data centers. The problem statement outlines a
need for control protocols to facilitate running these overlay
networks. This document outlines the high level requirements related
to the interaction between hypervisors and the Network Virtualization
Edge device when the two entities are not co-located on the same
physical device.
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 April 19, 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
Kreeger, et al. Expires April 19, 2013 [Page 1]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
(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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Hypervisor-NVE Control Plane Protocol Functionality . . . . . . 4
3.1. VN Connect/Disconnect Notification . . . . . . . . . . . . 6
3.2. VN Profile . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Informative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Kreeger, et al. Expires April 19, 2013 [Page 2]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
1. Introduction
Note: the contents of this document were originally in
[I-D.kreeger-nvo3-overlay-cp]. The content has been pulled into its
own document because the problem area covered is distinct and
different from what most folk think of as a "control protocol" for
NVO3. Other related documents on this same general topic include
[I-D.kompella-nvo3-server2nve], [I-D.gu-nvo3-overlay-cp-arch], and
[I-D.gu-nvo3-tes-nve-mechanism].
"Problem Statement: Overlays for Network Virtualization"
[I-D.ietf-nvo3-overlay-problem-statement] discusses the needs for
network virtualization using overlay networks in highly virtualized
data centers and provides a general motivation for building such
networks. "Framework for DC Network Virtualization"
[I-D.ietf-nvo3-framework] provides a framework for discussing overlay
networks generally and the various components that must work together
in building such systems. The reader is assumed to be familiar with
both documents.
Section 3.5 of [I-D.ietf-nvo3-overlay-problem-statement] describes
three separate work areas that fall under the general category of a
control protocol for NVO3. This document focuses entirely on the
control protocol related to the hypervisor-NVE interaction, labeled
as the "third work item" in
[I-D.ietf-nvo3-overlay-problem-statement]. Requirements for the
other control protocol components and work areas are described in
[I-D.kreeger-nvo3-overlay-cp].
This document uses the term "hypervisor" throughout when describing
the scenario where NVE functionality is implemented on a separate
device from the "hypervisor" that contains a VM connected to a VN.
In this context, the term "hypervisor" is meant to cover any device
type where the NVE functionality is offloaded in this fashion, e.g.,
a Network Service Appliance.
2. Terminology
This document uses the same terminology as found in
[I-D.ietf-nvo3-framework]. This section defines additional
terminology used by this document.
Network Service Appliance: A stand-alone physical device or a
virtual device that provides a network service, such as a
firewall, load balancer, etc. Such appliances may embed Network
Virtualization Edge (NVE) functionality within them in order to
more efficiently operate as part of a virtualized network.
Kreeger, et al. Expires April 19, 2013 [Page 3]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
VDC: Virtual Data Center. A container for virtualized compute,
storage and network services. Managed by a single tenant, a VDC
can contain multiple VNs and multiple Tenant End Systems that are
connected to one or more of these VNs.
VN Alias: A string name for a VN as used by administrators and
customers to name a specific VN. A VN Alias is a human-usable
string that can be listed in contracts, customer forms, email,
configuration files, etc. and that can be communicated easily
vocally (e.g., over the phone). A VN Name is independent of the
underlying technology used to implement a VN and will generally
not be carried in protocol fields of control protocols used in
virtual networks. Rather, a VN Alias will be mapped into a VN
Name where precision is required.
VN Name: A globally unique identifier for a VN suitable for use
within network protocols. A VN Name will usually be paired with a
VN Alias, with the VN Alias used by humans as a shorthand way to
name and identify a specific VN. A VN Name should have a compact
representation to minimize protocol overhead where a VN Name is
carried in a protocol field. Using a Universally Unique
Identifier (UUID) as discussed in RFC 4122, may work well because
it is both compact and a fixed size and can be generated locally
with a very high likelihood of global uniqueness.
VN ID: A unique and compact identifier for a VN within the scope of
a specific NVO3 administrative domain. It will generally be more
efficient to carry VN IDs as fields in control protocols than VN
Aliases. There is a one-to-one mapping between a VN Name and a VN
ID within an NVO3 Administrative Domain. Depending on the
technology used to implement an overlay network, the VN ID could
be used as the Context Identifier in the data plane, or would need
to be mapped to a locally-significant Context Identifier.
VN Profile: Meta data associated with a VN that is used by an NVE
when ingressing/egressing packets to/from a specific VN. Meta
data could include such information as QoS settings, etc. The VN
Profile contains parameters that apply to the VN as a whole.
Control protocols could use the VN ID or VN Name to obtain the VN
Profile.
3. Hypervisor-NVE Control Plane Protocol Functionality
The problem statement [I-D.ietf-nvo3-overlay-problem-statement],
discusses the needs for a control plane protocol (or protocols) to
populate each NVE with the state needed to perform its functions.
Kreeger, et al. Expires April 19, 2013 [Page 4]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
In one common scenario, an NVE provides overlay encapsulation/
decapsulation packet forwarding services to Tenant End Systems (TESs)
that are co-resident with the NVE on the same End System (e.g. when
the NVE is embedded within a hypervisor or a Network Service
Appliance). In such cases, there is no need for a standardized
protocol between the hypervisor and NVE, as the interaction is
implemented via software on a single device. Alternatively, a TES
may use an externally connected NVE (e.g. an NVE residing on a
physical Network Switch connected to the hypervisor via an access
network). The following figures give example scenarios where the NVE
and hypervisor are on different devices separated by an access
network.
Hypervisor Access Switch
+------------------+ +-----+-------+
| +--+ +-------+ | | | |
| |VM|---| | | VLAN | | |
| +--+ |Virtual|---------+ NVE | +--- Underlying
| +--+ |Switch | | Trunk | | | Network
| |VM|---| | | | | |
| +--+ +-------+ | | | |
+------------------+ +-----+-------+
Hypervisor with an External NVE.
Figure 1
Network Service Appliance Access Switch
+--------------------------+ +-----+-------+
| +------------+ |\ | | | |
| |Net Service |----| \ | | | |
| |Instance | | \ | VLAN | | |
| +------------+ | |---------+ NVE | +--- Underlying
| +------------+ | | | Trunk| | | Network
| |Net Service |----| / | | | |
| |Instance | | / | | | |
| +------------+ |/ | | | |
+--------------------------+ +-----+-------+
Physical Network Service Appliance with an External NVE.
Figure 2
In the examples above, the physical VLAN Trunk connecting the
Hypervisor or Network Services Appliance to the external NVE only
Kreeger, et al. Expires April 19, 2013 [Page 5]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
needs to carry locally significant (e.g. link-local) VLAN tag values.
These tags are only used to differentiate two different VNs as
packets cross the (shared) access network to the external NVE. When
the NVE receives packets, it uses the VLAN tag to identify the VN the
TES belongs to, strips the tag, and adds the appropriate overlay
encapsulation for that VN.
On the hypervisor-facing side of the NVE, a control plane protocol is
necessary to provide an NVE with the information it needs to connect
a given TES to its associated Virtual Network. Specifically, the
hypervisor (or Network Service Appliance) utilizing an external NVE
needs to "attach to" and "detach from" an NVE. Thus, they will need
a protocol that runs across the access network between the two
devices that identifies the TES and VN Name for which the NVE is
providing service. In addition, such a protocol will identify a
locally significant tag (e.g., an 802.1Q VLAN tag) that can be used
to identify the data frames that flow between the TES and VN.
3.1. VN Connect/Disconnect Notification
In the previous figures, NVEs reside on an external networking device
(e.g. an access switch). Using an external network device as the NVE
can provide an offload of the encapsulation / decapsulation function
and the protocol overheads which may provide performance improvements
and/or resource savings to the client End Device making use of the
external NVE.
When an NVE is external, a protocol is needed between a client End
Device making use of the external NVE and the NVE itself in order to
make the NVE aware of the changing VN membership requirements of the
client End Device. A key driver for using a protocol rather than
using static configuration of the external NVE is because the VN
connectivity requirements can change frequently as VMs are brought
up, moved and brought down on various hypervisors throughout the data
center.
The NVE must be notified when an End Device requires connection to a
particular VN and when it no longer requires connection. This
protocol should also provide the inner TES addresses within the VN
that the End Device contains (e.g. the virtual MAC address of a VMs
virtual NIC) to the external NVE. In addition, the external NVE must
provide a local tag value for each connected VN to the End Device to
use for exchange of packets between the End Device to the NVE (e.g. a
locally significant 802.1Q tag value).
The Identification of the VN in this protocol could either be through
a VN Name or a VN ID. A globally unique VN Name facilitates
portability of a Tenant's Virtual Data Center. When a VN within a
Kreeger, et al. Expires April 19, 2013 [Page 6]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
VDC is instantiated within a particular administrative domain, it can
be allocated a VN Context which only the NVE needs to use. An End
Device that is making use of an offloaded NVE only needs to
communicate the VN Name to the NVE, and get back a locally
significant tag value.
3.2. VN Profile
Once an NVE (embedded or external) receives a VN connect indication
with a specified VN Name or ID, the NVE must determine the VN Context
value to encapsulate packets with as well as other information that
may be needed (e.g., QoS settings). The NVE serving that hypervisor
needs a way to get a VN Context allocated or receive the already
allocated VN Context for a given VN Name or ID (as well as any other
information needed to transmit encapsulated packets). A protocol for
an NVE to get this mapping may be a useful function, but would be the
subject of work items 1 and 2 in
[I-D.ietf-nvo3-overlay-problem-statement].
4. Security Considerations
Editor's Note: This is an initial start on the security
considerations section; it will need to be expanded, and suggestions
for material to add are welcome.
NVEs must ensure that only properly authorized Tenant End Systems are
allowed to join and become a part of any specific Virtual Network.
In addition, NVEs will need appropriate mechanisms to ensure that any
hypervisor wishing to use the services of an NVE are properly
authorized to do so. One design point is whether the hypervisor
should supply the NVE with necessary information (e.g., VM addresses,
VN information, or other parameters) that the NVE uses directly, or
whether the hypervisor should only supply a VN ID and an identifier
for the associated VM (e.g., its MAC address), with the NVE using
that information to obtain the information needed to validate the
hypervisor-provided parameters or obtain related parameters in a
secure manner.
5. Informative References
[I-D.gu-nvo3-overlay-cp-arch]
Yingjie, G. and W. Hao, "Analysis of external assistance
to NVE and consideration of architecture",
draft-gu-nvo3-overlay-cp-arch-00 (work in progress),
July 2012.
Kreeger, et al. Expires April 19, 2013 [Page 7]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
[I-D.gu-nvo3-tes-nve-mechanism]
Yingjie, G., "The mechanism and protocol between VAP and
TES to facilitate NVO3",
draft-gu-nvo3-tes-nve-mechanism-00 (work in progress),
July 2012.
[I-D.ietf-nvo3-framework]
Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for DC Network Virtualization",
draft-ietf-nvo3-framework-00 (work in progress),
September 2012.
[I-D.ietf-nvo3-overlay-problem-statement]
Narten, T., Black, D., Dutt, D., Fang, L., Gray, E.,
Kreeger, L., Napierala, M., and M. Sridhavan, "Problem
Statement: Overlays for Network Virtualization",
draft-ietf-nvo3-overlay-problem-statement-00 (work in
progress), September 2012.
[I-D.kompella-nvo3-server2nve]
Kompella, K., Rekhter, Y., and T. Morin, "Using Signaling
to Simplify Network Virtualization Provisioning",
draft-kompella-nvo3-server2nve-00 (work in progress),
July 2012.
[I-D.kreeger-nvo3-overlay-cp]
Kreeger, L., Dutt, D., Narten, T., Black, D., and M.
Sridhavan, "Network Virtualization Overlay Control
Protocol Requirements", draft-kreeger-nvo3-overlay-cp-01
(work in progress), July 2012.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Authors' Addresses
Lawrence Kreeger
Cisco
Email: kreeger@cisco.com
Thomas Narten
IBM
Email: narten@us.ibm.com
Kreeger, et al. Expires April 19, 2013 [Page 8]
Internet-Draft NVO3 Hypervisor-NVE Control Protocol Reqs October 2012
David Black
EMC
Email: david.black@emc.com
Kreeger, et al. Expires April 19, 2013 [Page 9]