NVO3 Z. Gu Internet-Draft ZTE Intended status: Standards Track April 10, 2015 Expires: October 12, 2015 Virtual Network Transport Protocol (VNTP) draft-gu-nvo3-vntp-01 Abstract This document describes the overlay virtual network transport protocol (VNTP), which defines the interactions between NVE and NVA/ NVE and the relevant message to support virtual network implementation. 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 October 12, 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 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. Gu Expires October 12, 2015 [Page 1] Internet-Draft VNTP April 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 3. VNTP Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 4. VNTP Message Format . . . . . . . . . . . . . . . . . . . . . 3 4.1. VNTP Header format . . . . . . . . . . . . . . . . . . . 4 4.2. VNTP Data Format . . . . . . . . . . . . . . . . . . . . 6 5. The Operations of NVE . . . . . . . . . . . . . . . . . . . . 7 6. The operations of NVA . . . . . . . . . . . . . . . . . . . . 8 7. Interaction with TS/Hypervisor-NVE protocol . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA/IEEE Considerations . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative references . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction [RFC7364] and [RFC7365] describe the need and some characteristics of the interaction between NVE and NVA. [draft-ietf-nvo3-arch-03] has a more detailed architectural description about NVE-NVA protocol. And [draft-ietf-nvo3-nve-nva-cp-req-03] discusses the detail requirements of NVE-NVA protocol. This draft defines a NVE-NVA protocol, virtual network transport protocol (VNTP). It belongs to the second model mentioned in [draft- ietf-nvo3-arch-03], e.g. NVE interacts with NVA directly. It defines the interactions between NVE and NVA/NVE and the relevant message formats to support virtual network implementation and fulfill the requirements described in the related documents mentioned above. VNTP can be based on a broad transport mechanism such as TCP or UDP, or even IP. A new TCP/UDP port or protocol number allocation is needed if the transport mechanism is decided. 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. VNTP Overview VNTP based on some basic assumptions and the main points include: Gu Expires October 12, 2015 [Page 2] Internet-Draft VNTP April 2015 1), the first-hand mapping information provided by NVE, either configured by administrator or automatically created. Architecturally, VNTP also support other mapping resources such as downloaded from NVA. 2), NVE registers to NVA per VN and NVA may store two lists of NVE, the first one is all NVEs in a VN and the other one is about all the VNs NVE resides. 3), when mapping change occurs in NVE, the NVE send update message to NVA to initiate the synchronization procedures and NVA then forward the update message to all other NVEs in the same VN. Optionally, NVA can store all the update information for latter use. 4), when a NVE register to a VN and some update messages received by NVA, the NVA may use the messages stored or request the related NVEs to send the update again to synchronize. 5), if NVA obtains the mapping information from other resources different from NVE, for example configured by administrator or from VM Orchestration, it sends the mapping/update information to all NVEs in the same VN. The VNTP procedures can be simplified to implement by point-to-point communication between NVE and NVA. So the NVE-NVA interaction can be based on a broad transport mechanism such as TCP, UDP or even IP. A new TCP/UDP port or protocol number allocation is needed if the transport mechanism is decided. 4. VNTP Message Format Figure 1 shows the VNTP message format. VNTP message format definition is based on some transport mechanism, such as TCP or UDP transport protocol, or even based on IP, and further using its data/ payload field. Gu Expires October 12, 2015 [Page 3] Internet-Draft VNTP April 2015 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 | Number | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NVE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DATA | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 4.1. VNTP Header format The following are the Header fields definition. Ver (8bit): for VNTP version. Type (8bit): for VNTP Type Command or result/response definition. Number (8bit): item/entry number of data field. AuType and Authentication(length TBD): for authentication type and packet authentication. Checksum (16bit): checksum of the whole VNTP packet except authentication field. Length (16bit): total packet octets including header. NVE Address(length variable according AdrType): source NVE address. Figure 2 shows detail type definition. Gu Expires October 12, 2015 [Page 4] Internet-Draft VNTP April 2015 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E/A|C/R| CMD/RSP | AdrType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 E/A (1bit): set to 1, NVE->NVA; set to 0, NVA->NVE. C/R (1bit): 1, CMD/RSP represents Command; 0, CMD/RSP represents Response/Result. Table 1 shows detail NVE Command definition ( C/R = 1, E/A = 1 ) . CMD Description 000 NVE registration 001 NVE deregistration 010 Update 011-111: Reserved for future use Table 2 shows detail NVA Command definition ( C/R = 1, E/A = 0 ) CMD Description 000 NVE Mapping information request 001 NVE Mapping nullification/NVE deregistration 010 (NVE initiated) update 011-111: Reserved for future use Table 3 shows detail NVA/NVE Response/Result (E/A = 0/1, C/R = 0) RSP Description 000 command executed successfully 001-011 Reserved for future definition 100 command execution failed Gu Expires October 12, 2015 [Page 5] Internet-Draft VNTP April 2015 101 command execution partially successful (Optional reasons ) 110-111 Reserved for future definition AdrType (3bit): NVE address type. Detail definition as following. AdrType Description 000 IPv4 001 IPv6 010-111 Reserved 4.2. VNTP Data Format VNTP Data field varies according to different command. For Register/ Deregister Command, the field contains one or multiple VN-ID, each entry for one VN-ID. For Update Command, it also may include some entries, each entry has the detail definition refers to Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Op | R | AT | VN-ID/NVE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping/Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 The field means as following. Op (3bit): for Operation Code. Table 4 shows the detail Op field definition. Op Description 000 Update add 001 Update delete 010 Update set to migration status Gu Expires October 12, 2015 [Page 6] Internet-Draft VNTP April 2015 011 Update set to normal/non-migration status 100-111 Reserved for future use AT (3bit): for Address Type. Table 5 shows the detail AT field definition. AT Description 000 IPv4 001 IPv6 010 MAC 011-111 Reserved R (2bit): for Reserved. NVE Address/VN-ID (length variable according AT): the outer address of mapping. If VN-ID is used the NVE or NVA can refer to the related NVE address. Mapping/Address (length variable according AT): each/inner Address needs updating. 5. The Operations of NVE In the context of VNTP, the NVE works include: 1), If a VNI is created, the NVE will send Register command to NVA to register the VNI/NVE in the VN. 2), If a VNI is being deleted, the NVE will send update information to NVA to inform all the NVE related VN entry will be invalid. Or the NVA gets this information through the keep alive message, then nullify the all entries from this NVE_s VN. 3), If entries in the NVE have changed, for example, a new entry added or an existing entry deleted or become invalid, then the NVE will send update information to the NVA. Individual or batch update are supported. 4), And further, NVE also support tenant system migration. Gu Expires October 12, 2015 [Page 7] Internet-Draft VNTP April 2015 5), The NVE accepts the updates from NVA and update the VRF table. The commands may be individual update or updates resulted from NVE failure. 6), Keep alive. Monitor the connection between NVE and NVA. 7), if the command not properly executed retransfer the command again for pre-setting times. 8), When NVA is unavailable or the NVA connection lost, optionally the NVE can connect other NVEs in the VN directly to keep the VN synchronized. 9), Security functions. TBD. 6. The operations of NVA 1), VNI creation 2), Form list of NVEs in the VN based on NVE Registration. 3), Accept updates from NVE and forward these updates to all other NVEs in the VN. Optionally, NVA store the update information for late use. 4), If NVE not register but update accepted, NVA may register it and forward the update to other NVEs. 5), if NVE registering after some updates then NVA will forward the stored updates to this NVE. Or NVA send request message to all other registered NVE for update if the previous updates not stored in NVA. And the NVA controls the updates only to this NVE other than all registered NVEs in the VN. 6), Keep alive. Monitor the connection between NVE and NVA. 7), if the command not properly executed NVA can retransfer the command again for pre-setting times. 8), When NVE in the VN is unavailable or the NVE connection lost, optionally the NVA can flood this NVE unreachable information to all other NVEs in the VN to keep the VN synchronized. 9), VNI delete. If there are not any VM or NVE in the VN, or the customer does not need the VN anymore then the NVA delete the VNI and release all the resources occupied by this VN. 10), Security functions. TBD. Gu Expires October 12, 2015 [Page 8] Internet-Draft VNTP April 2015 7. Interaction with TS/Hypervisor-NVE protocol Generally, VNTP can run independent of TS/Hypervisor-NVE protocol, but the interaction triggered by VRF changes because of the operation of TS/Hypervisor-NVE protocol . If the direct interaction is needed for further study. 8. Security Considerations VNTP should support NVE and NVA mutual authentication and other security functions. The authentication has been covered by this draft, and the further security functions can be support through VNTP's command reservations. 9. IANA/IEEE Considerations VNTP needs a specific IP protocol value, or TCP/UDP port allocation if the transport mechanism is chosen. 10. References 10.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. 10.2. Informative References [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, October 2014. Author's Address Zhongyu Gu ZTE 50 Software Ave. Nanjing, Jiangsu, China Email: gu.zhongyu@zte.com.cn Gu Expires October 12, 2015 [Page 9]