NVO3 Z. Gu Internet-Draft T. Ao Intended status: Standards Track ZTE Expires: July 8, 2015 C. Xie China Telecom V. Liu China Mobile January 4, 2015 NVE Auto-Discovery Protocol draft-gu-nvo3-virt-edge-auto-discovery-01.txt Abstract NVO3 provides a framework for Network virtualization in data center, and it will include a series of protocols. This document describes the NVO3 NVE automatic discovery protocol, and shows how VN can be configured and how VM joins VN automatically. 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 July 8, 2015. Copyright Notice Copyright (c) 2015 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 Gu, et al. Expires July 8, 2015 [Page 1] Internet-Draft NVE Auto-Discovery Protocol January 2015 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 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA/IEEE Considerations . . . . . . . . . . . . . . . . . . 8 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative references . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. NVE auto-discovery protocol application: VM Migration . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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. 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. Gu, et al. Expires July 8, 2015 [Page 2] Internet-Draft NVE Auto-Discovery Protocol January 2015 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 The following packet formats are defined here. 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 July 8, 2015 [Page 3] Internet-Draft NVE Auto-Discovery Protocol January 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 July 8, 2015 [Page 4] Internet-Draft NVE Auto-Discovery Protocol January 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. 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 July 8, 2015 [Page 5] Internet-Draft NVE Auto-Discovery Protocol January 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 July 8, 2015 [Page 6] Internet-Draft NVE Auto-Discovery Protocol January 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 July 8, 2015 [Page 7] Internet-Draft NVE Auto-Discovery Protocol January 2015 5.5. NVE auto-discovery Termination (NADT) packet This packet may be sent anytime after a 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] 7. Security Considerations TBD 8. IANA/IEEE Considerations Should IEEE allocated types of new Ethernet-type frame. And IETF should allocate some types of packet encapsulation. Gu, et al. Expires July 8, 2015 [Page 8] Internet-Draft NVE Auto-Discovery Protocol January 2015 9. 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. 10. Acknowledgments The basic idea comes from PPPoE. And copious amounts of text have been stolen from RFC 2516. 11. References 11.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 11.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, 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 July 8, 2015 [Page 9] Internet-Draft NVE Auto-Discovery Protocol January 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 July 8, 2015 [Page 10] Internet-Draft NVE Auto-Discovery Protocol January 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 Ting Ao ZTE 50 Software Ave. Nanjing, Jiangsu, China Email: ao.ting@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 Gu, et al. Expires July 8, 2015 [Page 11]