• No results found

MultiGate6: An IPv6 multihoming gateway using a hybrid approach *

N/A
N/A
Protected

Academic year: 2021

Share "MultiGate6: An IPv6 multihoming gateway using a hybrid approach *"

Copied!
16
0
0

Loading.... (view fulltext now)

Full text

(1)

MultiGate6: An IPv6 multihoming gateway using a hybrid approach

*

Chung-ming Huang *, Ching-hsien Tsai, Po-chou Su

Laboratory of Multimedia Networking (LMN), Department of Computer Science and Information Engineering, National Cheng Kung University, No. 1 University Road, Tainan 70101, Taiwan, ROC

Received 17 January 2005; received in revised form 22 September 2005; accepted 6 October 2005 Available online 20 December 2005

Abstract

Multihoming allows a site/host to connect to multiple Internet Service Providers (ISPs) simultaneously. Network fault tolerance (service resilience), load balancing, and provider independent service can thus be achieved using the multihoming technique. With the benefits of the eased renumbering network mechanism and the large addressing space introduced by IPv6 network, multihoming will become much more popular. In this paper, a hybrid IPv6 multihoming approach, which combines the host-based multihoming approach and the router-based multihoming approach, is proposed. In the proposed design, Router Advertisements defined in Internet Control Message Protocol version 6 (ICMPv6) is adopted to handle the multihoming message exchange between the router and the hosts within the IPv6 multihomed network. The corresponding system implementation called ‘MultiGate6’ offers fault tolerance, load balancing, and provider independence services to both site and host levels. Hosts within the multihomed network are able to establish connections through multiple links simultaneously. With the five load balancing policies provided in MultiGate6, congestion of a single link can be prevented and thus bandwidths of links can be utilized more efficiently. q2005 Elsevier B.V. All rights reserved.

Keywords: Multihoming; Router advertisement; Fault tolerance; Load balancing; IPv6; ICMPv6

1. Introduction

The general definition of multihoming is that a host, a site, or a network is able to connect to the Internet through multiple external links or Internet Service Providers (ISPs) rather than a

single one. The Internet Engineering Task Force (IETF) IPv6 Multihoming (multiv6) WG [1] also gives multihoming a formal definition as “a site that has more than one connection to the public Internet with those connections through either the same or different ISPs”. From the above definition, if a node is able to connect to the Internet with more than one IP address as alternatives (even those IP addresses belong to the same ISP), the node can be regarded as ‘multihomed’. Although using more than one IP address belonging to a single ISP can prevent a node from being totally inaccessible to the Internet due to some attacks, such as Deny of Service (DoS) attack, to one specific IP address, it does not provide resilience if critical failure happens in the ISP. On the contrary, multihoming with different ISPs can tolerate the fault of an ISP at one time because the host/site can still connect to the Internet through the other ISPs.

A node or a host can be multihomed in two basic ways. The first one is a single network interface that is bound to multiple IP addresses, even if these IP addresses belong to the same ISP. The original use of binding multiple IP addresses to a single network interface is to achieve smooth transition in the case of address changes of servers. Recently, this method is widely used to create ‘virtual servers’ in World Wide Web (WWW) servers. The second one is multiple network interfaces, which may be homogeneous, e.g. multiple 802.11b WLAN interfaces, or heterogeneous, e.g. a Wireless LAN interface, a Bluetooth

www.elsevier.com/locate/comcom

0140-3664/$ - see front matter q 2005 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2005.10.020

Abbreviations BB, the ‘Best Bandwidth’ policy type that can be applied by MultiGate6 for the load balancing function; FT, fault tolerance; HD, the ‘Host Defined’ option that the host can use to ignore the indicated load balancing policy sent from MultiGate6; LB, load balancing; LLF, the ‘Least Load First’ policy type that can be applied by MultiGate6 for the load balancing function; LSD, the ‘Link Status Daemon’ by which MultiGate6 can detect the status of each link; MH, multihoming; MHH, multihomed host; RA, Router Advertisement; RAD, the ‘Router Advertisement Defined’ option that the host can use to accept the indicated load balancing policy sent from MultiGate6; RADVD, Router Advertisement Daemon; RR, the ‘Round Robin’ policy type that can be applied by MultiGate6 for the load balancing function; SRTT, the ‘Shortest Round Trip Time’ policy type that can be applied by MultiGate6 for the load balancing function; UD, the ‘User Default’ policy type that can be applied by MultiGate6 for the load balancing function.

*

This research is supported by Taiwan NICI IPv6 Steering Committee, R&D Division, under contract number R-0300, and the National Science Council of the Republic of China under the grant number 92-2219-E-006-003.

* Corresponding author. Tel.: 2757575/62523; fax: C886-6-2747076.

(2)

network interface, and a UMTS 3G network interface, that are bound to multiple addresses. One reason for equipping a computer with more than one network interface is cost: sometimes two low bandwidth connections cost less than a single high bandwidth connection.

Many concerns motivate a host or a site to be multihomed, such as (i) fault tolerance: the connections to the Internet can migrate to alternative links to prevent the loss caused by the sudden failure of the primary link, (ii) load balance: the load can be spread across multiple links to prevent a specific link from being overloaded, (iii) provider selection: selecting an ISP that can provide more cost-effective quality of service, (iv) performance: in the event that a site is multihomed with several low-bandwidth links, the overall performance may be equal to a single high-bandwidth link but with lower cost, and (v) policy concern: a government department or a campus network may not be allowed to serve commercial traffic through its connectivity provider.

In Ipv4 network, one method to achieve multihoming is to advertise the ASN prefix of a multihomed site to BGP neighbors. An alternate method is to advertise non-aggregated PA (Provider Assigned) prefix of one ISP through all other connected ISPs. Both methods would place more cost on the ISPs and cause a serious routing problem. Another method to carry out multihoming is to adopt the use of Network Address Translation. A gateway with built-in NAT service provides the ease of renumbering by overwriting IP headers depending on some specific needs or policies for outbound links. Although the NAT gateway approach offers the advantage of minimal administration, it also causes other problems, e.g. lack of external reachability into the local site, and the barrier of some end-to-end network applications.

Two particular solutions for achieving multihoming are router-based solutions and host-based solutions. Methods described in the previous paragraph can be categorized as router-based solutions, but they are not suitable for the IPv6 multihoming environment. The advertisements of Provider Independent (PI) blocks for all multihomed sites or networks to Default Free Zone (DFZ) will cause overloads to the global Internet routing infrastructure and therefore it is not a scalable approach. On the other hand, one essential reason driven for IPv6 is to avoid the use of NAT. Thus the NAT approach introduced in IPv4 should not be considered in the IPv6 network environment.

For the host-based solution, the multihoming support is enabled in hosts. One method is to assign multiple network addresses to a host and do network address selection while establishing connections. However, due to the lack of the status information about links, the selected address may not be the best one for the connection, and moreover, load balancing among links is unable to be achieved. The host-based approach may also cause ingress filtering problem. That is, when a host multihomed to providers A and B selects a source address from provider A, and sends the packets towards provider B, provider B may reject the packets because the source address is not within its own address space. On the other hand, the Default Address Selection (RFC3484)[2]algorithm used to select source address

is defined on a longest-match prefix basis. However, although the longest-match prefix essentially means the selected source address is closer to the destination node, using the selected source address does not guarantee a better transmission performance. Fig. 1depicts an illustrated example, in which the selected path is via ISP-A using the longest-match method, but the available bandwidth of A is lower than that of path-B. Under this concern, selecting ISP-B address as the source address, i.e. the connection is via path-B, will contribute better transmission performance, even though the prefix of ISP-B is not the longest-match one to the address of the server.

In this paper, an IPv6 multihoming gateway system called ‘MultiGate6’ is designed and implemented. MultiGate6 adopts a hybrid approach which merges both host-based and router-based solutions to achieve multihoming. MultiGate6 is an IPv6 multihoming gateway which connects to multiple external links. MultiGate6 also functions as a router which can broadcast Router Advertisements with multihoming infor-mation to hosts. Within the multihomed network administrated by MultiGate6, connections of hosts can be held through multiple links and thus multihoming function is enabled in hosts. On detecting the failure of a link, MultiGate6 will let it known to all hosts to prevent the loss caused by hosts’ trying to establish connections through the failed link. Five link selection policies are provided in MultiGate6 to allow a host to do provider selection for its preference, or to use the network address indicated by MultiGate6 for load balance consider-ation. Hence, bandwidths of links can be utilized more efficiently to provide hosts better network service experiences. The rest of this paper is organized as follows. In Section 2, current multihoming approaches for IPv6 network environ-ments are described. In Section 3, the functional scenario of

Fig. 1. An example of using the longest-match algorithm to select source address.

(3)

MultiGate6 is depicted. In Section 4, protocols inside Multi-Gate6 that are used to achieve ‘Fault Tolerance’ and ‘Load Balancing’ are presented. In Section 5, details of MultiGate6 implementation are described. In Section 6, performance evaluation of MultiGate6 is presented, and in Section 7, conclusion remarks are given.

2. Related works

The solutions for achieving IPv6 multihoming can be classified as five categories: (1) router-based solutions, (2) two-space identifier/locator solutions, (3) mobility solutions, (4) transport layer solutions, and (5) host-based solutions. Since the approaches for IPv6 multihoming are numerous, we choose part of the approaches for each category to expound the specialities of each one.

1. IPv6 router-based solutions: These solutions are designed in the way that no change is needed for hosts. This category of approaches uses the IPv6 routing system like the IPv4 approach. However, mechanisms are added to solve the scalability problem of injecting prefixes to the DFZ. The use of provider aggregatable (PA) addressing is also considered in IPv6 routing solutions. Multihoming mech-anisms of router-based solutions are summarized as follows.

† IPv6 multihoming with route aggregation [3]: In this approach, a site that is multihomed will choose one of its ISPs as the primary link. Assuming an IPv6 site is multihomed with ISP A and ISP B, and ISP A is chosen as the primary link of the site. The multihomed site will advertise the prefix of ISP A to all of its connected ISPs, including ISP B. ISP B will propagate the advertisement of prefix A only to ISP A, and thus this approach does not cause the routing table explosion of DFZ. Since ISP A advertises its own aggregation into the Internet, the packets destined to prefix A are routed to ISP A. ISP A can achieve load balancing by directly forwarding these packets to the site, or to ISP B according to proper routing policies. The drawback of this approach is the single point of failure problem of the primary link. The site will become unreachable when the ISP of the primary link fails.

† Routing header usage [4,5]: This approach enforces a multihomed site to have routing via a specific ISP. It inserts a routing header containing an intermediate any cast address that identifies the routers of the intended ISP. Therefore, the packets with such routing header will be routed to the selected ISP. The drawback of this solution is that the ISP must process the routing header, which causes extra overhead.

2. Two-space identifier/locator solutions: IP addresses are used for both locators of the nodes and identifiers of end-points. Applications handle identifiers, while locators become the responsibility of the network layer. Therefore, guaranteeing the uniqueness of identifier is an important requirement that may affect IPv6 stateless

auto-configuration. The summary of each two-space identifier/-locator solution is as follows.

† Host Identity Protocol (HIP) [6]: HIP decouples the transport layer from the network layer and introduces a new host namespace between. Thus the sockets are not bound to IP addresses as they used to be. Applications see the HIP identifiers instead of seeing IP addresses. The mapping between host identifiers and IP addresses can be one to many, hence multihoming can be achieved. Hosts can also change their IP addresses even the communication sessions have been established. When the host is going to change its IP address, it sends an HIP Readdress packet to its peer. After the peer checks the reachability using HIP Address Check and Address Check Reply packets, the new address of the host can actually be used. During the change of IP address, the connectivity can still be preserved. However, the way how HIP hosts interoperate with legacy hosts and the address selection mechanism of HIP are not clear now.

† Layer 3 shim approach [7]: In this approach, a shim layer is inserted into the host’s IP stack. The shim layer maps the single identifier, which is referred as the upper layer ID (ULID), and the set of available locators in the communication session. Unlike HIP, the layer 3 shim approach does not introduce new namespace as its identifier, it uses one locator from the locator set as its identifier instead. Furthermore, the shim layer is located between the IP layer and the transport/upper layers, which can only see the ULIDs. Thus the packets are transmitted end-to-end using the ULIDs by applications. Conceptually, the shim layer functions by placing an extension header before all other IPv6 extension headers. Thus this approach will cause packet overhead and reduce the available MTU (Maximum Transmission Unit) as a result.

† Location Independent Addressing for IPv6 (LIN6) [8]: LIN6 is a protocol supporting IPv6 multihoming and host mobility. The approach introduces two types of IPv6 addresses, including the LIN6 generalized ID and the LIN6 address. The LIN6 generalized ID is 128 bits, which consist of a 64-bit LIN6 prefix and a 64-bit LIN6-ID. The LIN6 ID is a global unique identifier and is only used in the transport and upper layers of a host. The LIN6 ID does not change even the host moves from one network to another one. The LIN6 address is 128-bit, consisting of a 64-bit network prefix and a 64-bit LIN6-ID. The network prefix is the network prefix at which the node is actually located. The LIN6 address is used by the network layer to designate the location and the identity of a node. The mapping between the LIN6 generalized ID and the LIN6 address is done by mapping agents, which will resolve the LIN6 generalized IDs to the current LIN6 addresses when the host is about to establish connection.

3. Mobility solutions: Mobility can be regarded as a special case of multihoming. In Mobile IPv6 [9], a mobile node

(4)

(MN) always uses its home address (HoA), and the change of addresses when MN moves is hidden from the transport layer and the upper layer protocols. When a MN moves and acquires a care-of-address (CoA), it sends binding update (BU) to inform the corresponding node (CN) of the change of its address. After receiving the BU, CN can map MN’s HoA and the new CoA, and then can redirect the connection to MN. In a multihoming scenario, the above procedure of Mobile IPv6 can be used to inform other hosts when the multihomed host is re-homed. However, the authentication mechanism of Mobile IPv6 needs the cooperation of the host’s home agent, which does not exist in multihomed network because the original path used by the multihomed host is not available when it is re-homed. Therefore, modifications are necessary if Mobile IPv6 is intended to be adopted as a multihoming solution.

4. Transport layer solutions: Traditional transport layer protocols, e.g. TCP and UDP, do not support multihoming in nature. The change of IPv6 address will break the ongoing connection semantics. Currently, there are new protocols, e.g. Stream Control Transmission Protocol (SCTP), or the enhanced version of traditional protocols, e.g. Preserving TCP, that can support multihoming features. The protocols and their mechanisms of supporting multi-homing are summarized as follows.

† Stream Control Transmission Protocol (SCTP) [10]: SCTP passes initial endpoint addresses on startup, and each endpoint address can be regarded as a transmission path of the association (SCTP’s term for ‘connection’). One of the paths of the association is chosen to be the ‘primary path’, in which new data is transmitted through, whereas another path can be used as the path for retransmission if it is necessary. After the association is setup, the ‘HEARTBEAT’ messages can be used to probe the reachability of each address combination. The SCTP ADDIP extension allows the SCTP association to dynamically add, delete, or change the address being used to achieve multihoming on both peers. The drawbacks of SCTP are heartbeat overhead, security issues on address change, and the requirement to have hosts and applications being SCTP-enabled.

† Preserving TCP[11]: This approach assumes that each participant in a TCP session may potentially have multiple global IPv6 addresses, and the valid set of these IPv6 addresses that can be used during the lifetime of the TCP connection should be exchanged among participants. The proposal introduces a ‘PREFIXES’ IPv6 option with the SYN and SYN/ACK packets during the 3-way handshake of a TCP connection establishment. ‘PREFIX_ACK’ is used by each partici-pant to acknowledge the received PREFIXES.

5. Host-based solutions: The multihoming support is enabled in the end hosts with the benefit of not altering router devices or not introducing new special devices.

† Multiple addresses and relexing source address checks: Multiple IPv6 addresses can be achieved with router renumbering and multiple Router Advertisements.

Although hosts can have multiple globally routable IPv6 addresses, there are some associated issues, such as the ingress filtering problem—service provider may reject the packets which are not within its own address space. If the ISPs could switch off the source address checks altogether, the ingress filtering problem then could be solved. However, it needs the cooperation of ISPs and may cause some serious security problems. † Source address selection by the host: This approach

allows a host to select its source address according to proper algorithms or policies using source address discovery when it is configured with multiple IPv6 addresses. Alternately, the host can tunnel its packets to the correct site exit router using exit router discovery. Both the two approaches require significant changes in the IPv6 implementation in hosts, extra changes in routers, or new ICMP packets.

Currently, there are not a lot of implementations for multihoming gateways. In [12], the authors proposed a dynamic traffic sharing method with the IPv4 NAT function and a backbone selection metrics based on connection set-up time. The router tries to establish a connection through each backbone simultaneously and selects the first backbone through which a connection has been actually established. Since the approach adopts TCP SYN packet for implemen-tation, the work does not support UDP traffic sharing. In[13], an IPv6 gateway with a prefix translation mechanism and a backbone selection scheme are presented. The gateway in this approach examines the packets from the host and collect the information of its destination. Then, the gateway measures the Round-trip Time (RTT) of the destination via each available external link and selects the most appropriate one having the minimum RTT. The packet is then translated into the prefix of the selected backbone. This approach may suffer performance degradation because packets must wait at the gateway for the RTT measurement and prefix rewriting. Both the above two related works adopt the NAT technique to implement their multihoming gateways. However, NAT may cause some serious problems, e.g. single point of failure, increasing network latency, and lack of support for some end-to-end applications. Thus, the NAT approach may not be a considerable approach in IPv6 network.

3. The functional scenario of MultiGate6

The functions that the MultiGate6 provides are as follows: † Multihomed network: MultiGate6 provides an IPv6 multi-homed network environment to hosts. Thus hosts can establish their connections with multiple link choices. † Link status monitoring: MultiGate6 detects and monitors

the network status of each link.

† Fault tolerance: MultiGate6 will let the failed link be known to all hosts to prevent the loss caused by hosts’ trying to establish connections through the failed link. † Load balancing: By calculating loads, measuring

(5)

bandwidths of all links, and measuring Round-Trip Time to ISPs’ gateways, MultiGate6 and hosts apply a message-based mechanism to achieve load balancing.

The scenarios corresponding to the functions described above are depicted as follows.

3.1. Multihomed network

The basic function of MultiGate6 is to provide an IPv6 multihomed network to hosts. To achieve this, MultiGate6 connects to multiple external links and thus the internal network is multihomed.Fig. 2depicts an abstract multihomed network environment using MultiGate6.

To enable host-level multihoming, MultiGate6 also acts as an IPv6 router, which broadcasts Router Advertisements periodically. The prefixes of alive (working) links will be broadcasted to hosts via Router Advertisements. For

example, assume a MultiGate6 is multihomed with two links connected to two different ISPs, such as ISP-A, and ISP-B, and assume both links works well. MultiGate6 will, respectively, broadcast Router Advertisements with the prefix of ISP-A and ISP-B periodically or on receiving router solicitations from hosts. Hosts within the multihomed network environment administrated by the MultiGate6 receive Router Advertisements of different network prefixes and hence multiple network addresses are available for a host. When a host is going to establish a connection to the Internet, it is able to select whatever network address it prefers, or apply the network address specified by the MultiGate6 for the load balancing concern. In this way, there will be no ingress filtering problem because the packets will follow the right route to the destination after mapping the MultiGate6’s routing table of the multihoming gateway. For example, packets that have ISP-A’s prefix address as their source addresses will be transmitted through ISP-A’s network. Moreover, MultiGate6 will not cause the routing problem because there would be no non-aggregated routes needed to be advertised specifically to the backbone routers.

Fig. 3shows a scenario that a MultiGate6 works to provide a multihomed network environment for hosts. A host then can establish connections of different source addresses.

3.2. Link status monitoring and fault tolerance

If one of the external links suddenly fails and becomes inaccessible to the Internet, hosts should be prevented to try connecting through the failed link. To actively prevent the host from trying to connect via failed links, MultiGate6 periodically measures the link status between MultiGate6 and the ISP’s gateway. On detecting a link outage between, MultiGate6 broadcasts messages indicating the faulty condition, which includes the prefix of the link, to hosts. When a host receives the message indicating the faulty condition, the host disables the network address of the indicated prefix in the message, and thus the host will not try to establish connections through the failed link.

Fig. 2. The abstract multihomed network environment using MultiGate6.

(6)

If the failed link later recovers to work and is detected by MultiGate6, MultiGate6 will broadcast messages indicating the well-functioning condition, which includes the link prefix to hosts. On receiving the messages of the same indicated prefix again, the host enables the use of the link’s network address. Thus the address becomes usable for hosts’ further connec-tions. Fig. 4 depicts an illustrated scenario for having fault tolerance.

3.3. Load balancing

The other essential benefit using the multihoming technique is load balancing. For host-based solutions, load balancing is hard to achieve due to the lack of the network status information. As an IPv6 multihoming gateway, MultiGate6 can be in charge of collecting and calculating the needed data for load balancing. In the design of the MultiGate6’s load balancing function, five kinds of load balancing policies are developed for different preferences. When the load balancing function is enabled and a preferred load balancing policy is set, MultiGate6 starts to periodically broadcasts messages of load balancing to hosts. The load balancing message contains the information of the selected load balancing policy, e.g. the type

of the policy and the prefix of the link to apply after evaluating loads of all links.

For example, assuming the load balancing policy is set as ‘Best Bandwidth’, which evaluates loads by calculating available bandwidths of links. Under the setting, MultiGate6 will periodically calculate and compare bandwidths of all connected links. After comparing bandwidths of all links, the link with the largest available bandwidth will be selected and the prefix of the link will then be contained in the message, which is going to be broadcasted to hosts. When a host receives the message, which includes information of the load balancing type, such as ‘Best Bandwidth’ and a specific prefix, the host will apply the network address of the specific prefix for its further connection establishments. That is, further connections of multihomed hosts will be established through the link that has the largest bandwidth. MultiGate6 repeats the action and broadcasts messages for the load balancing if the selected link changes after load evaluation for load balancing concern.Fig. 5

depicts such a scenario.

In our design, a host can decide whether to accept to apply the address selected by MultiGate6, or use its own preferred address for other concerns, e.g. some services are limited to specific addresses. In this way, load balancing can still be done

Fig. 4. An illustrated scenario of fault tolerance.

(7)

even in the case that some hosts intend to use specific addresses.

4. Protocol design

In this section, the protocols designed for MultiGate6 to achieve ‘fault tolerance’ and ‘load balancing’ corresponding to the scenarios described in Section 3 are introduced in detail.

According to the MultiGate6’s functional scenario depicted in Section 3, in addition to regular Router Advertisement messages, two more kinds of messages are necessary to achieve fault tolerance and load balancing. MultiGate6 utilizes some optional fields exist in Router Advertisements to achieve multihoming. To accomplish fault tolerance and load balan-cing, part of the reserved field is defined as the ‘Multihoming Option’ to carry extra information to hosts. Two fields in ‘Multihoming Option’ are ‘MH Service Type’ and ‘Policy Type’. The modified prefix option format is depicted inFig. 6, and the definitions of the multihoming option fields are depicted inFig. 7.

4.1. Fault tolerance

MultiGate6 enables a host to establish connections through alternate links if a failure occurs in the currently used link. A link status daemon is created in MultiGate6 to detect whether any of the links fails. The link status daemon is based on Internet Control Message Protocol version 6 (ICMPv6) [14]

packets and keeps the information of each link status. The information refers to the status of each link, such as ‘link alive’ and ‘link failed’. If MultiGate6 probes a specific path is out of linkage, the link status daemon updates the status information of the link and informs the hosts within the multihomed network by broadcasting a Router Advertisement, in which the value of the ‘MH Service Type’ field of the multihoming option is filled with ‘0001’, and the prefix field is filled with the prefix of the ISP which is suffering a linkage failure. On receiving the Router Advertisement of the fault tolerance type, the host reads the value of the multihoming option field, and disables the corresponding IP address, of which the prefix is the same as the indicated one in the prefix field. Hence, new

connections will not be established through the failed link. On the other hand, since MultiGate6 checks the status information of each link before broadcasting Router Advertisements to announce available prefixes to hosts, Router Advertisements will not contain the prefix of the failed link.

When the failed link recovers to work correctly and detected by the link status daemon of MultiGate6, the link status daemon again updates the link status information and broad-casts the Router Advertisement of the fault tolerance type including the prefix of the recovered link to hosts. On receiving the Router Advertisement, the host enables the network address corresponding to the indicated prefix in the Router Advertise-ment. Then, hosts are able connect to the Internet through the recovered link as an alternative.

4.2. Load balancing

Load balancing means distributing the traffic evenly and dynamically among different paths to avoid link congestion and saturation. The load balancing function of the MultiGate6 allows hosts in the multihomed network to establish connections through links that are less loaded. In this way, load is shared as equivalently as possible within all available links and all available bandwidths can be utilized as much as possible. In other words, hosts in the multihomed network can access the Internet with better connection quality, such as more bandwidth and faster transmission rate than the single-homed network.

Fig. 6. The modified format of the prefix option of Router Advertisements.

(8)

In Section 4.1 we have defined the fields of ‘Multihoming Option’ inserted in the reserved field of Router Advertisement for multihoming. With value ‘0010’ in the ‘MH Service Type’ field, the Router Advertisement is used for load balancing. The ‘Policy Type’ field is used to indicate which policy is applied for load balancing. Five defined load balancing policies are ‘RR’ (Round Robin), ‘LLF’ (Least Load First), ‘SRTT’ (Shortest Round Trip Time), ‘BB’ (Best Bandwidth), and ‘UD’ (User Default). Administrator of the MultiGate6 is in charge of deciding which load balancing policy is to be adopted within the multihomed network. These five load balancing policies and the corresponding actions taken by hosts after receiving the Router Advertisements are as follows.

On MultiGate6’s side:

† RR (Round Robin) policy: It is the simplest load balancing policy. When the Router Advertisement is broadcasted to hosts, value ‘0000’ will be filled in the ‘Policy Type’ field to inform hosts to change their load balancing policy to Round Robin.

† LLF (Least Load First) policy: MultiGate6 periodically calculates amounts of data (in bytes) transferred for each of its network interfaces, which are connected to different external links. The link with least load will be chosen for further connection establishments of hosts. When the Router Advertisement is broadcasted to hosts, the prefix of the least-load link will be used as the prefix in the prefix option and ‘0001’ will be filled in the ‘Policy Type’ field. † SRTT (Shortest Round Trip Time) policy: MultiGate6 uses

the response time to each ISP’s gateway in conjunction with heuristics to evaluate loads of links. The link with the Shortest Round Trip Time will be chosen for further connection establishments of hosts. When the Router Advertisement is broadcasted to hosts, the prefix of the shortest-round-trip-time link will be used as the prefix in the prefix option and ‘0010’ will be filled in the ‘Policy Type’ field.

† BB (Best Bandwidth) policy: MultiGate6 uses the Pchar

[15], a tool for Measuring Internet Path Characteristics to detect the available bandwidth of each link. The link with the best measured bandwidth is regarded as having the least load and will be chosen for further connection establish-ments of hosts. When the Router Advertisement is broadcasted to hosts, the prefix of the best-bandwidth link will be used as the prefix in the prefix option and ‘0011’ will be filled in ‘Policy Type’ field.

† UD (User Default) policy: This policy provides the simplest administration in the hosts’ use of IP addresses. When the Router Advertisement is broadcasted to hosts, ‘0100’ will be filled in the ‘Policy Type’ field to inform hosts to change their load balancing policy to ‘User Default’.

On the host’s side:

† RR (Round Robin) policy: On receiving this kind of Router Advertisement, a host will change its IP address in its address list alternatively to establish connections through

different links sequentially, until it receives a new Router Advertisement indicating other load balancing policy. † LLF (Least Load First), SRTT (Shortest Round Trip Time), or

BB (Best Bandwidth) policy: On receiving these kinds of Router Advertisements, a host will use the IP address of which the prefix is the same as which is indicated in the prefix option of the Router Advertisement. The host will use this address for further connections until it receives a new Router Advertisement indicating other load balancing policy. † UD (User Default) policy: On receiving this kind of Router

Advertisement, the host will use its default IP address (from manual settings or network address auto-configuration) for further connections until it receives a new Router Adver-tisement indicating other load balancing policy.

On the other hand, a host shall be able to decide whether to accept Router Advertisements of the load balancing type or not. A host may have to use a specific network address for some reasons, i.e. services that can only be accessible from specific addresses. Therefore, a host can switch between two kinds of status: ‘RAD’ (Router Advertisement Defined) and ‘HD’ (Host Defined). On the ‘RAD’ Status, the host receives the Router Advertisement and alternates its network addresses according to the load balancing policy indicated in the ‘Policy Type’ field. On the ‘HD’ status, the host ignores the indicated load balancing policy and establishes connections with the network address specified by the user. If the user does not specify which network address to use, the host will use the network address which has been advertised in previous Router Advertisements.

5. System development

The design and implementation of MultiGate6 is based on the Router Advertisement Daemon (RADVD)[16]executed in the RedHat 9.0 operating system. RADVD is executed in a Linux or BSD system acting as an IPv6 router. RADVD sends Router Advertisement messages, specified by RFC 2461[17], to a local Ethernet LAN periodically or when requested by a node sending a Router Solicitation message.

In this section, the implementation of MultiGate6 is presented in detail.

5.1. System architecture

Fig. 8 shows the system architectures of MultiGate6 and Multihomed Hosts (MHHs). The system consists of the following components: Multihoming module, Router Adver-tisement generator, Neighbor Discovery mechanism, ICMPv6 module and source address selection module. Each of the components defines a set of functions, which are used to access each component’s services. The features of each component are as follows:

† Multihoming module: The multihoming module in Multi-Gate6 consists of (1) Load Balance Module (LB) and (2) Fault Tolerance Module (FT). The LB module is implemented to achieve the load balancing function

(9)

described in Section 4.2, and the FT module is implemented to avoid the hosts to establish connections through the failed links.

† Router advertisement generator: Router advertisement generator periodically generates a Router Advertisement, which specifies the multihoming policy option in the Router Advertisement.

† ICMPv6 module: ICMPv6 module is a multi-functional control program that supports error reporting, Neighbor Discovery Address Resolution/Configuration and Redirect. Neighbor Discovery is used by IPv6 nodes to implement important functions, among which are the following:

– Locating neighbor routers

– Learning prefixes and configuring parameters related to address configuration

– Auto-configuring addresses to establish relationships between link layer addresses and IPv6 addresses – Discovering duplicated addresses

The Neighbor Discovery mechanism in MultiGate6 con-tains the main function achieved by the Router Solicitation packets and the Router Advertisement packets, which realize the auto-configuration of multiple addresses in MHHs.

† Source address selection module: The source address selection module in the MHH is used to let the MHH receive address selection information broadcasted by MultiGate6.

5.2. Implementation of load balancing function

A network environment is changeable and the network status is not stable all the time, such as network delay, packet

loss, congestion, failed link and narrow available bandwidth. Load Balancing (LB) Module and Fault Tolerance (FT) Module are implemented to efficiently utilize the multihomed network resources. With the two modules, MultiGate6 achieves load balancing and fault tolerance by processing the Router Advertisement with the multihoming option to notify MHHs to apply the indicated address.

A LB daemon is invoked by RADVD on MultiGate6. After the startup of RADVD, it instructs which kind of policy the LB should apply. Then, an MHH can make simultaneous use of several IP addresses and dynamically alternate the address used for each connection according to the policy.

Fig. 9is a functional flow example which applies the ‘SRTT’ load balancing policy. The execution steps are as follows.

1. When an MHH starts up, it sends a Router Solicitation message to MultiGate6.

2. MultiGate6 executes ProcessRA( ) to broadcast Router Advertisements and apply SRRTMode( ) to adopt the policy of ‘Shortest Round Trip Time’.

3. MultiGate6 broadcasts Router Advertisements to the MHH.

4. MultiGate6 measures the Round-Trip Time via each available external link to each ISP. If the default path should be changed for the load balancing concern, the Load Balance Daemon (LBD) will call the SelectionChange( ) function.

5. Multigate6 executes the AddMHOption function of RADVD to fill the multihomed option with service type ‘load balancing’, policy type ‘SRTT’, and the preferred prefix. 6. MultiGate6 broadcasts the Router Advertisements to MHHs. 7. After the MHH receives the message, it will call the PrefixChange( ) function to alternate the relevant IP addresses when the connection is to be initiated.

(10)

5.3. Implementation of fault tolerance function

After the LB daemon is startup, the FT module will also be driven. In the FT module, The Link state daemon (LSD) is implemented to detect the situation of each link. The daemon measures Round-Trip Time (RTT) using the ping6 utility. The ping6 utility uses the ECHO_REQUST datagram to elicit an ICMPv6 ECHO_RESPONSE from the ISP gateway in a pre-defined period of time. If ECHO_TIMEOUT happens, the LSD will instruct the host to disable the prefix of this path.Fig. 10

depicts the functional flow for achieving the fault tolerance function in MultiGate6. The execution step is as follows.

1. When an MHH starts up, it sends a Router Solicitation message to MultiGate6.

2. MultiGate6 calls ProcessRA( ) to send Router Advertise-ments.

3. MultiGate6 broadcasts Router Advertisements to the MHH. 4. If the link of an ISP fails, the link status daemon will call the

LinkStateChange( ) function to update the status flag. 5. The next stage requires calling the AddMHOption( )

function of RADVD to fill the multihoming option with service type ‘Fault Tolerance’ and deprecate the prefix.

6. MultiGate6 broadcasts the Router Advertisements to the MHHs. 7. After the MHH receives the message, it will call the

PrefixDisable( ) function to deprecate the prefix.

5.4. Implementation of the source address selection function

The source address selection module is implemented in the MHH to select the address indicated by MultiGate6. We modify addrconf_prefix_rcv in Linux kernel to receive the multihoming option and modify ipv6_get_saddr to support the IPv6 multi-homing selection policy. If the application does not request a particular IPv6 address, the ipv6_get_saddr will check the policy of multihoming option and apply the indicated address.

The following recapitulates the manner by which the kernel determines what the source address of an outbound packet is based on our IPv6 Multihominmg scheme.

† The application is already using the socket, in which case, the source address has been chosen. Also, the application can specifically request a particular address by using the bind call. So the kernel will apply the source address given by the application.

Fig. 10. The functional flow for achieving the fault tolerance function. Fig. 9. The functional flow example of applying the ‘SRTT’ load balancing policy.

(11)

† If the application does not select the source address for the outbound packets, the kernel will select the source address according to the policy type of the Multihoming option. † If the load balancing policy is not specified, the first address

configured on the interface is to be applied.

6. Performance evaluation

In this section, some performance evaluations of Multi-Gate6 are given. The average load ratio and the variance for each load balancing policy are calculated to evaluate the load balancing efficiency. Moreover, some experiments specific to load balancing policies are designed to evaluate the effect of applying the policy. The influence of the Router Advertisement interval on load balancing efficiency is also examined in this section.

6.1. Experimental environment

According to the characteristic of IPv6, a host can be assigned with multiple IPv6 addresses using IPv6 auto-configuration[18]. In order to configure multiple addresses in a host, we add two different prefixes to the RADVD configuration file (/etc/radvd.conf) of MultiGate6. Upon the execution of RADVD, a host can have multiple addresses using stateless configuration. Fig. 11 is the configuration of the experimental environment.

The MMNET is established in Department of Computer Science and Information Engineering, National Cheng Kung University with standard Ethernet supporting 100 Mbps. Two IPv6 experimental network backbones in Taiwan that the MultiGate6 connects are HINET and ASNET. The IPv6 network address prefixes that HINET and ASNET offered are 3ffe:3600:1a::/48 and 3ffe:4001:212a::/48, respectively. By using Pchar, each one of the two links is measured to provide 10 Mbps bandwidth. Thus the HINET and ASNET can be regarded as the two ISPs that can provide 20 Mbps bandwidth in total for the multihomed network. Network traffic is

randomly produced by using scripts to execute network applications repeatedly, e.g. web browsing and FTP services, to emulate actual mass bandwidth usage of many hosts. In our experiment, ‘lftpget’ is adopted to connect to the FTP service at 2001:770:18:2::1:3 and perform downloading tasks of random files. On the other hand, MultiGate6 adopts Router Advertise-ments to achieve load balancing. RADVD with the default configuration, which may send the Router Advertisement at a maximum interval of 600 s, is not suitable to evaluate the load balancing performance of MultiGate6. Thus, to have the evaluating experiments described in Sections 6.2 and 6.3, the interval of broadcasting Router Advertisements is set to 10 s, which is a legal value allowed in RFC 2461, by modifying RADVD. In Section 6.4, the interval of broadcasting Router Advertisements is changed to other values in order to evaluate its influence on load balancing performance.

6.2. Evaluation results on path load ratio

According to our load balancing policies, the administrator of MultiGate6 is able to choose a suitable policy to optimize the network performance. In this experiment, we evaluate the traffic load ratio of HINET (Path-HI) and ASNET (Path-AS) for each policy.

Fig. 12illustrates the traffic load ratio of Path-AS for each policy. For both RR and UD policies, the source address is decided by the MHH. Thus, they cause less system overhead in MultiGate6. For the UD policy, the host is free to choose which link to establish its connections for the provider selection concern. If the user does not request a particular IPv6 address, the system will choose the first address configured for the host. Connections of a host will go through the same path on MultiGate6. Therefore, the traffic load is far from being balanced between Path-HI and Path-AS. Fig. 12(a) and (b) shows the evaluation results of RR and UD, respectively.

SRTT, LLF and BB policies let MHHs apply the source address indicated by MultiGate6. MultiGate6 measures the network status of each link and informs MHHs to connect through the selected path. Fig. 12(c) shows the evaluation result of policy ‘SRTT’. The SRTT policy calculates the response time of each ISP, and the one with faster response time will have higher priority. Once the response time becomes longer, which means the traffic of the path may be crowdy, MultiGate6 will choose the other link for MHHs’ further connections.

Fig. 12(d) is the evaluation result of policy ‘LLF’. The LLF policy calculates the amount of data (in bytes) transferred in each of its network interfaces in a pre-defined period time. MultiGate6 will choose the path with lower load for MHHs’ further connections. Since an ISP gateway may also be connected with some subnets other than MultiGate6’s subnet, the path load should also consider other subnets’ bandwidth usage. Therefore, it may not be accurate enough for load balancing if the load is only calculated in each network interface by one subnet itself. Furthermore, the LLF policy is not suitable under the circumstance that bandwidths of links are not similar, e.g. Path-A offers a high bandwidth and path-B

(12)

offers a much lower bandwidth than Path-A. If the traffic load calculated in Path-A is a little bit heavier than that of Path-B, although the available bandwidth of Path-A is likely to be higher than that of Path-B, the LLF policy will still choose Path-B for MHHs to connect through. Thus, the above factors should be considered to apply the LLF policy for the multihomed network.

Fig. 12(e) is the evaluation result of policy ‘BB’. The BB policy uses the Pchar to calculate the bandwidth of each link. Comparing with other policies, policy BB achieves the best load balance between path-AS and path-HI. However, in order to calculate the available bandwidth, MultiGate6 has to send a lot of packets to ISPs, which may waste some bandwidth and cause extra overheads.

In order to evaluate the load balancing efficiency of the load balancing policies for more detail, the average load ratio, variance, and standard deviation of each policy is calculated. We do not calculate the data of the UD policy because it lets MHHs apply their default addresses without maintaining the balance of load actively.Table 1shows that the average load ratio is around 50G10%. However, it may not be precise enough to evaluate load balancing efficiency using the average

load ratio. Taking into comparison ofFig. 12(a) and (e) as an illustration. Although the average load ratio of RR (50.9%) is better than that of BB (57.6%), from the two figures we can observe that the variance of policy RR’s load ratio curve is larger than that of policy BB. Therefore, the variance is also calculated to be taken into consideration to evaluate load balancing efficiency. The result shows that, policy BB has the smallest load ratio variance value (0.0133), and the SRTT policy has the largest one (0.0361), whereas the standard deviations are 11.5 and 19.0%, respectively.

From the aforementioned experimental results, except the UD policy, load balancing policies of MultiGate6 can conduct

Fig. 12. Traffic load ratio of Path-AS Traffic load ratio of Path-AS: (a) for policy ‘RR’, (b) for policy ‘UD’, (c) for policy ‘SRTT’, (d) for policy ‘LLF’, and (f) for policy ‘BB’.

Table 1

The load ratios and variances of Path-AS with different load balancing policies Policy Avg. load ratio of

Path-AS (%)

Load ratio variance of Path-AS Standard deviation (%) RR 50.9 0.0338 18.4 LLF 59.1 0.0214 14.6 SRTT 47.2 0.0361 19.0 BB 57.6 0.0133 11.5

(13)

MHHs to distribute the load nearly evenly in the two paths. On the other hand, any MHH can choose whether to accept MultiGate6’s load balancing Router Advertisements or not. Thus, some MHHs can connect through some specific links on their demands without breaking the whole load balance of all links.

6.3. Evaluation results on effects of SRTT, BB, and LLF

Some additional experiments are done to evaluate the effects of applying the ‘SRTT’, ‘BB’, and ‘LLF’ policy.

The SRTT policy selects the path that has the Shortest Round Trip Time. For the SRTT policy, we evaluate its efficiency by measuring the Round-Trip Time of Path-HI and Path-AS. FromFig. 13, we can observe that the curves of

Path-HI and Path-AS are likely to be symmetric. It means that, after applying the SRTT policy, MHHs tend to establish connections through the path that has the Shortest Round Trip Time. More connections will cause more load in a path and hence the delay will increase. Once the path with the shorter Round-Trip Time formerly has longer Round-Trip Time than the other one later due to the more load caused by the connections built by MHHs, MultiGate6 will inform the MHHs to connect through the other path. The load will be distributed to the two paths and therefore the Round-Trip Time of the two paths will likely to be similar.

Fig. 14shows the available bandwidths of HI and Path-AS after applying the BB policy. The BB policy measures the bandwidths of the paths and selects the path that has the larger available bandwidth for MHHs to connect through. In our experimental environment, both Path-HI and Path-AS have the

Fig. 13. The measurements of Round-Trip Time in Path-HI and Path-AS after applying the ‘SRTT’ policy.

(14)

same bandwidth of 10 Mbps. FromFig. 14, we can observe that the available bandwidth curves of the two paths are also likely to be symmetric. It means that the load is distributed to the two paths evenly.

For the LLF policy, MultiGate6 calculates the amount of data transmitted in each path and selects the least-load link for MHHs’ further connections.Fig. 15shows the loads of Path-HI and Path-AS after applying the LLF policy. The loads are measured at every 10 s. The result shows that the loads do not differ much in the two paths, and no path is overloaded particularly. In our experiment, the average load of Path-AS is 86.6 KB whereas the average load of Path-HI is 72.8 KB.

6.4. Evaluation results on interval of Router Advertisements

Since MultiGate6 periodically broadcasts Router Adver-tisements with the multihoming option to MHHs to achieve load balance, the length of the interval that Router Advertisements are sent will influence the load balancing efficiency. For LLF, SRTT, and BB policies, if the interval of broadcasting Router Advertisements is too long, the load will be distributed to the same link for a long time period because MHHs would not change their paths to connect until Router Advertisements of the load balancing type are received. Thus, the bandwidths of all links cannot be utilized because

connections are established through the same path for a long period of time. However, the shorter the interval is, the more Router Advertisements will be broadcasted at the same time. More Router Advertisements will also cause more overheads. Therefore, an appropriate interval should be set to achieve better load balancing efficiency without causing too many overheads.

Fig. 16 shows the average load ratios of Path-AS corresponding to different Router Advertisement intervals, from 5 to 60 s. We do not do experiments on RR and UD policies because the RR policy lets the MHH alternate the address automatically in MHH itself, whereas the UD policy lets the MHH apply its default address to connect. The length of the Router Advertisement interval does not affect the RR and UD policies. FromFig. 16, we can observe that the value of the average load ratio is unrelated to different Router Advertisement intervals. However, from Fig. 17, which shows the load ratio variance of Path-AS corresponding to different Router Advertisement intervals, we can observe that the load variance is smaller with the smaller values of Router Advertisement interval. It means that when the Router Advertisement interval is smaller, the variance of the load ratio is also smaller. In other words, smaller Router Advertisement intervals result in better load balancing efficiency and better bandwidth utilization.

Fig. 15. The measurements of loads in Path-HI and Path-AS after applying the ‘LLF’ policy.

Fig. 16. The average load ratios of Path-AS corresponding to different Router Advertisement intervals.

Fig. 17. The variances of the load ratio of Path-AS corresponding to different Router Advertisement interval.

(15)

To setup an appropriate Router Advertisement interval, some factors should be taken into consideration, such as the number of MHHs, bandwidth usage of each MHH, and bandwidths of links, etc. More MHHs potentially mean more total bandwidth usage. Bandwidth usage of each MHH will also affect the total bandwidth usage. That is, the more the number of MHHs and the larger of the bandwidth usage of each MHH is, the shorter the Router Advertisement interval should be set to achieve better load balancing efficiency. On the other hand, low bandwidth links mean more congestions may happen. Thus the Router Advertisement interval should also be set shorter to prevent the congestions in low-bandwidth links.

6.5. Summary and discussion

From the evaluation results of the above experiments, the usefulness of MultiGate6 is described as follows. MultiGate6 can be used as the multihoming Gateway of a site, a SOHO network, or a small enterprise network that wants to have a multihomed network. MultiGate6 can connect to more than one ISP and provide a multihomed network that is associated with fault tolerance and load balancing functions. The advantages of the hybrid approach adopted in MultiGate6 are summarized as follows:

† Since the packets of MHHs will follow the right routes after mapping the MutiGate6’s routing table, there is no ingress filtering problem.

† Fault tolerance function is achieved by informing MHHs through Router Advertisements broadcasted by MultiGate6. No extra work or cooperation, e.g. tunnelling, is needed between transit ISPs.

† The approach does not cause the increment of DFZ. Therefore, the routing table explosion problem is not suffered and thus this approach is scalable.

† No new protocol is introduced. Only the Router Advertise-ments sent by MutliGate6 need to be modified. The approach is not complex for deployment.

† The approach is backward-compatible. The modification of the router advertisement does not affect the hosts/routers that do not support this approach.

† The approach does not modify the DNS system and hence no impact is caused on DNS.

† This approach can support all types of traffic, e.g. TCP and UDP.

† The approach is extendible. More load balancing policies can be developed according to specific requirements, e.g. a policy that enforces MHHs to connect through a specific ISP at specific time.

Except the UD policy, the evaluation results also show that the four kinds of load balancing policies achieve the approximate balance of load in our experimental environment, in which the two links have the same bandwidth. However, each load balancing policy has its own advantages, dis-advantages, and applicable situations, which are summarized as follows.

† RR: Sine the RR policy lets the MHH choose the link to establish connection in a round-robin way and does not consider the differed bandwidth between links, it is suitable for the multihomed network in which the bandwidths of links are similar. In our evaluation results, it has a large variance of load balancing performance. However, the RR policy is the simplest way to have load balance and nearly causes no overhead to the multihomed network.

† LLF: The LLF policy measures the load of each link and chooses the smallest one for MHH’s connection of the next time. As that is mentioned before, since the LLF policy does not consider the load caused by other subnets, the LLF policy may not provide good load balancing performance as a result. Moreover, the LLF policy does not consider the differed bandwidth between links. Hence, the LLF policy is only suitable for the multihomed network in which the bandwidths of links are similar.

† SRTT: In our evaluation results, the SRTT policy achieves good average load ratio, but it also has the largest load ratio variance. The possible reason is that the link with the Shortest Round Trip Time might not promise the best reachability to hosts’ destinations. The SRTT policy is also suitable for the multihomed network in which the bandwidths of links are not very similar.

† BB: The BB policy takes some time to measure the bandwidth of each link and chooses the link with best bandwidth. Since the network status keeps changing at all time, the measured bandwidth may not represent the real status of the current time. It also causes the most overhead among the load balancing policies. However, the BB policy achieves the best load ratio variance in our evaluation results, and it is also applicable for the multihomed networks in which the bandwidths of links are not similar.

7. Conclusion

In this paper, we have designed and implemented an IPv6 multihoming gateway called ‘MultiGate6’. MultiGate6 pro-vides multihomed network, fault tolerance, load balancing, and provider selection functions to hosts. In our proposed method, a ‘Multihoming Option’ field is inserted in Router Advertise-ments broadcasted by MultiGate6. With the Multihoming Option field, MultiGate6 can specify two multihoming service types—fault tolerance and load balancing, and five load balancing policies—RR, LLF, BB, SRTT, and UD, to hosts. The source address selection module is implemented in the host to accept Router Advertisements containing multihoming information, and then the host can apply the indicated network address for different load balancing concerns. On detecting a link failure, MultiGate6 broadcasts the Router Advertisement of fault tolerance to inform hosts not to connect through the failed link.

The results of evaluating load balancing effect of the five policies are given in this paper. In our experiment, although ‘Best Bandwidth’ (BB) policy works best, measuring bandwidths of links also brings overheads to network traffic.

(16)

Therefore, a load balancing policy should be appropriately chosen for the corresponding multihomed network to achieve the best load balancing efficiency. Moreover, we also analyze the effect of load balancing when different intervals are set for MultiGate6 to broadcast Router Advertisements. A short time interval will cause more overhead, while a larger time interval will cause larger variance of load ratio. It can conclude that the following factors—the number of MHHs, bandwidth usage of each MHH, and bandwidths of links, should be taken into consideration to set up a proper time interval of broadcasting Router Advertisements.

For the future work, an adaptive mechanism can be designed to automatically configure the best load balancing policy and Router Advertisement interval for the administrated network, instead of setting up manually. More load balancing polices can also be designed to achieve better efficiency with minimized overhead, too.

References

[1] The IETF IPv6 Multihoming Working Group,http://www.ietf.org/html. charters/multi6-charter.html.

[2] R. Draves, Default address selection for internet protocol version 6 (IPv6), RFC 3484, IETF, February 2003.

[3] J. Yu, IPv6 multihoming with route aggregation, IETF Internet Draft: draft-ietf-ipngwgipv6multihome-with-aggr-01.txt, August 2000. [4] M. Bagnulo, A. Garcia-Martinez, A. Azcorra, D. Larrabeiti, Survey on

proposed IPv6 multi-homing network level mechanisms, IETF Internet Draft draft-bagnulo-multi6-survey6-00.txt, July 2001.

[5] D. Johnson, S. Deering, Reserved IPv6 subnet anycast addresses, IETF RFC 2526, March 1999.

[6] IETF Internet-Draft: Host Identity Protocol, http://www.ietf.org/internet-drafts/draft-ietf-hip-base-00.txt

[7] IETF Inter-Darft: Architectural Commentary on Site Multi-homing Using a Level 3 Shim,http://www.potaroo.net/drafts/draft-ietf-shim6-arch-00. html

[8] Internet-Draft: LIN6 (Location Independent Networking for IPv6),http:// www.lin6.net/draft/draft-teraoka-multi6-lin6-00.txt

[9] D. Johnson, C. Perkins, J. Arkko, Mobility support in IPv6, IETF RFC 3775, June 2004.

[10] R. Stewart, Q. Xie, et al., Stream control transmission protocol, RFC 2960, IETF, October 2000.

[11] P. Ferguson, D. Senie, Network ingress filtering: defeating denial of service attacks which employ IP source address spoofing, IETF RFC 2827, May 2000.

[12] N. Yamai, K. Okayama, H. Shimamoto, T. Okamoto, A dynamic traffic sharing with minimal administration on multihomed networks, Proceed-ings of the IEEE International Conference on Communications 2001 (ICC2001), vol. 5, June 2001, pp. 1506–1510.

[13] Y. Hori, K. Onimaru, T. Ikenaga, Y. Oie, Design and implementation of IPv6 gateway allowing effective use of multihome network, IEEE PACRIM’03, Victoria, BC, Canada, 28–30 August 2003, pp. 601–604. [14] A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for

the Internet Protocol Version 6 (IPv6) specification, RFC 2463, IETF, December 1998.

[15] B.A. Mah, Pchar: a tool for measuring internet path characteristics, February 1999.

[16] Linux IPv6 Router Advertisement Daemon (radvd),http://v6web.litech. org/radvd/index.html

[17] T. Narten, E. Nordmark, W.A. Simpson, Neighbor discovery for IP version 6 (IPv6), RFC 2461.

[18] S. Thomson, T. Narten, IPv6 stateless address autoconfiguration, RFC2462, IETF, December 1998.

Chung-Ming Huang received the B.S. degree in electrical engineering from National Taiwan Univer-sity on 1984/6, and the M.S. and Ph.D. degrees in computer and informatioin science from The Ohio State University on 1988/12 and 1991/6 respectively. He is currently a professor in Dept. of Computer Science and Information Engineering, National Cheng Kung University, Taiwan, R.O.C. He is the director of The Promotion center for Network Applications and Services Education, National Innovative Communi-cation EduCommuni-cation Program, Ministry of EduCommuni-cation, Taiwan, R.O.C. He has published more than 100 referred journal and conference papers in wireless and mobile communication protocols, interactive multimedia systems, audio and video streaming and formal modeling of communication protocols. He is entitled as a Distinguished Professor of National Cheng Kung University since 2004/8. His research interests include broadband/mobile Internet, wireless and mobile communication protocols and software, wireless and mobile interactive multimedia systems, and media streaming protocols and applications.

Ching-Hsien Tsaireceived the B.S. degree from Department of Computer Science and Information Engineering, National Cheng Kung University on 2001/6. He is currently a Ph.D. candidate in Department of Computer Science and information Engineering, National Cheng Kung University. His research interests are wireless and mobile network protocols, multihoming protocols and applications, and multimedia streaming.

Po-Chou Su received the B.S. degree from Department of Computer Science and Information, Feng Chia University on 2002/6, and the M.S. degree from Department of Computer Science and Information Engineering, National Cheng Kung University on 2004/6. His research interests are embedded systems and multihoming protocols and applications.

References

Related documents

Durante os testes com a BLIS P16 e a bacteriocina A53, foi possível se observar que as mesmas possuíam uma ação sobre a morfologia externa celular da Leishmania, o que já

We argue in this paper that women in Egypt, particularly young women, face job quality issues that discourage them from continuing to work or even entering the

Obtaining the highest possible quality of signals is the first phase in the processing pipeline of biometrics. The second is the pattern recognition process, which heavily relies on

Co-coordinator - First Annual Nationwide Forensic Nursing Death Investigation Course at Harris County Medical Examiner Office, Houston, TX, 2005;. Presenter – “ Conducting

The FSC logo, the initials ‘FSC’ and the name ‘Forest Stewardship Council’ are registered trademarks, and therefore a trademark symbol must accompany the.. trademarks in

We have analysed four sets of labour-market experiences. The …rst was the transition from compulsory school to various states: continuing their education, …nding a job,

Crossmatch -The testing of donor blood cells against recipient blood cells to determine if pre-sensitization to donor antigens is present (such as, to determine whether the tissues

The proof of product effect on the selected panel of volunteers through an integrated and multi-tool approach MALDI-TOF based microorganism identification with