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]