[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03 04
draft-ietf-nvo3-overlay-problem-statement
Internet Engineering Task Force T. Narten, Ed.
Internet-Draft IBM
Intended status: Informational M. Sridharan
Expires: March 4, 2012 Microsoft
September 2011
Problem Statement: Using L3 Overlays for Network Virtualization
draft-narten-nvo3-overlay-problem-statement-00
Abstract
This document lays out the case for developing L3 overlays to provide
network virtualization. In addition, the document describes what
issues need to be resolved in order to produce an interoperable
standard. The goal is lead to scalable, interoperable
implementations of virtualization overlays based on standardized
encapsulation methods and control plane approaches.
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 4, 2012.
Copyright Notice
Copyright (c) 2011 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
Narten & Sridharan Expires March 4, 2012 [Page 1]
Internet-Draft L3 Overlays for Network Virtualization September 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Details . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Limitations Imposed by Spanning Tree and VLAN Spaces . . . 4
2.2. Multitenant Environments . . . . . . . . . . . . . . . . . 5
2.3. Stretching of L2 Domain . . . . . . . . . . . . . . . . . 5
2.4. Inadequate MAC Table Sizes in Switches . . . . . . . . . . 5
2.5. Decoupling Logical and Physical Configuration . . . . . . 6
3. Overlay Network Framework . . . . . . . . . . . . . . . . . . 6
3.1. Overlay Design Characteristics . . . . . . . . . . . . . . 6
4. Standardization Issues for Overlay Networks . . . . . . . . . 7
5. Benefits of an Overlay Approach . . . . . . . . . . . . . . . 9
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. ARMD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Trill . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. L2VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 11
6.4.1. LISP . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Narten & Sridharan Expires March 4, 2012 [Page 2]
Internet-Draft L3 Overlays for Network Virtualization September 2011
1. Introduction
Server virtualization is increasingly becoming the norm in data
centers. With server virtualization, each physical server supports
multiple virtual machines (VMs), each running its own operating
system, middleware and applications. Virtualization is a key enabler
of workload agility, i.e., allowing any server to host any
application and providing the flexibility of adding, shrinking, or
moving services within the physical infrastructure. Server
virtualization provides numerous benefits, including higher
utilization, increased data security, reduced user downtime, reduced
power usage, etc.
Server virtualization is driving and accentuating scaling limitations
in existing datacenter networks. Placement and movement of VMs in a
network effectively requires that VM IP addresses be fixed and
static. While a VM's IP address could be updated to always be
consistent with the VM's current point of attachment, changing the
VM's address makes it difficult for the VM to be reached by clients,
and breaks any open TCP connections. Thus, from an IP perspective,
VM's can generally only move within a single IP subnet. Having VMs
move to different subnets (while retaining their previous IP
addresses) requires taking additional steps at the IP routing level
to ensure that traffic continues to reach the VM at its new location.
In practice, this leads to a desire for larger and flatter L2
networks, so that a given VM can be placed (or moved to) anywhere
within the datacenter, without being constrained by subnet boundary
concerns.
The general scaling problems of large, flat L2 networks are well
known. In traditional data center architectures using Spanning
Trees, the size of a layer 2 domain is generally limited to two tiers
(access and aggregation), limiting the number of hosts within a
single L2 domain. Current network deployments, however, are
experiencing additional and new pain points. The increase in both
the number of physical machines, and the number of VMs per physical
machine has lead to MAC address explosion whereby switches need to
have increasingly large forwarding tables to handle the traffic they
switch. Furthermore, the dynamic nature of VM creation, deletion and
movement between between servers is leading to sub-optimal broadcast
domain expansion. Finally, the 4094 VLAN limit is no longer
sufficient in a shared infrastructure servicing multiple tenants.
This document outlines the problems encountered in scaling L2
networks in a datacenter and makes the case that an overlay based
approach, where individual L2 networks are implemented within
individual L3 "domains" provide a number of advantages over current
approaches. The goal is lead to scalable, interoperable
Narten & Sridharan Expires March 4, 2012 [Page 3]
Internet-Draft L3 Overlays for Network Virtualization September 2011
implementations of virtualization overlays based on standardized
encapsulation methods and control plane approaches.
Section 2 describes the problem space in detail. Section 3 provides
a general discussion of overlays. Section 4 covers standardization
issues and possible work areas. Section 5 summarizes the benefits of
an overlay approach. Section 6 and 7 discuss related work and
further work.
2. Problem Details
2.1. Limitations Imposed by Spanning Tree and VLAN Spaces
Years of operational experience with Spanning Tree Protocol has led
to best practices that limit topologies to two tiers, access and
aggregation, with the STP root at the aggregation switch. Such
topologies limit both the number of servers that can be connected to
the same layer 2 domain, and the amount of East-West bandwidth
available between servers connected to different access switches.
Newer initiatives like Trill overcome these topology restrictions and
allow high cross-sectional bandwidth between servers as well as large
layer 2 domains, but require new networking equipment. Another way
to expand the layer 2 domains, but stay within the topology
restrictions imposed by using STP, is to use Overlay Transport
Virtualization [I-D.hasmit-otv] to interconnect the individual STP
topologies.
Yet another approach for increasing East-West bandwidth is to
constrain the layer 2 domain to stay within the access switch, and
terminate layer 3 in the access switch as well. All communications
between servers connected to different access switches happens over
IP. However, this is incompatible with the desire to be able to move
VMs anywhere within the datacenter while maintaining Layer 2
adjacency between the VMs.
Another characteristic of Layer 2 data center networks is their use
of Virtual LANs (VLANs) to provide broadcast isolation. A 12-bit
VLAN ID is used in the Ethernet data frames to divide the larger
Layer 2 network into multiple broadcast domains. VLANs have worked
well in smaller data centers which are limited to less than 4094
VLANs. The growing demand for multitenancy, e.g., for clouds,
further accelerate the need for larger VLAN limits, as discussed
below. Finally, some switching equipment supports less than the 4094
maximum limit of VLANs.
Narten & Sridharan Expires March 4, 2012 [Page 4]
Internet-Draft L3 Overlays for Network Virtualization September 2011
2.2. Multitenant Environments
Cloud computing involves on-demand elastic provisioning of resources
for multitenant environments. The most common example of cloud
computing is the public cloud, where a cloud service provider offers
these elastic services to multiple customers over the same
infrastructure.
Isolation of network traffic by tenant could be done via Layer 2 or
Layer 3 networks. For Layer 2 networks, VLANs are often used to
segregate traffic - so a tenant could be identified by its own VLAN,
for example. Due to the large number of tenants that a cloud
provider might service, the 4094 VLAN limit is often inadequate. In
addition, there is often a need for multiple VLANs per tenant, which
exacerbates the issue. Note that there is a proposal in the Trill
working group to increase the VLAN space from 12 to 24 bits using two
concatenated 12-bit tags [I-D.eastlake-trill-rbridge-fine-labeling].
Additionally, IEEE 802.1aq has defined double tagging.
Layer 3 networks are not a complete solution for multi tenancy
either. Two tenants might use the same set of Layer 3 addresses
within their networks which requires the cloud provider to provide
isolation in some other form. Further, requiring all tenants to use
IP excludes customers relying on direct Layer 2 or non-IP Layer 3
protocols for inter VM communication, which puts limitations on
moving some applications onto a virtualized server environment.
2.3. Stretching of L2 Domain
Another use case is cross pod expansion. A pod typically consists of
one or more racks of servers with its associated network and storage
connectivity. Tenants may start off on a pod and, due to expansion,
require servers/VMs on other pods, especially the case when tenants
on the other pods are not fully utilizing all their resources. This
use case requires a "stretched" Layer 2 environment connecting the
individual servers/VMs.
2.4. Inadequate MAC Table Sizes in Switches
Today's virtualized environments place additional demands on the MAC
address tables of layer 2 switches. Instead of just one MAC address
per server link, the switching infrastructure now has to learn the
MAC addresses of the individual VMs (which could range in the 100s
per server). This is a requirement since traffic from/to the VMs to
the rest of the physical network will traverse the switched
infrastructure. This places a much larger demand on the switches'
MAC table capacity compared to non-virtualized environments.
Narten & Sridharan Expires March 4, 2012 [Page 5]
Internet-Draft L3 Overlays for Network Virtualization September 2011
If the table overflows, the switches do not learn new entries until
idle entries age out. This leads to flooding the frames over the
entire VLAN in accordance with IEEE standards.
2.5. Decoupling Logical and Physical Configuration
Data center operators must be able to achieve high utilization of
server and network capacity. In order to achieve efficiency it
should be possible to assign workloads that operate in a single
Layer-2 network to any server in any rack in the network. It should
also be possible to migrate workloads to any server anywhere in the
network while retaining the workload's addresses. This can be
achieved today by stretching VLANs (e.g., by using Trill or OTV).
However, in order to limit the broadcast domain of each VLAN, all
VLANs should not be configured to flow to every server in the
datacenter. When workloads migrate, the physical network (e.g.,
server access lists) need to be reconfigured which is typically time
consuming and error prone. By decoupling the network addresses used
by the VMs when communicating with each other from the network
addresses of the servers they are currently hosted on, the network
administrator can configure the network once and not every time a
service migrates. This decoupling enables any server to become part
of any server resource pool.
3. Overlay Network Framework
The idea behind overlays is straightforward. Take the set of
machines that are allowed to communicate with each other and group
them into a high-level construct called a domain. A domain could be
one L2 VLAN, a single IP subnet, or just an arbitrary collection of
machines. The domain identifies the set of machines that are allowed
to communicate with each other directly, and provides isolation from
machines not within the same domain. The overlay connects the
machines of a particular domain together. A switch connects each
machine to its domain, accepting ethernet frames from attached VMs
and encapsulating them for transport across the IP overlay. An
egress switch decapsulates the frame and delivers it to the target
VM.
3.1. Overlay Design Characteristics
There are existing layer 2 overlay protocols in existence, but they
were not necessarily designed to solve the problem in the environment
of a highly virtualized datacenter. Below are some of the
characteristics of environments that must be taken into account by
the overlay technology:
Narten & Sridharan Expires March 4, 2012 [Page 6]
Internet-Draft L3 Overlays for Network Virtualization September 2011
1. Highly distributed systems. The overlay should work in an
environment where there could be many thousands of access
switches (e.g. residing within the hypervisors) and many more end
systems (e.g. VMs) connected to them. This leads to a
distributed mapping system that puts a low overhead on the
overlay tunnel endpoints.
2. Many highly distributed segments with sparse connectivity. Each
overlay segment could be highly dispersed inside the datacenter.
Also, along with expectation of many overlay segments, the number
of end systems connected to any one segment is expected to be
relatively low; Therefore, the percentage of access switches
participating in any one overlay segment would also be expected
to be low.
3. Highly dynamic end systems. End systems connected to segments
can be very dynamic, both in terms of creation/deletion/power-on/
off and in terms of mobility across the access switches.
4. Work with existing, widely deployed network Ethernet switches and
IP routers without requiring wholesale replacement.
5. Network infrastructure administered by a single administrative
domain. This is consistent with operation within a datacenter,
and not across the internet.
6. Low access switch overhead / simple implementation. With the
requirement to support very large numbers of access switches, the
resource requirements on each switch should not be intensive both
in terms of memory footprint or processing cycles. This also
means consideration for hardware offload.
4. Standardization Issues for Overlay Networks
To provide a robust and interoperable overlay solution, a number of
issues need to be considered. First, an overlay header is needed for
transporting encapsulated Ethernet frames across the IP network to
their ultimate destination within a specific domain. To provide
multi-tenancy, the overlay header needs a field to identify which
domain an encapsulated packet belongs to. Consequently, some sort of
Domain Identifier is needed. VXLAN [I-D.mahalingam-dutt-dcops-vxlan]
uses a 24-bit VXLAN Network Identifier (VNI), while NVGRE
[I-D.sridharan-virtualization-nvgre] uses a 24-bit Tenant Network
Identifier (TNI).
The details of a specific overlay header format need to be worked
out. Questions to be resolved include whether to use existing
Narten & Sridharan Expires March 4, 2012 [Page 7]
Internet-Draft L3 Overlays for Network Virtualization September 2011
standard formats such as GRE [RFC2784] [RFC2890], or to define one
specifically tailored to meet the requirements of an overlay network.
One issue concerns whether to use UDP (in order to facilitate
transport through middlebox devices) or to build directly on top of
IP as GRE does. If the primary deployment environment is
datacenters, and paths will not generally cross the public internet,
middlebox traversal may not be a significant concern. Additionally,
the encapsulated payload could include a full Ethernet header,
including source and destination MAC addresses, VLAN information,
etc., or some subset thereof. Finally, the encapsulation will need
to consider whether inclusion of a checksum is necessary or whether
it imposes unacceptable overhead (when encapsulated packets are
themselves IP, they will carry their own end-to-end checksums). Note
that GRE supports an optional checksum. In IPv4, UDP checksums can
be disabled by setting the UDP checksum field to zero, but checksums
must always be included in IPv6. The 6man working group is currently
considering relaxing the IPv6 UDP checksum requirement
[I-D.ietf-6man-udpzero].
Separate from encapsulation, an address mapping system is needed to
map the destination address as specified by the originating VM into
the egress IP address of the router to which the Ethernet frame will
be tunneled. VXLAN uses a "learning" approach for this, similar to
what L2 bridges use. NVGRE has not indicated how it proposes to
perform address mapping, leaving details for a later document. Other
approaches are possible, such as managing mappings in a centralized
mapping system. Use of a centralized mapping system would require
development of a protocol for distributing address mappings from the
controller to the switches where encapsulation takes place.
Another aspect of address mapping concerns the handling of broadcast
and multicast frames, or the delivery of unicast packets when no
mapping exists. One approach is to flood such frames to all machines
belonging to the domain. Both VXLAN and NVGRE suggest associating an
IP multicast address taken from the network's infrastructure as a way
of connecting together all the machines belonging to the same domain.
All VMs within a domain can be reached by sending encapsulated
packets to the domain's IP multicast address. One issue with this
approach, however, is that some existing implementations may be
challenged in supporting large numbers of multicast groups.
Another issue is whether fragmentation is needed. Whenever tunneling
is used, one faces the potential problem that the packet plus
encapsulation overhead will exceed the MTU of the path to the egress
router. Fragmentation could be left to IP, could be done at the
overlay level in a more optimized fashion or could be left out
altogether, if it is believed that datacenter networks can be
engineered to prevent MTU issues from arising.
Narten & Sridharan Expires March 4, 2012 [Page 8]
Internet-Draft L3 Overlays for Network Virtualization September 2011
Related to fragmentation is the question of how best to handle Path
MTU issues, should they occur. Ideally, the original source of any
packet (i.e, the sending VM) would be notified of the optimal MTU to
use. Path MTU problems occurring within an overlay network would
result in ICMP MTU exceeded messages being sent back to the egress
tunnel switch at the entry point of the overlay. If the switch is
embedded within a hypervisor, the hypervisor could notify the VM of a
more appropriate MTU to use. It may be appropriate to specify a set
of best practices for implementers related to the handling of Path
MTU issues.
Both VXLAN and NVGRE assume that all machines belonging to the same
domain are on the same IP subnet and reflect one L2 broadcast domain.
This means that machines on different subnets cannot communicate
directly, and must (conceptually) go through a router that is also
part of the domain. The result can be suboptimal forwarding,
compared to the case where traffic is tunneled directly between the
two machines. Thus, another issue to consider is the handling of
machines belonging to the same domain, but residing on different IP
subnets. While one solution may simply be to assign a /0 subnet mask
to the entire domain (so that all machines are on the same subnet),
this could require a configuration change on individual VM images,
which may be undesirable in some deployments.
Finally, successful deployment of an overlay approach will likely
require appropriate Operations, Administration and Maintenance (OAM)
facilities.
5. Benefits of an Overlay Approach
A key aspect of overlays is the decoupling of the "virtual" MAC and
IP addresses used by VMs from the physical network infrastructure and
the infrastructure IP addresses used by the datacenter. If a VM
changes location, the switches at the edge of the overlay simply
update their mapping tables to reflect the new location of the VM
within the data center's infrastructure space. Because IP is used, a
VM can now be located anywhere in the data center without regards to
traditional constraints implied by L2 properties such as VLAN
numbering, or the span of an L2 broadcast domain scoped to a single
pod or access switch.
Multitenancy is supported by isolating the traffic of one domain from
traffic of another. Traffic from one domain cannot be delivered to
another domain without (conceptually) exiting the domain and entering
the other domain. Likewise, external communications (from a VM
within a domain to a machine outside a domain) is handled by having
an ingress switch forward traffic to an external router, where an
Narten & Sridharan Expires March 4, 2012 [Page 9]
Internet-Draft L3 Overlays for Network Virtualization September 2011
egress switch decapsulates a tunneled packet and delivers it to the
router for normal processing. This router is external to the
overlay, and behaves much like existing external facing routers in
datacenters today.
The use of a large (e.g., 24-bit) domain identifiers would allow 16
million distinct domains within a single datacenter, eliminating
current VLAN size limitations.
Using an overlay that sits above IP allows for the leveraging of the
full range of IP technologies, including quality-of-service (QoS) and
Equal Cost Multipath (ECMP) routing for load balancing across
multiple links.
Overlays are designed to handle the common case of a set of VMs
placed within a single L2 broadcast domain. Such configurations
include VMs placed within a single VLAN or IP subnet. All the VMs
would be placed into a common overlay domain.
6. Related Work
6.1. ARMD
ARMD is chartered to look at data center scaling issues with a focus
on address resolution. ARMD is currently chartered to develop a
problem statement and is not currently developing solutions. While
an overlay-based approach may address some of the "pain points" that
have been raised in ARMD (e.g., better support for multitenancy), an
overlay approach may also push some of the L2 scaling concerns (e.g.,
excessive flooding) to the IP level (flooding via IP multicast).
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.
6.2. Trill
Trill is an L2 based approach aimed at improving deficiencies and
limitations with current Ethernet networks. While Trill provides a
good approach to improving current Ethernets, it is entirely L2
based. Trill was not originally designed to scale to the sizes that
current data centers need to scale to. [RFC6325] explicitly says:
Narten & Sridharan Expires March 4, 2012 [Page 10]
Internet-Draft L3 Overlays for Network Virtualization September 2011
The TRILL protocol, as specified herein, is designed to be a Local
Area Network protocol and not designed with the goal of scaling
beyond the size of existing bridged LANs.
That said, approaches to extend Trill are currently under
investigation [I-D.eastlake-trill-rbridge-fine-labeling]
6.3. L2VPNs
The IETF has specified a number of approaches for connecting L2
domains together as part of the L2VPN Working Group. That group,
however is focused on Provider-provisioned L2 VPNs, where the service
provider participates in management and provisioning of the VPN. In
addition, much of the target environment for such deployments
involves carrying L2 traffic over WANs. Overlay approaches are
intended be used within data centers where the overlay network is
managed by the datacenter operator, rather than by an outside party.
While overlays can run across the Internet as well, they will extend
well into the datacenter itself (e.g., up to and including
hypervisors) and include large numbers of machines within the
datacenter itself.
Other L2VPN approaches, such as L2TP [RFC2661] require significant
tunnel state at the encapsulating and decapsulating end points.
Overlays require less tunnel state than other approaches, which is
important to allow overlays to scale to hundreds of thousands of end
points. It is assumed that smaller switches (i.e., virtual switches
in hypervisors or the physical switches to which VMs connect) will be
part of the overlay network and be responsible for encapsulating and
decapsulating packets.
6.4. Proxy Mobile IP
Proxy Mobile IP [RFC5213] [RFC5844] makes use of the GRE Key Field
[RFC5845] [RFC6245], but not in a way that supports multitenancy.
6.4.1. LISP
[Placeholder for LISP]
7. Further Work
It is believed that overlay-based approaches may be able to reduce
the overall amount of flooding and other multicast and broadcast
related traffic (e.g, ARP and ND) currently experienced within
current datacenters with a large flat L2 network. Further analysis
is needed to characterize expected improvements.
Narten & Sridharan Expires March 4, 2012 [Page 11]
Internet-Draft L3 Overlays for Network Virtualization September 2011
8. Summary
This document has argued that network virtualization using L3
overlays addresses a number of issues being faced as data centers
scale in size. In addition, careful consideration of a number of
issues would lead to the development of interoperable implementation
of virtualization overlays.
9. Acknowledgments
This document incorporates significant amounts of text from
[I-D.mahalingam-dutt-dcops-vxlan]. Specifically, much of Section 2
is incorporated verbatim from Section 3 of
[I-D.mahalingam-dutt-dcops-vxlan]. The authors of that document
include Mallik Mahalingam (VMware), Dinesh G. Dutt (Cisco), Kenneth
Duda (Arista Networks), Puneet Agarwal (Broadcom), Lawrence Kreeger
(Cisco), T. Sridhar (VMware), Mike Bursell (Citrix), and Chris Wright
(Red Hat).
Additional text in Section 2 was taken from
[I-D.sridharan-virtualization-nvgre]. The authors of that document
include Murari Sridharan (Microsoft), Kenneth Duda (Arista Networks),
Ilango Ganga (Intel), Albert Greenberg (Microsoft), Geng Lin (Dell),
Mark Pearson (Hewlett-Packard), Patricia Thaler (Broadcom), Chait
Tumuluri (Emulex), Narasimhan Venkataramiah (Microsoft) and Yu-Shun
Wang (Microsoft).
Helpful comments and improvements to this document have come from
Dinesh Dutt, Ariel Hendel, Vinit Jain and Larry Kreeger.
10. IANA Considerations
This memo includes no request to IANA.
11. Security Considerations
TBD
12. Informative References
[I-D.eastlake-trill-rbridge-fine-labeling]
Eastlake, D., Zhang, M., Agarwal, P., Dutt, D., and R.
Perlman, "RBridges: Fine-Grained Labeling",
draft-eastlake-trill-rbridge-fine-labeling-01 (work in
Narten & Sridharan Expires March 4, 2012 [Page 12]
Internet-Draft L3 Overlays for Network Virtualization September 2011
progress), July 2011.
[I-D.hasmit-otv]
Grover, H., Rao, D., Farinacci, D., and V. Moreno,
"Overlay Transport Virtualization", draft-hasmit-otv-03
(work in progress), July 2011.
[I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-03 (work in
progress), April 2011.
[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-00
(work in progress), August 2011.
[I-D.sridharan-virtualization-nvgre]
Sridharan, M., Duda, K., Ganga, I., Greenberg, A., Lin,
G., Pearson, M., Thaler, P., Tumuluri, C., Venkataramaiah,
N., and Y. Wang, "NVGRE: Network Virtualization using
Generic Routing Encapsulation",
draft-sridharan-virtualization-nvgre-00 (work in
progress), September 2011.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, June 2010.
Narten & Sridharan Expires March 4, 2012 [Page 13]
Internet-Draft L3 Overlays for Network Virtualization September 2011
[RFC6245] Yegani, P., Leung, K., Lior, A., Chowdhury, K., and J.
Navali, "Generic Routing Encapsulation (GRE) Key Extension
for Mobile IPv4", RFC 6245, May 2011.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
Authors' Addresses
Thomas Narten (editor)
IBM
Email: narten@us.ibm.com
Murari Sridharan
Microsoft
Email: muraris@microsoft.com
Narten & Sridharan Expires March 4, 2012 [Page 14]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/