Internet DRAFT - draft-yong-nvo3-frwk-dpreq-addition
draft-yong-nvo3-frwk-dpreq-addition
Network working group L. Yong
Internet Draft L. Dunbar
Category: Informational Huawei
Expires: March 2013 December 11, 2012
NVO3 Framework and Data Plane Requirement Addition
draft-yong-nvo3-frwk-dpreq-addition-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 11, 2013.
Copyright Notice
Copyright (c) 2009 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.
Yong & Dunbar Expires March 11, 2013 [Page 1]
Internet-Draft FRWK and DP Req. Addition December 2012
Abstract
This document describes some additional functions and requirements
for NVO3 framework [NVO3FRWK] and data plane requirements [DPREQ].
These additions are necessary in supporting VM communication and
mobility.
Conventions used in this document
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 [RFC2119].
Table of Contents
1. Introduction...................................................3
2. New NVE Service Type...........................................3
2.1. Why a New NVE Service Type................................3
2.2. L2-3 NVE Providing IP Routing/Bridging-like Service
(Framework Addition)...........................................4
2.3. L2-3 VNI (Data Plane Requirement Addition)................4
3. Tenant System Mobility.........................................5
3.1. Background................................................5
3.2. NVE Functions for TS Mobility (Framework Addition)........6
3.2.1. Tenant System Mobility...............................6
3.2.2. Tenant Multicast Traffic.............................6
3.2.3. The Policy Associated With TS........................7
3.3. Tenant System Mobility (Data Plane Requirement Addition)..7
4. Security Considerations........................................8
5. IANA Considerations............................................8
6. Acknowledgements...............................................8
7. References.....................................................8
7.1. Normative References......................................8
7.2. Informative References....................................8
Yong & Dunbar Expires March 11, 2013 [Page 2]
Internet-Draft FRWK and DP Req. Addition December 2012
1. Introduction
NVO3 framework [NVO3FRWK] and data plane requirement [DPREQ]
documents specify the network virtualization overlay framework and
data plane requirements, which aims on an architecture to support
the network virtualization overlay in DC [NVO3PRBM]. The main
application of NVO3 is to support multi-tenant networks on a common
infrastructure, where a tenant virtual network may contain one or
more subnets [HYPERV]. However, current framework specifies two NVE
service types. Neither of them naturally supports the communication
among the VMs when some VMs are on the same subnet and other on
different. Second, one of the key aspects of NVO3 is to support the
virtual machines (VM) mobility. However, neither document mentions
VM mobility nor specifies any function and/or requirements in
supporting VM mobility. This document addresses the two additions.
To use the terminologies specified in the framework document, this
document refers VM mobility as to Tenant System mobility or TS
mobility.
2. New NVE Service Type
2.1. Why a New NVE Service Type
A virtual machine on a server behaves like a physical server to an
application or guest OS on it. This means that any frame from/to a
virtual machine is an Ethernet frame, just as a frame from/to a
physical server.
L2 NVE service type specified in the framework [NVO3FRWK] provides
Ethernet LAN like service where multiple Tenant Systems appear to
interconnected by an LAN environment over a set of L3 tunnels.
However, from the host (physical servers or VMs) perspective, only
the hosts on the same subnet can communicate in an LAN network. This
implies that L2 NVE service type only applies to a single subnet.
L3 NVE service type [NVO3FRWK] provides a virtualized IP routing and
forwarding like IETF IP VPN. The IP VPN emulates a route domain and
provides forwarding and routing among TSes that are the same and/or
different subnets. IETF IP VPN has the assumption that the Layer 3
MUST be implemented between a PE and a CE, which means between an
NVE and a TS in this context. This assumption does not fit to the
case where an NVE attached by the multiple TSes that are on the same
subnet where the TSes uses bridging mechanism for the communication.
Yong & Dunbar Expires March 11, 2013 [Page 3]
Internet-Draft FRWK and DP Req. Addition December 2012
To support TSes, regardless on the same or different subnets,
communicating in an L2 environment, this document suggests adding a
new L2-3 NVE Service Type. Suggested Text for the framework and data
plane requirement documents is in section 2.2 and section 2.3,
respectively.
2.2. L2-3 NVE Providing IP Routing/Bridging-like Service (Framework
Addition)
L2-3 NVE is similar to IRB function on a router [CIRB] device today.
It supports the TSes attached to the NVE (locally or remotely) to
communicate with each other when they are in a same route domain,
i.e. a tenant virtual network. The NVE provides per tenant virtual
switching and routing instance with address isolation and L3 tunnel
encapsulation across the core. The L2-3 NVE supports the bridging
among TSes that are on the same subnet and the routing among TSes
that are on the different subnets.
2.3. L2-3 VNI (Data Plane Requirement Addition)
L2-3 VNIs MUST provide virtualized IP routing and bridging. L2-3 VNI
MUST support per-tenant forwarding instance with IP and MAC address
isolation and L3 tunneling for interconnecting instances of the same
VNI on NVEs. L2-3 VNI MUST perform the virtual bridging for the
Tenant Systems that are on the same subnet and the IP routing for
the Tenant Systems that are on the different subnets. L2-3 VNI MUST
support L2/3 gateway function.
L2-3 VNI MUST NOT change Tenant System communication mechanism in a
route domain, i.e. a tenant virtual network, and not violate Tenant
Systems communication rules. Tenant System communication rules are
if Tenant Systems are on the same subnet, they are bridged directly;
if Tenant Systems are on different subnets, they MUST communicate
through a router. A tenant system uses the ARP/ND protocol to
discover other tenant system MAC addresses if they are on the same
subnet; a tenant system sends a packet to a known gateway if the
destination of the packet is on different subnet from the sender TS;
a tenant system uses ARP/ND protocol to find the gateway MAC address.
Forwarding table entries provide mapping information between MAC/IP
and L3 Tunnel destination addresses. Such entries MAY be populated
by a control or management plane.
The L2-3 VNI MUST support the ARP protocol at virtual access points
(VAPs) and a default VGW MAC address.
Yong & Dunbar Expires March 11, 2013 [Page 4]
Internet-Draft FRWK and DP Req. Addition December 2012
In the case of L2-3 VNI, when the packet is forwarded from one
subnet to another subnet, inner TTL field and outer TTL field
process MUST be the same as described in L3 VNI section.
When tenant multicast is supported, L2-3 VNI SHOULD also be possible
to select whether the NVE provides optimized multicast trees inside
the VNI for individual tenant multicast groups or whether the
default VNI multicast tree is used, where all the NVEs of the
corresponding VNI are members, is used.
3. Tenant System Mobility
3.1. Background
NVO3 generic reference model specifies that a Tenant System can be
attached to an NVE locally or remotely. The local means that a TS
and the NVE are resident in the same device, e.g. server. The remote
means a TS attached to the NVE via a point-to-point connection or a
switched network, e.g. Ethernet.
When an NVE is local, the state of Tenant System can be provided
without protocol assistance. This implies that when Tenant System
state changes, the NVE is immediately aware of the changes. When an
NVE is remote, the state of the Tenant System needs to be exchanged
via a data or control plane protocol, or via a management entity.
VM mobility further requires support of hot and cold move [VMMOVE].
In the hot move, the moving is seamless to the application that runs
on the moved TS, which implies that the existing connectivity
between the moved TS and other TSes that the moved TS communicates
with MUST be maintained while the TS is moved regardless if these
TSes are on the same or different subnets.
When a TS and NVE are resident in the same device, the TS moves from
one NVE, NVE1 to another NVE, NVE2. NVE2 instantly knows the TS
address, state, and etc. However other NVEs that other TSes attach
to and have the connectivity with the moved TS MUST be also aware of
the TS new location, i.e. NVE2 location, and NVE2 MUST be also aware
of these NVE locations in order to maintain the connectivity.
When a TS and NVE are remotely attached, TS moving only applies when
a TS attaches to the NVE via a switched network, i.e. L2 physical
and/or virtual network.[VMMOVE] In addition of the actions in the
local NVE case (mentioned above), when an NVE is remote, the state
of the Tenant System needs to be exchanged via a data or control
plane protocol, or via a management entity.
Yong & Dunbar Expires March 11, 2013 [Page 5]
Internet-Draft FRWK and DP Req. Addition December 2012
Other two cases are a TS moved away from a local NVE and to a remote
NVE and vise versa.
To support TS mobility, this document suggests adding a new section
in the NVO3 framework and data plane requirement documents and the
suggested text is in section 3.2 and 3.3, respectively.
3.2. NVE Functions for TS Mobility (Framework Addition)
3.2.1. Tenant System Mobility
If an NVE (say ingress NVE) is responsible to notify other NVEs
(egress NVEs) regarding a new moved TS attaching to it. If the
ingress NVE is not yet on the tenant virtual network that the moved
TS belongs to, the NVE MUST establish the membership to the virtual
network first and create a virtual access point (VAP) to associate
to the virtual network. The NVE MUST send a notification about the
TS to other egress NVEs that has the same membership. This can be
done via data plane or control plane. Upon receiving the
notification from an ingress NVE, an egress NVE has to update its
VNIs that are associate to the same membership. If an NVE is remote,
the VNI MUST send the new TS address notification to the access
networks via the virtual access points (VAPs).
Note that if the ingress NVE is L2-3 NVE, and if it is not yet on
the same tenant virtual network subnet as the moved TS belongs to,
the NVE MUST establish the membership to the virtual subnet network
first and create a VAP to associate with it. The NVE MUST send a
notification about the TS to other egress NVEs that has the same
membership. If an NVE is remote, they MUST only send the
notification to the access networks that are on the same tenant
virtual subnet as the moved TS is on.
Note that, when a TS moves away from an NVE and it is the last TS
attached to the NVE belong to the tenant virtual network, the NVE
MAY delete the membership of the tenant virtual network.
3.2.2. Tenant Multicast Traffic
If a tenant application on a set of TSes needs to send broadcast or
multicast traffic among them, the NVE multicast and broadcast
capability can facilitate such forwarding [NVO3FRWK]. To support VM
mobility, when one of the TSes is moved from one NVE (say NVE1) to
another (say NVE2)in hot mode, the NVE2 has to know which multicast
groups that the TS is associated with. If NVE2 is local, such
information can be available to the NVE2 via some API; if NVE2 is
remote, such information can be available to the NVE2 via data plane,
Yong & Dunbar Expires March 11, 2013 [Page 6]
Internet-Draft FRWK and DP Req. Addition December 2012
control plane, or management entity [NVO3FRWK]. If NVE2 is need to
learn Tenant Multicast Groups that a moved TS is on, the NVEs MUST
be able to send a query message to the moved TS; The TS response
which groups it is on.
Once NVE2 knows which multicast groups that the new attached TS is
associated with, NVE2 MUST bind itself to these multicast groups if
it is not on yet. Furthermore, NVE2 MAY (if not yet) have to bind
the overlay multicast groups to one or more underlying multicast
tree if it uses the underlay multicast trees to delivery overlay
multicast traffic. An NVE MUST provide these capabilities, if it
supports tenant multicast traffic, to ensure tenant application
seamlessly running while a Tenant System is moved.
Similarly, when NVE1 knows a TS moved away and being the last one on
the tenant virtual network, NVE1 MAY unbind itself to the
corresponding multicast group. Furthermore, if this is the last
multicast group on the NVE1, NVE1 MAY unbind the multicast group to
the shared multicast tree if used.
3.2.3. The Policy Associated With TS
An NVE provides the policy based forwarding and routing [NVO3FRWK]
[DPREQ]. When a TS is moved from one NVE (say NVE1) to another (say
NVE2), the NVE2 has to apply to the same set of policy to the TS as
well. If TS related policies are specified in the TS service profile
that is moved along with the TS, and the file can be passed to the
NVE2 via API if the TS is locally attached to or via a data plane or
control plane protocol, or a management entity if remotely attached
to. An NVE MUST be able to automatically install these policies at
the VAP that a new TS attaches to. NVE1 MUST automatically delete
the policies that are applied to the moved TS only.
3.3. Tenant System Mobility (Data Plane Requirement Addition)
If the data plane learning is used to populate the forwarding
table[DPREQ], an NVE (local or remote) MUST be able to send a
notification message to all the NVEs that are the membership of the
tenant virtual network that the TS belongs to, e.g. ARP gratuitous
message. The notification MUST contain the TS address and tenant VN
ID. Upon receiving the notification message, an NVE MUST update the
corresponding VNI indicated in the NVO3 overlay header. If the
receiving NVE is remote, the NVE MUST send a notification to the
local access networks that is on the same subnet as of one indicated
in the NVO3 overlay header via the VAPs.
Yong & Dunbar Expires March 11, 2013 [Page 7]
Internet-Draft FRWK and DP Req. Addition December 2012
4. Security Considerations
When a Tenant System is moved from one NVE to another, automatic
virtual network membership creation on an NVE may leave some
security concern. Either certain authentication is needed for an NVE
to accept a new TS or management entity assisted process is used to
ensure the security.
Supporting TS mobility brings a new challenge for NVO3 is discussed
in [NVO3PRBM].
5. IANA Considerations
The document does not require any IANA action.
6. Acknowledgements
Thank Weiguo Hao for the review and input to the draft.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
7.2. Informative References
[DPREQ] Bitar, N., and etc, "NVO3 Data Plane Requirement", draft-bl-
nvo3-dataplane-requirements-03.txt, November 2012
[CIRB] Cisco, "Understanding and Configurating VLAN Routing and
Bridging on a Router Using the IRB Feature", Doc. ID 17054
[HYPERV] Microsoft, "Hyper-V Network Virtualization Packet Flow",
September 2012
[NVO3FRWK] LASSERRE, M., Motin, T., and etc, "Framework for DC
Network Virtualization", draft-ietf-nvo3-framework-01,
October 2012
[NVO3PRBM] Narten, T., and etc "Problem Statement: Overlays for
Network Virtualization", draft-ietf-nvo3-overlay-problem-
statement-01, October 2012
[VMMOVE] Rakhter, Y., and etc, "Network-related VM Mobility Issue",
draft-rekhter-nvo3-vm-mobility-issues-03.txt, Sept. 2012
Yong & Dunbar Expires March 11, 2013 [Page 8]
Internet-Draft FRWK and DP Req. Addition December 2012
Authors' Addresses
Lucy Yong
Huawei USA
5340 Legacy Drive
Plano, TX 75025
U.S.A
Phone: 469-277-5837
Email: lucy.yong@huawei.com
Linda Dunbar
Huawei USA
5340 Legacy Drive
Plano, TX 75025
U.S.A
Phone: 469-277-5840
Email: linda.dunbar@huawei.com
Yong & Dunbar Expires March 11, 2013 [Page 9]
