Network Layer Implemented Anycast Load Balancing

Network layer implemented Anycast Load Balancing

Ricardo Lopes Pereira Teresa Vaz˜ao IST, Inesc-ID IST, Inesc-ID [email protected] [email protected]

Abstract only server availability, but also the network distance and conditions along the paths from client to server and vice- This paper presents a server selection method where the versa. This is also what routing protocols such as Open server selection is performed by the network, at the first Shortest Path First (OSPF) do, compute shortest paths. As- router from the client. This method, usable in networks un- signing each server the same anycast address [16] allows der single administrative control, combines network metrics each router to know the path towards the nearest server. (such as traffic or latency) with common server load bal- When clients use the anycast address to reach servers, the ancing metrics (such as load, CPU utilisation or response network layer will automatically forward packets to the time), allowing network conditions to be taken into account nearest server (according to the routing metrics) [9]. This when selecting the server which will handle the request. method is successfully being used today in the Internet to The performance of this technique was compared, by distribute User Datagram Protocol (UDP) queries by the means of simulations, to that of widely used techniques such Domain Name System (DNS) root servers [6]. as random, round robin and least loaded server selection. This paper presents a transparent load balancing technique usable on networks under common administrative control, which aims at providing unmodified clients with 1 Introduction better reply times while maximising the total number of requests handled by the set of servers. This method, which was named Network layer implemented Anycast Load Bal- Despite the advent of the Personal Computers (PC) and ancing (NALB), combines network proximity and server distributed computing, the client/server model still plays load information in order to achieve dynamic load balanc- a major role today. Many applications, such as Database ing resorting to anycast addresses and link cost variation on servers and Web Services, remain centralised due to their already deployed routing protocols. This technique was val- nature. The ubiquity of the Internet or intranets, coupled idated by means of simulation using the HyperText Trans- with the emergence of the web browser as a human inter- fer Protocol (HTTP) protocol, although it may be applied face, also dictates that many applications are developed us- to other applications such as DNS, Simple Mail Transfer ing the web server centric paradigm. However, this cen- Protocol (SMTP) or proxy servers. tralised approach has its weaknesses, as it presents a single Section 2 details the anycast concept, its strengths and point of failure. The concentration of all clients on the same limitations. Section 3 presents the proposed load balanc- server may also result in slow response times due to server ing scheme, which was compared with others by means of overload or large network delays or congestion along the simulations, whose results are provided in section 4. The path from client to server. conclusions are presented in section 5. Replicating the application across several servers will eliminate the single point of failure. Server load can be mit- igated by placing the application in a set of servers located 2 IPAnycast in the same Local Area Network (LAN). Network latency and congestion may be avoided by placing servers across The anycast concept was introduced into IP networking a Wide Area Network (WAN), closer to the clients. The in [16], which defines it as: the best effortdeliveryof a data- two methods can be combined by spreading several clusters gram to at least one, and preferably only one, of the servers across a WAN. that accept datagrams for the anycast address. IPv6 is the For each of these approaches different load balancing first version of the IP protocol to support anycasting, albeit methods are used to distribute the clients’ requests [1]. with limitations: anycast addresses may only be assigned to WAN load balancing techniques may take into account, not routers, not hosts; and may only be used as the destination of a packets, never as the source [7]. anycast (SPRA) directs packets to the nearest server; it can Given several servers sharing the same anycast IP ad- be performed on small or confined networks using tradi- dress and a proper routing infrastructure in place, clients tional routing protocols as OSPF [18]. Multi-path routing should be directed to the nearest server (in number of hops distributes packets among all servers within the same dis- or other routing metric). tance. Multi-path or global scale deployment of single-path routing require specialised routing protocols [4,20]. 2.1 Current combined anycast load balancing methods 2.3 Maintaining TCP connections

Different research proposals appeared combining any- Stateful connections methods, such as TCP, expect end- cast load balancing methods. points to remain the same throughout the life-time of the Ticket based probing combines anycast with server load connection, But anycast routing does not ensure that packets information by sending probes to several anycast servers. from the same connectionwill always reach the same server. They reply indicating they status (load). The status infor- Routing tables may change due to topology changes or due mation combined with the reply time provides server and to the introduction or removal of anycast servers. Several network information which is used to select the server [3]. proposals address the lack of stateful transport support by This method, however, is not transparent, requiring clients anycast, either by adding support applications, modifying to be modified. Most importantly, it requires routers to be Transmission Control Protocol (TCP) or using IPv6 packet modified, for probe packets to reach several anycast servers. headers. These demands complicate its deployment in a legacy net- A supportapplication may be used to inform the client of work. the unicast address of an anycast server [20]. An UDP ser- Instead of leaving to the client the decision of which vice, running at each anycast server on a well known port server to use, [11] proposes to restore it to the network, by would receive UDP probe packets from the clients, which using an active network. Active networks use routers capa- would use the anycast address as destination. The server ble of running user supplied code on each packet. In this would respond with a UDP message indicating its unicast approach routers communicate with the servers, gathering address, which the client would then use to establish the load information, which may eventually be piggybacked on TCP connection. Should several anycast servers respond, traffic from the servers. This information is then used to only the first would be used. This method requires modifi- forward packets destined to the anycast server address. The cations to the clients and may not be used by legacy clients. router chooses the best server and changes the packet’s tar- Clients will also require a mechanism to know when a target get address from the anycast address to the best server’s uni- address is an anycast address. This method adds a round- cast address. When packets arrive in the opposite direction, trip to the connection establishment process. the source address is changed, from the server’s unicast ad- A client could also determine the servers unicast address dress to the anycast one. This solution requires an active by sending a ping (ICMP ECHO request) to the anycast ad- network, the development of a communication protocol be- dress. The server would then respond (ICMP ECHO reply) tween servers and routers and uses anycast addresses as the using its unicast address [13]. source of packets, which IPv6 disallows. Modifications to the TCP protocol would enable it to A different approach consists in the utilisation of rout- overcome anycast limitations [16]. Just like standard TCP, ing protocols which determine anycast routes using net- clients would send a SYN packet to the server’s anycast ad- work metrics as well as server state information [10]. This dress. However, the SYN-ACK response would arrive not method requires routers to collect and propagate server’s from the anycast address but from the server’s unicast ad- state information. Legacy routers would have to be up- dress, which would be used from then on. A different pro- graded to support these routing protocols. posal is to extend TCP’s tree way handshake to a five way handshake, creating a first phase where the unicast address 2.2 Anycast addressing and routing of the server is determined [20]. These methods do not require the client to know, before hand, when the address is Anycast addresses can not be aggregated with other ad- an anycast one. Large scale TCP implementation substitu- dresses as they may be dispersed by several subnetworks tion, albeit simpler than legacy applications modification, and their world wide deploymentswould result in the explo- still represents a monumental endeavour. sion of the number of routing entries carried by each router. IPv6 packet extension headers may also be used to Nevertheless, they can be successfully used under sin- achieve the same goal [17]. The SYN-ACK response packet gle administrative control and several anycast intra-domain is extended with an header containing the anycast address, routing protocols have been proposed. Single-path routing while it originates on the server’s unicast address. The extension header allows the client to perceive the original ad- routing protocols with server status information. dress as anycast and allows it to match the SYN-ACK to its TCP connection. The ensuing packets will use the unicast 3 Network layer implemented Anycast Load address. This method requires a special TCP implementa- Balancing tion. The IPv6 source route option has also been used to pro- 3.1 NALB architecture vide connection capabilities to anycast [5]. The client sends a normal SYN packet to the anycast address. The server NALB is an intra-domain architecture that provides load responds with a SYN-ACK using its anycast address as balancing by using a routing protocol that combines both source, but providing a route option header with its unicast network and server status information. NALB can also be address. The client may then, if and only if the packet is combined with network QoS conditions should the intranet properly authenticated, reverse the route header, forward- run a QoS enabled routing protocol [19]. ing the next packets to the server’s unicast address [7]. The Anycast addresses are assigned to the servers of a NALB server, upon receiving the packets at its unicast address, for- domain and these servers will run the routing protocol, an- wards them to the anycast address, according to the route nouncing a route to the anycast address. However, when header. The closest interface to the server with the anycast receiving a packet for this address, a server will process it address will always belong to the server. Other than the as his. added size, the use of the source route option will not over- The announced cost of the link to the anycast address load the intermediate routers, as the route option header will will vary, according to the server state. Should the server be only be processed at the hosts. Assuming the IPv6 source overloaded, the cost will be very high, should it be idle the route option to be honoured at the TCP layer, this method cost would drop. When all the servers are idle, or equally would only require modifications to the servers’ software as loaded, clients will use their nearest server. When a server well as an authentication infrastructure in place. However, becomes overloaded it will announce a higher cost to the this method infringes on IPv6 as the server sends packets anycast address, causing the routing protocol to consider originated at its anycast address. it to be more “distant”. This will result in a number of clients now having a different nearest server, effectively be- 2.4 IP Anycast evaluation ing transfered from the overloaded server. Server failure is automatically supported as down servers In a network under single administrative control, cur- will stop announcing their routes to the anycast address, be- rent intra-domain routing protocols, such as OSPF, provide ing removed from the anycast group by the routing protocol. single-path anycast routing, by considering paths to different servers sharing the same anycast address to be different 3.2 Routing metrics paths to the same server. Routing table dimension is not a problem as the number of anycast addresses used will be Different type of metrics may be used to measure the limited. This enable anycast use with stateless protocols server status, namely: CPU usage, run queue length, num- such as DNS. ber of clients, transfer rate or a combination. However, The deployment of one of the methods described in sec- should the load metric used be relative to each server’s per- tion 2.3 on a single owner intranet is viable, enabling TCP formance (like CPU usage) and not absolute (such as num- connections. Strict standard compliance may also be over- ber of requests being served) NALB method will automati- looked if the anycast methods are confined to the intranet. cally allow servers with different capacities to be used. In these conditions, SPRA load balancing is possible, di- The load metrics used, as well as the link cost variation recting clients to the nearest server, while also minimising should be fine tuned for best results experimentally. Fur- network traffic. The possibility of transparently using any- thermore, the link cost should only be increased when the cast without requiring client modifications makes it an at- load crosses a threshold, as assigning a client to a more dis- tractive option. However, [2] shows that scheduling each tant server to avoid a mildly loaded server might prove a client to the nearest server (networkwise) may caused un- bad move. balanced servers, resulting in higher response times, due to The periodicity of routing announcements will also have large variations in each network region’s traffic, attributable to be fine tuned for best performance. A trade-off must be to population distribution, time zones and hour of day. The achieved between the added network traffic and router pro- load unbalance caused by SPRA will prevent servers from cessing caused by frequentupdatingand the inaccurate view being used to the fullest and increases the response time for provided by making updates sparse. However, the added clients assigned to overloaded servers. A better result may routing traffic may be compensated by the global traffic be achieved by combining the network metrics used by the diminution granted by having clients use the nearest server. 3.3 Application examples

Figure 1 presents a situation where two anycast servers provide service to four clients. Servers S1 and S2 each have their own unicast address but both share the anycast address A. Routers are connected by links with a unitary cost. In this situation, both servers are under low load, announcing a cost of one towards the anycast address. The dashed lines encompass the clients closest to each server: clients C1 and C2 will use server S1, clients C3 and C4 will use server S2. Figure 2 portrays a scenario where S1 is under heavier load than S2. S1 reacts by increasing the announced route Figure 2. Left server under heavier load cost towards the anycast address. As a result C1 will now be closer to S2 and will use this server for future requests. S1 reduced the number of potential clients to one whereas S2 To each of the 25 core routers a network island was will now have to handle three clients. Clients are diverted attached. Network islands are all identical, each having from the server with the higher load to the one least loaded. 20 HTTP clients connected at 100Mb/s, 30 at 10Mb/s and 40 at 1Mb/s. Servers, connected to the core routers using 4 Simulation results 100Mb/s links, where placed on opposite sides of the network. The proposed method was compared with traditional The OSPFv2 routing protocol was used. A stateful con- HTTP load balancing methods via simulation, performed nection mechanism for anycast was assumed to be in place. using the 2.0.0 version of the SSFNet network simulator HTTP 1.1 with persistent connectionsand no pipeliningwas [15]. The simulator was modified to implement CPU pro- used. cessing delays, traditional load balancing algorithm, any- Whenever a client established a connection, the schedul- cast and the proposed method (including server perfor- ing algorithm was used by it to choose a server. mance measurement). Round robin state is keep globally. When a client The load balancing alternatives used where: SRPA, chooses server 1, the next client will choose the second source IP address hashing, random, round robin and least server and vice-versa. The least loaded algorithm is perfect, loaded. The utilisation of a single server, with capacity in the sense that it has instant up-to-date knowledge of the equal to the sum of that of all servers, was also tested in servers’ status. The least loaded server is considered to be order to provide a baseline for comparison. the one with the smallest CPU run queue, to which clients have instant access with no network overhead. 4.1 Simulation scenario As the server selection is performed at the client, no dispatching overhead is included. Traditional dispatching The core network of large American ISP, with points-of- mechanisms such as DNS, server redirection or triangula- presence in 25 cities was used. It spans four time zones, tion will add a further overhead to traditional load balanc- making it a good candidate for a dynamic load balancing ing techniques which does not affect SPRA or NALB. In technique. these simulations this overhead is not accounted, providing traditional load balancing techniques an advantage. The routing protocol uses link costs proportional to the link delay, which in turn is proportional to its distance. With NALB, servers generate new route announcements every 15 minutes. CPU utilisation is measured in 5 minute intervals. CPU’s utilisation moving average is used as the server’s load metric. The route to the anycast address will present a cost of 1 whenever this average is inferior to 50% and a cost from 1 to 25 when the moving averageraises abovethis figure. The longest core links present a cost of 30. Four adjacent time zones where defined: zone 0 has 6 islands, zone1 has2, zone2 has 7 andzone3 has10. Simula- tions were run overa 24 hourperiod,after a 2 hourwarm-up Figure 1. Two servers with equal load period. The client generated traffic was defined as an office work day, with low traffic during the night and lunch time, 100 and high activity during work hours (9 to 13 and 15 to 19). 80 Clients are simulated to perform like real persons. They access the web site in sessions, which occur from time to 60

time. During each session they will visit several pages, tak- 40 20 Link cost

CPU usage (%) 16 ing some time to read each one before going on to the next. 12 20 Each web page will be constituted by an HTML object and 8 4 several binary objects such as images, each with its own 0 0 2H 5H 8H 11H 14H 17H 20H 23H 2H size. For each object request the server will require some Time (s) CPU time. Servers assign 5ms CPU time slices to each re- S1 CPU S1 Link cost S2 CPU S2 Link cost quest using a round robin scheduler. Replies are only sent to the clients after the request has received the required CPU Figure 3. CPU usage using SPRA and 10Mb/s time. Clients timeout a request when the reply is not fully received within 20 minute. Simulations where performed with 100Kb/s, 1Mb/s and 10Mb/s links connecting the core routers. No traffic other to the previous SPRA scenario. Server 2’s traffic also in- than OSPF’s and HTTP’s existed. Links with 100Kb/s are creases more gradually. The same effect is visible during insufficient to responds to the demands of the clients, be- the afternoon period. This enables the set of servers to ser- coming the bottleneck. In this case the load balancing vice a greater number of requests, as shown in table 1. mechanism has to overcome the network limitations. Over- NALB also fares well when compared to the classical dimensioned 10Mb/s links guarantee traffic to flow swiftly load balancing methods. Table 1 shows the number of re- across the network, making servers the bottleneck. Here the quests successfully satisfied by each method during the af- load balancing mechanism has to divert clients to the least ternoon peak. Similar results were observed when consid- loaded server. 1Mb/s links provide a test where both server ering the entire duration of the simulation. CPU and network capacity are at a premium. When the core network bandwidth is limited to only 100Kb/s, it becomes the bottleneck. Under this scenario 4.2 Results analyses server capacity is not an issue. NALB and SPRA behave ex- actly the same as CPU utilisation remains bellow 50%, pre- The existence of different timezones, each with a differ- venting servers from announcing higher route costs. Any- ent number of clients, results in unbalance traffic generation cast assigns each clients to the closest server, limiting each across the network. Fig. 3 shows how the load is distributed request’s traffic to part of the network. Client locality re- across both servers when using SPRA. The thin lines repre- duces global traffic, enabling a better utilisation of the avail- sent CPU usage while the thick lines represent the moving able bandwidth. As a result, anycast is capable of answering average. In the beginning of the day, clients in the east start a significantly larger number of requests. peakingand, being closest to server 2, will cause it to have a Reply time is also better, as shown in Fig. 5. For each larger load than server 1. Server 2 remains the most loaded load balancing method the graphic shows the Cumulative during the day as it is closest to a larger number of clients Distribution Function (CDF) of the reply time. than server 1. Towards the end of the day, the roles are in- verted. Server 2’s load starts to decrease as the end of the day approaches. On the other hand, server 1 still has a sig- 100 nificant number of clients due to the 3 hour difference from 80 the east to the west of the network, and becomes the most loaded server. Overall, server 2 has to support a signifi- 60

cantly larger load. 40 20 Link cost

CPU usage (%) 16 Using NALB the load gap between servers is reduced as 12 20 8 can be observed in Fig. 4. The thin lines on the bottom 4 0 0 represent the link cost, which is read against the right ver- 2H 5H 8H 11H 14H 17H 20H 23H 2H tical axis. Around 8h, server 2 crosses the CPU utilisation Time (s) S1 CPU S1 Link cost threshold, prompting the cost of its link to the anycast ad- S2 CPU S2 Link cost dress to raise. As a result, the routing algorithm will determine that the shortest path to the anycast address for some Figure 4. CPU usage and link cost using of the network islands, now passes through server 1. Conse- NALB and 10Mb/s quently, server 1 has an increase in traffic when compared diverting clients from the loaded server to the least loaded Table 1. Successful requests from 14 to 17 one. However, this comes at a price. Fig. 6 shows that the Link speed reply time using NALB is higher than that of SPRA. Scheduler 100Kb/s 1Mb/s 10Mb/s Network bandwidth is still a bottleneck, as can be ob- NALB 64915 159382 180793 served by the relative performance of the other methods, SPRA 64915 152610 178207 which are similar to those attained using 100Kb/s links. IP hash 56941 129092 178159 10Mb/s links allow the network not to obstacle perfor- least loaded 50622 115548 181115 mance. Server CPU speed becomes the single bottleneck. In these simulations each serverrepresents what in a real de- random 60984 123908 179102 ployment would be a cluster of servers. Therefore, servers round robin 57980 125208 181255 are quick to respond to requests, and are only overloaded single server 40986 90458 179291 during the peak hours of the day, as may be observed in Fig. 3 and 4. This results in very homogeneous results for the several methods used. Reply time is also very similar, Due to the bandwidth limitations, no method is able to as shown in Fig. 7. serve more than 20% of the requests in under 5 second. SPRA no longer performs significantly better than tra- NALB and SPRA, whose lines overlap, show a clear ad- ditional methods with regard to the number of successful vantage over the other protocols. replies. NALB, however, by diverting further away clients IP hash, random and round robin present similar results to a least loaded server is capable of providing nearby as they all distribute clients over the two servers in close to clients with a fast response time, while only making far uniform ways. away clients move to the least loaded server. Clients fur- The selection of least loaded server will allocate most ther away from the loaded server may not be much fur- traffic to the first server, as server analyses is always per- ther away from the new server, suffering little impact from formed in the same order,and run queuelength will be zero. the move, while releasing some capacity on the overloaded As a consequence, the network surrounding it will be more server. This explains the better response time NALB ex- loaded, decreasing its response capacity. Therefore, it will hibits. not perform as well as the other methods. Least loaded performs comparably to NALB in terms of The worst performance is shown when using a single number of replies, but presents worse reply times, due to server. As all packets must cross the core links surround- client to server paths. Round robin also performs very well ing the server, these will become overloaded. Nevertheless, as it provides the most uniform client distribution. Using as the server’s CPU has double the capacity of all others, a single server, with double the capacity, does not turn out the processing time is smaller, resulting in a large number to be a problem as the network is capable of forwarding all of successful replies under 1 second. traffic easily. When 1Mb/s links are used in the core, CPU also becomes scarce in face of the large number of requests. In 5 Conclusion this situation, although SPRA performs the second best, it is outperformed by NALB. The SPRA method’s performance In this paper a load balancing method is presented that is limited by the CPU shortage during peak hours. NALB combines network proximity and server load information. method is capable of serving a larger number of requests, by This is accomplished by combining anycast mechanisms

0.8

0.7

0.6

0.5 0.1 0.4

NALB 0.3 NALB SPRA SPRA

Cumulative request ratio IP hash Cumulative request ratio 0.2 IP hash least loaded least loaded random random round robin 0.1 round robin single server single server 0 0 0 1 2 3 4 5 0 1 2 3 4 5 Reply time (s) Reply time (s)

Figure 5. Request reply time using 100Kb/s Figure 6. Request reply time using 1Mb/s References 0.9 0.8 0.7 [1] V. Cardellini, M. Colajanni, and P. S. Yu. Dynamic load bal- 0.6 ancing on web-server systems. 3(3):28–39, May-June 1999. 0.5 [2] V. Cardellini, M. Colajanni, and P. S. Yu. Geographic load 0.4 balancing for scalable distributed Web systems. In Proc. 8th NALB 0.3 SPRA International Symposium on Modeling, Analysis and Simu-

Cumulative request ratio IP hash 0.2 least loaded lation of Computer and Telecommunication Systems, pages random 0.1 round robin 20–27, San Francisco, CA, 2000. single server 0 [3] H. Chang, W. Jia, and L. Zhang. Distributed server selection 0 1 2 3 4 5 Reply time (s) with imprecise state for replicated server group. In Proc. 7th International Symposium on Parallel Architectures, Al- Figure 7. Request reply time using 10Mb/s gorithms and Networks, pages 73–78, May 2004. [4] S. Doi, S. Ata, H. Kitamura, and M. Murata. IPv6 anycast for simple and effective service-oriented communications. 42(5):163–171, May 2004. with varying link costs, forcing the routing protocol to for- [5] R. Engel, V. Peris, and D. Saha. Using IP anycast for load ward clients’ packets to the best server. This method was distribution and server location. In Proc. 3rd Global Internet compared to ideal implementation of traditional load bal- Mini-Conf., pages 27–35, Nov. 1998. ancing methods and single path routing anycast using sim- [6] T. Hardie. Distributing authoritative name servers via shared ulation. The results suggest it to perform as well or better unicast addresses. IETF RFC3258, Apr. 2002. than the other methods under different network conditions. [7] R. Hinden and S. Deering. Internet Protocol, Version 6 It also proved robust, providing consistent results under the (IPv6) Speciﬁcation. IETF RFC2460, Dec. 1998. different scenarios. [8] R. Hinden and S. Deering. IP Version 6 Addressing Archi- tecture. IETF RFC2373, July 1998. Although this method is not yet applicable to the Inter- [9] R. M. Hinden. IP next generation overview. Commun. ACM, net at large, it could be deployed on large corporate or ISP 39(6):61–71, 1996. networks. The method is completely distributed, supports [10] C.-Y. Lin, J.-H. Lo, and S.-Y. Kuo. Load-balanced anycast servers with different capacities and can overcome server routing. In Proc. Tenth International Conference on Parallel failure. and Distributed Systems, pages 701–708, July 2004. [11] H. Miura, M. Yamamoto, K. Nishimura, and H. Ikeda. The proposed load balancing method was used in HTTP Server load balancing with network support: Active anycast. load balancing simulations, yet nothing prevents it from be- In H. Yasuda, editor, IWAN, volume 1942 of Lecture Notes ing applied to other applications. in Computer Science, pages 371–384. Springer, 2000. Though simulations suggest this method to be better than [12] J. Moy. OSPF Version 2. IETF RFC2328, Apr. 1998. traditional ones, further work could be performed to over- [13] M. Oe and S. Yamaguchi. Implementation and Evaluation come some of its limitations. Anycast methods allow pack- of IPv6 Anycast. In Proc. 10th Annual Internet Soc. Conf., ets from client to server to travel the shortest path. However, 2000. [14] A. Ogielski. How to write DML network models. SSFNet in Web applications, the bulk of the trafﬁc is in the opposite Tutorial. direction. A server more distant to the client might present [15] A. Ogielski, D. Nicol, J. Cowie, et al. SSFNet network sim- a shorter path in the reverse direction. ulator. More complex server load metrics could be used, other [16] C. Partridge, T. Mendez, and W. Milliken. Host anycasting than CPU usage. Running queue length, connected clients, service. IETF RFC1546, Nov. 1993. bandwidth being consumed or a combination of these could [17] S. Shah and D. Sanghi. Host Anycast Support in IPv6. be tested. In Proc. of 5th Int’l Conf. on Advanced Computing (AD- COMP), Dec. 1997. Currently each server/cluster works independently, alter- [18] K. H. Tan, M. Yaacob, T. C. Ling, and K. K. Phang. IPv6 ing its link cost without regarding the other servers’ state. single-path and multi-path anycast routing protocols perfor- Cooperation between the servers could be established to mance analysis. In ISICT ’03: Proceedings of the 1st in- better balance the load. ternational symposium on Information and communication The simulations were performed using a single server at technologies, pages 555–560. Trinity College Dublin, 2003. [19] Z. Wang. Internet QoS: Architectures and Mechanisms for each location. In a real deploymentseveral servers would be Quality of Service. Morgan Kaufmann, Mar. 2001. used, in a cluster. Only one of them would run the routing [20] S. Weber and L. Cheng. A survey of anycast in IPv6 net- protocol, requiring knowledge of the other’s state to pro- works. 42(1):127–132, Jan. 2004. duce an aggregate link cost. Resilience would have to be introduced into the protocol, for this server to be replaced by one of the others should it fail.