1. Field of the Invention
The present invention relates to network address translation, and more specifically to performing network address translation among different virtual local area networks (VLANs) with potentially overlapping address ranges onto an external network with unique addresses.
2. Description of the Related Art
Conventional network devices, such as routers, switches, hubs, repeaters, etc., are generally not configured to handle network address conflicts, such as two or more computers or servers having the same internet protocol (IP) address within a local area network (LAN) or a common virtual LAN (VLAN). A VLAN is a group of hosts with a common set of requirements that communicate as if they were attached to the same wire, regardless of their physical location. In computer networking, Network Address Translation (NAT), also known as Network Masquerading, Native Address Translation or IP Masquerading, is a technique of transceiving network traffic through a router that involves re-writing the source and/or destination IP addresses and usually also the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port numbers of IP packets (or frames) as they pass through. NAT allows identical IP addresses to be used within each of many different and independent local or private networks while further enabling communication with an external or public network through a router. The router employs NAT to assign a unique external address to be used in the external or public network domain. In conventional configurations, however, the same network address may not be used within the same network or between VLANs in which communications are aggregated through a common router.
The problem of using identical network addresses most often arises when provisioning one or more virtual (or logical) servers using virtualization technology (not to be confused with the “virtual” aspect of a VLAN) to deliver an application within a network. A logical server operates in the same manner as a physical machine configured in the same manner, but is provided as a separate and independent virtual machine and is used much like a physical computer. Virtualization technology transforms the function of a physical computer (virtualization host) to operate as if it were multiple computers in which each virtualized computer or virtual machine (VM) mimics the same basic architecture as that of a generic physical computer. Virtualization technology provides a software layer called abstraction. In one abstraction configuration, virtualization software executes as an application on the operating system (OS) of the underlying physical host computer system and enables multiple virtual machines to be defined within the virtualized environment. Alternatively, the underlying physical host computer executes a hypervisor replacing the host OS, where the hypervisor sits on top of the computer hardware rather than the OS. In either case, the abstraction layer provides virtual isolation so that each virtual machine is operated substantially independent of other virtual machines on the same physical host. Virtualization technology overrides the attributes of the underlying physical server and allows the virtual machines to share the physical resources of the underlying computer host. Virtualized isolation allows each virtual machine to execute its own separate OS even if otherwise inconsistent with the OS of any other virtual machine or with the OS of the underlying physical system. In this manner, virtualization technology enables multiple applications to be executed on the same host even if the applications are otherwise incompatible, which in turn increases the overall utilization of the physical host.
In a virtualization system, an application may be implemented with one or more multiple virtual machines or logical servers having common attributes including identical network addresses. Each virtual machine is stored as an image until activated and provisioned by a management or control server. Multiple copies of a single virtual machine image can be provisioned to execute simultaneously within a network. Without some form of network partitioning or modification to the IP address configuration of each VM instance, however, the multiple identical VMs experience IP address conflict and connectivity disruption. Connecting each instance to a VLAN provides isolation and allows multiple concurrent deployments of the same IP address without conflict, but prevents any external communication of the VLANs through a common gateway. Typically, external or inter-VLAN communication is accomplished via a router with knowledge of each unique subnet per VLAN. If there is an overlap among the per-VLAN subnets, a traditional router cannot uniquely identify the constituent devices for routing traffic resulting a conflict and communication failure.
Although the problem of duplicate addresses is more pervasive in virtualized systems using virtualization technology, the problem also arises in other platforms including physical configurations.
Aggregating communication of multiple devices with potentially duplicate network addresses and providing a unique IP identity could be accomplished by using a dedicated NAT router per VLAN, but the maintenance and resource cost of running and coordinating multiple routers can be high and even prohibitive for a large number of VLANs. Alternatively, each IP device may use a low-level driver to perform NAT itself, but this requires configuration of each constituent device which is disadvantageous.
The benefits, features, and advantages of the present invention will become better understood with regard to the following description, and accompanying drawing in which:
The following description is presented to enable one of ordinary skill in the art to make and use the present invention as provided within the context of a particular application and its requirements. Various modifications to the preferred embodiment will, however, be apparent to one skilled in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular embodiments shown and described herein, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed.
A network system according to an embodiment of the present invention enables network address translation (NAT) among different virtual local area networks (VLANs) with potentially overlapping address ranges onto a network with unique IP addresses. An intermediate network system has multiple interfaces on separate VLANs, acts as a gateway for each serviced network, and provides unique address mappings for each constituent IP device. The system can service either unique or identical networks, including identical TCP connections, by tracking traffic by VLAN in addition to source and destination IP, port number, and media access control (MAC) address. The system maintains rules based on incoming NAT destination address, VLAN source device, source MAC address, etc., and allows multiple copies of the same IP device to coexist.
The control server 103 schedules multiple concurrent deployments of two virtual machine (VM) applications on each of the virtualization hosts 101 and 102. As understood by those skilled in the art, a virtualization host is an underlying physical host computer system (not shown) employing virtualization technology, which provides an abstraction layer on each virtualization host system for defining multiple logical servers or VMs within a virtualized environment. As shown, VMs 118, 119, 120 and 121 are provisioned on the virtualization host 101 and VMs 122, 123, 124 and 125 are provisioned on virtualization host 102. As shown, the VMs 118-125 are each provisioned from two different VM applications (images or instances or the like) VM1 and VM2, in which VMs 118, 120, 122 and 124 are provisioned from VM1 and VMs 119, 121, 123 and 125 are provisioned from VM2. The control server 103 configures the gateway device 106 for the IP addresses of the upcoming deployments, and dynamically selects a VLAN for each VM instance. As shown, the VM1 and VM2 are assigned two different “internal” or “local” IP addresses 192.168.0.13 and 192.168.0.14, respectively. The specific IP addresses are arbitrary and may be any suitable values as understood by those skilled in the art. Thus, each VM pair 118 and 119, 120 and 121, 122 and 123, and 124 and 125 retain the respective IP addresses 192.168.0.13 and 192.168.0.14.
On the virtualization host 101, the VMs 118 and 119 are coupled to respective ports of a switch device 114 and the VMs 120 and 121 are coupled to respective ports of another switch device 115. On the virtualization host 102, the VMs 122 and 123 are coupled to respective ports of a switch device 116 and the VMs 124 and 125 are coupled to respective ports of another switch device 117. In one embodiment, the switch devices 114-117 are “virtual” devices which operate in the virtual environment in substantially the same manner as a physical switch operates in the physical environment. Each of the switch devices 114-117 has an uplink port “UP” coupled to corresponding ports of the switch device 107 via the respective network links 110, 111, 112 and 113. The switch device 107 and the gateway device 106 are shown outside the virtualization hosts 101 and 102, although either or both of these devices may be implemented as virtual devices on either virtualization host 101 and 102. Alternatively, any of the switch devices may be implemented as physical devices. Each of the switch devices 114-117 enable network communications between the pair of VMs coupled to the respective switch devices. For example, the VMs 118 and 119 are able to communicate with each other via the switch device 114.
The VMs 118-125 are “local” devices within a local network 140, such as a local area network (LAN) or the like. The control server 103 and the database server 104 are located in an external network 141. The external network 141 is “external” relative to the local devices and may simply be another network, internal or external, or may incorporate larger networks and may be interfaced with one or more public networks, such as the internet or the like. It is desired that each of the VMs 118-125 have access to the services of any external network without conflict. The switch device 107 may be configured in substantially similar manner to enable communication between its ports so that the VMs 118-125 would otherwise be able to communicate with each other. Such communication causes conflicts, however, because the IP addresses are duplicated or otherwise overlapping. In particular, since the VMs 118, 120, 122 and 124 have the same IP address 192.168.0.13, and since the VMs 119, 121, 123 and 125 have the same IP address 192.168.0.14, such IP address duplication otherwise causes communication conflict within the local or internal network. Furthermore, communication to a different network, such as another internal or an external network or the like, is problematic given the local address conflicts.
The control server 103 configures the target virtualization hosts 101 and 102 to perform VLAN “tagging” of the switch devices 114, 115, 116, 117 for each VM pair. As shown, the VMs 118 and 119 are in a first VLAN 130, the VMs 120 and 121 are in a second VLAN 131, the VMs 122 and 123 are in a third VLAN 132, and the VMs 124 and 125 are in a fourth VLAN 133. In this manner, the local network 140 is divided into four VLANs 130-133. In one embodiment, the switch 107 is “VLAN aware” so that each of its ports may be assigned a VLAN identifier (VID) or VLAN tag or the like. As shown, the network link 110 is coupled to a port assigned VID 15 as a tag for the VLAN 130, the network link 111 is coupled to a port assigned VID 25 as a tag for the VLAN 131, the network link 112 is coupled to a port assigned VID 35 as a tag for the VLAN 132, and the network link 113 is coupled to a port assigned VID 45 as a tag for the VLAN 133. The particular VIDs illustrated are arbitrary where it is understood by those skilled in the art that VIDs are typically 12-bit values which typically range from 0-4095. The switch device 107 uses the VIDs to logically segment the local network to prevent communication conflicts within the local network between VMs having the same IP address. In this manner, the VMs 118 and 119 on the VLAN 130 may communicate with each other without conflict with any of the VMs of the other VLANs 131-133.
The switch 107 further includes a “trunked” uplink port T coupled to a trunked interface of a gateway device 106 via the trunked network link 108. A trunked interface aggregates communications from multiple networks. In the illustrated configuration, the communications on the VLANs 130-133 are aggregated on the trunked network link 108 and provided to the gateway device 106. In one embodiment, the gateway device 106 sees traffic “framed” with VLAN tags from each virtual machine application instance 118-125 of each of the VLANs 130-133. As understood by those skilled in the art, communications are in the form of packets or frames with frame headers incorporating the VLAN tag or VID. The gateway device 106 further includes an external access interface coupled via the external network link 109 to a port of the switch device 105 of the external network 141. The switch device 105 is “external” in the sense that it is outside or separate from the internal or local network 140 of the VLANs 130-133. The external network 141 may be a different internal or “local” network and may even be within a different VLAN. The switch device 105 may be implemented as a virtual device on either of the virtualization hosts 101 or 102 or any other virtualization hosts interfaced therewith, or may alternatively be implemented as a physical device. The switch device 105 includes ports for interfacing the network links 126 and 127 for enabling communications with the control server 103 and the database server 104. The gateway device 106 acts as the gateway for the VLANs 130-133 of the local network 140 for enabling each of the VMs 118-125 to access devices and services on or via the external network 141.
The gateway device 106 performs address translation for each VM 118-125 of the local network, in which it assigns a unique external address on the external network to allow traffic to any of the resources on the external network, such as the database server 104. In the illustrated embodiment, the gateway device 106 includes translation logic 128 that translates communications between the trunked network link 108 and the external access link 109. The translation logic 128 enables communication between any of the VMs 118-125 of any of the local VLANs to communicate with external devices, such as the database server 104. Although communications may be enabled with the control server 103, the control server 103 may be isolated to perform dedicated management functions. In a conventional NAT function, communication conflict otherwise arises because of the duplicate IP addresses. A conventional NAT maps the internal or local addresses with one or more external addresses. In a 1:N (or “one-to-many”) configuration, all of the internal addresses are translated between one external address, such as performed in a typical router or the like. Alternatively, in a 1:1 (or “one-to-one”) translation, each internal address is assigned a unique external address for external communications. In either case, however, the conventional tuple employed by the conventional NAT is insufficient so that the NAT function is unable to distinguish between devices having the same IP address. For example, a conventionally configured gateway assigns the same external address to communications from any of the VMs having the same IP address (e.g., 118, 120, 122 and 124), so that the conventional gateway is unable to resolve the correct destination for response communications from external devices.
In one embodiment, the VLAN ID in the header of each communication packet is programmed by the switch device 107 with the appropriate VID to enable the gateway device 106 to distinguish communications from among the VMs of the VLANs 130-133 with identical IP addresses. For example, a frame from VM1118 with IP address 192.168.0.13 has VID 15 whereas a frame from VM1124, also with IP address 192.168.0.13, has VID 45. As described further below, the translation logic 128 employs a connection tracking table 220 (
A connection tracking table 220 is shown which is used by the translation logic 128 of the gateway device 106 for establishing the four communication connections without conflict. The connection tracking table 220 lists the internal source address, internal port number, and VID for each of the VMs 118-121 attempting to establish a connection session with the database server 104. The destination address and destination port number are also listed in the connection tracking table 220 and are the same for each connection. As shown in the connection tracking table 220, the internal source addresses, the internal port numbers, the destination addresses and the destination port numbers are identical for the VMs 118 and 120. The same situation exists between the VMs 119 and 121. This situation might otherwise result in a conflict since a conventional NAT does not consider VLAN tags. As shown, the VMs 118 and 120 are on different VLANs 15 and 25, respectively, and this information is used by the translation logic 128 to distinguish between the corresponding communication connections. The translation logic 128 employs a VLAN tagged 1:1 NAT function and assigns different external source addresses for the VMs 118 and 120 based on IP address and VID. As shown, the communication for VM1118 is assigned an external source address 172.16.5.11 whereas the communication for VM1120 is assigned an external source address 172.16.5.20. In this manner, the internal source address 192.168.0.13 within a frame from the VM1118 is replaced with the external source address 172.16.5.11 before being forwarded to the database server 104. Similarly, the internal source address 192.168.0.13 within a frame from the VM1120 is replaced with the external source address 172.16.5.20 before being forwarded to the database server 104. Likewise, the internal source address 192.168.0.14 within a frame from the VM2119 is replaced with the external source address 172.16.5.32 and the internal source address 192.168.0.14 within a frame from the VM2121 is replaced with the external source address 172.16.5.29 before being forwarded to the database server 104.
It is appreciated that the database server 104 receives four different communications from four different devices, each having a different source address. The database server 104 may respond to each using the different source addresses as the destination address for return communications. The translation logic 128 employs the information from the connection tracking table 220 to cross-reference between the internal and external source addresses of the VMs 118-121. For example, a communication frame from the database server 104 with destination address 172.16.5.20 is mapped to VM1120 having address 192.168.0.13. The destination address of the frame is replaced with 192.168.0.13 and the frame header is programmed with VID 25 to identify the VLAN 131, and the return frame is forwarded to the switch device 107 via the trunked network link 108. The switch device 107 retrieves the destination address 192.168.0.13 and the VID 25, and uses this information to forward the return frame to the VM1120 on the network link 111. The frame sent to the switch device 115 may not include the VID information, but this is inconsequential since the destination IP address is sufficient to identify the VM1120 within the VLAN 131.
In summary, since two or more VMs are based on the same image, any deterministic network connection, such as an automated login to the external database server 104, would otherwise result in the same local and remote address and port selection. The gateway device 106 sees frames with different VLANs but identical IP source/destination address/port tuples. Because the gateway device 106 is connected via the trunked network link 108, and has a virtual interface on each VLAN, it can function as the default gateway for each VLAN. The gateway device 106 employs the connection tracking table 220 augmented to include VLAN tags (e.g., VID 15, 25, etc.). For traffic from the internal network 140 to the external network 141 (or other networks), the input VLAN tag or VID is associated with the connection stream, and provides a mechanism to determine uniqueness of connections that have identical source IP address, source port number, destination IP address, and destination port number. For traffic from any external network to one of the serviced internal networks (e.g., internal network 140), user-defined rules associate specific external IP addresses with known internal IP addresses on specific VLANs.
The trunked interface 303 has multiple virtual interfaces created from it, one per VLAN that is serviced. In the illustrated embodiment, three interfaces 305, 306 and 307 are provided for interfacing 3 separate VLANs having VIDs 55, 48 and 59, respectively. Each of the virtual interfaces 305-307 assumes the IP identity of the default gateway of the VLAN on which it resides. As shown, the default gateway for the interfaces 305 and 306 is 192.168.0.1 and the default gateway for interface 307 is 10.1.100.1. Each virtual interface 305-307 also maintains a routing table unique to it listing the internal IP address and MAC address for the gateway and for each of the VMs located within the corresponding VLAN. A first routing table 308 is provided for interface 305 which lists the internal IP addresses (192.168.0.13, 192.168.0.14) and corresponding MAC addresses (00:11:22:33:AA:A1, 00:11:22:33:AA:B2) for VMs VM1 and VM2, respectively, and which maps the default gateway IP address (192.168.0.1) to the MAC address of the interface 303 (00:11:22:33:44:FD). A second routing table 309 is provided for interface 306 which lists the internal IP addresses (192.168.0.13, 192.168.0.14) and corresponding MAC addresses (00:11:22:33:AA:C1, 00:11:22:33:AA:D2) for VMs VM1 and VM2, respectively, and which maps the default gateway IP address (192.168.0.1) to the MAC address of the interface 303 (00:11:22:33:44:FD). A third routing table 310 is provided for interface 307 which lists the internal IP address (10.1.100.45) and corresponding MAC address (00:11:22:33:CC:E1) for a single VM, VM3, and which maps the default gateway IP address (192.168.0.1) to the MAC address of the interface 303 (00:11:22:33:44:FD).
The translation logic 128 of the gateway device 106 employs a translation mapping table 312 to perform one-to-one NAT for each serviced virtual machine VM1, VM2 and VM3 of the VLANs. The translation mapping table 312 is a shortened version of the connection tracking table 220 previously described. The translation mapping table 312 maps each VM including VM1, VM2 and VM3 of each of the VLANs, the corresponding internal source addresses, the VIDs, and the corresponding external source addresses. As shown, a first IP address (192.168.0.13) of VM1 with VID 55 maps to a first external address (172.16.5.11), a second IP address (192.168.0.14) of VM2 with VID 55 maps to a second external address (172.16.5.32), a third IP address (192.168.0.13, same as first IP address) of VM1 with VID 48 maps to a third external address (172.16.5.76), a fourth IP address (192.168.0.14, same as second IP address) of VM2 with VID 48 maps to a fourth external address (172.16.5.9), and a fifth IP address (10.1.100.45) of VM3 with VID 59 maps to a fifth external address (172.16.5.36). In this manner, each internal device maps to a unique external address even if the internal addresses of any two or more internal devices are identical which would otherwise result in IP address conflict. The external addresses reside on the access interface 302 coupled to the external network.
A primary bridge routing table 311 is shown mapping each of the external addresses of the VMs to a MAC address (00:11:22:33:44:FA) assigned to the access switch port 302. The system responds to Address Resolution Protocol (ARP) requests for the external addresses via this interface. Because the routing tables are per-interface, each VLAN can support overlapped network ranges without ARP thrashing the primary bridge routing table 311. In the case of on-demand applications, an entirely duplicated network topology is supported with different virtual interfaces acting as the same gateway identity for a given copy of a network. The gateway device 106 maintains the translation mapping table 312 and uses configured rules to determine the address translation between traffic inbound to the external source, and the non-unique internal source.
The integrated switch device 401 further includes translation logic 411 implemented according to one embodiment. As shown, the translation logic 411 is incorporated within the switch logic 403, although these logic functions may alternatively be implemented as separate logic blocks coupled together. The four ports 407 are coupled to the translation logic 411 via a trunked interface 409 so that the translation logic 411 sees the traffic and communications of each of the machines 412-415. The translation logic 411 is further configured to be coupled to a pair of ports 416 and 418 of the integrated switch device 401. A mail server 417 is coupled to port 416 and a WEB server 419 is coupled to port 418. In one embodiment, the ports 416 and 418 are provided within a common network and in another embodiment, the ports 416 and 418 are provided within separate or different networks. One or both of the ports 416 and 418 are considered within an “external” network relative to the VLANs containing the machines 412-415 and may be internal or external or even within a different VLAN assigned by the integrated switch device 401. In any case, the translation logic 411 enables communication between any of the machines 412-415 and the servers 417 and 419 located within a different network. For outgoing communications (from any of the ports 407 to ports in different networks), the translation logic 411 differentiates between the M1 machines 412 and 414 and between the M2 machines 413 and 415 based on VID and assigns four different external addresses to each of the machines 412-415. For incoming communications from external networks, e.g., from either one of the servers 417 and 419, the translation logic 411 differentiates from among the machines 412-415 as the appropriate destination based on one of the four external addresses as the destination address. The translation logic 411 exchanges the external address with the appropriate internal address, programs the appropriate VID, and provides the communication onto the trunked interface 409. The switch logic 403 forwards the communication onto the correct VLAN based on VID provided within the communications.
The gateway device 511 receives the frame 503, generates a corresponding frame 517, and sends the frame 517 to the server 525 via an access switch port 515 interfacing the external network. The frame 517 also includes a VLAN tag header 519, an IP header 521, and a TCP header 523. The VLAN tag header 519 includes a source MAC address (11:22:33:44:CC), which is the MAC address of the access switch port 515, and a destination MAC address (11:22:33:44:DD) which is the MAC address of the server 525. The VID within the VLAN tag header 519 is not relevant (or otherwise not programmed) since the frame is processed through the external network. If the server 525 is in a different VLAN, then the VID is programmed with the appropriate VID. The IP header 521 includes a unique source IP address (5.6.7.8) provided by the gateway device 511 to differentiate the local machine 501 from other local machines as previously described. The IP header 521 includes a destination IP address (10.20.30.40) which is the IP address of the server 525. The TCP header 523 includes a source port number (e.g., 200) and the destination port number (e.g., 300) as shown.
In general, first devices of a first network may be provisioned with the same first network addresses. The first network is sub-divided into multiple virtual networks (e.g., different VLANs), and those first devices with the same first network addresses are separated into different virtual networks according to virtual network identifiers. The communications of the first network are aggregated or combined within a gateway device providing access to a second network associated with second network addresses. The second network is different from the first network and may be another local network, a different or external network, a public or other wide area network (WAN), etc. The gateway device assigns a unique second network address to each first device of the first network. Thus, those first devices having the same first network address within different virtual networks are assigned different second network addresses. The gateway device maps between each second network address and each unique combination of first network address and virtual network identifier.
Although the present invention has been described in considerable detail with reference to certain preferred versions thereof, other versions and variations are possible and contemplated. Those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiments as a basis for designing or modifying other structures for providing out the same purposes of the present invention without departing from the spirit and scope of the invention.
This application claims the benefit of U.S. Provisional Application Ser. No. 61/015,306 filed on Dec. 20, 2007 which is incorporated herein by reference for all intents and purposes.
Number | Name | Date | Kind |
---|---|---|---|
4912628 | Briggs | Mar 1990 | A |
5062037 | Shorter et al. | Oct 1991 | A |
5201049 | Shorter | Apr 1993 | A |
5611050 | Theimer et al. | Mar 1997 | A |
5757924 | Friedman et al. | May 1998 | A |
5802290 | Casselman | Sep 1998 | A |
5805824 | Kappe | Sep 1998 | A |
5917997 | Bell et al. | Jun 1999 | A |
5996026 | Onodera et al. | Nov 1999 | A |
5999518 | Nattkemper et al. | Dec 1999 | A |
6003050 | Silver et al. | Dec 1999 | A |
6006264 | Colby et al. | Dec 1999 | A |
6023724 | Bhatia et al. | Feb 2000 | A |
6038566 | Tsai | Mar 2000 | A |
6041347 | Harsham et al. | Mar 2000 | A |
6067545 | Wolff | May 2000 | A |
6069894 | Holender et al. | May 2000 | A |
6075938 | Bugnion et al. | Jun 2000 | A |
6092178 | Jindal et al. | Jul 2000 | A |
6104699 | Holender et al. | Aug 2000 | A |
6118784 | Tsuchiya et al. | Sep 2000 | A |
6130892 | Short et al. | Oct 2000 | A |
6185601 | Wolff | Feb 2001 | B1 |
6192417 | Block et al. | Feb 2001 | B1 |
6247057 | Barrera, III | Jun 2001 | B1 |
6256637 | Venkatesh et al. | Jul 2001 | B1 |
6263358 | Lee et al. | Jul 2001 | B1 |
6272523 | Factor | Aug 2001 | B1 |
6272537 | Kekic et al. | Aug 2001 | B1 |
6282602 | Blumenau et al. | Aug 2001 | B1 |
6347328 | Harper et al. | Feb 2002 | B1 |
6370560 | Robertazzi et al. | Apr 2002 | B1 |
6453426 | Gamache et al. | Sep 2002 | B1 |
6496847 | Bugnion et al. | Dec 2002 | B1 |
6535511 | Rao | Mar 2003 | B1 |
6553401 | Carter et al. | Apr 2003 | B1 |
6567839 | Borkenhagen et al. | May 2003 | B1 |
6571283 | Smorodinsky | May 2003 | B1 |
6607545 | Kammerer et al. | Aug 2003 | B2 |
6609213 | Nguyen et al. | Aug 2003 | B1 |
6625705 | Yanai et al. | Sep 2003 | B2 |
6633916 | Kauffman | Oct 2003 | B2 |
6640239 | Gidwani | Oct 2003 | B1 |
6665304 | Beck et al. | Dec 2003 | B2 |
6745303 | Watanabe | Jun 2004 | B2 |
6760775 | Anerousis et al. | Jul 2004 | B1 |
6865613 | Millet et al. | Mar 2005 | B1 |
6880002 | Hirschfeld et al. | Apr 2005 | B2 |
6931003 | Anderson | Aug 2005 | B2 |
6985479 | Leung et al. | Jan 2006 | B2 |
6985485 | Tsuchiya et al. | Jan 2006 | B2 |
6985937 | Keshav et al. | Jan 2006 | B1 |
6990666 | Hirschfeld et al. | Jan 2006 | B2 |
7020720 | Donahue et al. | Mar 2006 | B1 |
7043665 | Kern et al. | May 2006 | B2 |
7065589 | Yamagami | Jun 2006 | B2 |
7076560 | Lango et al. | Jul 2006 | B1 |
7139841 | Somasundaram et al. | Nov 2006 | B1 |
7154891 | Callon | Dec 2006 | B1 |
7200622 | Nakatani et al. | Apr 2007 | B2 |
7215669 | Rao | May 2007 | B1 |
7219161 | Fagundo et al. | May 2007 | B1 |
7222172 | Arakawa et al. | May 2007 | B2 |
7234075 | Sankaran et al. | Jun 2007 | B2 |
7257584 | Hirschfeld et al. | Aug 2007 | B2 |
7280557 | Biswas et al. | Oct 2007 | B1 |
7287186 | McCrory et al. | Oct 2007 | B2 |
7356679 | Le et al. | Apr 2008 | B1 |
7421505 | Berg | Sep 2008 | B2 |
7574496 | McCrory et al. | Aug 2009 | B2 |
7643484 | Willman et al. | Jan 2010 | B2 |
7769004 | Johnson et al. | Aug 2010 | B2 |
20020065864 | Hartsell et al. | May 2002 | A1 |
20020103889 | Markson et al. | Aug 2002 | A1 |
20020129082 | Baskey et al. | Sep 2002 | A1 |
20020152310 | Jain et al. | Oct 2002 | A1 |
20020159447 | Carey et al. | Oct 2002 | A1 |
20020184642 | Lude et al. | Dec 2002 | A1 |
20020194251 | Richter et al. | Dec 2002 | A1 |
20030005104 | Deborer et al. | Jan 2003 | A1 |
20030005166 | Seidman | Jan 2003 | A1 |
20030018927 | Gadir et al. | Jan 2003 | A1 |
20030023774 | Gladstone et al. | Jan 2003 | A1 |
20030105829 | Hayward | Jun 2003 | A1 |
20030188233 | Lubbers et al. | Oct 2003 | A1 |
20040044778 | Alkhatib et al. | Mar 2004 | A1 |
20040052216 | Roh | Mar 2004 | A1 |
20040078467 | Grosner et al. | Apr 2004 | A1 |
20040186905 | Young et al. | Sep 2004 | A1 |
20050013280 | Buddhikot et al. | Jan 2005 | A1 |
20050044220 | Madhavan | Feb 2005 | A1 |
20050228835 | Roa | Oct 2005 | A1 |
20050229175 | McCrory et al. | Oct 2005 | A1 |
20050240668 | Rolia et al. | Oct 2005 | A1 |
20050240964 | Barrett | Oct 2005 | A1 |
20050246436 | Day et al. | Nov 2005 | A1 |
20050249199 | Albert et al. | Nov 2005 | A1 |
20060013209 | Somasundaram | Jan 2006 | A1 |
20060136490 | Aggarwal et al. | Jun 2006 | A1 |
20060282892 | Jonnala et al. | Dec 2006 | A1 |
20060288251 | Jackson | Dec 2006 | A1 |
20070005769 | Ammerlaan et al. | Jan 2007 | A1 |
20070088721 | Srivastava | Apr 2007 | A1 |
20070180453 | Burr et al. | Aug 2007 | A1 |
20080240122 | Richardson et al. | Oct 2008 | A1 |
20100281181 | Johnson et al. | Nov 2010 | A1 |
Number | Date | Country | |
---|---|---|---|
61015306 | Dec 2007 | US |