Source: https://patents.google.com/patent/US8259720B2/en
Timestamp: 2019-04-21 18:25:04+00:00

Document:
In one embodiment, a solution is provided wherein redundant routers are treated as a single emulated switch. When a packet is received at a layer 2 edge switch from a host, the layer 2 edge switch may determine a switch identifier for the emulated switch using a destination anycast hardware address contained in the packet. The anycast hardware address may identify an emulated switch comprising a plurality of routers. Then a header may be added to the packet, the header including the switch identifier. Following that, the packet may be forwarded to another layer 2 switch along a shortest path from the layer 2 edge switch to the emulated switch.
FIG. 1 illustrates an “isolated application” environment.
FIG. 2 illustrates a DCE network.
FIG. 3 illustrates an example network containing layer 2 switches coupled to an emulated switch.
FIG. 4 illustrates an example of an ARP request packet.
FIG. 5 illustrates an example of an ARP request packet with an appended MAC-in-MAC header.
FIG. 6 illustrates an example of an ARP reply packet with an appended MAC-in-MAC header.
FIG. 7 illustrates an example method for handling a hardware address request to a router in an emulated switch of two or more routers.
FIG. 8 illustrates an example method for handling a packet received at a layer 2 edge switch from a router in an emulated switch of two or more routers.
FIG. 9 illustrates an example method for handling a packet from a host at an edge switch in a network containing layer 2 switches.
FIG. 10 illustrates an example method for handling a packet from a host at an edge switch in a network containing layer 2 switches.
FIG. 11 illustrates an example apparatus for handling a hardware address request to a router in an emulated switch of two or more routers.
FIG. 12 illustrates an example apparatus for handling a packet received at a layer 2 edge switch from a router in an emulated switch of two or more routers.
FIG. 13 illustrates an example apparatus for handling a packet from a host at an edge switch in a network containing layer 2 switches.
FIG. 14 illustrates an example apparatus for handling a packet from a host at an edge switch in a network containing layer 2 switches.
FIG. 15 illustrates a simplified architecture of DCE switch.
Data center managers face several challenges in fulfilling the goals of data centers. Most enterprise data centers grew rapidly to meet the explosive economic growth of recent times. Consequently, applications commonly stand alone in underutilized, isolated infrastructure silos. Each infrastructure silo is designed based on the inclination of the specific application being deployed, so that a typical data center supports a broad assortment of operating systems, computing platforms, and storage systems. The disparate infrastructures supporting different application “islands” are difficult to change or expand and expensive to manage, integrate, secure, and back up. FIG. 1 illustrates an “isolated application” environment.
One solution to this problem is to design a data center environment that is highly scalable, resilient, secure, and able to integrate multiple applications and protocols. One such solution is known as the Data Center Network Architecture. A specific implementation of the Data Center Network Architecture is known as Data Center Ethernet (DCE). DCE allows for consolidation of input and output, and improved forwarding of communications within the network. This may be accomplished via specialized protocols and functionality operated by switches within a DCE network via network layer 2. Each of the switches within the DCE network may be a layer 2 device. FIG. 2 illustrates a DCE network. Edge switch 200 may be connected to a host 202. Edge switch 204 may be connected to host 206. Edge switches 200, 204 may then be connected to several core switches 208, 210, which then may be connected to other edge switches 212, 214. Each DCE switch may be assigned a unique identifier. A routing protocol, such as Intermediate-System-to-Intermediate-System (IS-IS), may be used inside DCE. Edge switches implementing this routing protocol may append information to packets sent though the DCE. This appended information may be in the form of a MAC-in-MAC header attached to the packet. Edge switches 212, 214 may then each be connected to layer 3 devices, such as routers 216, 218. Rather than forwarding packets to MAC addresses, DCE switches send packets to edge switches based on the edge switch identification via the MAC-in-MAC header. The edge switch then knows which of its ports to send the packet out to arrive at the correct IP address (for example, the port connected to router 216), and strips off the MAC-in-MAC header prior to doing so.
Rather than operate routers 216 and 218 independently, it is often beneficial to link the routers so that one router can act as a backup to the other router in case of router or link failure. This linking may be accomplished via another routing protocol, such as Hot Standby Routing Protocol (HSRP). Other hot standby routing protocols include Virtual Router Redundancy Protocol (VRRP) and Gateway Load Balancing Protocol (GLBP). In these protocols, several routers are connected to the same subnet of a network and work together to present the appearance of a single virtual router. Typically, a single virtual IP address is assigned to the routers, which the links to a single virtual MAC address. The single virtual MAC address, however, points to a particular one of the routers, designated as the “active” router, whereas the other router(s) are designated as “backup.” If one router goes down, another takes over and the virtual MAC address is mapped to the backup router. However, while both are running, only one is being used for outbound communications. This can be inefficient for several reasons.
First of all, using just one of a plurality of redundant routers as the active router for outbound communications can create a bottleneck at the single router or on one of its associated links. It would be much more efficient to load balance between the redundant routers. Second of all, even if a hot routing protocol is utilized to load balance between redundant routers, the traffic generated by these protocols can be wasteful. Third of all, the amount of time for a router to switch from active to backup is non-trivial. If faster convergence is desired, a different solution is required.
A solution is provided wherein the redundant routers are treated as a single emulated switch. This allows for both a failure recovery and a load-balancing mechanism for host-switch-router connectivity through a protocol, such as DCE, used in network containing layer 2 switches. Through the use of this solution, hot standby routing protocols such as HSRP, VRRP, and GLBP can be eliminated.
Configuration of the network may be accomplished by first assigning the same IP address to all routers in the emulated switch. This IP address may be known as the “router anycast address.” Additionally, the same MAC address may be assigned to all routers in the emulated switch. This MAC address may be known as a “router anycast MAC address.” Each host may then be configured with a default router using a virtual IP address. The virtual IP address maps to a virtual MAC address. The virtual MAC addresses for the routers in the virtual switch correspond to a single anycast hardware address. The anycast hardware address may be used as a switch identification. This switch identification may be advertised to all layer 2 switches within the network using a protocol such as IS-IS, RIP, or (EIGRP) as long as the edge switches have a reachable connection to the router.
FIG. 3 illustrates an example network containing layer 2 switches coupled to an emulated switch. When a packet is to be sent from a host 300 to a network, such as the Internet, coupled to the emulated switch 302, it may forward the packet to the closest edge switch 304. However, this host 300 does not have a MAC address of a default router in its memory, such as an address resolution protocol (ARP) cache. Therefore, the host 300 may first send a request for the router anycast address as, for example, an ARP request. The ARP request is a broadcast packet that is transmitted across the DCE network on the broadcast tree. Since the set of routers is part of an emulated anycast switch, only one link into the emulated anycast switch receives the ARP request. This may be accomplished by, for example, coordination between edge switches connected to a particular emulated switch. The link on which the request is sent is connected to a single router, despite the fact that the router may be a part of an emulated switch.
The router that receives the ARP request may ARP reply by sending a unicast packet to the ARP requesting host. This allows the first-hop switch, directly connected to the host, to know the edge switch associated with the router. This edge switch may be identified according to the switch identification associated with the emulated anycast switch. The ARP reply may be sent with the source MAC address equal to the router anycast MAC address so that the edge switches, directly connected to the hosts, associate the MAC address with the emulated anycast switch.
At this point the host's off subnet traffic will find the shortest path to the emulated anycast switch. This may or may not be the same router that replied to the ARP request. For example, while router 306 may have responded to the ARP request, the path to router 308 may actually be the shortest path for traffic. Other hosts will find their own shortest paths to the emulated anycast switch, which may be through a different router. This effectively load balances between the redundant routers in the emulated switch. Additionally, if the connection to a particular router goes down, either by a topology change in the network or the router itself goes down, traffic is quickly rerouted to other routers. This is because a protocol, such as DCE, used in a network containing layer 2 switches, can discover topology changes or downed links much faster than a hot standby routing protocol such as HSRP, VRRP or GLBP. A solution is provided that takes advantage of this fact to perform failover much quicker than prior art solutions since failover can now be performed by the network of switches itself.
Assume host A 300 wants to discover a MAC address for one of the routers 306, 308. It may transmit the ARP packet depicted in FIG. 4. The IP source address 400 may be the IP address of A. The IP destination address 402 may be the anycast IP address of SW7. The Layer 2 destination address 404 of the packet may be set to broadcast (all addresses). The layer 2 source address 406 may be Host-A 406.
Upon receipt of the ARP packet from Host A 302, switch SW1 304 learns Host A 300 is off a particular interface (for example, interface 2). It may then append the MAC-in-MAC header depicted in FIG. 5. Here, the destination 500 may be set to broadcast, since the packet is still an ARP request, while the source may be set to SW2, 2, indicating switch 2, interface 2. A loop-free broadcast tree may be built which includes emulated SW5, and thus the tree indicates the shortest path to emulated SW7 302 (this may have been performed earlier in the process than the receipt of the ARP request). The ARP request may then be passed via the shortest path to emulated switch SW7. However, edge switch SW5 310, recognizing that the next switch is an emulated switch, may strip the MAC-in-MAC header. One of the routers 306, 308 may receive the ARP request and respond with an ARP reply. Here, it is assumed that this would be router 308. Upon receiving the ARP reply, edge switch SW5 310 may add a MAC-in-MAC header to arrive at the packet depicted in FIG. 6. The destination address 600 of the MAC-in-MAC header in the reply may be SW1. The source address 602 of the MAC-in-MAC header of the reply may be emulated switch SW7. An interface identification may also be included but such a value is irrelevant anyway since the packet is not going to be used to perform forwarding. Edge switch SW5 310 may then learn that router 308 is on its interface (e.g., interface 2). This information may be synchronized with information on switches throughout the DCE network, so that each switch knows that router 308 is on the interface of edge switch SW5 310. The ARP reply may then flow through switches 312, 304 to host A 300.
When host 300 then wishes to send normal traffic out through the anycast hardware address corresponding to emulated switch SW7 302, SW2 304 may receive the traffic. It may then look up the anycast hardware address in its table, finding that it is on emulated switch SW7. It then may add the MAC-in-MAC header to the traffic and forward it via the shortest path to emulated switch SW7. Once again, edge switch 310 recognizes that switch SW7 is an emulated switch and strips the MAC-in-MAC header off prior to forwarding it on. By doing so, routers 306 and 308 have been load balanced because a packet originating from host A 300 will be transmitted through router 308 (using the shortest path) while a packet originating from sever B 314 will be transmitted through router 306. In cases where both paths are equal, a tie-breaking mechanism may be used such as hashing based on the source address. Additionally, as stated above, if one link goes down, the DCE network is able to forward all packets to the other router until such time as the link is restored.
FIG. 7 illustrates an example method for handling a hardware address request, such as an ARP request or an IPv6 Neighbor Solicitation, to a first router in an emulated switch of two or more routers. This process may be performed at a layer 2 edge switch in a network containing layer 2 switches. At 700, the hardware address request may be received from a layer 2 switch. This request may be an ARP request and may include a layer 2 network header (e.g., MAC-in-MAC header) that was added to the request by another layer 2 switch (not necessarily the layer 2 switch from which the request was directly received). At 702, this layer 2 network header may be stripped from the request. At 704, the hardware address request may be forwarded to the first router. It does not matter which router within the emulated switch is designated as the first router. At 706, a hardware address reply may be received from the router. This reply may be an ARP reply and may include an anycast hardware address shared between each router in the emulated switch. At 708, a layer 2 network header, such as a MAC-in-MAC header, may be added to the hardware address reply. At 710, the hardware address reply may be forwarded to another layer 2 switch. This may or may not be the same layer 2 switch as in 700.
FIG. 8 illustrates an example method for handling a packet received at a layer 2 edge switch from a router in an emulated switch of two or more routers. At 800, the packet may be received. The packet may be an ARP reply but it could also be ordinary traffic. The packet may include an anycast hardware address shared between each router in the emulated switch. At 802, the anycast hardware address may be added to a table along with an identification of the edge switch. This table may be periodically synchronized with tables associated with other layer 2 switches in the network. At 804, a layer 2 network header, such as a MAC-in-MAC header, may be added to the packet. At 806, the packet may be forwarded to another layer 2 switch in the network.
FIG. 9 illustrates an example method for handling a packet from a host at an edge switch in a network containing layer 2 switches. At 900, the packet may be received. The packet may include an anycast hardware address of an emulated switch corresponding to a plurality of routers. At 902, a switch identifier may be determined for the emulated switch using the anycast hardware address. This may be determined by, for example, looking up the anycast hardware address in a table to retrieve the switch identifier. At 904, a header may be added to the packet, the header including the switch identifier. This header may be a layer 2 network header, such as a MAC-in-MAC header. At 906, the packet may be forwarded to another layer 2 switch along the shortest path to the emulated switch. The shortest path may be determined by for example, referencing a spanning tree created for the switches, including the emulated switch. If there is a tie between two paths such that the shortest path cannot be determined based on distance, the tie may be broken by, for example, referencing a hash table based upon the source address of the packet.
FIG. 10 illustrates an example method for handling a packet from a host at an edge switch in a network containing layer 2 switches. At 1000, the packet may be received. The packet may include a destination anycast hardware address of an emulated switch corresponding to a plurality of routers. At 1002, a switch identifier may be determined for the emulated switch using the anycast hardware address. This may be determined by, for example, looking up the anycast hardware address in a table to retrieve the switch identifier. At 1004, a header may be added to the packet, the header including the switch identifier. This header may be a layer 2 network header, such as a MAC-in-MAC header. At 1006, a shortest path to the emulated switch may be determined. At 1008, it may be determined if the shortest path includes a link that is inoperative. If so, then at 1010, a new shortest path may be selected that does not include a link that is inoperative. At 1012, the packet may be forwarded to another layer 2 switch along a path representing the shortest path to the emulated switch. The shortest path may be determined by for example, referencing a spanning tree created for the switches, including the emulated switch. If there is a tie between two paths such that the shortest path cannot be determined based on distance, the tie may be broken by, for example, referencing a hash table based upon the source address of the packet.
FIG. 11 illustrates an example apparatus for handling a hardware address request to a first router in an emulated switch of two or more routers. This apparatus may be a layer 2 edge switch or a portion of a layer 2 edge switch (e.g., software). A hardware address request receiver 1100 may receive the hardware address request from a layer 2 switch. This request may be an ARP request and may include a layer 2 network header (e.g., MAC-in-MAC header) that was added to the request by another layer 2 switch (not necessarily the layer 2 switch from which the request was directly received). A layer 2 network header stripper 1102 coupled to the hardware address request receiver 1100 may strip this layer 2 network header from the request. A hardware address request forwarder 1104 coupled to the layer 2 network header stripper 1102 may forward the hardware address request to the first router. It does not matter which router within the emulated switch is designated as the first router. A hardware address reply receiver 1106 may receive a hardware address reply from the router. This reply may be an ARP reply and may include an anycast hardware address shared between each router in the emulated switch. A layer 2 network header adder 1108 coupled to the hardware address reply receiver 1106 may add a layer 2 network header, such as a MAC-in-MAC header, to the hardware address reply. A hardware address reply forwarder 1110 coupled to the layer 2 network header adder 1108 may forward the hardware address to another layer 2 switch. This may or may not be the same layer 2 switch as before.
FIG. 12 illustrates an example apparatus for handling a packet received at a layer 2 edge switch from a router in an emulated switch of two or more routers. A packet receiver 1200 may receive the packet. The packet may be an ARP reply but it could also be ordinary traffic. The packet may include an anycast hardware address shared between each router in the emulated switch. An anycast hardware address table adder 1202 coupled to the packet receiver 1200 may add the anycast hardware address request to a table along with an identification of the edge switch. This table may be periodically synchronized with tables associated with other layer 2 switches in the network. A layer 2 network header adder 1204 coupled to the anycast hardware address table adder 1202 may add a layer 2 network header, such as a MAC-in-MAC header, to the packet. A packet forwarder 1206 coupled to the layer 2 network header adder 1204 may forward the packet to a layer 2 switch in the network.
FIG. 13 illustrates an example apparatus for handling a packet from a host at an edge switch in a network containing layer 2 switches. A packet receiver 1300 may receive the packet. The packet may include an anycast hardware address of an emulated switch corresponding to a plurality of routers. A switch identification unit 1302 coupled to the packet receiver 1300 may determine a switch identifier for the emulated switch using the anycast hardware address. This may be determined by, for example, looking up the anycast hardware address in a table to retrieve the switch identifier. A switch identifier header adder 1304 coupled to the switch identification unit 1302 may add a header to the packet, the header including the switch identifier. This header may be a layer 2 network header, such as a MAC-in-MAC header. A shortest path packet forwarder 1306 coupled to the switch identifier header adder 1304 may forward the packet to another layer 2 switch along a path representing the shortest path to the emulated switch. The shortest path may be determined by for example, referencing a spanning tree created for the switches, including the emulated switch. If there is a tie between two paths such that the shortest path cannot be determined based on distance, the tie may be broken by, for example, referencing a hash table based upon the source address of the packet.
FIG. 14 illustrates an example apparatus for handling a packet from a host at an edge switch in a network containing layer 2 switches. A packet receiver 1400 may receive the packet. The packet may include a destination anycast hardware address of an emulated switch corresponding to a plurality of routers. A switch identification unit 1402 coupled to the packet receiver 1400 may determine a switch identifier for the emulated switch using the anycast hardware address. This may be determined by, for example, looking up the anycast hardware address in a table to retrieve the switch identifier. A switch identifier header adder 1404 coupled to the switch identification unit 1402 may add a header to the packet, the header including the switch identifier. This header may be a layer 2 network header, such as a MAC-in-MAC header. A shortest path determiner 1406 coupled to the switch identifier header adder may determine a shortest path to the emulated switch. A shortest path inoperative link determiner 1408 coupled to the shortest path determiner 1406 may determine if the shortest path includes a link that is inoperative. If so, then a new shortest path determiner 1410 coupled to the shortest path inoperative link determiner may select a new shortest path that does not include a link that is inoperative. A shortest path packet forwarder 1412 coupled to the shortest path inoperative link determiner 1408 and the new shortest path determiner 1410 may forward the packet to another layer 2 switch via a path representing the shortest path to the emulated switch. The shortest path may be determined by for example, referencing a spanning tree created for the switches, including the emulated switch. If there is a tie between two paths such that the shortest path cannot be determined based on distance, the tie may be broken by, for example, referencing a hash table based upon the source address of the packet.
In each of these embodiments, various protocols may be used (for example, DCE using the IS-IS protocol). Additionally, in each of these embodiments, it is no longer necessary to run a hot standby routing protocol.
FIG. 15 illustrates a simplified architecture of DCE switch 1500. DCE switch 1500 includes N line cards, each of which characterized by and ingress side (or input) 1205 and an egress side (or output) 1525. Line card ingress sides 1505 are connected via switching fabric 1550, which includes a crossbar in this example, to line card egress sides 1525. In this embodiment, one or more of the processes described above is performed by one or more of the line cards.
Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. For example, it is possible that an edge switch is connected to multiple routers within a single emulated switch. Accordingly, the embodiments described are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
forwarding the hardware address reply to a third layer 2 switch.
adding the anycast hardware address to a table along with an identification of the first layer 2 switch.
synchronizing the table with one or more tables associated with one or more layer 2 switches other than the first layer 2 switch.
4. The method of claim 1, wherein the first layer 2 switch, the second layer 2 switch, and the third layer 2 switch belong to a same network that includes a plurality of layer 2 switches that include the first, second, and third layer 2 switches, and wherein each of the routers of the emulated switch is configured as a layer 3 gateway device of the same network for forwarding data between devices of this same network and devices outside this same network, via one or more of the switches of this same network.
forwarding the packet to a second layer 2 switch.
adding the anycast hardware address to a table along with an identification of the edge switch.
forwarding the packet to another layer 2 switch along a shortest path from the layer 2 edge switch to the emulated switch.
9. The method of claim 8, wherein the determining includes looking up the anycast hardware address in a table to retrieve the switch identifier.
10. The method of claim 8, wherein the shortest path is determined based on a source address of the packet, using a hash table, if the shortest path cannot be determined based on distance due to a tie between two or more paths.
forwarding the packet to another layer 2 switch via the shortest operative path.
12. The method of claim 11, wherein the determining includes looking up the anycast hardware address in a table to retrieve the switch identifier.
13. The method of claim 11, wherein the shortest path is determined based on the source address of the packet, using a hash table, if the shortest path cannot be determined based on distance due to a tie between two or more paths.
14. The method of claim 11, wherein the network containing a plurality of layer 2 switches is a Data Center Ethernet (DCE) network.
15. The method of claim 11, wherein the header is a MAC-in-MAC header.
16. The method of claim 11, wherein the routers do not run a hot standby routing protocol.
forward the packet to another layer 2 switch via the shortest operative path.
18. The layer 2 edge switch of claim 17, wherein the layer 2 edge switch is a DCE switch.
19. The layer 2 edge switch of claim 17, wherein the header is a MAC-in-MAC header.
means for forwarding the packet to another layer 2 switch via the shortest operative path.
21. The apparatus of claim 20, wherein the network containing a plurality of layer 2 switches is a Data Center Ethernet (DCE) network.
CN First Office Action mailed Aug. 18, 2011 in Chinese Application No. 200880003496.0.
CN First Office Action mailed Feb. 12, 2010, in Chinese Application No. 200580034955.8.
CN Fourth Office Action mailed Jan. 10, 2011, in Chinese Application No. 200580034647.5.
CN Second Office Action mailed Aug. 11, 2010, in Chinese Application No. 200580034955.8.
CN Third Office Action mailed Dec. 3, 2010, in Chinese Application No. 200580034955.8.
CN Third Office Action mailed Jul. 6, 2011, in Chinese Application No. 200580034646.0.
EPO Extended Search Report mailed Jul. 16, 2009, in EP Application No. 05810244.3.
EPO Extended Search Report mailed Jun. 1, 2011 in EP Application No. 05812799.4.
EPO Office Action mailed Apr. 12, 2011, in EP Application No. 05810244.3.
EPO Office Action mailed May 19, 2011, in EP Application No. 05810800.2.
EPO Office Action mailed Nov. 18, 2011, in EP Application No. 08728248.9.
F. Kamoun, et al., "Analysis of Shared Finite Storage in a Computer Network Node Environment Under General Traffic Conditions", IEEE Transactions on Communications, Jul. 1980.
Floyd et al., Random Early Detection Gateways for Congestion Avoidance, Lawrence Berkeley Laboratory, Univ. of California, IEEE/ACM Transactions on Networking, Aug. 1993, 22 pages.
IEEE Standards 802.3(TM)-2002, IEEE Computer Society, Mar. 8, 2002, 1538 pages.
IEEE Standards 802.3ah(TM)-2004, IEEE Computer Society, Sep. 7, 2004, 623 pages.
IEEE Standards 802.3ah™—2004, IEEE Computer Society, Sep. 7, 2004, 623 pages.
IEEE Standards 802.3ak(TM)-2004, IEEE Computer Society, Mar. 1, 2004, 52 pages.
IEEE Standards 802.3ak™—2004, IEEE Computer Society, Mar. 1, 2004, 52 pages.
IEEE Standards 802.3™—2002, IEEE Computer Society, Mar. 8, 2002, 1538 pages.
InfiniBand Arch, Spec, vol. 1. Oct. 24, 2000 Final. Infiniband SM Trade Association.
InfiniBand Arch, Spec, vol. 2. Oct. 24, 2000 Final. Infiniband SM Trade Association.
International Search Report, dated Sep. 21, 2006 from corresponding International Application No. PCT/US05/37069, 4 pp.
International Search Report, mailed Feb. 20, 2007, from related International Application No. PCT/US05/37651, from International Application No. PCT/US05/37651.
International Search Report, mailed Jan. 16, 2007, from related International Application No. PCT/US05/37239from International Application No. PCT/US05/37239.
International Search Report, mailed Nov. 1, 2006 from related International Application No. PCT/US05/36700, 3 pp. including Notification of Transmittal.
International Search Report, mailed Oct. 18, 2006, from related International Application PCT/US05/37765, 3 pp. including Notification of Transmittal.
K. Ramakrishnan et al., "The Addition of Explicit Congestion Notification (ECN) to IP," RFC 3168, Sep. 2001.
PCT Search Report mailed Sep. 27, 2007 from International Application No. PCT/US06/38858, including Notification of Transmittal, (4 pp.).
PCT Written Opinion mailed Sep. 27, 2007 from International Application No. PCT/US06/38858, including Notification of Transmittal, (4 pp.).
U.S. Appl. No. 10/777,886, entitled "End-to-End Congestion Control", filed on Dec. 18, 2001.
U.S. Office Action mailed May 14, 2009, for U.S. Appl. No. 11/248,933.
US Final Office Action mailed Dec. 28, 2009 in related U.S. Appl. No. 11/248,933.
US Final Office Action mailed Sep. 16, 2011 in related U.S. Appl. No. 11/400,671.
US Notice of Allowance mailed Aug. 26, 2011 in related U.S. Appl. No. 12/485,337.
US Notice of Allowance mailed Feb. 22, 2011, in related U.S. Appl. No. 11/084,587.
US Notice of Allowance mailed Feb. 4, 2011, in related U.S. Appl. No. 11/248,933.
US Notice of Allowance mailed Jul. 17, 2009 in related U.S. Appl. No. 11/155,388.
US Notice of Allowance mailed Nov. 25, 2011 in related U.S. Appl. No. 11/825,631.
US Notice of Allowance mailed Oct. 7, 2011 in related U.S. Appl. No. 11/842,866.
US Notice of Allowance mailed Oct. 8, 2010 in related U.S. Appl. No. 11/248,933.
US Office Action mailed Apr. 13, 2011 in related U.S. Appl. No. 12/485,337.
US Office Action mailed Mar. 17, 2011 in related U.S. Appl. No. 11/400,671.
US Office Action mailed May 13, 2010 in related U.S. Appl. No. 11/248,933.
US Office Action mailed May 26, 2011 in related U.S. Appl. No. 11/825,631.
US Office Action mailed May 27, 2011 in related U.S. Appl. No. 11/842,866.
US Office Action mailed May 29, 2008 in related U.S. Appl. No. 11/155,388.
Written Opinion of the International Searching Authority, dated Sep. 21, 2006 from corresponding International Application No. PCT/US05/37069, 7 pp.
Written Opinion of the International Searching Authority, mailed Nov. 1, 2006 from related International Application No. PCT/US05/36700, 5 pp.
Written Opinion of the International Searching Authority, mailed Oct. 18, 2006, from related International Application PCT/US05/37765, 7 pp.

References: Application No. 200880003496
 Application No. 200580034955
 Application No. 200580034647
 Application No. 200580034955
 Application No. 200580034955
 Application No. 200580034646
 Application No. 05810244
 Application No. 05812799
 Application No. 05810244
 Application No. 05810800
 Application No. 08728248