Internet DRAFT - draft-gu-nvo3-virt-edge-auto-discovery
draft-gu-nvo3-virt-edge-auto-discovery
NVO3 Z. Gu
Internet-Draft ZTE
Intended status: Standards Track C. Xie
Expires: February 22, 2016 China Telecom
V. Liu
China Mobile
B. Khasnabish
ZTE (TX) Inc.
August 21, 2015
NVE Auto-Discovery Protocol
draft-gu-nvo3-virt-edge-auto-discovery-02.txt
Abstract
NVO3 provides a framework for Network virtualization in data center,
and it will include a series of protocols.
This document describes the NVE automatic discovery protocol, and
shows how VN can be configured and how VM joins VN
automatically.Further this Protocol can be used to exchange the
status between VM and NVE, and to deliver the dynamic resources
request information.
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 February 22, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gu, et al. Expires February 22, 2016 [Page 1]
Internet-Draft NVE Auto-Discovery Protocol August 2015
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Discovery stage . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. NVE auto-discovery Initiation (NADI) packet . . . . . . . 6
5.2. NVE auto-discovery offer (NADO) packet . . . . . . . . . 6
5.3. NVE auto-discovery Request (NADR) packet . . . . . . . . 7
5.4. NVE auto-discovery Session-Confirmation (NADS) packet . . 7
5.5. NVE auto-discovery Termination (NADT) packet . . . . . . 8
6. VN Session stage . . . . . . . . . . . . . . . . . . . . . . 8
6.1. NVE auto-discovery Session-Confirmation (NADS) packet . . 8
6.2. VM-NVE status exchange (VNSE) packet . . . . . . . . . . 8
6.3. VM dynamic resources request (VMDRR) packet . . . . . . . 9
7. NVE-NVA protocol interaction . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA/IEEE Considerations . . . . . . . . . . . . . . . . . . 9
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative references . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. NVE auto-discovery protocol application: VM
Migration . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
There are Tens of thousands servers or even more in datacenters, and
up to millions of virtual networks should be supported for the
public/Internet users. It_s a huge burden for provider_s network
administrators to configure the NVEs and VMs and to deploy these
virtual networks. This document provides a method to eliminate the
NVE configuration task, includes NVE automatic discovery protocol.
Gu, et al. Expires February 22, 2016 [Page 2]
Internet-Draft NVE Auto-Discovery Protocol August 2015
Further, the NVE auto-discovery protocol can support other features,
such as virtual machine live migration, L2/L3 forwarding tables
decision per VN, and support different encapsulation mechanism per
VN-based.
2. 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].
3. Protocol Overview
There are two stages in the VN auto-configuration. The first stage
is NVE/VN automatic discovery, and the other is VN session, includes
VN joining or NVE auto-configuration, e.g. VNI generation/initiation
or VNI automatic configuration in the related NVE.
When a TS/virtual machine wants to join to a VN, it first shall find
the suitable NVE to serve it, e.g. to provide the connection between
VM and NVE and to implement other related VN functionalities. Based
on the network topology, there may be more than one NVE that the TS/
VM can communicate with. The discovery stage allows the VM to
discover all NVE and then select one. When the discovery completes
successfully, both the VM and the selected NVE have the information
then will be used to build their VN connection, especially the VN-ID
and/or session-ID.
4. Payload
Two type of packet formats are defined here for NVE auto-Discovery
and VN session, which are based on Ethernet frame. The payload
contents will be defined in the NVE auto-Discovery and VN session
sections.
An Ethernet frame is as follows:
Gu, et al. Expires February 22, 2016 [Page 3]
Internet-Draft NVE Auto-Discovery Protocol August 2015
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The DESTINATION_ADDR field contains either a unicast Ethernet
destination address, or the Ethernet broadcast address (0xffffffff).
For Discovery packets, the value is either a unicast or broadcast
address as defined in the auto-Discovery section. For VN session
traffic, this field MUST contain the peer's unicast address as
determined from the Discovery stage.
The SOURCE_ADDR field MUST contains the Ethernet MAC address of the
source device.
The ETHER_TYPE is set to either 0xXXXX (auto-Discovery Stage, TBD) or
0xXXXX (VN Session Stage, TBD).
The Ethernet payload for NVE auto-discovery is as follows:
Gu, et al. Expires February 22, 2016 [Page 4]
Internet-Draft NVE Auto-Discovery Protocol August 2015
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN_ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| VN Name |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The VER field is four bits and MUST be set to 0x1(TBD) for this
version of the VN auto-configuraton specification.
The TYPE field is four bits and MUST be set to 0x1(TBD) for this
version of the VN auto-configuraton specification.
The CODE field is eight bits and is defined below for the auto-
Discovery and VN Session stages.
The SESSION_ID field is sixteen bits. It is an unsigned value
innetwork byte order. It_s value is defined below for auto-Discovery
packets. The value is fixed for a given VN session and, in fact,
defines a VN session along with the Ethernet SOURCE_ADDR and
DESTINATION_ADDR. A value of 0xffff is reserved for future use and
MUST NOT be used.
It is optional and TBD.
The VN_ID field is twenty-four bits (or TBD according to NVO3_s
progress). It is an unsigned value in network byte order. It_s
value is defined below for auto-Discovery packets. The value is
fixed for a given VN session/connection and, in fact, defines a VN
session along with the Ethernet SOURCE_ADDR and DESTINATION_ADDR. A
value of 0xffff is reserved for future use and MUST NOT be used.
The VN Name field is optional, its length TBD.
The LENGTH field is sixteen bits. The value, in network byte order,
indicates the length of the VN session payload. It does not include
the length of the Ethernet or VN session headers.
Gu, et al. Expires February 22, 2016 [Page 5]
Internet-Draft NVE Auto-Discovery Protocol August 2015
The NVE auto-discovery payload contains zero or more TAGs. A TAG is
a TLV(type-length-value) construct and is defined as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE | TAG_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_VALUE __ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
TAG_TYPE is a sixteen bit field in network byte order. Appendix A
contains a list of all TAG_TYPEs and their TAG_VALUEs.
5. Discovery stage
There are four steps in NVE auto-discovery protocol. TS/VM
broadcasts NVE auto-discovery packets so to discover the NVEs in the
broadcast domain where the TSs/VMs reside. All the NVEs which can
serve the TS/VM in the domain response with NVE offer massage to TS/
VM. The TS/VM then selects one NVE as its serving NVE according to
some polices depend on the TS/VM priority or the NVE_s capability or
so, and send a request message to the selected NVE using unicast
packet/frame. Then the NVE acknowledge the request by send the
confirm message.
5.1. NVE auto-discovery Initiation (NADI) packet
The TS/VM sends the NADI packet with the DESTINATION_ADDR set to the
Broadcast address. The CODE field is set to 0x00(TBD) and the
SESSION_ID (optional, TBD) and VN-ID MUST be set to 0x0000.
The NADI packet MUST contain exactly one TAG of TAG_TYPE NVE-Type
Name, and/or NVE preference policy etc, indicating the NVE type the
Host is requesting, and any number of other TAG types.
[The related TAGs TBD]
5.2. NVE auto-discovery offer (NADO) packet
When the NVE receives a NADI that it can serve, it replies by sending
a NADO packet. The DESTINATION_ADDR is the unicast address of the
TS/VM that sent the NADI. The CODE field is set to 0x07(TBD) and the
SESSION_ID (optional, TBD)and VN-ID MUST be set to 0x0000.
Gu, et al. Expires February 22, 2016 [Page 6]
Internet-Draft NVE Auto-Discovery Protocol August 2015
The NADO packet MUST contain one NVE Name TAG containing the NVE_s
name, a NVE Name TAG identical to the one in the PADI, and any number
of other Service-Name TAGs indicating other services that the NVE
offers. If the NVE can not serve the NADI it MUST NOT respond with a
NADO.
[The related TAGs TBD]
5.3. NVE auto-discovery Request (NADR) packet
Since the NADI was broadcast, the TS/VM may receive more than one
NADO. The TS/VM looks through the NADO packets it receives and
chooses one. The choice can be based on the NVE Name/Type or the
Services offered. The TS/VM then sends one NADR packet to the NVE
that it has chosen. The DESTINATION_ADDR field is set to the unicast
Ethernet address of the NVE that sent the PADO. The CODE field is
set to 0x19 (TBD) and the SESSION_ID (optional, TBD) and VN-ID MUST
be set to 0x0000.
The NADR packet MUST contain exactly one TAG of TAG_TYPE Service-
Name, indicating the service the TS/VM is requesting, and any number
of other TAG types.
[The related TAGs TBD]
5.4. NVE auto-discovery Session-Confirmation (NADS) packet
When the NVE receives a NADR packet, it prepares to begin a VN
session. It generates a unique SESSION_ID for the VN session and set
the VN-ID field to 0x0000 and replies to the TS/VM with a NADS
packet. The DESTINATION_ADDR field is the unicast Ethernet address
of the TS/VM that sent the NADR. The CODE field is set to 0x65(TBD)
and the SESSION_ID MUST be set to the unique value generated for this
VN session.
The NADS packet contains exactly one TAG of TAG_TYPE Service-
Name,indicating the service under which NVE has accepted the VN
session, and any number of other TAG types.
If the NVE does not like the Service-Name in the NADR, then it MUST
reply with a NADS containing a TAG of TAG_TYPE Service-Name-Error
(and any number of other TAG types). In this case the SESSION_ID
MUST be set to 0x0000.
[The related TAGs TBD]
Gu, et al. Expires February 22, 2016 [Page 7]
Internet-Draft NVE Auto-Discovery Protocol August 2015
5.5. NVE auto-discovery Termination (NADT) packet
This packet may be sent anytime after a VN session is established to
indicate that a VN session has been terminated. It may be sent by
either the TS/VM or the NVE. The DESTINATION_ADDR field is a unicast
Ethernet address, the CODE field is set to 0xa7(TBD) and the
SESSION_ID MUST be set to indicate which session is to be terminated.
No TAGs are required.
When a NADT is received, no further VN traffic is allowed to be sent
using that session.
6. VN Session stage
After the TS/VM discovers the NVE and the NVE confirms the session,
then the NVE should authenticate the TS/VM_s identity of VN, if it
pass the authentication, then the NVE send another NADS message to
return the TS/VM with specified VNID and session-ID as special
parameters for secure communication between the TS/VM and NVE.
After the TS/VM passed the VN authentication successfully, the NVE
then generates the VN context, and add the TS/VM related entry to the
VN forwarding table. If the VN context already exists, then the NVE
only adds the VM related entry to the VN forwarding table.
6.1. NVE auto-discovery Session-Confirmation (NADS) packet
After the TS/VM passed the VN authentication successfully, the NVE
obtains or generates the VN-ID for the VN, then send the VN-ID to TS/
VM using the NADS packet, where the DESTINATION_ADDR field is the
unicast Ethernet address of the TS/VM that passed VN authentication.
The CODE field is set to 0x65(TBD) and the SESSION_ID MUST be set to
the unique value generated for this VN session.
After the TS/VM received the VN-ID, then all the followed packet
using the Session-ID and VN-ID to identify the packets.
[The related TAGs TBD]
6.2. VM-NVE status exchange (VNSE) packet
VN and NVE use VNSE to exchange VM status information. VNSE can be
VM used to report status, for example running, idle or keepalive
information. And NVE can use it to inquire the VM_s running status
information.
After the TS/VM received the VN-ID, then all the followed packet
using the Session-ID and VN-ID to identify the packets.
Gu, et al. Expires February 22, 2016 [Page 8]
Internet-Draft NVE Auto-Discovery Protocol August 2015
[The related TAGs TBD]
6.3. VM dynamic resources request (VMDRR) packet
This packet may be sent anytime after a VN session is established,
and when the VM want to change its resources requirements, such as
network access bandwidth, and/or CPU, or Memory, or Disk parameters,
etc. The DESTINATION_ADDR field is a unicast Ethernet address, the
CODE field is set to 0xa9(TBD). After received VMDRR, NVE
authenticate and authorize the request supported by NVA or/and other
function entities such as Hypervisor etc. to realize the dynamic
resources modification.
[The related TAGs TBD]
7. NVE-NVA protocol interaction
Generally, NVE auto-discovery protocol doesn't need to interact with
NVE-NVA protocol directly, but they all work on VN context,
especially on VN's VRF table, e.g. create, modify or delete entry in
the table which may trigger the peer protocol's action.
Please note that if VM's VN identity authentication function resides
in NVA, NVE auto-discovery protocol can use NVE-NVA protocol to
deliver the authentication packets.
8. Security Considerations
NVE auto-discovery protocol works in an open environment and VMs are
for public users, so VM access to VN shall pass the VN_s identity
authentication. NVE auto-discovery protocol can realize this
authentication by using various existing authentication protocol such
as EAP, etc.Further, NVE auto-discovery protocol_s Session-ID
mechanism can protect forgery packet attack.
9. IANA/IEEE Considerations
Should IEEE allocated types of new Ethernet-type frame. And IETF
should allocate some types of packet encapsulation.
10. Conclusions
The NVE auto-discovery protocol defined in this document is simple,
light-weighed, efficient and effective for automatic NV deployment in
large data center to support millions of VN provisioning.
Gu, et al. Expires February 22, 2016 [Page 9]
Internet-Draft NVE Auto-Discovery Protocol August 2015
11. Acknowledgments
The basic idea comes from PPPoE. And copious amounts of text have
been stolen from RFC 2516.
12. References
12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <http://www.rfc-editor.org/info/rfc2234>.
12.2. Informative References
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <http://www.rfc-editor.org/info/rfc2516>.
Appendix A.
TAG_TYPES and TAG_VALUES
TBD.
0x0102(TBD) NVE-Name
This TAG indicates that a string follows which uniquely identifies
this particular NVE unit from all others. It may be a combination of
trademark, model, and serial id information, or simply an UTF-8
rendition of the MAC address of the box. It is not NULL terminated.
0x0202(TBD) Migration Initiation Indication
This TAG indicates that the TS/VM is Destination TS/VM which migrated
from the Source one. After received this TAG, the NVE will initiate
a migration procedure.
0x0204(TBD) Migration Completion Indication
Gu, et al. Expires February 22, 2016 [Page 10]
Internet-Draft NVE Auto-Discovery Protocol August 2015
This TAG indicates that the TS/VM as Destination TS/VM has
synchronized with the Source TS/VM. After received this TAG, the NVE
will initiate a migration completion procedure.
Appendix B. NVE auto-discovery protocol application: VM Migration
NVE auto-discovery protocol is very helpful for the VM migration as
depicted inFigure1. The key point is when the migrating VM has been
prepared by the VM provider, the VM automatically start to discover
the NVE and register to the VN through the NVE auto-discovery
protocol.
7 VM --- NVE ---------- NVE --- Corresponding VM
\ /
\ /
5 \ 4 / 6
\ /
\ /
2 \ /
1 VM -------- NVE 3
8 9
Figure 4
The detail steps as follows:
Step1: VM preparation.
Step2: VM auto-discovers the NVE, e.g. the migration destination NVE,
contrast to the source NVE, which the VM connected to before
migration.
Step3: NVE authenticates the VM for a specific VN. After VM passed
the VN authentication, NVE then auto-configure itself to generate
related VN context.
Step4: NVE flood the VN update information to all other related VN
nodes, e.g. NVE.
Step5 6: The destination NVE supports to synchronize with source NVE
and corresponding NVE for VM migration and gets the point at which
the destination VM and source VM synchronization has been
achieved.The synchronization may be attained by other mechanism, not
shown in these steps.
Step7: Source VM stops running.
Gu, et al. Expires February 22, 2016 [Page 11]
Internet-Draft NVE Auto-Discovery Protocol August 2015
Step8: Destination VM starts to run.
Step9: Destination NVE flood the update message as the active NVE to
instead the source NVE.
Authors' Addresses
Zhongyu Gu
ZTE
50 Software Ave. Nanjing, Jiangsu, China
Email: gu.zhongyu@zte.com.cn
Chongfeng Xie
China Telecom
No.118, Xizhimennei Street, Beijing, China
Email: xiechf@ctbri.com.cn
Vic Liu
China Mobile
32 Xuanwumen West Ave. Beijing, China
Email: liuzhiheng@chinamobile.com
Bhumip Khasnabish
ZTE (TX) Inc.
55 Madison Ave, Suite 302
Morristown, New Jersey 07960
USA
Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/
Gu, et al. Expires February 22, 2016 [Page 12]
