Title of Invention: AGILE DATA CENTER NETWORK ARCHITECTURE Abstract: This patent application relates to an agile network architecture that can be employed in data centers, among others. One implementation provides a virtual layer-2 network connecting machines of a layer-3 infrastructure. Detailed Description: PRIORITY This patent application claims priority from U.S. Provisional Application No. 61/182,063, filed on 2009 May 28. BACKGROUND Conventional data center network architectures suffer from several design drawbacks which can undermine their agility (their ability to assign any server of a data center network to any service). First, the configurations of conventional networks are typically tree-like in nature and consist of relatively expensive equipment. This can result in congestion and the development of computational hotspots—even when spare capacity is available elsewhere in the network. Second, conventional data center networks do little to prevent a traffic flood in one service from affecting the other services around it. When one service experiences a traffic flood, it is common for all those services sharing the same network sub-tree to suffer collateral damage. Third, the routing design in conventional data center networks typically achieves scale by assigning servers topologically significant Internet Protocol (IP) addresses and dividing servers up among virtual local area networks (VLAN)s. However, this can create an enormous configuration burden when servers are reassigned among services, thus further fragmenting the resources of the data center. Furthermore, human involvement can typically be required in these reconfigurations, thus limiting the speed of this process. Finally, other considerations such as the difficulty in configuring conventional data center networks and the costs of equipment used in such networks can also negatively impact the agility of these networks. SUMMARY This patent application relates to an agile network architecture that can be employed in data centers, among others. One implementation provides a virtual layer-2 network connecting machines, such as servers of a layer-3 infrastructure. Another implementation includes a plurality of computing devices communicatively coupled via a plurality of switches. Individual computing devices can be associated with an application address. An individual computing device can be configurable to act as a source and another individual computing device can be configurable to act as a destination. The source computing device can be configured to send a packet to the application address of the destination computing device. This implementation can also include an agile agent that is configured to intercept the packet and to identify a location address associated with the destination computing device and to select an individual switch through which to send the packet to the location address. The above listed implementations are provided for introductory purposes and do not include and/or limit all of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings illustrate implementations of the concepts conveyed in the present application. Features of the illustrated implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings. Like reference numbers in the various drawings are used wherever feasible to indicate like elements. Further, the left-most numeral of each reference number conveys the figure and associated discussion where the reference number is first introduced. FIGS. 1-6 show examples of agile network architectures in accordance with some implementations of the present concepts. FIGS. 7-9 show examples of agile network data center layouts in accordance with some implementations of the present concepts. FIG. 10 is a flowchart of an agile network method that can be accomplished in accordance with some implementations of the present concepts. DETAILED DESCRIPTION Overview This patent application relates to an agile network architecture that can be employed in data centers, among others. Cloud services are driving the creation of huge data centers potentially holding tens to hundreds of thousands of servers. These data centers can concurrently support a large and dynamic number of distinct services (web apps, email, map-reduce clusters, etc.). The implementation of cloud service data centers can depend on a scale-out design: reliability and performance achieved through large pools of resources (e.g., servers) that can be rapidly reassigned between services as needed. The ability to assign any server of a data center network to any service can be considered the agility of a data center network. To effectively leverage the benefits of data centers, which can be associated with enormous costs, network agility can be valuable. Without network agility, data center server resources can be stranded, and thus money wasted. First Example Agile Network Architecture For introductory purposes consider FIGS. 1-2 which show examples of an agile network architecture 100. The agile data network architecture 100 can include a plurality of server-side computing devices, such as servers 102(1), 102(2), 102(3), and 102(N). The terms server and machine should be understood to refer to any device that can send or receive data. For example, these terms should be understood to refer to any of: a physical server, a virtual machine that runs on a server (e.g., using virtualization technology),a computing device running a single operating system, a computing device running more than one operating system, computing devices running different operating systems (e.g., Microsoft Windows, Linux, FreeBSD), a computing device other than a server (e.g., a laptop, addressable power supply), or a portion of a computing device (e.g., a network attached disk, network-attach memory, a storage subsystem, a storage area network (SAN), a graphics processing unit, a numerical accelerator, a quantum computing device). The agile network architecture 100 can promote scalability relative to the number of servers. One way that the scalability can be achieved is by creating Ethernet-like flat addressing for the servers 102(1)-102(N) utilizing application addresses. Ethernet layer-2 semantics can be associated with achieving a network state that supports flat addressing where any internet protocol (IP) address can be assigned to any server connected to any network port—as if the servers were on a local area network (LAN). In this case, an application address (AA) 104(1), 104(2), 104(3), 104(N) can be assigned to each server 102(1), 102(2), 102(3), 102(N), respectively. From a server perspective, any server can talk to any other server via an associated application address 104(1), 104(2), 104(3), 104(N). This can be thought of as a layer-2 functionality, as the application addresses can be arranged in any fashion, including all those that would be valid for a Local Area Network (LAN) containing servers 102(1), 102(2), 102(3), 102(N). However, as will be explained below, in some implementations, the agile network architecture's underlying infrastructure may be layer-3 as leetimothy@example.com. Thus, these implementations can create a virtual layer-2 network 108 upon (or utilizing) the layer-3 infrastructure 106. There can be more than one virtual layer-2 network 108 created upon the same layer-3 infrastructure 106, and each server can belong to one or more of these virtual layer-2 networks 108. FIG. 2 introduces an external client 202 that is connected to agile network architecture 100 via the internet 204. The agile network architecture 100 can allow the external client to communicate with a global or location address 206 that is assigned to one or more of servers 102(1)-102(N) without the external client having knowledge of the application addresses 104(1)-104(N). These concepts are explained in more detail below in regards to the discussion of FIGS. 3-5. Second Example Agile Network Architecture FIG. 3 shows an example agile network architecture 300 upon which the above described concepts can be implemented. In this case, an external client 302 can communicate with an agile system 304 via the internet 306 and/or other network. In this implementation, agile system 304 includes a set of routers indicated generally at 308 and indicated with specificity at 308(1) to 308(N), a plurality of intermediate switches indicated generally at 310 and indicated with specificity at 310(1), 310(2), and 310(N), a plurality of aggregation switches indicated generally at 312 and indicated with specificity at 312(1), 312(2), and 312(N), a plurality of top of rack (TOR or ToR) switches indicated generally at 314 and with specificity at 314(1), 314(2), and 314(N), and a plurality of servers indicated generally at 316 and with specificity at 316(1), 316(2), 316(3), 316(4), 316(5), and 316(N). Due to space constraints of the drawings page, only six servers 316(1)-316(N) are illustrated here, but the agile system 304 can readily accommodate thousands, tens of thousands, hundreds of thousands, or more servers. Note that for sake of brevity and due to space constraints of the drawing page not all connections (i.e. communication paths) between components are illustrated in FIGS. 3-8. Servers 316(1) and 316(2) are associated with TOR switch 314(1) as a server rack 318(1). Similarly, servers 316(3) and 316(4) are associated with TOR switch 314(2) as a server rack 318(2), and servers 316(5) and 316(N) are associated with TOR switch 314(N) as a server rack 318(N). Again, this is due to space constraints of the drawing page; often, server racks include ten or more servers. Further, individual servers can be associated with an agile agent. For instance, server 316(1) is associated with an agile agent 320(1). Similar relationships are shown between servers 316(2)-316(N) and agile agents 320(2)-320(N), respectively. The function of the agile agents 320(1)-320(N) is described in more detail below. Briefly, the agile agents can facilitate communication between individual servers. In this particular instance, the agile agents can be thought of as logical modules stored upon the servers as computer-readable instructions. Other implementations can involve configurations where the agile agent 320 that serves a set of servers is located on a switch, for example a TOR switch 314 or an Intermediate switch 310. When located on a switch, the agile agent can process packets as they flow up the network from servers 316 towards the Intermediate switch 310. In such configurations the agile agent 320 might be implemented using a combination of custom hardware on the packet forwarding path and software instructions that execute in the forwarding path or in a control processor of the switch. Agile system 304 further includes three directory service modules 322(1)-322(N). The illustrated number of directory service modules is not critical to the agile system and other implementations can employ fewer or more directory service modules (and/or other illustrated components). The function of the directory servers is discussed in more detail below. Briefly, the directory service modules can contain, among other information, application address-to-location address mappings (either or both forward and reverse mappings) that can be utilized by the agile agents 320(1)-320(N) (and/or other components) to facilitate communications over agile system 304. In this case, the directory service modules 322(1)-322(N) are associated with specific servers 316(1), 316(3), and 316(5). In other configurations, the directory service modules can occur with other components, such as data center control servers, switches, and/or on dedicated computing devices. Agile system 304 can be thought of as containing two logical groupings. The first logical grouping is a link state network carrying location or global addresses as leetimothy@example.com. The second logical grouping is a fungible pool of servers that own application addresses as leetimothy@example.com. Briefly, components of the link state network 326 don't need to exchange information to track which server in the pool of servers 328 is currently using which application address. Also, from a server's perspective, a server can communicate with any other server in server pool 328 via the other server's application address. This process is facilitated by the agile agents, directory service, and/or other components in such a manner as to be transparent to the servers. Stated another way, the process can be transparent to applications running on the servers, though other components on the server may be aware of the process. Routers 308, intermediate switches 310, aggregation switches 312, TOR switches 314 and servers 316(1)-316(N) can be communicatively coupled, such as using layer-3 technologies. From an individual server's perspective, communication with other servers appears as layer-2 communications (i.e., virtual layer-2). However, inter-rack communication, such as from source server 316(1) of server rack 318(1) to destination server 316(3) of server rack 318(2) actually occurs over the layer-3 infrastructure. For instance, agile agent 320(1) can intercept the communication (i.e., packet addressed to the application address of server 316(3)) and facilitate transmission thereof. Agile agent 320(1) can access one or more of the directory service modules 322(1)-322(N) to obtain a mapping of an application address to a location address associated with server 316(3). For instance, the mapped location address may be to TOR switch 314(2). The agile agent can encapsulate the packet with the location address. The agile agent can then select an individual (or a set of) aggregation and/or intermediate switch(es) over which to send or bounce the encapsulated packet. Features of this selection process are described in more detail below. Upon receipt of the encapsulated packet at TOR switch 314(2), the TOR switch can de-capsulate the packet and send the packet on to server 316(3). In alternative embodiments, the location address might be associated with the server 316(3) or a virtual machine running on server 316(3), and the packet can be decapsulated on the destination server itself. In these embodiments, the location address assigned to the server or virtual machine might be hidden from other applications operating on the server so as to maintain the illusion to the applications that they are connected by a LAN on which the application address is the address other hosts use to communicate with them. In alternative embodiments, the packets may be decapsulated by other components upon crossing the layer-3/layer-2 boundary. For instance, examples of components that can perform the decapsulation can include the hypervisor and/or the root partition of the virtual machine monitor. This configuration can allow servers to be added to server pool 328 in great numbers, yet from the servers' perspective other servers can appear as though they are on the same sub-network. Alternatively or additionally, the components of the link state network 326 do not need to be aware of the server application addresses. Further, whenever address information changes, such as when a server is added or removed, the directory server(s) can simply be updated, rather than having to update multiple different types of components. In summary, layer-2 semantics can be associated with achieving a network state that supports flat addressing where any IP address can be assigned to any server connected to any network port—as if the servers were on a LAN. Also, components (i.e., switches) in the link state network 326 can be aware of other components within the link state network but do not need to be aware of components of the server pool 328. Further, the TOR switches can know about the servers in their respective racks, but do not need to know about servers of other racks. Further still, agile agents can intercept server application address (AA) packets and identify a location address (LA) associated with the AA's destination computing device. The agile agent can then select an individual switch (or set of switches) through which to send the packet to the LA. In this case, the individual switch can include any one or more of the available switches. This configuration also facilitates another server feature relating to service. For instance, data center management software, such as may be contained in the directory service modules 322(1)-322(N), can assign any server 316(1)-316(N) to any service and configure that server with whatever IP address the service expects. The network configuration of each server can be identical to what it would be if connected via a LAN, and features such as link-local broadcast can be supported. The objective of communication isolation between services can be associated with providing an easy and consistent application program interface (API) for defining services and communication groups. In this regard, the directory service can define groups of servers associated with a service (e.g., a customer). Full connectivity can be permitted between servers in a group, and policies such as Access Control List (ACL) may be specified for governing which servers in different groups should be allowed to communicate. The above configuration further lends itself to traffic management. For purposes of explanation, assume that a first customer pays a relatively high rate for services to be performed by servers of agile system 304 and accordingly gets a relatively high quality of service agreement. Further, assume that a second customer pays a relatively lower rate and accordingly receives a relatively lower quality of service agreement. In such a case, a relatively high percentage, or all, of the intermediate switches 614-408-9080(N) can be assigned to handle traffic for the first customer, while a smaller number of the switches can be assigned to the second customer. Stated another way, a first sub-set of the switches can be assigned to the first customer and a second sub-set of the switches can be assigned to the second customer. The first and second sets can be mutually exclusive or overlapping. For instance, in some implementations, individual switches can be dedicated to a particular customer or assigned to multiple customers. For example, intermediate switch 310(1) can be assigned to both of the customers, while intermediate switches 310(2) and 310(N) can be exclusively assigned to the first customer. To summarize, and as will be explained in more detail below, the agile network architecture 300 can be associated with one or more of the following objectives: uniform high capacity between servers, performance isolation between services, Ethernet layer-2 semantics, and/or communication isolation between services. An objective of a uniform high capacity between servers can be associated with achieving a network state where the rate of traffic flow in the network is primarily unlimited except by the available capacity on the network interface cards of the sending and receiving servers. As such, from a developer's perspective, by achieving this objective, network topology may no longer be a primary concern when adding servers to a service. The objective of performance isolation between services can be associated with achieving a network state where the traffic of one service is unaffected by the traffic handled by any other service—as if each service was connected by a separate physical switch. An objective of Ethernet layer-2 semantics can be associated with achieving a network state that supports flat addressing where almost any IP address can be assigned to any server connected to any network port—as if the servers were on a LAN. As such, data center management software can assign any server to any service and configure that server with whatever IP address the service expects. The network configuration of each server can be identical to what it would be if connected via a LAN, and features such as link-local broadcast can be supported. The objective of communication isolation between services can be associated with providing an easy and consistent API for defining services and communication groups. In this regard, a directory system (i.e., via for instance, directory service modules 322(1)-322(N)) defining groups of servers can be provided. Full connectivity can be permitted between servers in a group, and policies may be specified for governing which servers in different groups should be allowed to communicate. By utilizing the described agile network architecture, a data center network can be provided that is associated with one or more of the following network characteristics: (1) flat addressing to allow service instances to be placed anywhere in the network, (2) load balancing (e.g., valiant load balancing (VLB)) that uses randomization to spread traffic uniformly across network paths, and (3) a new end system based address resolution service to achieve layer-2 Ethernet semantics while scaling to large server pools. To achieve the above-noted objectives, in at least some embodiments, one or more of the following agile network architectural design principles can be employed in various implementations. Utilizing a Topology with Extensive Path Diversity By utilizing a “meshy” topology, multiple paths between individual sets of servers can be provided. For instance, communications between servers of server rack 318(1) and servers of server rack 318(N) may go from TOR switch 314(1) through any of aggregation switches 312(1)-312(2) to any of intermediate switches 614-408-9080(N). From the intermediate switch the communication can go through either of aggregation switches 312(2)-312(N) to TOR switch 314(N). This configuration can result in several benefits. For example, the presence of multiple paths can enable reduction and/or elimination of congestion from the network without the need for explicit traffic engineering or the tuning of parameters. Further, multiple paths allows for a “scale-out” network design. In other words, more capacity can be added by adding more low cost switches. In contrast, the conventional hierarchical network designs concentrate traffic in one or a very few links at higher levels of the hierarchy. As a result, conventional networks may require the purchase of expensive “big iron” switches to cope with the high density of traffic. Further still, by utilizing the “meshy” topology, the multiple paths can allow for graceful degradation as links or switches fail. For example, an agile network implemented according to the described agile data center network architecture with “n” switches at a given layer may lose only 1/n of its capacity when a switch fails, as compared to a conventional network that may lose 50% of its capacity. An agile network implemented according to the described agile data network architecture can potentially utilize the complete bipartite topology. Randomizing to Address Volatility Data centers can have tremendous volatility in their workload, their traffic, and their failure patterns. Accordingly, large pools of resources can be created. Work can then be spread over them randomly; some performance on the best-cases can be traded off to improve the worst-case to the average case. In at least some embodiments, a topology (e.g., for example as evidenced in FIG. 3) associated with an extensive path diversity can be utilized. Work flows can be routed across the topology using a load balancing technique, such as a Valiant Load Balancing (VLB) technique. Briefly, VLB techniques can involve randomly selecting the path or paths used to carry a data transmission, where a path is composed of a series of links and or switches. Subsequently, the path can be reselected, where reselection entails changing one or more of the switches or links that comprise the original path. The reselection can occur periodically, such as after sending/receiving a specified number of bytes/packets, and/or responsively upon indication of transmission problems associated with the selected path, switch, or link. For instance, if packet delay or other communication impairment is detected, then the selection process can be repeated. Through application of this principle the uniform capacity and performance isolation objectives can be met. More particularly, to address volatility and uncertainty in data center traffic matrices, the load balancing technique (e.g., VLB) can be utilized to hash flows randomly across network paths. An objective to this approach can be to provide bandwidth guarantees for arbitrary traffic variation subject to network ingress-egress constraints as in the hose traffic model. Briefly, the hose model specifies that data transmission rates over a given path cannot exceed a slowest or most constrained portion of the path. Using a load balancing technique like VLB at the flow granularity (meaning that most packets of a flow follow the same path through the network except when reselecting paths) can be advantageous, as it can reduce the chances that the packets of a flow will be reordered or experience rapidly changing latency perceived at the destination, and/or disrupt operations of path Maximum Transmission Unit (MTU) discovery protocols due to MTU differences within a flow. Some types of traffic (e.g., those not harmed by packet reordering) and some environments (e.g., those with very uniform delays along all paths) may prefer to use load balancing like VLB at a packet granularity (meaning that potentially different paths are used for each packet in a sequence of packets). Any of the commonly accepted definitions of flow can be used, for example: an IP 5-tuple flow, an IP 2-tuple flow, or the set of packets between two subnets or address ranges. In the context of providing an agile data center network, the ingress-egress constraints can correspond to server line card speeds. In combination with a high bisection bandwidth topology (e.g., a folded Clos topology), the load balancing technique can be utilized to create a non-interfering packet switched network (the counterpart of a non-blocking circuit switched network) and provide hot-spot-free performance for traffic patterns that do not have sustained loads exceeding server ingress-egress port speed. In this regard, in some implementations, the Transmission Control Protocol's (TCP) end-to-end congestion control mechanism can be utilized to enforce the hose model and avoid over-running server port speeds. This principle can lead to the logical topology illustrated in FIG. 3, which can consist of three different layers of switches: TOR 314, Aggregation 312, and Intermediate 310. A flow from one server to another can take a random path via a random intermediate switch, across TORs and Aggregation switches. A load balancing technique, such as VLB, can thus be utilized in the context of inter-switch fabric of a data center to smooth utilization while eliminating persistent traffic congestion. Separating Names From Locations Separating names from locations can create a degree of freedom that can be used to implement new features. This principle can be leveraged to enable agility in the data center networks and to improve utilization by reducing fragmentation that the binding between addresses and locations can cause. Through the application of this principle and the principle of embracing end systems described below, layer-2 semantics objectives can be met. As such, developers can be allowed to assign IP addresses without regard for the network topology and without having to reconfigure their applications or the network switches. To enhance network agility (supporting any service on any server, dynamic growing and shrinking of server pools, and workload migration), an IP addressing scheme can be used that separates names, termed AAs, and locators, termed LAs. An agile directory service, such as can be manifest as directory service modules 322(1)-322(N), can be defined to manage the mappings between AAs and LAs in a scalable and reliable fashion. The agile directory service can be invoked by a shim layer running in the networking stack on individual servers. In the implementation represented in FIG. 3, this shim layer can be manifested as agile agents 320(1)-320(N). Embracing End Systems Software, including operating systems, on data center servers is typically extensively modified for use inside the data center. For example, new or modified software can create hypervisors for virtualization or blob file systems to store data across servers. Rather than altering software on switches, the programmability of this software can be leveraged. Furthermore, changes to the hardware of the switches or servers can be avoided or limited and legacy applications can remain unmodified. By using software on the servers to work within limitations of the low-cost switch application-specific integrated circuits (ASICs) currently available, a design can be created that can be built and deployed today. For example, the scalability problems created by broadcast Address Resolution Protocol (ARP) packets can be reduced and/or eliminated by intercepting ARP requests on the servers and converting them into lookup requests to a directory system, rather than attempting to control ARPs via software or hardware changes on the switches. FIG. 4 shows an example agile agent 320(1) in more detail. In this case, agile agent 320(1) operates on a server machine 402 that includes a user mode 406 and a kernel mode 408. The server machine includes a user-mode agent 410 in the user mode. The kernel mode includes a TCP component 412, an IP component 414, an encapsulator 416, a NIC 418 and a routing information cache 420. The server machine can include and/or communicate with directory service 322(1). The directory service can include a server role component 422, a server health component 424, and a network health component 426. Agile agent 320(1) can include the user-mode agent 410, encapsulator 416, and routing information cache 420. Encapsulator 416 can intercept ARP and send it to the user-mode agent 410. The user mode agent can query the directory service 322(1). It should be understood that other arrangements of these blocks are possible, such as including the user mode agent into a kernel mode component or invoking the directory lookup via a mechanism other than ARP, such as during routing table lookup or via mechanisms such as IP tables or IP chains. In the agile network architecture of FIG. 3, an end-system control can provide a mechanism to rapidly inject new functionality. As such, the agility agent can provide a fine grained path control by controlling the randomization used in load balancing. In addition, to realize the separation of names and locators, the agile agent can replace Ethernet's ARP functionality with queries to the agile directory service. The agile directory service itself can be realized on servers, rather than switches. This agile directory service allows fine grained control of server reachability, grouping, access control, resource allocation (e.g., capacity of intermediate switches), isolation (e.g., non-overlapping intermediate switches), and dynamic growing and shrinking. Leveraging Network Technologies Utilizing one or more network technologies that have robust implementations in network switches can simplify the design of an agile network and increase operator willingness to deploy such a network. For example, in at least some embodiments, link-state routing protocols may be implemented on network switches to hide certain failures from servers and also can be leveraged to help reduce the load on the agile directory service. These protocols may be utilized to maintain the topology and routes for the agile network, which can reduce coupling between the agile directory service and the network control plane. Through a routing design that defines anycast addresses on the switches, the described agile architecture can leverage Equal Cost Multi-Path (ECMP) to hide the failure of switches from servers. This can further reduce the load on the directory system. Other routing protocols that support the use of multiple paths are also suitable. Implementation Details Regarding Virtual Layer Two Networking Examples Scale-Out Topologies Conventional networks typically concentrate traffic into a few switches at the highest levels of the network. This can both restrict the bisection bandwidth to the capacity of these devices and significantly impact the network when they fail. However, to avoid these problems, an agile network topology driven by the principle of using randomization for coping with traffic volatility can be utilized. In this regard, an approach of scaling out network devices can be taken. This can result in a relatively broad network of low complexity switches, as illustrated in FIG. 3, that can be dedicated to fast forwarding. This is an example of a folded Clos network where the links between the intermediate switches 614-408-9080(N) and the aggregation switches 312(1)-312(N) can form a complete bipartite graph. As in conventional topology, TORS can connect to two aggregation switches. However the large number of paths between any two aggregation switches means that if there are n intermediate switches, the failure of any of them reduces the bisection bandwidth by only 1/n—a desirable property that can be referred to as graceful degradation of bandwidth. Further, networks such as Clos networks can be designed so that there is no oversubscription. For example, in FIG. 3, aggregation and intermediate switches having a count of D interface ports can be used. These switches can be connected such that the capacity between each layer of switches is D*D/2 times the link capacity. Networks, such as Clos networks, can be exceptionally well suited for load balancing (e.g., VLB) in that by bouncing through an intermediate switch at the top tier or “spine” of the network, the network can provide bandwidth guarantees for potentially all possible traffic matrices subject to ingress-egress bounds at server line cards. Routing can be simple and resilient (e.g., a random path can be taken up to a random intermediate node and a random path taken down). The described agile architecture can provide greater path control than can be achieved with conventional network architectures. More particularly, intermediate nodes can be partitioned, and traffic classes dedicated to different partitions to allocate higher overall bandwidth to some traffic classes. Congestion indications can be signaled back to senders through Explicit Congestion Notification (ECN) or similar mechanisms, as in the Institute of Electrical and Electronics Engineers (IEEE) 802.1 Qau congestion control. As such, a sender that accumulates ECN signals could respond by varying the fields in the source packet used to choose alternative paths through the network (referred to as reselecting a path above). Agile Routing To implement the principle of separating names from locators, an agile network can use two IP address families. FIG. 3 illustrates such a separation. The network infrastructure can work in terms of LAs. Switches and interfaces 614-408-9080(N), 312(1)-312(N), and 314(1)-314(N), can be assigned LAs. The switches can run a link state IP routing protocol that carries these LAs. Applications, such as those running on servers 316(1)-316(N), can be unaware of LAs but aware of AAs. This separation can be associated with several benefits. First, packets can be tunneled to an appropriate LA rather than sent directly to an AA (the switches do not need to maintain a routing entry per host to deliver them). This means the agile directory service, which converts AAs to LAs, can implement policies regarding which services should be allowed to communicate. Second, low-cost switches often have small routing tables (e.g., 12K entries) that can hold all LA routes, but would be overwhelmed by the number of AAs. This concept can be especially valuable in that it can allow a network to be built that is bigger than the number of routing entries the switches can hold. Third, the separation enables agility since any AA can be assigned to any server without regard for topology. Fourth, the freedom to assign LAs separately from AA means that LAs can be assigned in such a manner as they can be summarized in a topologically significant fashion, further limiting the amount of routing state the switches must carry, while not impeding the ability to assign application addresses in whatever fashion is desired by the services running inside the data center or the data center's operators. Alternative embodiments of the invention might use other types of data for LA and AA addresses. For example, LA addresses could be IPv4 and AA addresses could be IPV6, or vice versa, or IPV6 address could be used for both AA and LA addresses, or IEEE 802.1 MAC addresses could be used as AA addresses while IP addresses (v4 or v6) are used for LA addresses, or vice versa, etc. Addresses can also be created by combining together different types of addresses, such as a VLAN tag or VRF identifier with an IP address. The following discussion explains how the topology, routing design, agile agent, and agile directory service can be combined to virtualize the underlying network fabric and create an illusion to servers 316(1)-316(N) of the agile network that they are connected to other servers 316(1)-316(N) of their group in a layer-2 LAN, and anything above it, and that the host is part of a relatively large data center-wide layer-2 LAN. Address Resolution and Packet Forwarding In at least some implementations, to enable servers 316(1)-316(N) to believe they share a single large VLAN with other servers in the same service while eliminating the broadcast ARP scaling bottleneck that can plague large Ethernets, the below mentioned solutions are provided. Preliminarily, it should be noted that the following solutions can be backwards compatible and transparent to existing data center applications. Packet Forwarding AAs typically may not be announced into the routing protocols of the network. Accordingly, for a server to receive a packet, the packet's source can first encapsulate the packet, setting the destination of the outer header to the LA for the host. Upon reaching the device holding the LA address, the packet is decapsulated and delivered to the destination server. In one embodiment, the LA for a destination server is assigned to the TOR under which the destination server is located. Once the packet arrives at its destination TOR, the TOR switch can de-capsulate the packet and deliver it based on the destination AA in the inner header, according to normal layer-2 delivery rules. Alternatively, an LA can be associated with the physical destination server or a virtual machine running on the server. Address Resolution Servers can be configured to believe that AA addresses are in the same LAN as them, so when an application sends a packet to an AA for the first time, the kernel network stack on the host can generate a broadcast ARP request for the destination AA. The agile agent running in the source server's networking stack can intercept the ARP request and convert it to a unicast query to the agile directory service. When the agile directory service answers the query, it can provide the LA to which packets should be tunneled. It can also provide the intermediate switch or set of intermediate switches that can be used to bounce the packets. Inter-Service Access Control by Directory Service Servers may be unable to send packets to an AA if they cannot obtain the LA of the TOR to which they must tunnel packets for the AA. Accordingly, agile directory service 322(1)-322(N) can enforce communication policies. When handling a lookup request, the agile directory service knows which server is making the request, the service to which both source and destination belong, and the isolation policy between those services. If the policy is “deny”, the agile directory service can simply refuse to provide the LA. An advantage of the described agile network architecture is that when inter-service communication is allowed, packets can flow directly from sending server to receiving server, without being detoured to an IP gateway. This is unlike the connection of two VLANs in conventional architectures. Interaction with the Internet Often, approximately 20% of the traffic handled by data centers can be to or from the Internet. Therefore, it is advantageous for a data center network to be able to handle these large volumes. While it might at first seem strange that the described agile network architecture utilizes a layer-3 fabric to implement a virtual layer-2 network, one advantage of this is that external traffic can flow directly across the high-speed silicon of the switches that can make up an agile data center network with this architecture without being forced through gateway servers to have their headers rewritten, as required in some conventional and proposed network environments. Servers that need to be directly reachable from the Internet (e.g., front-end web servers) can be assigned two addresses: an LA and an AA. The LA can be used for internetwork communications. The AA can be used for intra-data-center communications with back-end servers. The LA can be drawn from a pool that is announced via Border Gateway Protocol (BGP) and that is externally reachable. Traffic from the Internet can then directly reach the server. Packets from the server to external destinations can be routed toward the core routers while being spread across the available links and core routers by ECMP. Handling Broadcasts The described agile network architecture can provide layer-2 semantics to applications for backwards compatibility. This can include supporting broadcast and multicast. The agile network architecture's approach is to eliminate the most common sources of broadcast completely, such as ARP and the Dynamic Host Configuration Protocol (DHCP). ARP can be handled by intercepting ARP packets in the agility agent 320 and providing a response after consulting information from the agile directory service as described above, and DHCP packets can be intercepted at the TOR using conventional DHCP relay agents and unicast forwarded to DHCP servers. To handle other broadcast packets, each set of hosts that should be able to receive broadcast packets sent by other hosts in that set can be assigned an IP multicast address. This address can be assigned by the directory system and agility agents can learn it by querying the directory system. Packets sent to the broadcast address can be modified to go to the service's multicast address instead. The agile network architecture's agile agent can rate limit broadcast traffic to prevent storms. The agile agent can maintain an estimate of the rate of broadcast packets the server has sent over recent time intervals (e.g., the past 1 second and past 60 seconds), and prevent the server from sending more than a configured number of broadcast packets during each interval. Packets sent in excess of the allowed can be either dropped or delayed until the next interval. Native IP multicast can also be supported. A potential advantage of embodiments where the switches operate as layer-3 routers is that implementing the delivery of packets addressed to a multicast group to all hosts or machines belonging to the multicast group is particularly easy. Any of the existing IP multicast routing protocols, such as PIM-BIDIR, can be configured onto the switches. This will cause them to compute a multicast distribution tree with endpoints at each host or machine belonging to a multicast group. The agility agent on the host, machine, or server registers the host, machine, or server as being part of the appropriate multicast groups, typically by sending IGMP join messages to its default gateway. The multicast routing protocols will then take care of adding the host, machine, or server to the distribution tree for that multicast group. Switches that operate at layer-2 can use a variety of mechanisms, such as a VLAN per multicast group, or flood filling packets through the network, with the agility agent on each host, machine, or server filtering out the packets that the agent's host, machine or server should not receive. Randomization with Multi-Path Routing The described agile network architecture can leverage/utilize the principle of using randomization to cope with volatility using, in at least some embodiments, two related mechanisms: VLB and Equal Cost Multipath (ECMP). The goals of both are similar—VLB distributes traffic randomly across intermediate nodes and ECMP sends traffic across equal cost paths so as to reduce or prevent persistent congestion. As explained in more detail below, VLB and ECMP can be complementary in that each can be used to overcome limitations in the other. Both mechanisms can provide controls that a packet's sender can use to influence the choice of paths across the network. The agile agent allows for these controls to be leveraged to avoid congestion. FIG. 5 illustrates a sub-set of the agile network architecture 300 that was introduced in FIG. 3. FIG. 5 offers further detail in server to server communications. This example involves server 316(1) communicating with server 316(5). Sending server 316(1) and destination server 316(5) can function in server pool 328 that functions as a VLAN and have an application address of 10.128/9. Intermediate switches 614-408-9080(N) reside in link state network 326. Agile network architecture 300 can allow the benefits of VLB to be accomplished by forcing packets to bounce off a randomly chosen intermediate node. In this case, the sender's agile agent 320(1) can implement this by encapsulating each packet to an intermediate switch 614-408-9080(N). The intermediate switch tunnels the packet to the destination's TOR (in this case 314(N)). Hence the packet can first be delivered to one of the intermediate switches, such as 310(2), decapsulated by the switch, delivered to the LA of TOR 314(N), decapsulated again and finally sent to the destination server 316(5). If the agile agent 320(1) knew the addresses of the active intermediate switches 614-408-9080(N), it could randomly choose among them when sending packets. However, this could require updating potentially hundreds of thousands of agile agents as intermediate switches fail. Instead, the same LA address can be assigned to multiple intermediate switches (in this case LA address 614-408-9080). The agile directory service (shown FIG. 3) can return this anycast address to agile agent 320(1) as part of one or more lookup results. ECMP can take care of delivering packets encapsulated to the anycast address to one of the active intermediate switches 614-408-9080(N). If a switch fails, ECMP can react, eliminating the need to notify agile agents. ECMP, however, may have scaling limitations. Conventional switches today can support 16-way ECMP, and 256-way ECMP switches may also be available or may soon be available. If there happen to be more paths available than ECMP can use, then VLB encapsulation can compensate. One solution is to define several anycast addresses, individual anycast addresses being associated with as many intermediate switches 614-408-9080(N) as ECMP can accommodate. Senders can hash across the anycast addresses to distribute the load, and, as switches fail, the anycast addresses can be reassigned to other switches by the directory system so that individual servers do not need to be notified. For purposes of explanation, this aspect can be thought of as a network control functionality offered by the directory system. The described VLB based oblivious routing can be implemented using pure OSPF/ECMP mechanisms on folded-clos network topology. Such a configuration does not need decapsulation support at the intermediate switches. For instance, if N is the number of uplinks on each TOR, then the aggregation switches can be grouped into sets. In some cases, each of these sets can contain exactly N switches. Each TOR can have an uplink to all N switches in a set, or to none of the switches in a set. With this wiring of the TORS, it can be shown that the bandwidth guarantees for arbitrary traffic subject to server ingress/egress constraints continue to hold even when protocols like OSPF and/or ECMP are used for routing between TORS. The use of OSPF or ECMP for routing between TORS can cause some packet(s), such as packets between two TORS in the same set of aggregation switches, to take a path that does not go through the intermediate switches. Thus, these paths can be termed “early turnaround paths” as they follow the shortest path between source and destination and allow early turnaround of traffic between servers under the same TOR or under TORS connected to the same aggregation switch or switches. These traffic flows do not need to enter the core aggregation/intermediate network. Potential benefits of using early-turnaround paths can include freeing up capacity in the core for other classes of traffic (e.g., external). The capacity freed could be substantial for the “average” case when existing applications have been written to minimize cross-TOR traffic, for example. Viewed another way, this can allow the core to be under-provisioned by some factor and still work just as well for server-to-server traffic. The use of early-turnaround paths can also allow wider range of devices to be used as Intermediate switches, resulting in lower costs for those switches. Coping with Congestion With both ECMP and VLB, there may be a chance that large flows will be hashed to the same links and intermediate switches respectively, which may cause congestion. If this should occur, the sending agile agent can change the path its flows take through the agile network by altering the value of the fields that ECMP uses to select a next-hop, that is, the next switch through which the packet should pass. In this regard, an agile agent can detect and deal with such situations with simple mechanisms, such as rehashing the large flows periodically or when a severe congestion event (e.g., a full window loss) or an Explicit Congestion Notification is detected by TCP or after sending/receiving a threshold number of bytes/packets. Maintaining Host Information A network system implemented according to the described agility network architecture can use a scalable, reliable, and/or highly performant store or directory system designed for data center workloads. A network implemented according to the agility network architecture can possess one or more of these four properties: uniform high capacity, performance isolation, L-2 semantics, and communication isolation between services. The network can also exhibit graceful degradation, where the network can continue to use whatever capacity remains after a failure. As such, the network can be reliable/resilient in the face of failures. In this regard, a directory system in such a network can provide two potentially key functionalities: (1) lookups and updates for AA-to-LA mappings, and (2) a reactive cache update mechanism that can support latency-sensitive operations, such as live virtual machine migration, for example. Characterizing Requirements A lookup workload for a directory system can be frequent and bursty. Servers can communicate with up to thousands or tens of thousands of other servers in a short time period with each flow generating a lookup for an AA-to-LA mapping. For updates, the workload can be driven by failures and server startup events. Many failures are typically small in size, and large correlated failures are likely rare. Performance Requirements The bursty nature of workload implies that lookups may require high throughput and low response time to quickly establish a large number of connections. Since lookups increase the time required to communicate with a server for the first time, the response time should be kept as small as possible: for instance, tens of milliseconds is a reasonable value. For updates, however, a potentially key requirement can be reliability, and response time may be less critical. Further, since updates are typically scheduled ahead of time, high throughput can be achieved by batching updates. Consistency Considerations In a conventional Layer-2 network, ARP can provide eventual consistency due to ARP timeout. In addition, a host can
{'application_number': '<application-reference appl-type="utility">\n<document-id>\n<country>US</country>\n<doc-number>12578608</doc-number>\n<date>20091014</date>\n</document-id>\n</application-reference>', 'publication_number': '<publication-reference>\n<document-id>\n<country>US</country>\n<doc-number>20100306408</doc-number>\n<kind>A1</kind>\n<date>20101202</date>\n</document-id>\n</publication-reference>', 'source_file': './application/2010/ipa101202.xml', 'source_data': 'USPTO-Application'}