1. Field of the Invention
The present disclosure relates generally to network virtualization, and more particularly to a technique for eliminating the need to include a gateway function between virtualized servers and non-virtualized servers and clients in a network.
2. Description of Related Art
Servers comprising a local network can be configured to support traffic/flows associated with one or more virtual LANs (VLAN). VLANs are typically employed in networks for the purpose of, among other things, segregating tenant traffic and performance isolation. A tenant in this context can mean an entity, or a portion of an entity, that is providing some service to customers (sales, marketing, hosting, information, etc.), and each VLAN can be typically configured to support traffic associated with a single tenant. Each VLAN is identified by a tag (VLAN.ID) included in a frame of information transmitted over the VLAN, and the number of VLAN identities is currently limited to sixteen bits or 4080 separate VLANs. As the volume of traffic in a local network increases, it becomes necessary to upgrade the network's capacity to process the increased traffic. Such network upgrades can include increasing the number of physical servers and switches comprising a network, and/or it can include upgrading certain functionality associated with each server and switch in the network, such as implementing virtual server and virtual switch functionality. However, implementing virtual network devices does not solve the problem associated with the VLAN limitation described earlier.
Recently, network virtualization (NV) has been proposed as a methodology to use when upgrading a network to more efficiently support larger volumes of traffic and larger numbers of tenants. Network virtualization methods can extend the capacity of a network to support many millions of “virtual networks”, and each virtual network can be utilized to support traffic associated with one tenant, but possibly more. One network virtualization technique is described in a Network Working Group Internet Draft entitled “VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks” published in August 2011, the entire contents of which are incorporated herein by reference. This internet draft describes a virtual, extensible local area network that supports a large number of VXLAN segments, with each segment assigned a twenty four (24) bit segment ID which is referred to as a VXLAN Network Identifier (VNI). A VNI is included in a VXLAN header (outer header) that envelopes or encapsulates an inner Ethernet frame transmitted by a server (typically a VM on a server). The outer VXLAN header is attached to the inner Ethernet frame by functionality that is referred to as a virtual tunnel end point (VTEP). The twenty four bits allocated to the segment ID permits up to 16M VXLAN segments to be configured within a local network, such as a data center, and the VXLAN methodology can be implemented on some or all of the servers comprising a network and those servers on which it is implemented are typically referred to as VXLAN capable servers.
Another network virtualization technique is described in Network Working Group Internet Draft entitled “NVGRE: Network Virtualization using Generic Routing Encapsulation” published September 2011, the entire contents of which are incorporated herein by reference. This draft describes a Tenant Network Identifier (TNI) which is included in a header that envelopes or encapsulates an Ethernet frame generated by a NVGRE capable server in a network. GRE is a proposed IETF standard and is described in RFC 2784 and RFC 2890. Hereinafter, NVGRE capable and VXLAN capable servers are referred to as Network Virtualization (NV) capable servers, and VNI and TNI are referred to as a Virtual Network Segment Identifier (VNSI). The VNSI is included in a NVGRE header (outer header) that envelopes or encapsulates an inner Ethernet frame transmitted by a server (typically associated with a VM on a server). The outer NVGRE header is attached to an inner Ethernet frame by what is referred to as a NVGRE End Point (NVGRE-EP). The VXLAN and NVGRE headers are both referred to herein as a NV header. The VTEP and NVGRE-EP are both referred to her as an NV function, and the VN function is typically implemented in a hypervisor residing in a NV capable server.
Each NV-capable server (VXLAN or NVGRE) can be configured to support some number of virtual machines (VM) which are typically managed by a hypervisor function running on the server. Each virtual machine can be assigned a VNSI, and two or more VMs on the same or different servers can be assigned the same VNSI. Virtual machines running on NV-capable servers are only able to transmit and receive frames of information from VMs running on other NV capable servers if both VMs are assigned the same VNSI. More specifically, the hypervisor on each NV capable server builds a table (binding table) of information that associates VM addresses with physical server addresses on which the VMs are supported. In the case of a server, a binding table entry can include an association between the MAC address of a VM, such as the VM in NV capable server A of FIG. 1, and the IP address of the NV capable server A. Binding tables can be built and maintained by each NV capable server, and the information included in a binding table maintained by each NV capable server is typically distributed to all other NV capable servers in a local network, such as network 10 in FIG. 1. Also, the hypervisor in a NV capable server maintains a table that associates VMs with a VNSIs. This association can be performed manually by a network administrator, or more typically it can be performed by the hypervisor. In operation, when a source VM wants to send a frame to another, destination VM, a NV function running in the hypervisor examines the address of the source VM and the address of the destination VM which are included in the frame to be transmitted. The NV function then determines whether both VM addresses are members of the same VNSI, and if they are the NV function adds the NV header to the Ethernet frame and the frame is forwarded through the network to its destination. At the destination server, an NV function removes the NV header from the frame and the frame is delivered to the destination VM. Whereas, a frame generated by a first VM with one VNSI can't be transmitted to a second VM with another VNSI, the same frame can be sent by the first VM to another VM outside the virtual network.
In order to transmit Ethernet frames between NV-capable servers and non-NV-capable servers comprising a local network, it is necessary that a Gateway function be included at the interface between the virtualized portion of the network and the non-virtualized portion of the network. This Gateway functionality can be implemented on switches linked to the NV capable servers, or to switches not directly linked to NV capable servers, and is similar to the NV functionality running in a hypervisor on a physical server which was described earlier with reference to FIG. 1. Briefly, the Gateway function can operate to, among other things, identify packets that are encapsulated with a NV header, strip the VXLAN or NVGRE headers (collectively referred to here as NV header) from the packet if the packets destination is a non-NV capable device, and in the reverse direction, it can operate to attach a NV header to an Ethernet frame transmitted from a non-NV capable server to a NV capable server. Each network device that includes such a Gateway function can build and maintain a binding table similar to that built and maintained by a NV capable server. Information included in these binding tables can then be used by the Gateway function to identify packets that are encapsulated by a NV header and to determine how to forward them to their destination.
FIG. 1 illustrates a local network 10 topology in which the network virtualization methodologies described above can be implemented. The local network 10 (such as an Ethernet network) is comprised of one or more CORE switches, such as the aggregation switch 11, linked to two or more top-of-rack (TOR) switches TOR.0-TOR.n, each of which are in turn linked to a plurality of servers. Each of the servers can be configured as a NV capable server or configured without NV capability, which is referred to here as simply a “server”, and both types of servers can be configured to support some number of VMs. Each of the TORs, TOR.0-TOR.n, and the one or more aggregation switches (AS.n) in FIG. 1 can include the Gateway function described above, and the switches generally operate to receive data frames from a neighboring network device and forward the frames to their destination, whether the destination is a server or another switch. Generally, when a source VM running on a NV-capable server, such as NV capable server A in FIG. 1, generates a data frame for transmission to a destination VM running on a NV-capable server, such as NV capable server B, and both of the VMs are assigned the same VNSI, an NV function running on the source server A attaches an outer NV header to an inner Ethernet frame and forwards the frame to the destination VM on the server B. The server B receives the Ethernet frame, and an NV function at the server strips the outer NV header and sends the inner MAC frame to the destination VM.
USPTO Backgrounds
USPTO Backgrounds