Computer Communications 33 (2010) 365–371

Contents lists available at ScienceDirect

Computer Communications

journal homepage: www.elsevier .com/locate /comcom

SCTP for robust and flexible IP anycast services

Tim Stevens *, Daan Pareit, Filip De Turck, Ingrid Moerman, Bart Dhoedt, Piet DemeesterGhent University—IBBT, Department of Information Technology (INTEC), Gaston Crommenlaan 8, Bus 201, 9050 Ghent, Belgium

a r t i c l e i n f o

Article history:Received 3 August 2009Received in revised form 1 October 2009Accepted 2 October 2009Available online 13 October 2009

Keywords:AnycastSCTPOverlay networkStateful communications

0140-3664/$ - see front matter � 2009 Elsevier B.V. Adoi:10.1016/j.comcom.2009.10.002

* Corresponding author. Tel.: +32 9 3314900.E-mail addresses: tim.stevens@intec.ugent.be (T.

ugent.be (D. Pareit).

a b s t r a c t

IP anycast is a powerful network layer mechanism that can be used for transparent communicationsbetween clients and a distributed service infrastructure. Unfortunately, large-scale deployment of IP any-cast would cause a number of severe problems, including excessive routing table growth and potentialrouting instability. In order to solve these problems, a number of overlay network architectures havebeen proposed over the last years. In this paper we show that the robustness of anycast services providedvia such anycast architectures can be significantly improved by using SCTP transport layer facilities. Morespecifically, the proposed approach adds the following important features to existing anycast overlays:Robustness to anycast overlay node failure or network reconfiguration, seamless anycast service deliveryto mobile clients, and true stateful anycast communications over an entirely stateless infrastructure. Fur-thermore, we argue that the number of overlay nodes can be drastically reduced in comparison with theearlier architectures, without degrading service quality or increasing the end-to-end path stretch.

� 2009 Elsevier B.V. All rights reserved.

1. Introduction

IP anycast [1] enables communications between a sender and asingle node out of a group of potential receivers, usually the near-est group member based on network distance. In practice, networklayer anycast is realized by assigning the same IP address to allmembers of the anycast group, whereupon the routing infrastruc-ture is reconfigured to take into account all potential anycast targetlocations. From the sender’s perspective, communicating with ananycast group (member) is indistinguishable from traditional uni-cast communications. This, combined with the fact that anycastgroups can support an arbitrarily large number of members (by de-sign), makes IP anycast a powerful network layer tool for distrib-uted service provisioning.

Despite these promising features, present operational use of IPanycast in the Internet is essentially limited to DNS root server rep-lication [2]. This is because IP anycast introduces serious networkproblems, including routing scalability issues and potential routinginstability caused by joining or leaving anycast group members.Over the past decade, several network layer solutions have beenproposed that—at least partially—address these anycast issues.One of the first proposals is the Global IP Anycast (GIA) frameworkdue to Katabi and Wroclawski [3], where anycast routing scalabil-ity is achieved by introducing a GIA-specific address prefix andadding extra anycast logic to routers that distinguishes betweenpopular and unpopular anycast destinations. More recently, Ballani

ll rights reserved.

Stevens), daan.pareit@intec.

and Francis [4] have proposed the Proxy IP Anycast Service (PIAS).PIAS is an overlay infrastructure providing anycast routing scala-bility, network stability, and full transparency towards clients. Inshort, PIAS edge nodes attract anycast traffic and silently tunnelanycast packets towards their final destinations based on anycastdestination IP address and TCP port information. The Architecturefor Scalable and Transparent Anycast Services (ASTAS) proposed byStevens et al. [5] elaborates on PIAS by introducing a fine-grainedtarget selection mechanism that improves resource utilization effi-ciency, albeit at the expense of adding extra complexity to theoverlay nodes.

Even though PIAS and its derivative ASTAS enable practical useof IP anycast for large scale deployments and a virtually unlimitednumber of coexisting anycast services, there are still a number oflimitations that prevent ideal service provisioning:

(1) The mechanism is non-resistant to network configurationchanges or overlay node failures.

(2) PIAS and ASTAS lack support for stateful services on mobileclients, even when Mobile IP (MIP) [6] is used.

(3) The overlay edge nodes introduce packet forwardingbottlenecks.

In this paper, we show how the interaction between an anycastoverlay infrastructure and the Stream Control Transmission Protocol(SCTP) [7] provides an elegant and natural solution for the abovementioned operational shortcomings related to anycast communi-cations. The proposed solution relies on overlay nodes only duringsession initialization, but supports true stateful, flexible, and ro-bust anycast services. Moreover, overlay nodes do not maintain

Fig. 2. PIAS [4] data path.

366 T. Stevens et al. / Computer Communications 33 (2010) 365–371

individual session state, which significantly improves overall scala-bility of the proposed architecture.

The remainder of this paper is structured as follows. Section 2reviews existing anycast architectures and differentiates betweennetwork and application layer anycasting mechanisms. New designgoals to improve IP anycast-based service provisioning are dis-cussed in Section 3. In Section 4, we reveal our architectural any-cast solution based on SCTP. The discussion in Section 5 revisitsthe initial design objectives and comments on minor limitations.Finally, Section 6 concludes the paper.

2. Background

Similar to multicast, anycast communications can be realized intwo fundamentally different ways: Either at the application layeror at the network layer. Fig. 1 depicts both anycasting techniques.Application layer anycast consists of two successive phases: First, ahigher layer redirection mechanism (indicated by R in Fig. 1(a)) re-solves the anycast service identified by A to a regular (unicast) IPaddress. Once the client C1 receives the IP address, the server S1is contacted directly using unicast communications (step 2). Inter-mediate routers forward IP packets over the shortest path to theirdestination. Most often, the redirection service R is implementedusing the Domain Name System (DNS) infrastructure. Zeguraet al. [8] show how application layer anycasting can be used forsuccessful web server replication. Freedman et al. [9] further opti-mize end-to-end latency for DNS-based anycasting through theirOASIS infrastructure that selects target servers based on a mappingof the Internet to geographical coordinates. Although applicationlayer anycast is the easiest to deploy, it has the disadvantage thattarget selection and connection establishment cannot be combinedin an inseparable, one-step operation. Once a unicast IP address isdiscovered, the redirection mechanism can be bypassed for subse-quent service requests, eventually disrupting load-balancingmechanisms or centralized management tasks (e.g., accounting).

Native IP anycast [10] immediately forwards IP packets targetedat an anycast group to the nearest group member, as depicted inFig. 1(b). This simple property makes it an appealing packet deliv-ery mode in the context of distributed service provisioning, be-cause the network automatically selects a target server for eachinitiated service request. From the client perspective, communicat-ing with the group is no different from unicast communications.Unfortunately, the benefits of IP anycast are largely overshadowedby the severe network problems it introduces, which immediatelyexplains its limited use in today’s Internet. IP anycast suffers from:

(1) Excessive routing table growth: Contrary to IP unicast, routesto anycast destinations cannot be aggregated because any-cast group members may be scattered all over the Internet,i.e., there is no correlation between anycast IP address andphysical location. Hence, routing tables grow linearly withthe number of globally deployed anycast groups.

Fig. 1. Application and network layer anycasting side by side.

(2) Frequent route updates: Each joining and leaving anycastgroup member potentially triggers a cascade of routing tableupdates in a large network area. If the target joining and/orleaving frequency is too high, this results in networkinstability.

The Proxy IP Anycast Service (PIAS) architecture proposed byBallani and Francis [4] eliminates these anycast deployment prob-lems in an elegant way and opens the door for global IP anycastdeployment. Additionally, PIAS enables to select a target serverbased on several criteria (e.g., server load) instead of only minimiz-ing end-to-end path length. The basic working principles of PIASare depicted in Fig. 2. PIAS consists of inbound (e.g., P1) and out-bound (e.g., P2) overlay nodes called proxies. Proxies behave justas regular routers for unicast traffic, but anycast traffic is handleddifferently. Furthermore, PIAS assumes that all anycast addressesare grouped in a small number of IP address ranges. By making thisassumption, it is easy to configure the PIAS proxies to capture allanycast traffic. This is achieved by advertising a route to these any-cast IP ranges through the proxies. In short, setting up a session viaPIAS takes place in five steps (See Fig. 2):

(1) An anycast packet is attracted by the nearest proxy P1.(2) The inbound proxy P1 tunnels (IP-in-IP [11]) this packet to a

suitable outbound proxy P2 in the neighborhood of an actualtarget server for the requested service.1

(3) The outbound proxy decapsulates the tunneled packet andinitiates a connection with the target server S1 on behalfof the client C (using Network Address Translation (NAT)[12]).

(4) S1 sends a return packet to P2, thinking P2 is the actual cli-ent (due to NAT).

(5) P2 performs NAT on the return packet and forwards itdirectly to the client C (via unicast routing).

New anycast target servers join by sending a registration mes-sage to their nearest proxy, again by using native anycast. Serverstatus updates are sent in a similar way (step U in Fig. 2).

Stevens et al. [5] have extended PIAS to the Architecture forScalable and Transparent Anycast Services (ASTAS) in order to en-able fine grained control over outbound proxy selection in inboundproxies, and to enhance support for stateful communications. TheASTAS data path is depicted in Fig. 3. Differences between the AS-TAS and PIAS data path are the following:

(1) ASTAS inbound proxies maintain session state to enable persession outbound proxy selection.

1 Appropriate outbound proxies are located via a distributed registry. This is notshown in Fig. 2.

Fig. 3. ASTAS [5] data path.Fig. 5. Established PIAS and ASTAS connections are broken when a client nodemoves to a new location. The return path is not depicted.

T. Stevens et al. / Computer Communications 33 (2010) 365–371 367

(2) Outbound ASTAS proxies use stateful tunneling instead ofNAT to communicate with the anycast targets for IPv6compliance.

(3) Return packets are tunneled to the inbound proxy (step 5) tobe able to track session state in these proxies.

(4) The inbound proxy decapsulates the return packet and for-wards it to the client (step 6).

3. Design goals

The anycast overlay architectures PIAS and ASTAS reviewed inthe previous section truly enable Internet-wide adoption of IP any-cast services without risk for destabilizing the installed IP networkinfrastructure. Nonetheless, the robustness of IP anycast serviceprovisioning by means of aforementioned overlay systems—oreven native anycast—could be drastically improved if a numberof additional limitations could be eliminated. In this paper, weput forward the following extra design goals that are not addressedby PIAS and ASTAS:

(1) Immunity from proxy failure: Fig. 4 depicts a first problemrelated to PIAS and ASTAS. Initially, anycast traffic from theclient is delivered to its closest proxy node P1 (step 1). WhenP1 fails (step 2), the network reconfigures itself (e.g., OSPF orBGP recovery from failure) and anycast traffic is delivered tothe second closest proxy P4 (step 3), which is not noticed bythe client. This is not a problem for newly created sessions,but established connections are broken because each inboundproxy autonomically selects the most suitable outboundproxy (PIAS: semi-fixed, ASTAS: session based), with itsown locally registered target servers (S1 or S2).

(2) Mobility support: Today, the number of mobile devices andmultihomed Internet hosts increases steadily. In this con-text, a second shortcoming of the existing anycast architec-tures becomes apparent. As depicted in Fig. 5, a client sets upa connection to an anycast service from its current locationvia proxy P1 (step 1). Subsequently, the client moves toanother location (step 2) and expects its anycast service to

Fig. 4. Established PIAS and ASTAS connections are broken when a proxy fails. Thereturn path is not depicted.

continue—just as if the service would have been set up toa unicast destination. Imperceptibly to the client, P4becomes the closest proxy and attracts the client’s anycasttraffic (step 3), which again results in a broken session.

(3) Highly scalable anycast data exchange: As illustrated in Fig. 6,all data exchanged between anycast servers and clients isdelivered via the PIAS or ASTAS overlay infrastructure. Sinceby design only a small fraction of all Internet routers isupgraded to an anycast proxy (both for PIAS and ASTAS),proxies may attract more traffic than they can actually pro-cess and become a performance bottleneck (e.g., when any-cast services gain popularity, when services exchange alarge amount of data). In addition, network paths leadingtowards the proxies might experience congestion, whichalso hampers non-anycast services. In short, these anycastproxy infrastructures partially undo the decentralized nat-ure of the Internet.Apart from the architectural centralization, proxies also per-form tasks that are more complicated than simple packetforwarding. Depending on the architecture (PIAS or ASTAS),one or two proxies on the client–server path maintain ses-sion state and perform IP tunneling encapsulation and/ordecapsulation. Obviously, this further limits the totalamount of data that can be transported via the anycast infra-structure.In order to evaluate the impact of these additional tasks onpacket forwarding performance, an ASTAS prototype nodewas constructed by implementing extra modules for theClick modular router [13]. The evaluation results for Linux/Click running on top of common PC hardware equipped withgigabit Ethernet interfaces are depicted in Fig. 7. The differ-ence in maximum throughput between the regular Clickrouter and the ASTAS proxy for 96-byte IP packets gives aclear indication of the additional complexity involved inanycast operations. Note that the ASTAS proxy throughputdecreases further when all packets initiate a new session:This is due to the stateful nature of the ASTAS inboundproxy. Furthermore, this evaluation assumes that the

Fig. 6. All anycast traffic is processed by PIAS or ASTAS proxies, thereby creating apotential performance bottleneck. The return path is not depicted.

0

20

40

60

80

100

0 0.2 0.4 0.6 0.8 1

Thr

ough

put (

%)

Transmitted frames/second (fps)×106

RouterASTASASTAS, new sessions

Fig. 7. ASTAS throughput measurement on a Click [13] router for 96-byte packets.

368 T. Stevens et al. / Computer Communications 33 (2010) 365–371

outbound proxy is known prior to session initiation, i.e., thelookup time via the distributed registry is not taken intoaccount. In a wide area setting, the outbound proxy lookuptime may further decrease the session initiation rate,depending on the network and overlay configuration andstate.

4. Design with SCTP

4.1. SCTP transport layer opportunities

Most Internet applications use TCP for reliable and statefulcommunications, whereas UDP is generally used for unreliabledata transfer. However, SCTP [14] and its extensions [15,16] haverecently emerged as an alternative multipurpose and flexibletransport layer protocol that supports both reliable and partiallyunreliable data transfer. Just like TCP and UDP, SCTP could be usedin cooperation with PIAS or ASTAS for anycast services.

Unlike TCP that packetizes a byte stream being sent from sourceto destination, SCTP is a message-oriented protocol. This means thata higher layer application provides messages to the transport layer.These messages may be sent individually to their destination ormay be aggregated into a larger SCTP datagram consisting of sev-eral messages, each in a separate chunk. Indeed, an SCTP packetconsists of a minimal common header, followed by one or morechunks (control and/or data). As the name suggests, control chunksare used to manage associations (connections), while data chunkscontain the actual messages to be exchanged between the end-hosts.

Fig. 8. SCTP four-way handshake for connection establishment.

Fig. 8 depicts the SCTP four-way handshake protocol to set up anassociation between two hosts. First, the client initiates the con-nection by sending a packet containing an INIT control chunk tothe server. Upon reception of the connection initiation request,the server sends an INIT ACK control chunk containing a server-generated cookie back to the client. If the T1-init timer did nottimeout, the client in turn responds with a COOKIE ECHO message,otherwise the INIT message is retransmitted. Upon reception of theCOOKIE ECHO message, the server establishes the association, allo-cates the necessary resources for the association, and sends a COO-KIE ACK message back to the client. If the T1-cookie timer did notexpire upon reception of the COOKIE ACK message, the client alsomarks the connection as ESTABLISHED and data can be ex-changed.2 Unlike TCP, SCTP does not allocate any resources beforeclient legitimacy is checked by the cookie exchange. This four-wayhandshake is a countermeasure against blind denial-of-service at-tacks (e.g., TCP SYN flooding attack).

The most distinguishing SCTP feature in the context of this pa-per is its native support for multihoming, which is lacking in bothTCP and UDP. SCTP multihoming has triggered research both to in-crease total bandwidth between end-hosts by means of multipathcommunications [17,18], and to enhance end-host mobility sup-port [19]. The upper layer protocol can specify several addressesthat are announced to the corresponding host via either the INITor INIT ACK control chunk. Once all addresses are exchanged, a pri-mary path is selected for data transfer. If data transmission over theprimary path fails, SCTP switches to an alternative source–destina-tion address pair, preferably the most divergent one.3 Note that theavailability of alternative paths (i.e., all paths except the primarypath) is continuously being monitored by HEARTBEAT exchanges.

The SCTP Dynamic Address Reconfiguration (DAR) [16] exten-sion adds several interesting features to further improve thesemultihoming capabilities, including adding and deleting addressesto/from existing associations after the initial handshake andexpressing primary address preference.

4.2. Towards a stateless infrastructure

Equipped with the multihoming features of SCTP, it is our goalto make the anycast architectures PIAS and ASTAS more robust byimplementing the new design goals described in Section 3.

Fig. 9(a) depicts the path traversed by an SCTP INIT messagesent from a client C to an anycast destination. Just as before, theconnection request is captured by the nearest proxy P1 (step 1)and tunneled towards P2 (step 2), the proxy with the most suitabletarget server(s) to handle the service request. Subsequently, P2 se-lects one target server and delivers the SCTP INIT message bymeans of IP tunneling (step 3). Instead of traversing the proxy sys-tem in the opposite direction for the return path, the anycast targetS1 addresses C directly by sending the INIT ACK from its unicastaddress. In practice, S1 completes the address parameter list inthe INIT ACK with the anycast address and its unicast address S1.Once the association is established, the client C and target serverS1 directly exchange data messages without using the proxy infra-structure, as depicted in Fig. 9(b).

The most noticable differences compared to both PIAS and AS-TAS are the removal of all session state information in the proxy nodesand the possibility of direct communication between client andtarget after the SCTP association has been set up. In the PIAS archi-tecture, only the inbound proxy (P1 in Fig. 2) is stateless, while theoutbound PIAS proxy (P2 in Fig. 2) performs NAT and is a stateful

2 Actually, data chunks can be piggybacked during the COOKIE ECHO and COOKIEACK exchanges too.

3 How to select an alternative address pair that results in the most divergent end-to-end path is an open research issue [20].

Fig. 9. SCTP INIT requests are forwarded by the anycast overlay to a suitable target S1 (Fig. 9(a)), whereupon unicast communication is used for the actual data transferbetween the client (C) and S1 (Fig. 9(b)).

T. Stevens et al. / Computer Communications 33 (2010) 365–371 369

component. However, for PIAS this has the disadvantage that theinbound proxy must forward all requests for the same service tothe same outbound proxy, because it cannot differentiate betweenmultiple sessions to the same anycast IP address (and TCP port).Using ASTAS, inbound proxies select an outbound proxy for eachsession request, which makes inbound proxies more flexible butstateful. The outbound ASTAS proxy (P2 in Fig. 3) performs statefulIP tunneling and is also a stateful component. In contrast with bothASTAS and PIAS, the SCTP anycast infrastructure is entirely stateless(inbound and outbound proxies), but it supports statefulcommunications.

4.3. SCTP considerations

In order to keep the SCTP anycast infrastructure entirely state-less, it is absolutely necessary that only the SCTP INIT message isdelivered via the overlay. If also the COOKIE ECHO message in re-sponse to the INIT ACK is sent to the anycast address, the inboundproxy would capture this packet—just as any other anycast pack-et—without knowing its destination. At this moment, SCTP stan-dards specifications [14,16] do not thoroughly specify failoverbehavior in the association establishment phase. Therefore we pro-pose a number of SCTP implementation guidelines that would ben-efit the anycast use case.

Fig. 10 depicts a sequence diagram for a client initiating an SCTPassociation to an anycast destination. The INIT message is trans-ported to the target server via the overlay network as depicted in

Fig. 10. Failover from anycast to unicast address during SCTP connectionestablishment.

Fig. 9(a). The target server immediately responds with an INITACK message (containing a cookie) from its unicast address S1and informs the client about its IP addresses. At this moment,the target server must include the anycast address A in its addressparameter list to ensure that the client can track down the associ-ation to which this INIT ACK belongs. According to the SCTP stan-dards specifications, the client marks the anycast address A asCONFIRMED, while the status of the unicast address S1 is set toUNCONFIRMED.4 A direct consequence of this specification is thatthe COOKIE ECHO will be sent to the anycast address A (because thisaddress is CONFIRMED). When the inbound proxy captures thisCOOKIE ECHO, there are two possible proxy actions: (i) the proxy si-lently discards this packet, or (ii) the proxy discards this packet andsends an ICMP Destination UnReachable (DUR) message back to theclient. The implemented proxy action will naturally affect the failov-er time depicted in Fig. 10.

If proxy action (i) is implemented, the client will retransmit theCOOKIE ECHO multiple times to address A—each time the retrans-mission timer expires—before finally failing over to address S1.When the recommended SCTP implementation parameters areused [14], this results in a failover time varying between 63 and360 seconds,5 depending on the retransmission timeout (RTO) va-lue determined by the underlying network conditions.

For proxy action (ii), if the client receives the ICMP DUR mes-sage the standards specifications suggest to either increment thepath error counter or to mark the destination immediately intothe unreachable state. Both actions drastically decrease the failovertime because they avoid unnecessary waiting for the retransmis-sion timer to expire.

Obviously, in the anycast case the most elegant solution wouldbe to address S1 immediately, for the first COOKIE ECHO messagetransmitted by the client. Unfortunately, current standards specifi-cations do not foresee this behavior. The following three solutionshave been identified [21]:

(1) Ensure that the COOKIE ECHO is sent to the source address ofthe INIT ACK message (S1). If this source address is UNCON-FIRMED, the COOKIE ECHO must be accompanied by aHEARTBEAT REQUEST. This behavior would not violate thestandards specifications but would be implementation-specific.

(2) If both end-hosts support the SCTP DAR extension [16],ensure that the primary address S1 specified by the optionalSet Primary Address parameter in the INIT ACK is used as thedestination address for the COOKIE ECHO message. Again,

4 If an ACK is received for a message sent to a specific address, this address isCONFIRMED regardless of the source address/interface used to send this ACK.

5 Path:Max:Retrans ¼ 5;RTO:Min ¼ 1s;RTO:Max ¼ 60s.

Fig. 11. Using a new SCTP parameter INIT-FW to achieve instant failover to theunicast address S1.

370 T. Stevens et al. / Computer Communications 33 (2010) 365–371

the COOKIE ECHO must be accompanied by a HEARTBEATREQUEST if this primary address is UNCONFIRMED. Thissolution would also be implementation-specific.

(3) Define a new mechanism that results in the desired protocolhandling. This could be achieved by defining a new parame-ter that requires the receiver of the INIT ACK to immediatelyswitch to the specified address S1 to proceed with the asso-ciation initialization. This solution is illustrated in Fig. 11,where the new parameter is named INIT-FW.

Even though the third solution would necessitate an extensionof current standards specifications, it is clearly the most elegantone. Since the behavior of the first and second approach is imple-mentation-dependent, it is impossible to identify a priori whichhosts would support these solutions.

Once the association is established, the anycast server can de-lete the anycast address A from the association if both end-hostssupport the SCTP DAR extension. When applied, established asso-ciations cannot reuse the anycast address at a later stage (e.g.,when the primary path fails).

5. Discussion

PIAS and ASTAS are improved in a number of ways by the SCTP-based architecture in order to fulfill the objectives specified in Sec-tion 3.

(1) Robust communications: The SCTP architecture is the first tosupport stateful communications in a robust way, becauseestablished sessions are invulnerable to proxy failures andnetwork reconfigurations (e.g., due to a link failure). Newlyinitiated sessions may be deviated to a different proxy aftera configuration change, but this is not an issue since only theSCTP INIT traverses the proxy infrastructure. Already estab-lished sessions do not use the anycast overlay and are notsusceptible to network reconfigurations.

(2) Mobile clients: Using ASTAS or PIAS without the SCTP exten-sion, client mobility is problematic for established sessions ifthe client moves to a part of the network covered by a differ-ent proxy. Mobile IP (MIP) [6] handles seamless mobility in aunicast situation, but flapping towards a different proxyoccurs behind the scenes and is not within scope of MIP. For-tunately, the SCTP overlay re-enables full mobility supportin two distinct ways. At the network layer, MIP could beused, because the data path does no longer traverse theproxy infrastructure (See Fig. 9(b)). Alternatively, the SCTP

DAR [16] features could seamlessly handle client mobilityat the transport layer. In the latter situation, MIP supportin the client and server are not required.

(3) Decentralized data plane: Since data is no longer exchangedvia the double proxy detour, this has direct impact on theoverlay scalability and performance. In this case, the systemcapacity is determined by the maximum number of simulta-neously initiated sessions and not the total amount of dataexchanged between all clients and anycast targets. More-over, the path stretch for traversing the proxy systembecomes less important because it only affects the SCTP INITmessage.An important consequence of these findings is that the num-ber of proxies can be drastically reduced when compared toPIAS or ASTAS, for the same number of anycast servicerequests. Additionally, proxy placement is less important.This is a significant result because Ballani and Francis [4]have shown that naive proxy placement can lead to high-latency PIAS client–server paths.

Next to the extra design goals realized by the SCTP anycastoverlay, there are two minor side-effects compared to PIAS and AS-TAS. First, target server unicast IP addresses are being discovered.This property deserves special attention when the anycast systemis primarily deployed for peer-to-peer applications where anycastend-host anonymity is an important issue. In this context, a hybridsolution could be used where outbound proxies set up NAT con-nections to target servers—just like PIAS—and maintain SCTP asso-ciations with clients on behalf of the anonymous target servers.

Second, ASTAS and PIAS offered the ability to implement trafficengineering between inbound and outbound proxies. Since theSCTP proxy system is not used for transporting the actual data, itcannot integrate traffic engineering in the solution. On the otherhand, the SCTP approach cancels out the overlay path stretch,which naturally results in end-to-end paths with lower latency.Furthermore, the anycast architecture does not preclude trafficengineering actions below the overlay.

6. Conclusion

A number of overlay architectures have been proposed in theliterature that overcome the most stringent problems with nativeIP anycast, including severe routing scalability issues. We have ex-plained in this paper why these architectures have to be mademore robust in a number of ways, however. First, we have shownthat services offered via these architectures are prone to networkreconfigurations or overlay node failures. Second, anycast servicesprovided to mobile clients can get disrupted. Finally, existing any-cast solutions introduce packet forwarding bottlenecks at the in-bound and outbound overlay nodes.

The solution proposed in this paper combines the positive fea-tures of the overlay-based approach with the multihoming facili-ties offered by SCTP to eliminate these shortcomings. We haveshown that transport layer multihoming at the anycast server sideremoves the overlay bottlenecks and optimizes the client–serverend-to-end path. Furthermore, we have argued that the numberof overlay nodes can be drastically reduced in comparison withprevious anycast architectures, without degrading service quality.

Acknowledgment

The authors would like to thank Michael Tüxen, affiliated withMünster University of Applied Sciences (Germany), for the fruitfuldiscussions on SCTP multihoming aspects. These discussionsundoubtedly improved the overall quality of this paper.

T. Stevens et al. / Computer Communications 33 (2010) 365–371 371

Daan Pareit would like to thank the IWT (Institute for the Pro-motion of Innovation through Science and Technology in Flanders)for financial support through his Ph.D. grant.

References

[1] C. Partridge, T. Mendez, W. Milliken, RFC 1546: Host Anycasting Service,November 1993.

[2] S. Sarat, V. Pappas, A. Terzis, On the use of anycast in DNS, SIGMETRICSPerformance Evaluation Review 33 (1) (2005) 394–395.

[3] D. Katabi, J. Wroclawski, A framework for scalable global IP-anycast (GIA), ACMSIGCOMM Computer Communication Review 30 (4) (2000) 3–15.

[4] H. Ballani, P. Francis, Towards a global IP anycast service, ACM SIGCOMMComputer Communication Review 35 (4) (2005) 301–312.

[5] T. Stevens, M. De Leenheer, C. Develder, F. De Turck, B. Dhoedt, P. Demeester,ASTAS: architecture for scalable and transparent anycast services, Journal ofCommunications and Networks 9 (4) (2007) 457–465.

[6] C.E. Perkins, Mobile networking through mobile IP, IEEE Internet Computing 2(1) (1998) 58–69.

[7] A.L. Caro, J.R. Iyengar, P.D. Amer, S. Ladha, G.J. Heinz, K.C. Shah, SCTP: aproposed standard for robust Internet data transport, IEEE Computer 36 (11)(2003) 56–63.

[8] E. Zegura, M. Ammar, Z. Fei, S. Bhattacharjee, Application-layer anycasting: aserver selection architecture and use in a replicated Web service, IEEE/ACMTransactions on Networking 8 (4) (2000) 455–466.

[9] M. Freedman, K. Lakshminarayanan, D. Mazières, OASIS: anycast for anyservice, in: Proceedings of the 3rd Symposium on Networked Systems Designand Implementation (NSDI 06), San Jose, California, United States, 2006.

[10] C. Metz, IP anycast, IEEE Internet Computing 6 (2) (2004) 94–98.[11] C. Perkins, RFC 2003: IP Encapsulation within IP, October 1996.[12] G. Tsirtsis, P. Srisuresh, RFC 2766: Network Address Translation – Protocol

Translation (NAT-PT), February 2000.[13] E. Kohler, The Click Modular Router, Ph.D. thesis, Massachusetts Institute of

Technology, 2001.[14] R. Stewart, RFC 4960: Stream Control Transmission Protocol, September 2007.[15] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, RFC 3758: Stream Control

Transmission Protocol (SCTP) Partial Reliability Extension, May 2004.[16] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka, RFC 5061: Stream

Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,September 2007.

[17] J.R. Iyengar, P.D. Amer, R. Stewart, Concurrent multipath transfer using SCTPmultihoming over independent end-to-end paths, IEEE/ACM Transactions onNetworking 14 (5) (2006) 951–964.

[18] M. Fiore, C. Casetti, G. Galante, Concurrent multipath communication for real-time traffic, Computer Communications 30 (17) (2007) 3307–3320.

[19] L. Budzisz, R. Ferrs, A. Brunstrom, K.-J. Grinnemo, R. Fracchia, G. Galante, F.Casadevall, Towards transport-layer mobility: evolution of SCTP multihoming,Computer Communications 31 (5) (2008) 980–998.

[20] S. Ladha, S. Baucke, R. Ludwig, P.D. Amer, On making SCTP robust to spuriousretransmissions, SIGCOMM Computer Communication Review 34 (2) (2004)123–135.

[21] M. Tüxen, Personal Communication, 2009.