Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

Overlay Networking

Versions: 01
Proposed Charter for "Network Virtualization Overlays" (nvo3) WG
WG State: Active
Charter State:
Responsible AD: none

Send notices to: none
Last updated: 2012-02-23

Other versions: plain text

Charter charter-ietf-nvo3-01

Support for multi-tenancy has become a core requirement of data centers
  (DCs), especially in the context of data centers supporting virtualized
  hosts known as virtual machines (VMs). Three  key requirements needed
  to support multi-tenancy are:
    o Traffic isolation, so that a tenant's traffic is not visible to
      any other tenant, and
    o Address independence, so that one tenant's addressing scheme does
      not collide with other tenant's addressing schemes or with addresses
      used within the data center itself.
     o Support the placement and migration of VMs anywhere within the
       data center, without being limited by DC network constraints
       such as the IP subnet boundaries of the underlying DC network.
  An NVO3 solution (known here as a Data Center Virtual Private
  Network (DCVPN)) is a VPN that is viable across a scaling
  range of a few thousand VMs to several million VMs running on
  greater than one hundred thousand physical servers. It thus has
  good scaling properties from relatively small networks to
  networks with several million DCVPN endpoints and hundreds of
  thousands of DCVPNs within a single administrative domain.
  A DCVPN also supports VM migration between physical servers
  in a sub-second timeframe.
  Note that although this charter uses the term VM throughout, NVO3 must
  also support connectivity to traditional hosts e.g. hosts that do not
  have hypervisors.
  NVO3 will consider approaches to multi-tenancy that reside at the
  network layer rather than using traditional isolation mechanisms
  that rely on the underlying layer 2 technology (e.g., VLANs).
  The NVO3 WG will determine which types of connectivity services
  are needed by typical DC deployments (for example, IP and/or
  NVO3 will document the problem statement, the applicability,
  and an architectural framework for DCVPNs within a data center
  environment. Within this framework, functional blocks will be
  defined to allow the dynamic attachment / detachment of VMs to
  their DCVPN, and the interconnection of elements of the DCVPNs
  over the underlying physical network. This will support the
  delivery of packets to the destination VM within the scaling
  and migration limits described above.
  Based on this framework, the NVO3 WG will develop requirements for both
  control plane protocol(s) and data plane encapsulation format(s), and
  perform a gap analysis of existing candidate mechanisms. In addition
  to functional and architectural requirements, the NVO3 WG will develop
  management, operational, maintenance, troubleshooting, security and
  OAM protocol requirements.
  The NVO3 WG will investigate the interconnection of the DCVPNs
  and their tenants with non-NVO3 IP network(s) to determine if
  any specific work is needed.
  The NVO3 WG will write the following informational RFCs, which
  must have completed Working Group Last Call before rechartering can be
      Problem Statement
      Framework document
      Control plane requirements document
      Data plane requirements document
      Operational Requirements
      Gap Analysis
  Driven by the requirements and consistent with the gap analysis,
  the NVO3 WG may request being rechartered to document solutions
  consisting of one or more data plane encapsulations and
  control plane protocols as applicable.  Any documented solutions
  will use existing IETF protocols if suitable. Otherwise,
  the NVO3 WG may propose the development of new IETF protocols,
  or the writing of an applicability statement for non-IETF
  If the WG anticipates the adoption  of the technologies of
  another SDO, such as the IEEE, as part of the solution, it
  will liaise with that SDO to ensure the compatibility of
  the approach.