NVO3 Working Group Z. Qiang
Internet Draft Ericsson
Intended status: Informational October 27, 2014
Expires: April 2015
Data Plane Signaling in NVO3
draft-zu-nvo3-user-plane-signalling-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 27, 2015.
Z. Qiang Expires April 27, 2015 [Page 1]
Internet-Draft Data Plane Handling in NVO3 October 2014
Copyright Notice
Copyright (c) 2014 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.
Abstract
This draft discusses the considerations on user plane signaling and
data handling in NVO3 architecture and several related issues which
need to be considered when designing a NVO3 based virtualized data
center network for multiple tenants.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Terminology....................................................3
4. Data Forwarding................................................3
5. STP/RSTP/MSTP..................................................4
6. LACP...........................................................5
7. ARP and Neighbor Discovery.....................................5
8. Routing protocol...............................................6
9. Security Considerations........................................8
10. IANA Considerations...........................................8
11. References....................................................8
11.1. Normative References.....................................8
11.2. Informative References...................................8
12. Acknowledgments...............................................9
Z. Qiang Expires April 27, 2015 [Page 2]
Internet-Draft Data Plane Handling in NVO3 October 2014
1. Introduction
A high-level overview of a possible architecture for building NVO3
overlay networks has been present in [nvo3-arch]. The corresponding
control plane requirements has documented in [hypervisor-nve-cp] and
[nve-nva-cp-req].
User plane signaling is referring to the Layer 2 Control Protocol
(L2CP) specified in IEEE802.1 and Layer 3 Control Protocol (L3CP)
specified in IETF.
This document is providing some considerations on how the user plane
signaling shall be handled by NVE. And several related issues are
discussed.
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terminology
This document uses the same terminology as found in the NVO3
Framework document [framework] and [hypervisor-nve-cp].
4. Data Forwarding
In NVO3, a L2 NVE implements Ethernet LAN emulation, an Ethernet
based multipoint service similar to an IETF VPLS [RFC4761] [RFC4762]
or EVPN [EVPN] service. It forwards the multicast and unicast L2
traffic between the TSs. From the Tenant Systems aspect, the NVE is
just like a L2 bridge as specified in IEEE 802.1Q [IEEE 802.1Q].
A L3 NVE provides Virtualized IP forwarding service, similar to IETF
IP VPN, e.g. BGP/MPLS IPVPN [RFC4364]. An L3 NVE provides inter-
subnet layer 3 switching/routing for the TS. The NVE is the first hop
or next hop router to the attached TS.
In NVO3, it is very common to provide both L2 and L3 service to a TS.
In logic view, the TS is attached to a NVE which provides both L2 and
L3 function. In implementation, the L2 NVE function and L3 NVE
function may be collocated. The L2 NVE function provides intra-subnet
Z. Qiang Expires April 27, 2015 [Page 3]
Internet-Draft Data Plane Handling in NVO3 October 2014
traffic forwarding. The L3 NVE function provides inter-subnet traffic
forwarding.
In NVO3, to avoid flooding issues, the inner-outer address mapping
table is built using the NVA-NVE control signaling [nve-nva-cp-req].
Both L2 and L3 data forwarding are based on the inner-outer address
mapping table lookup (and forwarding policies).
The data forwarding procedure is similar for both L2 NVE and L3 NVE.
Upon receiving a unicast packet from the TS, the NVE performs a
lookup in the inner-outer address mapping table using the received
destination IP/MAC address. If a mapping is found, the received
packet will be encapsulated and forwarded to the destination NVE. If
no mapping is found, the received unknown unicast packet should be
dropped. As an alternative, the inner-outer address mapping table
updating procedure may be triggered using the NVA-NVE control
signaling [nve-nva-cp-req]. However, an attacker may generate large
amount of unknown unicast packets from a compromised VM, which may
result a denial of service (DOS) attacks. Therefore for security
reason, the inner-outer address mapping table updating procedure
shall not be triggered too often. One easy way to avoid this kind
security issue is to implement user plane filtering function.
Discussions: Some kind user plane filtering functions need to be
supported in the NVE for security reason.
5. STP/RSTP/MSTP
For a L2 NVE, the VAP is an emulation of a physical Ethernet port. It
shall have the capability to handle any L2CP. The Spanning Tree
Protocol (STP) is a L2 protocol that ensures a loop-free topology for
any bridged Ethernet local area network. STP is originally
standardized as IEEE 802.1D. It is deprecated as of 802.1d-2004 in
favor of Rapid Spanning Tree Protocol (RSTP). The Multiple Spanning
Tree Protocol (MSTP) defines an extension to RSTP to further develop
the usefulness of VLANs.
In NVO3 network, the looping of the L2 connections among the NVEs can
be avoided by correctly configuring the NVE inner-outer address
mapping table. There is no need to use any L2CP for that purpose
among the participated NVEs of a TS. However, STP/RSTP/MSTP may be
used by the TS, including multi-homing case.
In NVO3 network, the NVE does not need to propagate any STP messages
to the remote NVEs. But, the NVE may need to learn the Root Bridge
MAC address and Bridge Priority of the root of the Internal Spanning
Tree (IST) of the attached layer 2 segment by listening to the BPDUs.
Z. Qiang Expires April 27, 2015 [Page 4]
Internet-Draft Data Plane Handling in NVO3 October 2014
Discussions: The NVE does not need to forward the message. But it may
need to participate it. Once there is updating of Internal Spanning
Tree, NVA-NVE control signaling may be triggered for address mapping
table updates.
6. LACP
Link Aggregation [IEEE 802.1AXbk-2012] is a mechanism for making
multiple point-to-point links between a pair of devices appear to be
a single logical link between those devices.
A L2 NVE does not have to be involved in the Link Aggregation
procedure. It only needs to encapsulate and forward any Link
Aggregation Control Protocol Data and data packets between the
participated TSs.
Discussions: The NVE does not need to be involved. But it may need to
forward the messages.
7. ARP and Neighbor Discovery
For an L2 service, it is not a must for NVE to support any special
processing of ARP [RFC0826] and IPv6 Neighbor Discovery (ND)
[RFC4861] in NVO3 architecture. However, as a performance
optimization, an NVE does not need to propagate the ARP or ND
messages. It can intercept ARP or ND requests from its attached TSs
and respond based on the information configured in the inner-outer
address mapping table.
Discussions: The NVE does not need to forward the ARP or ND messages.
But it may need to response to the received messages based on the
inner-outer address mapping table.
Upon receiving ARP or ND request from a TS, the NVE sends the ARP or
ND response with the requested MAC address back. The NVE may perform
ARP or ND proxy when responding the ARP or ND request. If the NVE
does not have the interested MAC information in the receiving ARP or
ND request, it may query the NVA using the NVA-NVE control signaling
[nve-nva-cp-req]. However, an attacker may generate large amount of
ARP / ND request packets from a compromised VM, which may result a
denial of service (DOS) attacks. Therefore for security reason, the
inner-outer address mapping table updating procedure shall not be
triggered too often. One easy way to avoid this kind security issue
is to implement user plane filtering function.
Discussions: The NVE shall have some kind ARP and/or ND filtering
functions installed for security reason.
Z. Qiang Expires April 27, 2015 [Page 5]
Internet-Draft Data Plane Handling in NVO3 October 2014
In multi-homing case, a TS may be attached to more than one NVE and
it is possible for the TS to reach a remote TS via multiple NVEs. In
this case, it may be racing issue if all NVEs support ARP and ND
proxy function. One alternative is to select a primary NVE by using
control signaling.
Discussions: The NVA may need to select one primary NVE per network
segment of a TS to avoid the racing issue at multi-homing case.
At VM mobility, a VM may be moved from one layer-2 segment to another
layer-2 segment, assuming IP address preservation is supported. To
optimize the ARP updating procedure, the source NVE and the target
NVE can have the same MAC address configured at the VAP where the TS
attached. However, the ARP updating cannot be avoided completely.
Discussions: The NVA may need a property way to configure the primary
NVEs with same MAC address on the VAP of the same VN at each network
segment.
8. Routing protocol
A routing protocol specifies how routers communicate with each other,
disseminating information that enables them to select routes between
any two nodes on a computer network.
In NVO3, there are different developments to support layer 3
services: centralized GW function, distributed GW function, or both.
If the L3 service is provided by a NVO3 Centralized Gateway function,
the user plane routing function and the NVO3 Centralized Gateway
functions appears as router adjacencies to each other. A routing
protocol may be used between the routers for overlay data plane. Any
user plane routing messages (e.g. routing updates message from a vR
function installed in a VM of the TS) will be handled by the NVO3
Centralized Gateway function. Once there is a routing rules
installation or updating, the NVO3 Centralized Gateway function may
update its routing distribution polices and forward data packets
accordingly. The user data packet will be forwarded by the attached
NVE to the NVO3 Centralized Gateway function. Then the NVO3
Centralized Gateway function will make the L3 routing decision that
either discarding the packet or tunneling it to the destination NVE
where the destination VM attached. In this case, the NVEs, both
source NVE and destination NVE, only need to support layer 2
functionalities.
If the L3 service is provided by the Distributed GW function embedded
in the L3NVE, this can be an issue for dynamic routing updates. All
Z. Qiang Expires April 27, 2015 [Page 6]
Internet-Draft Data Plane Handling in NVO3 October 2014
participated L3NVEs grouping together appears as next hop router to
the user plane routing functions, e.g. vR functions installed in a VM
of the TS. The Distributed GW function embedded in the L3NVE may need
to support one or more routing protocols (e.g. BGP/OSPF/RIP) to learn
any user plane routing rules installation or updating. This allows a
L3NVE and the attached TS router to learn the IP routes updates from
each other. However, as the user plane packet forwarding in the L3NVE
is based on the inner-outer address mapping table configured by NVA
using the NVA-NVE control protocol, any user plane routing updates
may trigger the inner-outer address mapping table updates
accordingly, not in the attached NVE, but in the remote NVEs. With
the NVO3 architecture specified in [nvo3-arch], it is an issue on how
this dynamic updates can be done.
Discussion: One alternative is to use the NVE-NVE interaction
signaling for peer NVE updates at the data plane routing updates. For
instance, the L3NVE may inform the peer NVEs with the received
routing updates information. However, in this case, should the peer
NVE update its inner-outer address mapping table without NVA's
involvements? This may be challenging the NVA's centralized control
role. And it may also cause some security violation concerns.
Another alternative is that the L3NVE shall not forward any routing
updates information to any peer NVEs to avoid flooding. Instead, it
shall always inform the NVA about any routing changes. Then the NVA
will use the NVA-NVE signaling for the inner-outer address mapping
table updating at the peer NVE. This alternative gives the
centralized GW function role to the NVA.
It is possible to have the L3 service provided by both a centralized
GW function and a few distributed GW functions in a NVO3 network. For
instance, the centralized GW function can be used to handle the user
plane routing installing and updating. And the distributed GW
functions can be used for data forwarding only. In this case, at any
user plane routing installing and updating, the centralized GW
function may update the routing policies (i.e. RIB), and notify the
distributed GW functions with the updated forwarding policies (i.e.
FIB).
Discussion: However, unless the NVA has the centralized GW function
role, this alternative is also violating the NVO3 architecture
specified in [nvo3-arch], as the FIB is the inner-outer address
mapping table in the NVE.
Z. Qiang Expires April 27, 2015 [Page 7]
Internet-Draft Data Plane Handling in NVO3 October 2014
9. Security Considerations
This is a discussion paper which provides inputs for the NVO3
requirement documents and in itself does not introduce any new
security concerns.
10. IANA Considerations
No actions are required from IANA for this informational document.
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. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
11.2. Informative References
[overlay-problem-statement] Narten, T., Gray, E., Black, D., Fang,
L., Kreeger, L., and M. Napierala, "Problem Statement:
Overlays for Network Virtualization", draft-ietf-nvo3-
overlay-problem-statement-04 (work in progress), July 31,
2013.
[hypervisor-nve-cp] Li, Y., Yong L., Kreeger, L., Narten, T., and D.
Black, "Hypervisor to NVE Control Plane Requirements",
draft-ietf-nvo3-hpvr2nve-cp-req-00(work in progress), July
1, 2014.
[nvo3-framework] Lasserre, M., Balus, F., Morin, T., Bitar, N., and
Y. Rekhter, "Framework for DC Network Virtualization",
draft-ietf-nvo3-framework-09 (work in progress), July 4,
2014.
[nve-nva-cp-req] Kreeger, L., D. Dutt, T. Narten, D. Black, "Network
Virtualization NVE to NVA Control Protocol Requirements",
draft-ietf-nvo3-nve-nva-cp-req-02 (work in progress), April
24, 2014
[nvo3-arch] D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten,
"An Architecture for Overlay Networks (NVO3)", draft-ietf-
nvo3-arch-01(work in progress), February 14, 2014
Z. Qiang Expires April 27, 2015 [Page 8]
Internet-Draft Data Plane Handling in NVO3 October 2014
[IEEE 802.1Q] "Virtual Bridged Local Area Networks", 2005
[EVPN] Sajassi, A. et al, "BGP MPLS Based Ethernet VPN", draft-
ietf-l2vpn-evpn (work in progress)
[RFC4761] Kompella, K. et al, "Virtual Private LAN Service (VPLS)
Using BGP for auto-discovery and Signaling", RFC4761,
January 2007
[RFC4762] Lasserre, M. et al, "Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling",
RFC4762, January 2007
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
12. Acknowledgments
Many people have contributed to the development of this document and
many more will probably do so before we are done with it. While we
cannot thank all contributors, some have played an especially
prominent role. The following have provided essential input: Suresh
Krishnan.
Authors' Addresses
Zu Qiang
Ericsson
8400, boul. Decarie
Ville Mont-Royal, QC,
Canada
Email: Zu.Qiang@Ericsson.com
Z. Qiang Expires April 27, 2015 [Page 9]