RFC 7364: Problem Statement: Overlays for Network Virtualization
Internet Engineering Task Force (IETF) T. Narten, Ed.
Request for Comments: 7364 IBM
Category: Informational E. Gray, Ed.
ISSN: 2070-1721 Ericsson
D. Black
EMC
L. Fang
Microsoft
L. Kreeger
Cisco
M. Napierala
AT&T
October 2014
Problem Statement: Overlays for Network Virtualization
Abstract
This document describes issues associated with providing multi-
tenancy in large data center networks and how these issues may be
addressed using an overlay-based network virtualization approach. A
key multi-tenancy requirement is traffic isolation so that one
tenant's traffic is not visible to any other tenant. Another
requirement is address space isolation so that different tenants can
use the same address space within different virtual networks.
Traffic and address space isolation is achieved by assigning one or
more virtual networks to each tenant, where traffic within a virtual
network can only cross into another virtual network in a controlled
fashion (e.g., via a configured router and/or a security gateway).
Additional functionality is required to provision virtual networks,
associating a virtual machine's network interface(s) with the
appropriate virtual network and maintaining that association as the
virtual machine is activated, migrated, and/or deactivated. Use of
an overlay-based approach enables scalable deployment on large
network infrastructures.
Narten, et al. Informational [Page 1]
RFC 7364 Overlays for Network Virtualization October 2014Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7364. 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.Narten, et al. Informational [Page 2]
RFC 7364 Overlays for Network Virtualization October 20141. Introduction ....................................................4 2. Terminology .....................................................6 3. Problem Areas ...................................................6 3.1. Need for Dynamic Provisioning ..............................6 3.2. Virtual Machine Mobility Limitations .......................7 3.3. Inadequate Forwarding Table Sizes ..........................7 3.4. Need to Decouple Logical and Physical Configuration ........7 3.5. Need for Address Separation between Virtual Networks .......8 3.6. Need for Address Separation between Virtual Networks and ...8 3.7. Optimal Forwarding .........................................9 4. Using Network Overlays to Provide Virtual Networks .............10 4.1. Overview of Network Overlays ..............................10 4.2. Communication between Virtual and Non-virtualized Networks ..................................................12 4.3. Communication between Virtual Networks ....................12 4.4. Overlay Design Characteristics ............................13 4.5. Control-Plane Overlay Networking Work Areas ...............14 4.6. Data-Plane Work Areas .....................................15 5. Related IETF and IEEE Work .....................................15 5.1. BGP/MPLS IP VPNs ..........................................16 5.2. BGP/MPLS Ethernet VPNs ....................................16 5.3. 802.1 VLANs ...............................................17 5.4. IEEE 802.1aq -- Shortest Path Bridging ....................17 5.5. VDP .......................................................17 5.6. ARMD ......................................................18 5.7. TRILL .....................................................18 5.8. L2VPNs ....................................................18 5.9. Proxy Mobile IP ...........................................19 5.10. LISP .....................................................19 6. Summary ........................................................19 7. Security Considerations ........................................19 8. References .....................................................20 8.1. Normative Reference .......................................20 8.2. Informative References ....................................20 Acknowledgments ...................................................22 Contributors ......................................................22 Authors' Addresses ................................................23Narten, et al. Informational [Page 3]
RFC 7364 Overlays for Network Virtualization October 20141 . IntroductionNarten, et al. Informational [Page 4]
RFC 7364 Overlays for Network Virtualization October 20142 . TerminologyRFC7365]. In addition, this document use the following terms. Overlay Network: A virtual network in which the separation of tenants is hidden from the underlying physical infrastructure. That is, the underlying transport network does not need to know about tenancy separation to correctly forward traffic. IEEE 802.1 Provider Backbone Bridging (PBB) [IEEE-802.1Q] is an example of an L2 overlay network. PBB uses MAC-in-MAC encapsulation (where "MAC" refers to "Media Access Control"), and the underlying transport network forwards traffic using only the Backbone MAC (B-MAC) and Backbone VLAN Identifier (B-VID) in the outer header. The underlay transport network is unaware of the tenancy separation provided by, for example, a 24-bit Backbone Service Instance Identifier (I-SID). C-VLAN: This document refers to Customer VLANs (C-VLANs) as implemented by many routers, i.e., an L2 virtual network identified by a Customer VLAN Identifier (C-VID). An end station (e.g., a VM) in this context that is part of an L2 virtual network will effectively belong to a C-VLAN. Within an IEEE 802.1Q-2011 network, other tags may be used as well, but such usage is generally not visible to the end station. Section 5.3 provides more details on VLANs defined by [IEEE-802.1Q]. This document uses the phrase "virtual network instance" with its ordinary meaning to represent an instance of a virtual network. Its usage may differ from the "VNI" acronym defined in the framework document [RFC7365]. The "VNI" acronym is not used in this document. 3 . Problem Areas3.1 . Need for Dynamic ProvisioningNarten, et al. Informational [Page 6]
RFC 7364 Overlays for Network Virtualization October 20143.2 . Virtual Machine Mobility Limitations3.3 . Inadequate Forwarding Table Sizes3.4 . Need to Decouple Logical and Physical ConfigurationNarten, et al. Informational [Page 7]
RFC 7364 Overlays for Network Virtualization October 20143.5 . Need for Address Separation between Virtual Networks3.6 . Need for Address Separation between Virtual Networks andInfrastructure
As in the previous case, a tenant needs to be able to use whatever addresses it wants in a virtual network independent of what addresses the underlying data center network is using. Tenants (and the underlay infrastructure provider) should be able use whatever addresses make sense for them without having to worry about address collisions between addresses used by tenants and those used by the underlay data center network.Narten, et al. Informational [Page 8]
RFC 7364 Overlays for Network Virtualization October 20143.7 . Optimal ForwardingNarten, et al. Informational [Page 9]
RFC 7364 Overlays for Network Virtualization October 20144 . Using Network Overlays to Provide Virtual Networks4.1 . Overview of Network OverlaysSection 3, a network overlay approach can be used. The idea behind an overlay is quite straightforward. Each virtual network instance is implemented as an overlay. The original packet is encapsulated by the first-hop network device, called a Network Virtualization Edge (NVE), and tunneled to a remote NVE. The encapsulation identifies the destination of the device that will perform the decapsulation (i.e., the egress NVE for the tunneled packet) before delivering the original packet to the endpoint. The rest of the network forwards the packet based on the encapsulation header and can be oblivious to the payload that is carried inside. Overlays are based on what is commonly known as a "map-and-encap" architecture. When processing and forwarding packets, three distinct and logically separable steps take place: 1. The first-hop overlay device implements a mapping operation that determines where the encapsulated packet should be sent to reach its intended destination VM. Specifically, the mapping function maps the destination address (either L2 or L3) of a packet received from a VM into the corresponding destination address ofNarten, et al. Informational [Page 10]
RFC 7364 Overlays for Network Virtualization October 2014RFC4364], Transparent Interconnection of Lots of Links (TRILL) [RFC6325], the Locator/ID Separation Protocol (LISP) [RFC6830], and Shortest Path Bridging (SPB) [IEEE-802.1aq]. In the data plane, an overlay header provides a place to carry either the virtual network identifier or an identifier that is locally significant to the edge device. In both cases, the identifier in the overlay header specifies which specific virtual network the data packet belongs to. Since both routed and bridged semantics can be supported by a virtual data center, the original packet carried within the overlay header can be an Ethernet frame or just the IP packet. A key aspect of overlays is the decoupling of the "virtual" MAC and/ or IP addresses used by VMs from the physical network infrastructure and the infrastructure IP addresses used by the data center. If a VM changes location, the overlay edge devices simply update their mapping tables to reflect the new location of the VM within the data center's infrastructure space. Because an overlay network is used, a VM can now be located anywhere in the data center that the overlay reaches without regard to traditional constraints imposed by the underlay network, such as the C-VLAN scope or the IP subnet scope.Narten, et al. Informational [Page 11]
RFC 7364 Overlays for Network Virtualization October 20144.2 . Communication between Virtual and Non-virtualized Networks4.3 . Communication between Virtual NetworksNarten, et al. Informational [Page 12]
RFC 7364 Overlays for Network Virtualization October 20144.4 . Overlay Design CharacteristicsNarten, et al. Informational [Page 13]
RFC 7364 Overlays for Network Virtualization October 20144.5 . Control-Plane Overlay Networking Work AreasNarten, et al. Informational [Page 14]
RFC 7364 Overlays for Network Virtualization October 2014RFC7365], more generally) from a specific virtual network instance. When a VM attaches, the NVE associates the VM with a specific overlay for the purposes of tunneling traffic sourced from or destined to the VM. When a VM disconnects, the NVE should notify the NVA that the Tenant System to NVE address mapping is no longer valid. In addition, if this VM was the last remaining member of the virtual network, then the NVE can also terminate any tunnels used to deliver tenant multi-destination packets within the VN to the NVE. In the case where an NVE and hypervisor are on separate physical devices separated by an access network, a standardized protocol may be needed. In summary, there are three areas of potential work. The first area concerns the implementation of the NVA function itself and any protocols it needs (e.g., if implemented in a distributed fashion). A second area concerns the interaction between the NVA and NVEs. The third work area concerns protocols associated with attaching and detaching a VM from a particular virtual network instance. All three work areas are important to the development of scalable, interoperable solutions. 4.6 . Data-Plane Work AreasRFC7365] for the virtual network to which the data packet belongs. Numerous encapsulation or tunneling protocols already exist that can be leveraged. In the absence of strong and compelling justification, it would not seem necessary or helpful to develop yet another encapsulation format just for NVO3. 5 . Related IETF and IEEE WorkNarten, et al. Informational [Page 15]
RFC 7364 Overlays for Network Virtualization October 20145.1 . BGP/MPLS IP VPNsRFC4364] support multi-tenancy, VPN traffic isolation, address overlapping, and address separation between tenants and network infrastructure. The BGP/MPLS control plane is used to distribute the VPN labels and the tenant IP addresses that identify the tenants (or to be more specific, the particular VPN/ virtual network) and tenant IP addresses. Deployment of enterprise L3 VPNs has been shown to scale to thousands of VPNs and millions of VPN prefixes. BGP/MPLS IP VPNs are currently deployed in some large enterprise data centers. The potential limitation for deploying BGP/ MPLS IP VPNs in data center environments is the practicality of using BGP in the data center, especially reaching into the servers or hypervisors. There may be computing workforce skill set issues, equipment support issues, and potential new scaling challenges. A combination of BGP and lighter-weight IP signaling protocols, e.g., the Extensible Messaging and Presence Protocol (XMPP), has been proposed to extend the solutions into the data center environment [END-SYSTEM] while taking advantage of built-in VPN features with its rich policy support; it is especially useful for inter-tenant connectivity. 5.2 . BGP/MPLS Ethernet VPNsEVPN] provide an emulated L2 service in which each tenant has its own Ethernet network over a common IP or MPLS infrastructure. A BGP/MPLS control plane is used to distribute the tenant MAC addresses and the MPLS labels that identify the tenants and tenant MAC addresses. Within the BGP/MPLS control plane, a 32-bit Ethernet tag is used to identify the broadcast domains (VLANs) associated with a given L2 VLAN service instance, and these Ethernet tags are mapped to VLAN IDs understood by the tenant at the service edges. This means that any VLAN-based limitation on the customer site is associated with an individual tenant service edge, enabling a much higher level of scalability. Interconnection between tenants is also allowed in a controlled fashion. VM mobility [MOBILITY] introduces the concept of a combined L2/L3 VPN service in order to support the mobility of individual virtual machines (VMs) between data centers connected over a common IP or MPLS infrastructure.Narten, et al. Informational [Page 16]
RFC 7364 Overlays for Network Virtualization October 20145.3 . 802.1 VLANsIEEE-802.1Q] are 12 bits. The 24-bit I-SID [IEEE-802.1aq] allows the support of more than 16 million virtual networks. 5.4 . IEEE 802.1aq -- Shortest Path BridgingIEEE-802.1aq] is an overlay based on IS-IS that operates over L2 Ethernets. SPB supports multipathing and addresses a number of shortcomings in the original Ethernet Spanning Tree Protocol. Shortest Path Bridging Mac (SPBM) uses IEEE 802.1ah PBB (MAC-in-MAC) encapsulation and supports a 24-bit I-SID, which can be used to identify virtual network instances. SPBM provides multi- pathing and supports easy virtual network creation or update. SPBM extends IS-IS in order to perform link-state routing among core SPBM nodes, obviating the need for bridge learning for communication among core SPBM nodes. Learning is still used to build and maintain the mapping tables of edge nodes to encapsulate Tenant System traffic for transport across the SPBM core. SPB is compatible with all other 802.1 standards and thus allows leveraging of other features, e.g., VSI Discovery Protocol (VDP), Operations, Administration, and Maintenance (OAM), or scalability solutions. 5.5 . VDPIEEE-802.1Qbg]. VDP is a protocol that supports the association of a VSI with a port.Narten, et al. Informational [Page 17]
RFC 7364 Overlays for Network Virtualization October 20145.6 . ARMDRFC6820]. While an overlay-based approach may address some of the "pain points" that were raised in ARMD (e.g., better support for multi-tenancy), analysis will be needed to understand the scaling trade-offs of an overlay-based approach compared with existing approaches. On the other hand, existing IP-based approaches such as proxy ARP may help mitigate some concerns. 5.7 . TRILLRFC7172] 5.8 . L2VPNsRFC3931] require significant tunnel state at the encapsulating and decapsulating endpoints. Overlays require less tunnel state than other approaches, which is important to allow overlays to scale to hundreds of thousands of endpoints. It is assumed that smallerNarten, et al. Informational [Page 18]
RFC 7364 Overlays for Network Virtualization October 20145.9 . Proxy Mobile IPRFC5213] [RFC5844] makes use of the Generic Routing Encapsulation (GRE) Key Field [RFC5845] [RFC6245], but not in a way that supports multi-tenancy. 5.10 . LISPRFC6830] essentially provides an IP-over-IP overlay where the internal addresses are end station identifiers and the outer IP addresses represent the location of the end station within the core IP network topology. The LISP overlay header uses a 24-bit Instance ID used to support overlapping inner IP addresses. 6 . Summary7 . Security ConsiderationsNarten, et al. Informational [Page 19]
RFC 7364 Overlays for Network Virtualization October 2014Section 5.3). In addition to isolation, assurances against spoofing, snooping, transit modification and denial of service are examples of other important data-plane considerations. Some limited environments may even require confidentiality. In the control plane, the primary security concern is ensuring that an unauthorized party does not compromise the control-plane protocol in ways that improperly impact the data plane. Some environments may also be concerned about confidentiality of the control plane. More generally, denial-of-service concerns may also be a consideration. For example, a tenant on one virtual network could consume excessive network resources in a way that degrades services for other tenants on other virtual networks. 8 . References8.1 . Normative ReferenceRFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, October 2014, <http://www.rfc-editor.org/info/rfc7365>. 8.2 . Informative ReferencesEND-SYSTEM] Marques, P., Fang, L., Sheth, N., Napierala, M., and N. Bitar, "BGP-signaled end-system IP/VPNs", Work in Progress, draft-ietf-l3vpn-end-system-04, October 2014. [EVPN] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-10, October 2014.Narten, et al. Informational [Page 20]
RFC 7364 Overlays for Network Virtualization October 2014
![Toni Kroos là ai? [ sự thật về tiểu sử đầy đủ Toni Kroos ]](https://evbn.org/wp-content/uploads/New-Project-6635-1671934592.jpg)
