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, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . 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, . 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]