draft-ietf-nvo3-dataplane-requirements-00.txt   draft-ietf-nvo3-dataplane-requirements-01.txt 
Internet Engineering Task Force Nabil Bitar Internet Engineering Task Force Nabil Bitar
Internet Draft Verizon Internet Draft Verizon
Intended status: Informational Intended status: Informational
Expires: June 2013 Marc Lasserre Expires: January 2014 Marc Lasserre
Florin Balus Florin Balus
Alcatel-Lucent Alcatel-Lucent
Thomas Morin Thomas Morin
France Telecom Orange France Telecom Orange
Lizhong Jin Lizhong Jin
Bhumip Khasnabish Bhumip Khasnabish
ZTE ZTE
December 13, 2012 July 1, 2013
NVO3 Data Plane Requirements NVO3 Data Plane Requirements
draft-ietf-nvo3-dataplane-requirements-00.txt draft-ietf-nvo3-dataplane-requirements-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2013. This Internet-Draft will expire on January 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 21 skipping to change at page 2, line 24
Abstract Abstract
Several IETF drafts relate to the use of overlay networks to support Several IETF drafts relate to the use of overlay networks to support
large scale virtual data centers. This draft provides a list of data large scale virtual data centers. This draft provides a list of data
plane requirements for Network Virtualization over L3 (NVO3) that plane requirements for Network Virtualization over L3 (NVO3) that
have to be addressed in solutions documents. have to be addressed in solutions documents.
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction................................................3
1.1. Conventions used in this document.......................3 1.1. Conventions used in this document.......................3
1.2. General terminology.....................................3 1.2. General terminology.....................................3
2. Data Path Overview...........................................3 2. Data Path Overview..........................................4
3. Data Plane Requirements......................................5 3. Data Plane Requirements......................................5
3.1. Virtual Access Points (VAPs)............................5 3.1. Virtual Access Points (VAPs)............................5
3.2. Virtual Network Instance (VNI)..........................5 3.2. Virtual Network Instance (VNI)..........................5
3.2.1. L2 VNI................................................5 3.2.1. L2 VNI...............................................5
3.2.2. L3 VNI................................................6 3.2.2. L3 VNI...............................................6
3.3. Overlay Module..........................................7 3.3. Overlay Module.........................................7
3.3.1. NVO3 overlay header...................................8 3.3.1. NVO3 overlay header...................................8
3.3.1.1. Virtual Network Context Identification..............8 3.3.1.1. Virtual Network Context Identification..............8
3.3.1.2. Service QoS identifier..............................8 3.3.1.2. Service QoS identifier..............................8
3.3.2. Tunneling function....................................9 3.3.2. Tunneling function....................................9
3.3.2.1. LAG and ECMP........................................9 3.3.2.1. LAG and ECMP.......................................10
3.3.2.2. DiffServ and ECN marking...........................10 3.3.2.2. DiffServ and ECN marking...........................10
3.3.2.3. Handling of BUM traffic............................10 3.3.2.3. Handling of BUM traffic............................11
3.4. External NVO3 connectivity.............................11 3.4. External NVO3 connectivity.............................11
3.4.1. GW Types.............................................11 3.4.1. GW Types............................................12
3.4.1.1. VPN and Internet GWs...............................11 3.4.1.1. VPN and Internet GWs...............................12
3.4.1.2. Inter-DC GW........................................12 3.4.1.2. Inter-DC GW........................................12
3.4.1.3. Intra-DC gateways..................................12 3.4.1.3. Intra-DC gateways..................................12
3.4.2. Path optimality between NVEs and Gateways............12 3.4.2. Path optimality between NVEs and Gateways............12
3.4.2.1. Triangular Routing Issues (Traffic Tromboning).....13 3.4.2.1. Triangular Routing Issues (Traffic Tromboning)......13
3.5. Path MTU...............................................14 3.5. Path MTU..............................................14
3.6. Hierarchical NVE.......................................14 3.6. Hierarchical NVE.......................................15
3.7. NVE Multi-Homing Requirements..........................15 3.7. NVE Multi-Homing Requirements..........................15
3.8. OAM....................................................15 3.8. OAM...................................................16
3.9. Other considerations...................................16 3.9. Other considerations...................................16
3.9.1. Data Plane Optimizations.............................16 3.9.1. Data Plane Optimizations.............................16
3.9.2. NVE location trade-offs..............................16 3.9.2. NVE location trade-offs..............................17
4. Security Considerations.....................................17 4. Security Considerations.....................................17
5. IANA Considerations.........................................17 5. IANA Considerations........................................17
6. References..................................................17 6. References.................................................18
6.1. Normative References...................................17 6.1. Normative References...................................18
6.2. Informative References.................................17 6.2. Informative References.................................18
7. Acknowledgments.............................................18 7. Acknowledgments............................................19
1. Introduction 1. Introduction
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
skipping to change at page 3, line 40 skipping to change at page 4, line 5
1.2. General terminology 1.2. General terminology
The terminology defined in [NVO3-framework] is used throughout this The terminology defined in [NVO3-framework] is used throughout this
document. Terminology specific to this memo is defined here and is document. Terminology specific to this memo is defined here and is
introduced as needed in later sections. introduced as needed in later sections.
BUM: Broadcast, Unknown Unicast, Multicast traffic BUM: Broadcast, Unknown Unicast, Multicast traffic
TS: Tenant System TS: Tenant System
VAP: Virtual Access Point
2. Data Path Overview 2. Data Path Overview
The NVO3 framework [NVO3-framework] defines the generic NVE model The NVO3 framework [NVO3-framework] defines the generic NVE model
depicted in Figure 1: depicted in Figure 1:
+------- L3 Network ------+ +------- L3 Network ------+
| | | |
| Tunnel Overlay | | Tunnel Overlay |
+------------+---------+ +---------+------------+ +------------+---------+ +---------+------------+
| +----------+-------+ | | +---------+--------+ | | +----------+-------+ | | +---------+--------+ |
skipping to change at page 6, line 5 skipping to change at page 6, line 9
3.2.1. L2 VNI 3.2.1. L2 VNI
An L2 VNI MUST provide an emulated Ethernet multipoint service as if An L2 VNI MUST provide an emulated Ethernet multipoint service as if
Tenant Systems are interconnected by a bridge (but instead by using Tenant Systems are interconnected by a bridge (but instead by using
a set of NVO3 tunnels). The emulated bridge MAY be 802.1Q enabled a set of NVO3 tunnels). The emulated bridge MAY be 802.1Q enabled
(allowing use of VLAN tags as a VAP). An L2 VNI provides per tenant (allowing use of VLAN tags as a VAP). An L2 VNI provides per tenant
virtual switching instance with MAC addressing isolation and L3 virtual switching instance with MAC addressing isolation and L3
tunneling. Loop avoidance capability MUST be provided. tunneling. Loop avoidance capability MUST be provided.
Forwarding table entries provide mapping information between MAC Forwarding table entries provide mapping information between tenant
addresses and L3 tunnel destination addresses. Such entries MAY be system MAC addresses and VAPs on directly connected VNIs and L3
tunnel destination addresses over the overlay. Such entries MAY be
populated by a control or management plane, or via data plane. populated by a control or management plane, or via data plane.
In the absence of a management or control plane, data plane learning In the absence of a management or control plane, data plane learning
MUST be used to populate forwarding tables. As frames arrive from MUST be used to populate forwarding tables. As frames arrive from
VAPs or from overlay tunnels, standard MAC learning procedures are VAPs or from overlay tunnels, standard MAC learning procedures are
used: The source MAC address is learned against the VAP or the NVO3 used: The tenant system source MAC address is learned against the
tunnel on which the frame arrived. This implies that unknown unicast VAP or the NVO3 tunneling encapsulation source address on which the
traffic be flooded i.e. broadcast. frame arrived. This implies that unknown unicast traffic be flooded
i.e. broadcast.
When flooding is required, either to deliver unknown unicast, or When flooding is required, either to deliver unknown unicast, or
broadcast or multicast traffic, the NVE MUST either support ingress broadcast or multicast traffic, the NVE MUST either support ingress
replication or multicast. In this latter case, the NVE MUST be able replication or multicast. In this latter case, the NVE MUST have one
to build at least a default flooding tree per VNI. In such cases, or more multicast trees that can be used by local VNIs for flooding
multiple VNIs MAY share the same default flooding tree. The to NVEs belonging to the same VN. For each VNI, there is one
flooding tree is equivalent with a multicast (*,G) construct where flooding tree, and a multicast tree may be dedicated per VNI or
all the NVEs for which the corresponding VNI is instantiated are shared across VNIs. In such cases, multiple VNIs MAY share the same
members. The multicast tree MAY be established automatically via default flooding tree. The flooding tree is equivalent with a
routing and signaling or pre-provisioned. multicast (*,G) construct where all the NVEs for which the
corresponding VNI is instantiated are members. The multicast tree
MAY be established automatically via routing and signaling or pre-
provisioned.
When tenant multicast is supported, it SHOULD also be possible to When tenant multicast is supported, it SHOULD also be possible to
select whether the NVE provides optimized multicast trees inside the select whether the NVE provides optimized multicast trees inside the
VNI for individual tenant multicast groups or whether the default VNI for individual tenant multicast groups or whether the default
VNI flooding tree is used. If the former option is selected the VNI VNI flooding tree is used. If the former option is selected the VNI
SHOULD be able to snoop IGMP/MLD messages in order to efficiently SHOULD be able to snoop IGMP/MLD messages in order to efficiently
join/prune Tenant System from multicast trees. join/prune Tenant System from multicast trees.
3.2.2. L3 VNI 3.2.2. L3 VNI
skipping to change at page 7, line 28 skipping to change at page 7, line 38
are members, is used. are members, is used.
3.3. Overlay Module 3.3. Overlay Module
The overlay module performs a number of functions related to NVO3 The overlay module performs a number of functions related to NVO3
header and tunnel processing. header and tunnel processing.
The following figure shows a generic NVO3 encapsulated frame: The following figure shows a generic NVO3 encapsulated frame:
+--------------------------+ +--------------------------+
| Tenant Payload | | Tenant Frame |
+--------------------------+ +--------------------------+
| NVO3 Overlay Header | | NVO3 Overlay Header |
+--------------------------+ +--------------------------+
| Outer Underlay header | | Outer Underlay header |
+--------------------------+ +--------------------------+
| Outer Link layer header | | Outer Link layer header |
+--------------------------+ +--------------------------+
Figure 2 : NVO3 encapsulated frame Figure 2 : NVO3 encapsulated frame
where where
. Customer payload: Ethernet or IP based upon the VNI type . Tenant frame: Ethernet or IP based upon the VNI type
. NVO3 overlay header: Header containing VNI context information . NVO3 overlay header: Header containing VNI context information
and other optional fields that can be used for processing and other optional fields that can be used for processing
this packet. this packet.
. Outer underlay header: Can be either IP or MPLS . Outer underlay header: Can be either IP or MPLS
. Outer link layer header: Header specific to the physical . Outer link layer header: Header specific to the physical
transmission link used transmission link used
3.3.1. NVO3 overlay header 3.3.1. NVO3 overlay header
An NVO3 overlay header MUST be included after the underlay tunnel An NVO3 overlay header MUST be included after the underlay tunnel
header when forwarding tenant traffic. Note that this information header when forwarding tenant traffic. Note that this information
can be carried within existing protocol headers (when overloading of can be carried within existing protocol headers (when overloading of
specific fields is possible) or within a separate header. specific fields is possible) or within a separate header.
skipping to change at page 10, line 13 skipping to change at page 10, line 24
implementations of LAG and ECMP uses a hash of various fields in the implementations of LAG and ECMP uses a hash of various fields in the
encapsulation (outermost) header(s) (e.g. source and destination MAC encapsulation (outermost) header(s) (e.g. source and destination MAC
addresses for non-IP traffic, source and destination IP addresses, addresses for non-IP traffic, source and destination IP addresses,
L4 protocol, L4 source and destination port numbers, etc). L4 protocol, L4 source and destination port numbers, etc).
Furthermore, hardware deployed for the underlay network(s) will be Furthermore, hardware deployed for the underlay network(s) will be
most often unaware of the carried, innermost L2 frames or L3 packets most often unaware of the carried, innermost L2 frames or L3 packets
transmitted by the TS. Thus, in order to perform fine-grained load- transmitted by the TS. Thus, in order to perform fine-grained load-
balancing over LAG and ECMP paths in the underlying network, the balancing over LAG and ECMP paths in the underlying network, the
encapsulation MUST result in sufficient entropy to exercise all encapsulation MUST result in sufficient entropy to exercise all
paths through several LAG/ECMP hops. The entropy information MAY be paths through several LAG/ECMP hops. The entropy information MAY be
inferred from the NVO3 overlay header or underlay header. inferred from the NVO3 overlay header or underlay header. If the
overlay protocol does not support the necessary entropy information
or the switches/routers in the underlay do not support parsing of
the additional entropy information in the overlay header, underlay
switches and routers should be programmable, i.e. select the
appropriate fields in the underlay header for hash calculation based
on the type of overlay header.
All packets that belong to a specific flow MUST follow the same path All packets that belong to a specific flow MUST follow the same path
in order to prevent packet re-ordering. This is typically achieved in order to prevent packet re-ordering. This is typically achieved
by ensuring that the fields used for hashing are identical for a by ensuring that the fields used for hashing are identical for a
given flow. given flow.
All paths available to the overlay network SHOULD be used All paths available to the overlay network SHOULD be used
efficiently. Different flows SHOULD be distributed as evenly as efficiently. Different flows SHOULD be distributed as evenly as
possible across multiple underlay network paths. For instance, this possible across multiple underlay network paths. For instance, this
can be achieved by ensuring that some fields used for hashing are can be achieved by ensuring that some fields used for hashing are
skipping to change at page 11, line 50 skipping to change at page 12, line 20
3.4.1. GW Types 3.4.1. GW Types
3.4.1.1. VPN and Internet GWs 3.4.1.1. VPN and Internet GWs
Tenant sites may be already interconnected using one of the existing Tenant sites may be already interconnected using one of the existing
VPN services and technologies (VPLS or IP VPN). If a new NVO3 VPN services and technologies (VPLS or IP VPN). If a new NVO3
encapsulation is used, a VPN GW is required to forward traffic encapsulation is used, a VPN GW is required to forward traffic
between NVO3 and VPN domains. Translation of encapsulations MAY be between NVO3 and VPN domains. Translation of encapsulations MAY be
required. Internet connected Tenants require translation from NVO3 required. Internet connected Tenants require translation from NVO3
encapsulation to IP in the NVO3 gateway. The translation function encapsulation to IP in the NVO3 gateway. The translation function
SHOULD NOT require provisioning touches and SHOULD NOT use SHOULD minimize provisioning touches.
intermediate hand-offs, for example VLANs.
3.4.1.2. Inter-DC GW 3.4.1.2. Inter-DC GW
Inter-DC connectivity MAY be required to provide support for Inter-DC connectivity MAY be required to provide support for
features like disaster prevention or compute load re-distribution. features like disaster prevention or compute load re-distribution.
This MAY be provided via a set of gateways interconnected through a This MAY be provided via a set of gateways interconnected through a
WAN. This type of connectivity MAY be provided either through WAN. This type of connectivity MAY be provided either through
extension of the NVO3 tunneling domain or via VPN GWs. extension of the NVO3 tunneling domain or via VPN GWs.
3.4.1.3. Intra-DC gateways 3.4.1.3. Intra-DC gateways
skipping to change at page 19, line 28 skipping to change at page 19, line 41
Alcatel-Lucent Alcatel-Lucent
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA, USA 94043 Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com Email: florin.balus@alcatel-lucent.com
Thomas Morin Thomas Morin
France Telecom Orange France Telecom Orange
Email: thomas.morin@orange.com Email: thomas.morin@orange.com
Lizhong Jin Lizhong Jin
ZTE Email : lizho.jin@gmail.com
Email : lizhong.jin@zte.com.cn
Bhumip Khasnabish Bhumip Khasnabish
ZTE ZTE
Email : Bhumip.khasnabish@zteusa.com Email : Bhumip.khasnabish@zteusa.com
 End of changes. 26 change blocks. 
45 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/