Internet DRAFT - draft-kj-nvo3-encapsulation-reqt

draft-kj-nvo3-encapsulation-reqt






Network Working Group                                             L. Jin
Internet-Draft                                                       ZTE
Intended status: Informational                             B. Khasnabish
Expires: March 29, 2013                                          ZTE USA
                                                            Sep 25, 2012


      Encapsulation Requirement of Network Virtualization Overlay
                draft-kj-nvo3-encapsulation-reqt-00.txt

Abstract

   This document discusses NVO3 data plane encapsulation requirements.

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 March 29, 2013.

Copyright Notice

   Copyright (c) 2012 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.






Jin & Khasnabish         Expires March 29, 2013                 [Page 1]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  List of Acronyms  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  General Requirement . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Protocol Layers and Encapsulation Requirement . . . . . . . . . 3
     4.1.  Encapsulation Layer Requirement . . . . . . . . . . . . . . 4
     4.2.  Tenant Network Identifier Layer Requirements  . . . . . . . 5
     4.3.  PSN Layer Requirements  . . . . . . . . . . . . . . . . . . 6
     4.4.  PSN Layer Association Requirements  . . . . . . . . . . . . 6
   5.  Forwarding Behavior Requirements  . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8





































Jin & Khasnabish         Expires March 29, 2013                 [Page 2]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


1.  Introduction

   This document specifies the encapsulation requirement of the NVO3
   data plane: the protocol layer concerned with the encapsulation and
   forwarding behavior requirements.  There is an initial such kind of
   effort discussed in [I-D.kj-nvo3-pion-architecture], most of the
   contents in this draft are inherited from
   [I-D.kj-nvo3-pion-architecture] and are further discussed here.


2.  List of Acronyms

   PSN: Packet Switched Network

   ECMP: Equal Cost Multi-Path

   NVE: Network Virtualization Edge

   LAN: Local Area Network

   VLAN: Virtual LAN


3.  General Requirement

   It is suggested that only one type of data plane be standardized for
   both Layer-2 and Layer-3 Network Virtualization.

   The NVO3 provides a virtualized overlay network that MUST be
   independent of the underlying PSN.  The PSN in this draft refers to
   IP or MPLS network.  That means that the overlay network could work
   on any underlying PSN layer, and can reuse the capability of the
   underlying layer.

   The packet transport capabilities provided by NVO3 are inherited from
   the capability of the underlying PSN.  Enabling overlay network to be
   independent of underlying PSN allows NVO3 to be benefitted from
   different kinds of underlying PSN capabilities, e.g., bandwidth and
   QoS assurance, multicast, traffic engineering, security and other
   capabilities.


4.  Protocol Layers and Encapsulation Requirement

   The NVO3 data packet SHOULD consist of the following layers:

      1.  Customer payload layer: the customer payload in datacenter
      would be an Ethernet payload, but here it does not preclude the



Jin & Khasnabish         Expires March 29, 2013                 [Page 3]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


      other type of payload, e.g., IP payload.

      2.  Encapsulation layer: it provides packet transport with some
      NVO3 specific capabilities that other layers could not provide.

      3.  Tenant Network Identifier (TNI) layer: it provides customer
      traffic and address isolation among different tenants.  Different
      customer address domain MUST have different TNI value.

      4.  Underlying network PSN layer: it provides physical network
      transport for the virtualized network in datacenter, and is
      maximally reused from IETF-defined protocols.

      5.  Data-Link and physical layer are out of the scope of this
      document.

   One example of the NVO3 protocol layering model could be as shown
   below:


       +-------------------------------------------+
       |                Customer Payload           |
       |                      ~~~                  |
       /===========================================\
       H           Tenant Network Identifier       H
       H-------------------------------------------H
       H                 Encapsulation             H
       \===========================================/
       |                  PSN Layer                |
       +-------------------------------------------+
       |                  Data-Link                |
       +-------------------------------------------+
       |                Physical Layer             |
       +-------------------------------------------+

                                 Figure 1

4.1.  Encapsulation Layer Requirement

   There are several functions/services that the encapsulation layer
   should provide.  This draft lists the following functions/services:

      a.  Customer payload indication to indicate different type of
      customer payloads.

      b.  Packet sequencing and fragmentation capability.





Jin & Khasnabish         Expires March 29, 2013                 [Page 4]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


      c.  Flow entropy value to add flow based entropy, and tag all the
      packets from a flow with an entropy label, e.g., MPLS label, and
      ECMP tag.

   An "indicator" value in encapsulation layer could be provided to
   indicate the customer payload type.  The purpose of this is to have
   one NVO3 data plane format for both Layer-2 and Layer-3 Network
   Virtualization.

   In order to obtain information about packet loss, the applications
   that use UDP transport requires transmitting packets with sequence
   number.  Some application requires lager packet transport in order to
   improve efficiency, and then packet fragmentation maybe required, and
   is preferred to be performed at hardware layer.  The encapsulation
   layer SHOULD have the capability to provide packet fragmentation
   information.  Some PSN connection used by NVO3 does not provide ECMP
   capability, e.g., GRE.  The encapsulation layer SHOULD provide such
   ECMP capability, by adding a flow entropy value to indicate flow
   based entropy, and it is required to tag all the packets from one
   flow with same entropy value.

   As the PSN layer with UDP encapsulation, the entropy value could be
   added to the UDP source port, and then the flow entropy value in
   encapsulation layer could be omitted.

   As the PSN layer with GRE tunnel, the flow entropy value in
   encapsulation layer should be added if ECMP per flow is required.

   As the PSN layer with TCP-like encapsulation [I-D.davie-stt], the
   sequencing and fragmentation could be provided by the IP layer, and
   then the sequencing and fragmentation capability in tenant header
   could be omitted.  The entropy value could be added to the TCP source
   port, and then the flow entropy value in encapsulation layer could be
   omitted.

   As the PSN layer with MPLS tunnel, the sequencing and fragmentation
   in tenant header would be applied if required.  The entropy value
   could be added to the MPLS flow label, and then the flow entropy
   value in encapsulation layer could be omitted.

4.2.  Tenant Network Identifier Layer Requirements

   The tenant network identifier (TNI) SHOULD be an integer to indicate
   the membership of each customer packet.  One example is to use an
   global integer number, like VLAN tag/ID.  For example, in datacenters
   the use of explicit tenant ID will simplify the interoperations in
   the inter-datacenter communications.  By whatever control plane TNI
   has been allocated, static configuration or dynamic allocation, the



Jin & Khasnabish         Expires March 29, 2013                 [Page 5]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


   overlay network with different control plane could be always
   interoperable with same TNI.  That would be particular useful when
   interconnecting two datacenter with different control plane, the
   operator only needs to ensure the same TNI (or by TNI translation) to
   interoperate.

4.3.  PSN Layer Requirements

   The PSN layer MUST provide some value to indicate the tenant payload
   type, so as to parse the packet format following PSN layer.

   The PSN Layer for NVO3 SHOULD be any type of PSN connection that has
   capability to transmit tenant packets.  There SHOULD be generally two
   kinds of PSN connection that could be provided, IP and MPLS.

   The ECMP transport capability of PSN layer SHOULD be able to hash the
   traffic per flow per tenant.

4.4.  PSN Layer Association Requirements

   It SHOULD be the function of NVE to associate the tenant traffic with
   PSN connection to one peer NVE, which could be done by configuration
   or other implementation specific way.  Different type of PSN
   connections SHOULD be allowed to use between different NVEs within
   one tenant.

   The NVE SHOULD have the capability to setup the specified PSN
   connection if required.  For example, if only IP connection required
   between or among NVEs, IP connection setup capability is required for
   NVEs.  If one NVE requires BW guarantee connection to peer NVE which
   is located in another datacenter across WAN, the NVE should be able
   to setup hierarchical MPLS LSP and specify the bandwidth required.


5.  Forwarding Behavior Requirements

   The tenant forwarding table entry MUST contain destination MAC
   address for Layer2 network virtualization, or with destination IP
   address for Layer3 network virtualization, and PSN tunnel
   information.

   When an NVE receives packets from host/virtual machine, it MUST have
   at least following information: the tenant membership the packet
   belongs to, the network virtualization type (Layer2 or Layer3).  The
   NVE MUST lookup the tenant forwarding table to forward the packet
   with destination MAC address for Layer2 network virtualization, or
   with destination IP address for Layer3 network virtualization.




Jin & Khasnabish         Expires March 29, 2013                 [Page 6]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


   Additionally, NVE SHOULD determine the encapsulation header:

      a) If fragmentation required, packet fragmentation or reassembling
      SHOULD be supported;

      b) If sequencing required, packet sequencing SHOULD be supported;

      c) If entropy value provided, packet ECMP SHOULD be supported with
      this entropy value.

   Then the Ethernet packet for Layer2 network virtualization, or IP
   packet for Layer3 network virtualization MUST be sent with tenant
   network identifier, encapsulation layer and PSN tunnel encapsulated
   to remote NVE.

   When an NVE receives packets from another remote NVE, the PSN tunnel
   MUST be terminated and it will strip the PSN header, and SHOULD be
   able to parse the format of tenant header.  NVE SHOULD examine the
   encapsulation header to determine:

      a) Whether the packet is Ethernet packet for Layer2 network
      virtualization, or IP packet for Layer3 network virtualization;

      b) If fragmentation required, packet fragmentation or reassembling
      SHOULD be supported;

      c) If sequencing required, packet sequencing SHOULD be supported;

      d) If entropy value provided, packet ECMP SHOULD be supported with
      this entropy value.

   NVE MUST strip encapsulation layer and tenant network identifier to
   get customer packet.  The tenant forwarding table should be indexed
   by the TNI contained in Tenant Network Identifier Layer.  NVE MUST
   forward the customer packets by looking up the tenant forwarding
   table:

      a) If Layer2 packet type is indicated in the encapsulation header,
      customer payload should be parsed with standard Ethernet format.
      The customer payload!_s destination MAC address MUST be used to
      lookup tenant forwarding table.

      b) If Layer3 packet type is indicated in the encapsulation header,
      customer payload should be parsed with IP payload format.  The
      customer payload!_s destination IP address MUST be used to lookup
      tenant forwarding table.





Jin & Khasnabish         Expires March 29, 2013                 [Page 7]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


6.  Acknowledgments

   Will be added in future.


7.  Informative References

   [I-D.davie-stt]
              Davie, B. and J. Gross, "A Stateless Transport Tunneling
              Protocol for Network Virtualization (STT)",
              draft-davie-stt-02 (work in progress), September 2012.

   [I-D.kj-nvo3-pion-architecture]
              Jin, L. and B. Khasnabish, "Architecture of PSN
              Independent Overlay Network(PION)",
              draft-kj-nvo3-pion-architecture-00 (work in progress),
              May 2012.

   [I-D.mahalingam-dutt-dcops-vxlan]
              Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
              Framework for Overlaying Virtualized Layer 2 Networks over
              Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02
              (work in progress), August 2012.

   [I-D.sridharan-virtualization-nvgre]
              Sridhavan, M., Greenberg, A., Venkataramaiah, N., Wang,
              Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P.,
              and C. Tumuluri, "NVGRE: Network Virtualization using
              Generic Routing Encapsulation",
              draft-sridharan-virtualization-nvgre-01 (work in
              progress), July 2012.


Authors' Addresses

   Lizhong Jin
   ZTE
   889, Bibo Road
   Shanghai, 201203, China

   Email: lizhong.jin@zte.com.cn, lizho.jin@gmail.com









Jin & Khasnabish         Expires March 29, 2013                 [Page 8]

Internet-Draft     draft-kj-nvo3-encapsulation-reqt-00          Sep 2012


   Bhumip Khasnabish
   ZTE USA, Inc.
   55 Madison Avenue, Suite 160
   Morristown, NJ 07960 USA

   Email: bhumip.khasnabish@zteusa.com, vumip1@gmail.com













































Jin & Khasnabish         Expires March 29, 2013                 [Page 9]