Abstract:
A method for generating a decision table for selecting an optimal path out of a plurality of data paths between a client and a destination server connected through a network system, each of the plurality of data paths is connected to a router configured with a unique internet protocol (IP) address is provided. The method includes for each subnet IP address of the remote destination server and each of the plurality of data paths, measuring a network proximity; factoring the network proximity measured for each of the plurality of data paths; and ranking the plurality of data paths based on a decision function computed using the factored network proximity.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a Continuation of U.S. application Ser. No. 13/566,171, now U.S. Pat. No. 8,484,374. The Ser. No. 13/566,171 application is a continuation of U.S. application Ser. No. 10/449,016 filed Jun. 2, 2003, now U.S. Pat. No. 8,266,319. The 10/449,016 Application is a Division of U.S. application Ser. No. 09/467,763 filed Dec. 20, 1999, now U.S. Pat. No. 6,665,702, which is a Continuation-in-part of U.S. application Ser. No. 09/115,643, filed Jul. 15, 1998, now U.S. Pat. No. 6,249,801. The contents of the above-referenced applications are herein incorporated by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention relates to computer networks in general, and in particular to load balancing client requests among redundant network servers in different geographical locations. 
       BACKGROUND 
       [0003]    In computer networks, such as the Internet, preventing a server from becoming overloaded with requests from clients may be accomplished by providing several servers having redundant capabilities and managing the distribution of client requests among the servers through a process known as “load balancing”. 
         [0004]    In one early implementation of load balancing, a Domain Naming System (DNS) server connected to the Internet is configured to maintain several IP addresses for a single domain name, with each address corresponding to one of several servers having redundant capabilities. The DNS server receives a request for address translation and responds by returning the list of server addresses from which the client chooses one address at random to connect to. Alternatively, the DNS server returns a single address chosen either at random or in a round-robin fashion, or actively monitors each of the servers and returns a single address based on server load and availability. 
         [0005]    More recently, a device known as a “load balancer,” such as the Web Server Director, commercially available from the Applicant/assignee, has been used to balance server loads as follows. The load balancer is provided as a gateway to several redundant servers typically situated in a single geographical location and referred to as a “server farm” or “server cluster.” DNS servers store the IP address of the load balancer rather than the addresses of the servers to which the load balancer is connected. The load balancer&#39;s address is referred to as a “virtual IP address” in that it masks the addresses of the servers to which it is connected. Client requests are addressed to the virtual IP address of the load balancer which then sends the request to a server based on server load and availability or using other known techniques. 
         [0006]    Just as redundant servers in combination with a load balancer may be used to prevent server overload, redundant server farms may be used to reroute client requests received at a first load balancer/server farm to a second load balancer/server farm where none of the servers in the first server farm are available to tend to the request. One rerouting method currently being used involves sending an HTTP redirect message from the first load balancer/server farm to the client instructing the client to reroute the request to the second load balancer/server farm indicated in the redirect message. This method of load balancing is disadvantageous in that it can only be employed in response to HTTP requests, and not for other types of requests such as FTP requests. Another rerouting method involves configuring the first load balancer to act as a DNS server. Upon receiving a DNS request the first load balancer simply returns the virtual IP address of the second load balancer. This method of load balancing is disadvantageous in that it can only be employed in response to DNS requests where there is no guarantee that the request will come to the first load balancer since the request does not come directly from the client, and where subsequent requests to intermediate DNS servers may result in a previously cached response being returned with a virtual IP address of a load balancer that is no longer available. 
         [0007]    Where redundant server farms are situated in more than one geographical location, the geographical location of a client may be considered when determining the load balancer to which the client&#39;s requests should be routed, in addition to employing conventional load balancing techniques. However, routing client requests to the geographically nearest server, load balancer, or server farm might not necessarily provide the client with the best service if, for example, routing the request to a geographically more distant location would otherwise result in reduced latency, fewer hops, or provide more processing capacity at the server. 
       SUMMARY 
       [0008]    Certain embodiment disclosed herein include a method for load balancing client requests among a plurality of internet service provider (ISP) links in a multi-homed network. The method comprises resolving an incoming domain name server (DNS) query for an address associated with a domain name of a server within the multi-homed network, wherein the incoming DNS query is received from a client; 
         [0009]    selecting, based on at least one load balancing criterion, one ISP link from the plurality ISP links; and returning an internet protocol (IP) address selected from a range of IP addresses associated with the selected ISP link, thereby subsequent requests from the client are routed through the selected ISP link. 
         [0010]    Certain embodiment disclosed herein also include a device for load balancing client requests among a plurality of internet service provider (ISP) links in a multi-homed network. The devices comprises a network controller configured to resolve an incoming domain name server (DNS) query for an address associated with a domain name of a server within the multi-homed network, wherein the incoming DNS query is received from a client; and a balancer module configured to select, based on at least one load balancing criterion, one ISP link from the plurality ISP links; wherein the network controller is further configured to return an internet protocol (IP) address selected from a range of IP addresses associated with the selected ISP link, thereby subsequent requests from the client are routed through the selected ISP link. 
         [0011]    Certain embodiment disclosed herein also include a method for load balancing traffic among a plurality of data paths between a client and a destination server connected through a network system, each of the plurality of data paths is connected to a router configured with a unique internet protocol (IP) address. The method comprises receiving a data packet from a client; selecting a data path to route the received data packet to the destination server using a decision function, wherein the decision function is based at least on a content type of the received data packet; and routing the received data packet and subsequent data packets from the client to the destination server over the selected data path. 
         [0012]    Certain embodiment disclosed herein also include a content router for load balancing traffic among a plurality of data paths between a client and a destination server connected through a network system, each of the plurality of data paths is connected to a router configured with a unique internet protocol (IP) address. The content router comprises an interface for receiving a data packet from a client; a memory for maintaining a decision table summarizing decision functions computed for the destination server for each type of content; and a load balancing module for selecting a data path to route the received data packet to the destination server using a decision function, wherein the decision function is based at least on a content type of the received data packet; wherein the interface is further configured to route the received data packet and subsequent data packets from the client to the destination server over the selected data path. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    The present invention will be understood and appreciated from the following detailed description, taken in conjunction with the drawings in which: 
           [0014]      FIGS. 1A-1C , taken together, are simplified pictorial flow illustrations of a triangulation load balancing system constructed and operative in accordance with a preferred embodiment of the present invention; 
           [0015]      FIGS. 2A-2F , taken together, are simplified pictorial flow illustrations of a network proximity load balancing system constructed and operative in accordance with another preferred embodiment of the present invention; 
           [0016]      FIGS. 3A-3F , taken together, are simplified pictorial flow illustrations of a preferred embodiment of the present invention for managing and load balancing a multi-homed network architecture whereby a client is connected to the Internet through multiple ISPs; and 
           [0017]      FIGS. 4A and 4B , taken together, are simplified pictorial illustrations of a preferred embodiment of the present invention used to resolve incoming DNS requests for a-multi-homed network architecture; 
           [0018]      FIG. 5  illustrates a content routing system constructed and operative in accordance with yet another preferred embodiment of the present invention; 
           [0019]      FIG. 6  is a simplified flowchart illustrating the operation of the content router in accordance with another preferred embodiment of the present invention; and 
           [0020]      FIG. 7  illustrates a typical Destination Table which is compiled by the content router for each router and its respective path in accordance with another preferred embodiment&#39; of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]    Reference is now made to  FIGS. 1A-1C  which, taken together are simplified pictorial flow illustrations of a triangulation load balancing system constructed and operative in accordance with a preferred embodiment of the present invention. Two server farms, generally designated  10  and  12  respectively, are shown connected to a network  14 , such as the Internet, although it is appreciated that more than two server farms may be provided. Server farms  10  and  12  typically comprise a load balancer  16  and  18  respectively, which may be a dedicated load balancer or a server or router configured to operate as a load balancer, with each of the load balancers being connected to one or more servers  20 . Load balancers  16  and  18  are alternatively referred to herein as LB 1  and LB 2  respectively. LB 1  and LB 2  typically maintain a server status table  22  and  24  respectively, indicating the current load, configuration, availability, and other server information as is common to load balancers. LB 1  and LB 2  also typically periodically receive and maintain each other&#39;s overall status and load statistics such that LB 1  and LB 2  can know each other&#39;s availability. 
         [0022]    Typical operation of the triangulation load balancing system of  FIGS. 1A-1C  is now described by way of example. As is shown more particularly with reference to FIG. IA, a client  26 , such as any known computer terminal configured for communication via network  14 , is shown sending a request  28 , such as an FTP or HTTP request, to LB 1  whose virtual IP address is 100.100.1.0. In accordance with network transmission protocols, request  28  indicates the source IP address of the requestor, being the IP address 197.1.33.5 of client  26 , and the destination IP address, being the virtual IP address 100.100.1.0 of LBI. LB 2  preferably periodically sends a status report  30  to LB 1 , the virtual IP address 100.100.1.0 of LB 1  being known in advance to LB 2 . Status report  30  typically indicates the availability of server farm  12  and provides load statistics, which LBI maintains. 
         [0023]    LB 2  is preferably capable of having multiple virtual IP addresses as is well known. It is a particular feature of the present invention for LB 2  to designate a currently unused virtual IP address, such as 200.100.1.1, for LBI&#39;s use and store the mapping between the IP address of LB 1  and the designated IP address in a triangulation mapping table  32 , as is shown more particularly with reference to  FIG. 1B . The designated address is referred to herein as the triangulation address and may be preconfigured with LBI or periodically provided to LB 1  from LB 2 . LB 1  preferably maintains in a client mapping table  36  a mapping of the IP address 197.1.33.5 of client  26  and the triangulation address 200.100.1.1 of LB 2  to which client  26 &#39;s requests may be redirected. 
         [0024]    As shown in the example of  FIG. 1A , server status table  22  of LB 1  indicates that no servers in server farm  10  are available to service client  26 &#39;s request, but indicates that server farm  12  is available. Having decided that client  26 &#39;s request should be forwarded to LB 2  in  FIG. 1C  LB 1  substitutes the destination IP address of request  28  with the virtual IP address 200.100.1.1 of LB 2  which is now mapped to the IP address of client  26  as per client mapping table  36  and sends an address-modified client request  38  to LB 2 . LB 2 , upon receiving request  38  at its virtual IP address 200.100.1.1, checks triangulation mapping table  32  and finds that virtual IP address 200.100.1.1 has been designated for LB 1 &#39;s use. LB 2  therefore uses the virtual IP address 100.100.1.0 of LB 1  as per triangulation mapping table  32  as the source IP address of an outgoing response  40  that LB 2  sends to client  26  after the request has been serviced by one of the servers in server farm  12  selected by LB 2 . It is appreciated that response  40  must appear to client  26  to come from LB 1 , otherwise client  26  will simply ignore response  40  as an unsolicited packet. Client  26  may continue to send requests to LB 1  which LB 1  then forwards requests to LB 2  at the designated triangulation address. LB 2  directs requests to an available server and sends responses to client  26  indicating LBI as the source IP address. 
         [0025]    Reference is now made to  FIGS. 2A-2F  which, taken together, are simplified pictorial flow illustrations of a network proximity load balancing system constructed and operative in accordance with another preferred embodiment of the present invention. The configuration of the system of  FIGS. 2A-2F  is substantially similar to  FIGS. 1A-1C  except as otherwise described hereinbelow. For illustration purposes, a third server farm, generally designated  50 , is shown connected to network  14 , although it is appreciated that two or more server farms may be provided. Server farm  50  typically comprises a load balancer  52 , which may be a dedicated load balancer or a server or router configured to operate as a load balancer, with load balancer  52  being connected to two or more servers  20 . Load balancer  52  is alternatively referred to herein as LB 3 . 
         [0026]    Typical operation of the network proximity load balancing system of  FIGS. 2A-2F  is now described by way of example. As is shown more particularly with reference to  FIG. 2A , client  26  is shown sending request  28 , such as an FTP or HTTP request, to LB 1  whose virtual IP address is 100.100.1.0. LB 1  preferably maintains a proximity table  54  indicating subnets and the best server farm site or sites to which requests from a particular subnet should be routed. Determining the “best” site is described in greater detail hereinbelow. 
         [0027]    Upon receiving a request, LB 1  may decide to service the request or not based on normal load balancing considerations. In any case, LB 1  may check proximity table  54  for an entry indicating the subnet corresponding to the subnet of the source IP address of the incoming request. As is shown more particularly with reference to  FIG. 2B , if no corresponding entry is found in proximity table  54 , LB 1  may send a proximity request  56  to LB 2 , and LB 3 , whose virtual IP addresses are known in advance to LB 1 . Proximity request  56  indicates the IP address of client  26 . 
         [0028]    A “network proximity” may be determined for a requestor such as client  26  with respect to each load balancer/server farm by measuring and collectively considering various attributes of the relationship such as latency, hops between client  26  and each server farm, and the processing capacity and quality of each server farm site. To determine comparative network proximity, LB 1 , LB 2  and LB 3  preferably each send a polling request  58  to client  26  using known polling mechanisms. While known polling mechanisms included pinging client  26 , sending a TCP ACK message to client  26  may be used where pinging would otherwise fail due to an intervening firewall or NAT device filtering out a polling message. A TCP ACK may be sent to the client&#39;s source IP address and port. If the client&#39;s request was via a UDP connection, a TCP ACK to the client&#39;s source IP address and port  80  may be used. One or both TCP ACK messages should bypass any intervening NAT or firewall and cause client  26  to send a TCP RST message, which may be used to determine both latency and TTL. While TTL does not necessarily indicate the number of hops from the client to the load balancer, comparing TTL values from LB 1 , LB 2 , and LB 3  should indicate whether it took relatively more or less hops. 
         [0029]    Another polling method involves sending a UDP request to a relatively high port number at the client, such as  2090 . This request would typically be answered with an “ICMP port unreachable” reply which would indicate the TTL value of the UDP request on arrival at the client. Since the starting TTL value of each outgoing UDP request is known, the actual number of hops to the client may be determined by subtracting the TTL value on arrival at the client from the starting TTL value. A combination of pinging, TCP ACK, UDP, TCP SYN, and other polling techniques may be used since any one polling request might fail. 
         [0030]    Client  26  is shown in  FIG. 2D  sending a polling response  60  to the various polling requests. The responses may be used to determine the latency of the transmission, as well as the TTL value. LB 2  and LB 3  then send polling results  62  to LB 1 , as shown in  FIG. 2E . The polling results may then be compared, and LB 1 , LB 2 , and LB 3  ranked, such as by weighting each attribute and determining a total weighted value for each server farm. Polling results may be considered together with server farm capacity and availability, such as may be requested and provided using known load balancing reporting techniques or as described hereinabove with reference to  FIGS. 1A and 1B , to determine the server farm site that is “closest” to client  26  and, by extension, the client&#39;s subnet, which, in the example shown, is determined to be LB 2 . For example, the closest site may be that which has the lowest total weighted value for all polling, load, and capacity results. LB 1  may then store the closest site to the client/subnet in proximity table  54 . 
         [0031]    As was described above, a load balancer that receives a request from a client may check proximity table  54  for an entry indicating the subnet corresponding to the subnet of the source IP address of the incoming request. Thus, if a corresponding entry is found in proximity table  54 , the request is simply routed to the location having the best network proximity. Although the location having the best network proximity to a particular subnet may have already been determined, the load balancer may nevertheless decide to forward an incoming request to a location that does not have the best network proximity should a load report received from the best location indicate that the location is too busy to receive requests. In addition, the best network proximity to a particular subnet may be periodically redetermined, such as at fixed times or after a predetermined amount of time has elapsed from the time the last determination was made. 
         [0032]    As is shown more particularly with reference to  FIG. 2F , once the closest site for client  26  has been determined, client  26  may be redirected to the closest site using various methods. If a DNS request is received from client  26 , LBI may respond with LB 2 &#39;s address. If an HTTP request is received from client  26 , HTTP redirection may be used. Alternatively, regardless of the type of request received from client  26 , triangulation as described hereinabove with reference to  FIGS. 1A-1C  may be used. 
         [0033]    The present invention can also be used in a multi-homing environment; i.e., for management of networks that have multiple connections to the Internet through multiple Internet Service Providers (ISPs). 
         [0034]    Reference is now made to  FIGS. 3A-3F , which illustrate a preferred embodiment of the present invention for managing and load balancing a multi-homed network architecture whereby a client is connected to the Internet through multiple ISPs. As illustrated in  FIG. 3A , a client  105  is connected to the Internet  110  through three ISPs,  115 ,  120  and  125 , each having a respective router  130 ,  135  and  140  to controls the flow of data packets. The system includes a content router  145 , operative in accordance with a preferred embodiment of the present invention, to provide efficient connectivity between client  105  and Internet servers, such as server  150 . As illustrated in  FIG. 3A , client  105  has an IP address of 10.1.1.1 on a private network, and seeks to connect to server  150  having an IP address of 192.115.90.1. 
         [0035]    As illustrated in  FIG. 3B , ISPs  115 ,  120  and  125  assign respective IP address ranges to the client network, indicated in  FIG. 3B  by ranges 20.x.x.x, 30.x.x.x and 40x.x.x. The first time that client  105  connects to server  150 , content router  145  preferably sends polling requests through each of routers  130 ,  135  and  140  in order to determine the proximity of server  150  to client  105 . When sending the polling requests, content router  145  assigns respective network addresses 20.1.1.1, 30.1.1.1 and 40.1.1.1 to client  105 . Thus three polling requests are sent: one from each of the sources 20.1.1.1, 30.1.1.1 and 40.1.1.1 to destination 192.115.90.1. 
         [0036]    As illustrated in  FIG. 3C , server  150  replies to each network address 20.1.1.1, 30.1.1.1 and 40.1.1.1, and the replies are accordingly transmitted through each of the respective ISPs  115 ,  120  and  125 . Each of the replies is measured for latency and number of hops. For example, as illustrated in  FIG. 3C , the three replies respective have latency and TTL metrics of 800/60; 300/54; and 500/56. 
         [0037]    Based on these polling results, content router  145  chooses, for example, router  135  as its first choice for connecting client  105  with server  150 . As illustrated in  FIG. 3D , proximity results are stored in a proximity table  155 . Specifically, proximity table  155  indicates that router  135  is the first choice for connecting content router  145  to any computer residing on subnet 192.115.90. Thus, when a new client  160  with IP address 10.2.2.2 on the private network attempts to connect to a server  165  with IP address 192.115.90.2, through a content router  145 , content router  145  determines from proximity table  155  that the best router to use is router  135 . 
         [0038]    In turn, as illustrated in  FIG. 3E , content router  145  sends requests issued from client  160  via router  135 , and indicates a source IP address of 30.1.1.1 with each such request, which is the IP address associated with router  135  from within the range of IP addresses allocated by ISP  120 . 
         [0039]    As illustrated in  FIG. 3F , this ensures that subsequent responses sent back from server  165  will be addressed to IP address 30.1.1.1 and, accordingly, will be routed through ISP  120 . Content router  145  in turn uses network address translation (NAT) data to determine that IP address 30.1.1.1 corresponds to private IP address 10.2.2.2, and transmits the responses from server  165  back to client  160 . 
         [0040]    Reference is now made to  FIG. 4A , which illustrates a preferred embodiment of the present invention used to resolve incoming DNS requests for a multi-homed network architecture. Server  170  is assigned IP address 10.3.3.3 within a private multi-homed network, similar to the network illustrated in  FIG. 3A . Each of ISPs  115 ,  120  and  125  assigns a range of IP addresses to the multi-homed network. A DNS request for resolution of a domain name is issued from a client  175  with IP address 192.115.90.3. The DNS request has a source IP address of 192.115.90.3 and a destination IP address of 20.1.1.1. As such, it arrives at content router  145  via router  130 . 
         [0041]      FIG. 4B  indicates a NAT mapping table  180 , showing that the private IP address 10.3.3.3 for server  170  is translated to IP addresses 20.3.3.3, 30.3.3.3 and 40.3.3.3, respectively, by routers  130 ,  135  and  140 . Content router  145  looks up the subnet entry 192.115.90 in proximity table  155 , and identifies router  135  as the first choice for best proximity between server  170  and client  175 . In resolving the DNS request, content router  145  accordingly provides 30.3.3.3 as the IP address for server  170 . This ensures that requests from client  175  are sent to server  170  with a destination IP address of 30.3.3.3, which in turn ensures that the client requests are transmitted through ISP  120 . 
         [0042]    It can be seen from  FIGS. 3A-3F  that the present invention efficiently balances the load among the three ISPs  115 ,  120  and  125  for outgoing connections. Similarly, it can be seen from  FIGS. 4A and 4B  that the present invention efficiently balances the load among the three ISPs  115 ,  120  and  125  for incoming connections. In the event that the router indicated as first choice for the best proximity connection is unavailable or overloaded, the present invention preferably uses a second choice router instead. Thus the present invention ensures that if an ISP service is unavailable, connectivity to the Internet is nevertheless maintained. 
         [0043]    Referring back to  FIG. 3F , suppose for example that ISP  120  is unavailable, and that content router  145  routes the outgoing client request through ISP  125  instead of through ISP  120 . In accordance with a preferred embodiment of the present invention, content router  145  routes the outgoing request through ISP  125  and labels the outgoing request with a source IP address of 40.1.1.1. Had content router  145  used ISP  125  but indicated a source IP address of 30.1.1.1, the response from server  150  would be directed back through ISP  120 , and not be able to get through to client  160 . 
         [0044]    Similarly, referring back to  FIG. 4B , suppose for example that ISP  120  is unavailable, and that content router  145  resolves the DNS request with IP address 40.3.3.3 instead of IP address 30.3.3.3. This ensures that client  175  directs its requests through ISP  125 , and avoids any blockage at ISP  120 . 
         [0045]    Reference is now made to  FIG. 5 , which illustrates a content routing system  500  constructed and operative in accordance with yet another preferred embodiment of the present invention. The content routing system  500 , connects a client  502  to a destination  504  via a network system, such as the Internet network  506 , using a content router  508 . The content router  508  is connected to the Internet  506  typically via routers, R 1   510  and R 2   512 . The content router  508  presents to the client  502  the most efficient pathway for choosing his connection to the destination  504 . The routers  510  and  512  are connected to paths  514  and  516 , respectively, and each path possess a path quality factor, Q 1  and Q 2 , respectively. 
         [0046]    The path quality factor Qi is defined as: 
         [0000]      Path Quality Factor  Qi=Q (traffic load; packet loss; link pricing) 
         [0047]    The path quality factor, for a given path, is typically dependent on the data content of the data packet. Typical path quality weighting factors are shown in Table 1 for the listed data content. It is appreciated that path quality factor is typically checked periodically, by the content router  508 , for each Internet path. 
         [0048]    It is appreciated that the managing of the routing by the content router  508 , typically depends on the following factors: the content type, the number of hops to the destination, the response time of the destination, the availability of the path, the costing of the link and the average packet loss in the link. 
         [0049]    In order for the content router  508  to determine the “best” path, a “Decision Parameter Table” is built for each content type. It is appreciated that the content type may vary between the application type and actual content (URL requested, or any other attribute in the packet). The Decision Parameter Table is preferably dependent on the parameters: Data packet content; Hops weighting factor; Packet loss factor and Response time factor. Typical values of these parameters are also given in Table 1. 
         [0000]    
       
         
               
               
               
               
               
             
               
               
               
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 Content 
                   
                   
                 Response 
                   
               
               
                 Type 
                 Packet Loss, % 
                 Hops, % 
                 Time, % 
                 Path Quality, % 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 HTTP 
                 0 
                 20 
                 60 
                 20 
               
               
                 FTP 
                 30 
                 0 
                 50 
                 20 
               
               
                 URL1 
                 0 
                 30 
                 50 
                 20 
               
               
                 URL2 
                 0 
                 30 
                 50 
                 20 
               
               
                 File Type 1 
                 20 
                 20 
                 40 
                 20 
               
               
                 File Type 2 
                 20 
                 10 
                 30 
                 40 
               
               
                 Telnet 
                 0 
                 0 
                 20 
                 80 
               
               
                   
               
             
          
         
       
     
         [0050]    In addition to the parameters listed in Table 1, the following additional parameters may also be taken into consideration Hops count factor; Response time factor, Path quality factor; and Packet loss factor. 
         [0051]    A Destination Table is built to summarize the following factors: the content type, the number of hops to the destination, the response time of the destination, the availability of the path, and the average packet loss in the link, based on proximity calculations, as previously defined. 
         [0052]    Using the relevant data, as typically listed in Table 1, the content router  508  determines a Decision Function F content  for each path: 
         [0000]        F   content   =F (Hops weighting factor*Hops count factor; Response weighting factor*Response time factor,Path quality weighting factor*Path quality factor; Packet loss weighting factor*Packet loss factor). 
         [0053]    It is appreciated that the above parameters, which are used in the calculation of F content , are typically normalized for each path. 
         [0054]    Based on the Decision Function the content router  508  selects one of the available paths. The data packet is then routed through the selected path. The Decision Function for a particular path is determined by an administrative manager (not shown) and may depend, for example, on the minimum number of hops or on the relevant response time, or on the packet loss, or on the path quality, or any combination of the above parameters, according to the administrative preferences. 
         [0055]    The operation of the content router  508  is summarized in the flowchart  600  illustrated in  FIG. 6 . In the first step  602 , the client  502  wishing to send a data packet to the destination  504 , sends the data packet (step  602 ) to the content router  508 . The content router  508  preferably first checks (step  604 ) to determine if the destination  504  is known (familiar) from the Destinations Table ( FIG. 7 ) and that a previous check for the subnet of the destination  504  was already performed. If the destination  504  is familiar, the content router  508  selects a link to the destination  504  using the F content  function, taking into account the parameters that were gathered earlier (step  606 ). The F content  function is normalized. The decision made in step  608  is then used by the content router  508  to make the connection with the destination  504  for routing the data packet. 
         [0056]    If the destination  504  is unfamiliar, the content router  508  performs a destination check (step  610 ). The destination check is performed by using the proximity methods, as described hereinabove, by generating actual web traffic towards the destination subnet. This function, as carried out by the content router  508  comprises building a Destination Table ( FIG. 7 ), for each available router and its respective path. The Destination Table may then be used by the content router  508  on the next occasion the client  502  wishes to transfer data packets to the destination  504 . Consecutively, the content router  508  chooses the router (step  608 ) for transferring the data packet to the destination  504 . This decision is preferably dependent on the path quality factor, as defined hereinabove. 
         [0057]    Thus it may be appreciated that the present invention enables a multi-homed network architecture to realize the full benefits of its redundant route connections by maintaining fault tolerance and by balancing the load among these connections, and preferably using data packet content information in an intelligent decision making process. 
         [0058]    It is appreciated that elements of the present invention described hereinabove may be implemented in hardware, software, or any suitable combination thereof using conventional techniques. 
         [0059]    It is appreciated that the steps described with reference to  FIGS. 1A-1C  and  2 A- 2 F need not necessarily be performed in the order shown unless otherwise indicated, and that in fact different implementations of the steps may be employed to yield similar overall results. 
         [0060]    It is appreciated, that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination. 
         [0061]    It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention is defined only by the claims that follow: