[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
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]