WO2005006649A1 - Multi-node network having common routing table - Google Patents

Multi-node network having common routing table Download PDF

Info

Publication number
WO2005006649A1
WO2005006649A1 PCT/US2003/018469 US0318469W WO2005006649A1 WO 2005006649 A1 WO2005006649 A1 WO 2005006649A1 US 0318469 W US0318469 W US 0318469W WO 2005006649 A1 WO2005006649 A1 WO 2005006649A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
node
field
entry
routing table
stores
Prior art date
Application number
PCT/US2003/018469
Other languages
French (fr)
Inventor
Lan Ngoc Vu
Original Assignee
Web Office, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/44Distributed routing

Abstract

System and method for operating, via the Internet, a multi-node network (12) having a common routing table (32). A local copy of the common routing table (12) is maintained in each of the network (12), both servers (14,22) and their respective clients (16,18,20,24,26,28). In the event that any node discovers that another node is no longer online, the discovering node takes appropriate steps to assure that all of the other nodes are made aware of the system change and can make appropriate updates to their local copies of the common routing table (32). Preferably, the common routing table (32) contains recent workload information sufficient to allow dynamic distribution of workload among the several servers.

Description

MULTI-NODE NETWORK HAVING COMMON ROUTING TABLE CROSS-REFERENCE TO RELATED APPLICATIONS The present invention is related to the following co-pending applications for patents (the "Related Applications"): "System and Method for Facilitating Business-to-Business Business", U.S. Application Serial Number 09/597,359, filed 19 June 2000 and assigned to the assignee hereof ("First Application"); "System and Method for Dynamic Local Caching of Web Content", U.S. Application Serial Number 09/699,093, filed 28 October 2000 and assigned to the assignee hereof ("Second Application"); "System and Method for Multi-Tier Multi-Casting Over the Internet", U.S.

Application Serial Number 09/917,412, filed 28 July 2001 and assigned to the assignee hereof ("Third Application"); and "System and Method for Secure Communication Over the Internet", U.S. Application Serial Number 10/039,792, filed 24 October 2001 and assigned to the assignee hereof ("Fourth Application"). BACKGROUND OF THE INVENTION

1. TECHNICAL FIELD. Our invention relates generally to a method and apparatus for operating a multi-node network over the Internet. 2. BACKGROUND ART. In general, in the descriptions that follow, we will italicize the first occurrence of each special term of art which should be familiar to those skilled in the art of network communication systems. In addition, when we first introduce a term that we believe to be new or that we will use in a context that we believe to be new, we will bold the term and provide the definition that we intend to apply to that term. In addition, throughout this description, we may use the terms assert and negate when referring to the rendering of a signal signal flag, status bit, or similar apparatus into its logically true or logically false state, respectively. In our Related Applications, we related, among other things, the following: While the number of single entity intra-nets continually increases, most multi-site entities utilize -public networks for inter-site transactions. Since the Internet is the best known of the public networks, we will tend to refer to it hereafter (or to its alter ego, the World Wide Web ("WWW")or just Web) for purposes of example. However, numerous Internet service providers or ISPs have set up their privately-owned networks so as to be semi-autonomous from the remainder of the Internet, thereby allowing their subscribers to exploit the many advantages inherent in such intra-ISP communication facilities. For our purposes, therefore, we intend the term "public network" to include any network to which a member of the public, in our case any business entity, can obtain access by payment of a periodic service fee. Thus, we distinguish such intra-ISP- networks from truly private networks that are owned and operated by single organizations, such as large corporations, and to which access is limited to only members (e.g., employees) of that organization (these we will refer to as "iNets"). For purposes of this application, we shall refer hereinafter to an employee connected to an iNet as if she were a client of the business systems that have been fully and completely disclosed in the First, Second, Third and Fourth Applications. A virtual private network ("VPN") is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. A VPN can be contrasted with a system of owned or leased lines that can only be used by one company. The idea of the VPN is to give the company the same capabilities at much lower cost by using the shared public infrastructure rather than a private one. In theory, a VPN facilitates sharing of public resources for the secure exchange of private data. One major use of VPN is to enable secure communications between client servers connected to different, remotely located segments of a distributed iNet. For convenience of reference, we refer to the set of commonly owned client servers connected to a single, corporate-wide iNet as siblings. Using a VPN involves encrypting data before sending it through the public network and decrypting it at the receiving end. An additional level of security involves encrypting not only the data but also the originating and receiving network addresses. VPN software is typically installed as part of a company's firewall server. The Point-to-Point Tunneling Protocol 'PPTP") is one protocol that has been proposed to create a VPN using tunnels through the Internet. Each tunnel is the particular path that a given company message or file might travel through the Internet. Using PPTP, which is an extension of the Internet's Point-to-Point Protocol ("PPP"), any employee having a PC with PPP client support will be able to use any ISP to connect securely to the employer's server. This means that companies will no longer need their own leased lines for wide-area communication but could securely use the public networks. One primary function of a firewall is to render invisible from the Internet side all client servers that may be connected to the iNet side. We refer to think of such client servers as being cloaked by the firewall. One consequence of being cloaked is that a VPN can be initiated only by a cloaked client server. Accordingly, special procedures are required before a sibling client server connected to a remotely located segment of that iNet (or perhaps a mobile client server that is connected to the Internet via a temporary public connection) will be allowed to initiate a VPN with a cloaked client server. This problem is further exacerbated if the sibling client server is itself cloaked by a second firewall. What is needed is a general solution to secure communications between cloaked, sibling client servers and their respective clients. In general, chatting is talking to other people who are simultaneously using the Internet. In a typical chat session, messages entered at one site (using an input device such as a keyboard) are deposited into a message repository at a chat site, and then relayed to a group of users who take part from anywhere on the Internet. If desired, a private chat can be arranged between two parties.

Chat sites open to members of the public are often established by popular ISP's. Internet Relay Chat ("IRC") is a preferred protocol for performing various essential chat-related functions, such as establishing a chat group or channel or discovering existing chat groups and their members. The IRC protocol uses TCP, usually on port 6667. While current chat technology is sufficient to facilitate informal communication between chat users, it, by itself, is not sufficient to provide secure communication between users. Now, since the filing of our Related Applications, we have come to realize that, in addition to the deficiencies and problems related above, the following deficiencies and problems are present in currently-available Internet communication systems: In a typical iNet comprising multiple client servers organized into multiple tiers, a selected one of the servers, located at the logical root of the tree-like structure, is tasked with mamtairύng a master routing table ("RT") that must be constantly updated to reflect the status of each node in the structure. In such an arrangement all intra-net traffic must be routed by the root server. As a result, the entire system to vulnerable to catastrophic failure in the event the root server goes down. For reasons of system reliability, it would be preferable to provide a more distributed mechanism for maintaining the RT. In a typical multi-partition iNet, in which the iNet is partitioned into a plurality of interconnected sub-nets, each partition is managed by a respective partition server. Depending upon the size of the iNet, one or more higher levels of multi-partition servers may be provided to manage increasing larger combinations of sub-nets. At each level, one or more respective partition servers maintain the respective RTs for their sub-nets. In such an arrangement, the loss of one of the partition servers results in the effective loss of the entire sub-net until some higher lever partition server finally succeeds in reestabHshing communication with the surviving nodes of that sub-net. To minimize system recovery time, it would be preferable to provide a mechanism whereby a single master RT is coherently maintained within each server, thereby facilitating, in the event of loss of any one or more of the partition servers, rapid reconstruction of the balance of the iNet by the remaining partition servers. In the typical multi-tiered iNet wherein a plurality of servers are each responsible for managing a respective portion of the system RT, the workload on each server just to manage the RT increases rapidly as the total number of nodes in the structure varies over time (e.g., due to new machines coming on-line while others go off-line). This workload will be further increased if, in addition to reflecting simply node membership, the RT maintains node operating history information. For reasons of system workload management, it would be preferable to provide a more efficient mechanism for sharing the burden of maintaining the RT. BRIEF SUMMARY OF THE INVENTION In accordance with a preferred embodiment of our invention, we provide a method for operating, via the Internet, a network comprised of n nodes. According to our method, we first determine an address on the Internet of each of the nodes. We then create a routing table having, for each of the nodes, an entry comprising a first field that stores the IP address of the node. Once created, we store a copy of said routing table at each of said nodes. Thereafter, we can route all accesses by a first of the nodes to a second of the nodes using the copy of the routing table stored locally at the first node, thereby eliminating the requirement to provide centralized routing services. In accordance with another embodiment of our invention, we provide, in an n-node network, operated via the Internet, a distributed routing method.

According to our method we first determine an address on the Internet of each of the nodes. We then create a routing table having, for each of the nodes, an entry comprising a first field that stores the IP address of the node. Once created, we store a copy of said routing table at each of said nodes. Thereafter, we can route all accesses by a first of the nodes to a second of the nodes using the copy of the routing table stored locally at the first node, thereby eliminating the requirement to provide centralized routing services. In accordance with yet another embodiment of our invention, we provide a network, operated via the Internet, comprising n nodes, each including a common routing table. In accordance with our invention, each, copy of the common routing table comprises n entries, each entry corresponding to a respective one of the nodes. Preferably, each of the entries comprises a first field that stores an address on the Internet of the respective one of the nodes. Accordingly, we can route all accesses by a first of the nodes to a second of the nodes using the copy of the routing table stored locally at the first node, thus eliminating the requirement to provide centralized routing services. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS Our invention may be more fully understood by a description of certain preferred embodiments in conjunction with the attached drawings in which: Figure 1 illustrates in block diagram form a business system adapted to provide a virtual VPN (" WPN") as set forth in our Related Applications; Figure 2 illustrates in block diagram form an iNet configured as a ring of stars ("RoS") which is managed using a common routing table ("CRT); Figure 3 illustrates in diagrammatic form one possible instantaneous • topology of the RoS shown in Figure 2; Figure 4 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a first abnormal operation ("Case 1"); Figure 5 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a second abnormal operation ("Case 2"); Figure 6 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a third abnormal operation ("Case 3"); Figure 7 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a fourth abnormal operation ("Case 4"); Figure 8 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a fifth abnormal operation ("Case 5"); Figure 9 illustrates an RoS comprising four (4) servers and fifteen (15) clients, prior to performing a load balancing operation; and Figure 10 illustrates an RoS comprising four (4) servers and fifteen (15) clients, subsequent to performing the load balancing operation. DETAILED DESCRIPTION OF THE INVENTION Shown in Figure 1 is a business system 2 having a server 4 that can be accessed electronically via the Internet 6 by a plurality of businesses, including for example a first client 8, and a second client 10. Each member business may subscribe for any of the several services available from our server 4. A number of such services are described in our First, Second and Third Applications. One additional service, described in our Fourth Application, is the creation and maintenance of WPNs to facilitate secure communication between clients, at least some of which are behind local firewalls. However, as the number of clients increases and the set of available services expands, the workload that is placed on the server 4 will eventually exceed its ability to provide timely service to all clients. At some point, additional server capacity must be added to the system 2. Balancing the workload among the available servers then becomes an problem that must be resolved. Shown in Figure 2 is a multi-node iNet configured as a ring of stars that we shall refer to as RoS 12. In RoS 12, a first server, S1 14, provides, at a minimum, VVPN services to three (3) clients, Cα 16, C2 18 and C3 20, and a second server, S2 22, provides, at a minimum, VVPN services to three (3) clients, C4 24, C5 26 and C6 28. In contrast to the de minimus RoS 12, we have shown in Figure 9 a larger, more complex RoS 30. In general, we prefer to classify our RoS iNets according to the numbers of servers vis-a-vis clients: using such a taxonomy, for example, RoS 12 would be classified as a "2-server x 6-client RoS", or simply as a "2x6 RoS", whereas RoS 30 is a 4:ci5 RoS. We will defer for now further discussion of RoS 30. In accordance with the preferred embodiment of our invention, the management of the set of all connections among the several nodes comprising RoS 12 is accomplished using a single, iNet-specific routing table, iRT 32 (see, Figure 2) that contains the pertinent information relating to each node-to-node connection. In contrast to existing iNet implementations, each of the nodes in RoS 12, including both the servers and the clients, maintains a local copy of the iRT 32. We shall discuss below, on a case-by-case basis, our preferred mechanism for assuring coherency among the several copies. By way of example, we have shown in Figure 3 one possible topology of RoS 12, wherein, at the illustrated instant: 16 is having a session with C4 24 over a fully open connection; C2 18 is having a session with C5 26 with the assistance of S2 22, wherein the connection between C2 18 and S2 22 is open but the connection from S2 22 to C5 26 is a closed VVPN connection; S1 14 is having a session with C3 20 over a WPN connection; and C6 28 is on-line but is not currently in session.

Since all nodes of RoS 12 maintain local copies of the iRT, any node can, in general, contact any other node without relying on the services of a router. The only exception is if the desired node has gone off-line since the last update of the iRT 32. Note that those nodes which are behind firewalls are, at least from the perspective of any other node of RoS 12, still directly accessible simply by using the IP address of the respective VVPN server stored in the local copy of the iRT 32. In accordance with the invention disclosed in our Fourth Application, direct access to a client that is located behind a firewall can only be made via a VVPN that has been established, and thereafter maintained, by a respective ser er. At the ins nf- iUiistrated Figure 2, S, 14 is providing VVPN services to only one of its clients, namely C3 20, while S2 22 is providing WPN services to only one of its clients, namely C5 26. To distinguish in the drawings between normal open connections and VVPN connections we have depicted the former using solid lines and the latter using dashed lines. To distinguish in the iRT 32 between normal open connections and VVPN connections we tag the former with the letter "O" in the connections ("C") column and the latter using the letter "V". (See, e.g., Figure 2.) The remaining fields of the iRT 32 consist, at a minimum, of: the logical name ("ID") of the respective node; the current static IP address of the node; and, finally, the ID of the node ("Server") which has been assigned the task of providing services, such as WPN, to the respective node. Preferably, the responsibility for maintaining a client entry in the iRT 32 is assigned to that client's Server; similarly, responsibility for maintaining the entry for each server is assigned to a designated one of the other servers. Since a coherent copy of the iRT 32 is maintained within every node of the RoS 12, any client which may find itself isolated because of the failure of its Server, can immediately reestablish contact with the Server assigned to the now-lost Server (a process we call "walking the iRT"). Similarly, if a server, say Sx 14, should discover that the other server, S222, is off-line, it can immediately initiate recovery procedures to reestablish the connections to those clients who were being serviced by S2 22. Let us now show, on a case-by-case basis, how this recovery mechanism works. Case 1: In Case 1, illustrated in Figure 4, Cα 16 is initially having a normal dialog with C2 18 over an open connection. Suddenly, C2 18 fails to timely respond to a request from 16. Consulting its local copy of the iRT 32, 16 finds that the Server for C2 18 is Sx 14. Cα 16 then issues a corresponding fault report to Sx 14. Upon receiving this fault report, Sα 14 will initiate a procedure designed to verify that C2 18 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact C2 18. If, at the completion of the verification procedure, S1 14 is unable to reestablish contact with C2 18, S1 14 will update in the local copy of the iRT 32 the entry for C2 18. As soon as possible thereafter, Sx 14 will distribute that update fiist to S2 22, and then, in a predetermined order, to its other clients, namely Ct 16 and C3 20. (Remember that C2 18 is off-line and thus can not be contacted.) Upon receiving the update from St 14, S2 22 will immediately update its local copy of the iRT 32, and then distribute that update to its clients, namely C4 24, C5 26 and C6 28. Upon receiving the update, each of the clients will immediately update its local copy of the iRT 32. Thus, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of the updates, RoS 12 is now a 2x5 RoS. Note that 16, the reporting client, changes its local cop}7 of the iRT 32 only as result of receiving a proper update request from its server. Thus, if the problem was transient in nature and St 14 found no problem in the link to C2 18, there would have been no unnecessary changes anywhere in the RoS 12. In such a case, it would be desirable for Sx 14 to so notify C- 16 so that the latter can retry the earlier-faulted transaction with C, 18. Case 2: In Case 2, illustrated in Figure 5, Cx 16 is initially having a normal dialog with C4 24 over an open connection. Suddenly, C4 24 fails to timely respond to a request from <ZX 16. Consulting its local copy of the iRT 32, Cα 16 finds that the Server for C4 24 is S2 22. 16 then issues a corresponding fault report to S2 22, preferably without going through S 14. Upon receiving this fault report, S2 22 will initiate a procedure designed to verify that C4 24 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact C4 24. If, at the completion of the verification procedure, S2 22 is unable to reestablish contact with C4 24, S2 22 will update in the local copy of the iRT 32 the entry for C424. As soon as possible thereafter, S2 22 will distribute that update first to St 14, and then, in a predetermined order, to its other clients, namely C5 26 and C6 28. (Remember that C424 is down and thus can not be contacted.) Upon receiving the update from S2 22, Sα 14 will immediately update its local copy of the iRT 32, and then distribute that update to its clients, namely Cx 16, C2 18, and C3 20. Upon receiving the update, each of the clients will immediately update its local copy of the iRT 32. Thus, as in Case 1, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is now also a 2:3 RoS, but it has a different topology than in Case 1. Case 3: In Case 3, illustrated in Figure 6, Sj 14 is initially having a normal dialog with C( 16 over an open connection. Suddenly, Cj 16 fails to timely respond to a request from Sα 14. Consulting its local copy of the iRT 32, Sα 14 finds that it itself is the Server for 16. Accordingly, S1 14 will immediately initiate a procedure designed to verify that Cα 16 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact Cα 16. If, at the completion of the verification procedure, Sx 14 is unable to reestablish contact with Ct 16, St 14 will update in the local copy of the iRT 32 the entry for 16. As soon as possible thereafter, Sj 14 will distribute that update first to S2 22, and then, in a predetermined order, to its other clients, namely C2 18 and C3 20. (Remember that Cα 16 is down and thus can not be contacted.) Upon receiving the update from S1 14, S222 will immediately update its local copy of the iRT 32, and then distribute that update to its clients, namely C4 24, C5 26 and C6 28. Upon receiving the update, each of the clients will immediately update its local copy of the iRT 32. Thus, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is yet another 2x5 RoS, but it has a different topology than in either Case 1 or Case 2. Case 4: In Case 4, illustrated in Figure 7, 16 is initially having a normal dialog with Sα 14 over an open connection. Suddenly, Sα 14 fails to timely respond to a request from 16. Walking its local copy of the iRT 32, 16 finds that the Server for Sα 14 is S2 22. 16 then issues a corresponding fault report directly to S2 22. Upon receiving this fault report, S222 will initiate a procedure designed to verify that S1 14 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact S1 14. If, at the completion of the verification procedure, S2 22 is unable to reestablish contact with S1 14, S2 22 will update in the local copy of the iRT 32 the entry for Sα 14. In addition, however, S2 22 will update the entries in the iRT 32 for all of the current clients of Sx 14, namely 16, 18 and C3 20, to indicate that thereafter S2 22 will be their Server. As soon as possible thereafter, S2 22 will distribute all of these updates, in a predetermined order, to all of its client , namely Cx 16, C2 1G, C, 20, 24, C5 26 and C6 2G. Upon receiving the updates, each of the clients will immediately update its local copy of the iRT 32. Thus, as in Case 1, Case 2 and Case 3, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is now a 1x6 RoS. Case 5: In Case 5, illustrated in Figure 8, Sα 14 is initially having a normal dialog with S2 22 over an open connection. Suddenly, S2 22 fails to timely respond to a request from Sα 14. Consulting its local copy of the iRT 32, Sα 14 finds that the Server for S2 22 is itself. Sλ 14 then initiates a procedure designed to verify that S2 22 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact S2 22. If, at the completion of the verification procedure, Sx 14 is unable to reestablish contact with S2 22, Sα 14 will update in the local copy of the iRT 32 the entry for S2 22. In addition, however, Sα 14 will update in the local copy of the iRT 32 the entries for all of the current clients of S2 22, namely C424, C5 26 and C6 28, to indicate that thereafter S1 14 will be their Server. As soon as possible thereafter, St 14 will distribute all of these updates, in a predetermined order, to all of its clients, namely 16, C2 18, C3 20, C4 24, C5 26 and C6 28. Upon receiving the updates, each of the clients will immediately update its local copy of the iRT 32. Thus, as in Case 1, Case 2, Case 3 and Case 4, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is now also a 1x6 RoS, but it has a different topology than in Case 4. As mentioned briefly above, shown in Figure 9 is the 4x15 RoS 30 and the associated iRT 34. As can be seen in both the topographic diagram and the iRT 34: a first server, S 36, provides, at a minimum., VVPN and update services to four (4) clients, namely 38, C2 40, C3 42 and C4 44; a second server, S2 46, provides, at a minimum, VVPN and update services to four (4) clients, namely C5 48, 50, C7 52 and C8 54; a third server, S3 56, provides, at a minimum., VVPN and update services to three (3) client, namely C, 58, CI (J 60 and Cn 62; i i a fourth server, Si 64, provides, at a minimum, VVP and update services to four (4) clients, namely C12 66, Crj 68, Cu 70 and C15 72. At the illustrated instant: Sα 36 is providing VVPN services to both C2 40 and C3 42; 52 46 is providing VVPN services to only 50; 53 56 is providing WPN services to none of its clients; and 54 64 is providing WPN services to only C14 70. Since it requires significant resources of a server to maintain a WPN connection, let us assume that, as a result of having to simultaneously maintain two (2) VVPN connections, St 36 has just determined that its response time to its clients has fallen below a predetermined minimum response time. In response, Sj 36 sends to its Server, namely S246, a request to transfer responsibility for servicing, for example, C4 44. Upon receiving the transfer request, S246 determines if it has sufficient available resources to assume responsibility for an additional normal (i.e., non- VVPN) client. Preferably, this determination would take into account both the current workload of S2 46 and the anticipated load imposed by such a client.

Both numbers can be determined either statically, using best estimates (e.g., the number of clients), or dynamically, by continuously monitoring the actual loading patterns of each of the nodes of the RoS 30. In this regard, such information can be conveniently maintained for each node in respective, additional columns of the iRT 34 (not shown). Let us assume, for this example, that S246 decides that, because of the load imposed by the WPN connection it is maintaining with 50, assuming responsibility for C4 44 would unreasonably jeopardize its ability to timely service its existing clients. Instead, S2 46 forwards the transfer request to its Server, namely S3 56. Upon receiving the transfer request, S3 56 determines if it has sufficient available resources to assume responsibility for C444. For this example, we will now assume that S, 56 decides that, because it has only three (3) normal clients to service, it is indeed in a position to assume responsibility for C4 44 and stall provide timely services to all four (4) clients. Consulting its local copy of the iRT 34, it retrieves the ID of the Server for 44, namely S, 36. S3 56 then sends a transfer approval to Sα 36. In response to receiving the transfer approval from S3 56, Sx 36 will send a transfer notice to C444 indicating that it should contact S3 56 for further services. Upon successfully establishing contact with C444, S3 56 will then update the entry in the iRT 34 for C4 44 to show that it is now the Server for C4 44. Using the ' update distribution mechanism described above, S3 56 will then distribute the update to the other nodes of RoS 30. The resulting topology and associated iRT are shown in Figure 10. In addition to being effective in dynamically balancing workload to relieve local over-loading, the same mechanism can be used equally effectively to dynamically assign to an appropriate server a node that desires to join an established RoS. Similarly, when a node drops out for any reason, the same general mechanism can be advantageously employed in reverse to transfer workload from a relatively loaded server to a now-under-loaded server. If, as we described above, the iRT 34 is expanded to accommodate recent workload history for servers as well as clients, such workload balancing decisions can be made quite efficiently. Those skilled in the art will recognize that modifications and variations can be made without departing from the spirit of our invention. Therefore, we intend that our invention encompass all such variations and modifications as fall within the scope of the appended claims.

Claims

CLAIMS What we claim is:
1. A method for operating, via the Internet, a network comprised of n nodes, the method comprising: determining an address on the Internet of each of said nodes; creating a routing table having, for each of said nodes, an entry comprising: a first field that stores said address of said node; storing a copy of said routing table at each of said nodes; and routing all accesses by a first of said nodes to a second of said nodes using said copy of said routing table stored at said first node.
2. The method of claim 1, wherein: upon creating said routing table, a unique identifier is assigned to each of said nodes; and wherein each entry in said routing table further includes: a second field that stores said identifier of said node.
3. The method of claim 2 wherein: said first node provides a first selected service to said second node.
4. The method of claim 3 wherein each entry in said routing table includes: a third field that stores the address on the internet of a selected one of said nodes other than the node corresponding to said entry; and wherein: said third field of said entry for said second node stores the address o£ said first node; whereby, using the copy of the routing table stored in the second node, the second node can request the first selected service from the first node via the address stored in the third field of the entry for the second node.
5. The method of claim 4 wherein, as said first selected service, said first node creates, and thereafter selectively destroys, a virtual private network (VPN) connection over the Internet for said second node.
6. The method of claim 5, wherein: upon creating said VPN connection, said first node stores in said first field of said entry for said second node said address of said first node; and upon destroying said VPN connection, said first node stores in said first field of said entry for said second node said address of said second node.
7. The method of claim 6, wherein said routing table further includes: a fourth field that stores an indicator indicating that said node is connected to the Internet via an open connection; and wherein: upon creating said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via a VPN connection; and upon destroying said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via an open connection.
8. The method of claim 7, wherein: a third node provides a second selected service to said first node.
9. The method of claim 8, wherein: said third field of said entry for said first node stores the address of said third node; whereby, using the copy of the routing table stored in the first node, the first node can request the second selected service from the third node via the address stored in the third field of the entry for the third node.
10. The method of claim 9 wherein, as second selected service, said third node provides said first selected service to said second node if said first node is unavailable to provide said first selected service; whereby, if the first node is unavailable to provide the first selected service to the second node, then, using the copy of the routing table stored in the second node, the second node can request the first selected service from the third node via the address stored in the third field of the entry for the third node.
11. In an n-node network, operated via the Internet, a distributed routing method comprising: determining an address on the Internet of each of said nodes; creating a routing table having, for each of said nodes, an entry comprising: a first field that stores said address of said node; storing a copy of said routing table at each of said nodes; and routing all accesses by a first of said nodes to a second of said nodes using said copy of said routing table stored at said first node.
12. The method of claim 11, wherein: upon creating said routing table, a unique identifier is assigned to each of said nodes; and wherein each entry in said routing table further includes: a second field that stores said identifier of said node.
13. The method of claim 12 wherein: said first node provides a first selected service to said second node.
14. The metliod of claim 13 wherein each entry in said routing table includes: a third field that stores the address on the Internet of a selected one of said nodes other than the node corresponding to said entry; and wherein: said third field of said entry for said second node stores the address of said first node; whereby, using the copy of the routing table stored in the second node, the second node can request the first selected service from the first node via the address stored in the third field of the entry for the second node.
15. The method of claim 14 wherein, as said first selected service, said first node creates, and thereafter selectively destroys, a virtual private network
(VPN) connection over the Internet for said second node.
16. The method of claim 15, wherein: upon creating said VPN connection, said first node stores in said first field of said entry for said second node said address of said first node; and upon destroying said VPN connection, said first node stores in said first field of said entry for said second node said address of said second node.
17. The method of claim 16, wherein said routing table further includes: a fourth field that stores an indicator indicating that said node is connected to the Internet via an open connection; and wherein: upon creating said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via a VPN connection; and upon destroying said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via an open connection.
18. The method of claim 17, wherein: a third node provides a second selected service to said first node.
19. The method of claim 18, wherein: said third field of said entry for said first node stores the address of said third node; whereby, using the copy of the routing table stored in the first node, the first node can request the second selected service from the third node via the address stored in the third field of the entry for the third node.
20. The method of claim 19 wherein, as second selected service, said third node provides said first selected service to said second node if said first node is unavailable to provide said first selected service; whereby, if the first node is unavailable to provide the first selected service to the second node, then, using the copy of the routing table stored in the second node, the second node can request the first selected service from the third node via the address stored in the third field of the entry for the third node.
21. A network, operated via the Internet, comprising: n nodes, each including a common routing table, said common routing table comprising n entries, each entry corresponding to a respective one of said nodes, each of said entries comprising: a first field that stores an address on the Internet of said respective one of said nodes; whereby all accesses by a first of said nodes to a second of said nodes may be routed using said copy of said routing table stored at said first node.
22. The network of claim 21 wherein each of said entries further comprises: a second field that stores a unique identifier assigned to said respective one of said nodes.
23. The network of claim 22 wherein: said first node provides a first selected service to said second node.
24. The network of claim 23 wherein each of said entries further comprises: a third field that stores the address on the Internet of a selected one of said nodes other than said respective node; whereby, using the copy of the routing table stored in the second node, the second node can request the first selected service from the first node via the address stored in the third field of the entry for the second node.
25. The network of claim 24 wherein, as said first selected service, said first node creates, and thereafter selectively destroys, a virtual private network
(VPN) connection over the Internet for said second node.
26. The network of claim 25, wherein: upon creating said VPN connection, said first node stores in said first field of said entry for said second node said address of said first node; and upon destroying said VPN connection, said first node stores in said first field of said entry for said second node said address of said second node.
27. The network of claim 26, wherein said each of said entries further includes: a fourth field that stores an indicator indicating that said respective node is connected to the Internet via an open connection; and wherein: upon creating said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via a VPN connection; and upon destroying said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via an open connection.
28. The network of claim 27, wherein: a third node provides a second selected service to said first node.
29. The network of claim 28, wherein: said third field of said entry for said first node stores the address of said third node; whereby, using the copy of the routing table stored in the first node, the first node can request the second selected service from the third node via the address stored in the third field of the entry for the third node.
30. The network of claim 29 wherein, as second selected service, said third node provides said first selected service to said second node if said first node is unavailable to provide said first selected service; whereby, if the first node is unavailable to provide the first selected service to the second node, then, using the copy of the routing table stored in the second node, the second node can request the first selected service from the third node via the address stored in the third field of the entry for the third node.
PCT/US2003/018469 2003-06-11 2003-06-11 Multi-node network having common routing table WO2005006649A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2003/018469 WO2005006649A1 (en) 2003-06-11 2003-06-11 Multi-node network having common routing table

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/US2003/018469 WO2005006649A1 (en) 2003-06-11 2003-06-11 Multi-node network having common routing table
AU2003243512A AU2003243512A1 (en) 2003-06-11 2003-06-11 Multi-node network having common routing table

Publications (1)

Publication Number Publication Date
WO2005006649A1 true true WO2005006649A1 (en) 2005-01-20

Family

ID=34061413

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/018469 WO2005006649A1 (en) 2003-06-11 2003-06-11 Multi-node network having common routing table

Country Status (1)

Country Link
WO (1) WO2005006649A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5583862A (en) * 1995-03-28 1996-12-10 Bay Networks, Inc. Method and apparatus for routing for virtual networks
US5732072A (en) * 1994-08-31 1998-03-24 Siemens Aktiengesellschaft Method for adaptive routing in a communication network
US6226751B1 (en) * 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5732072A (en) * 1994-08-31 1998-03-24 Siemens Aktiengesellschaft Method for adaptive routing in a communication network
US5583862A (en) * 1995-03-28 1996-12-10 Bay Networks, Inc. Method and apparatus for routing for virtual networks
US6226751B1 (en) * 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network

Similar Documents

Publication Publication Date Title
US6496866B2 (en) System and method for providing dynamically alterable computer clusters for message routing
US7185096B2 (en) System and method for cluster-sensitive sticky load balancing
US5191651A (en) Apparatus and method for making of interconnected processors act like a single node in a multinode communication system
US6553401B1 (en) System for implementing a high volume availability server cluster including both sharing volume of a mass storage on a local site and mirroring a shared volume on a remote site
US5588121A (en) Parallel computer having MAC-relay layer snooped transport header to determine if a message should be routed directly to transport layer depending on its destination
US6229787B1 (en) Mechanism to achieve very fast failover in ATM backbone networks using multi-homed circuits
US6628654B1 (en) Dispatching packets from a forwarding agent using tag switching
US6370584B1 (en) Distributed routing
US6665705B1 (en) Method and apparatus for proxy replication
US4995035A (en) Centralized management in a computer network
US7000121B2 (en) Computer systems, in particular virtual private networks
US7120697B2 (en) Methods, systems and computer program products for port assignments of multiple application instances using the same source IP address
US6219715B1 (en) Automatic address distributing system
US6104717A (en) System and method for providing backup machines for implementing multiple IP addresses on multiple ports
US6941366B2 (en) Methods, systems and computer program products for transferring security processing between processors in a cluster computing environment
US6687731B1 (en) Arrangement for load sharing in computer networks
US6154776A (en) Quality of service allocation on a network
US7346686B2 (en) Load balancing using distributed forwarding agents with application based feedback for different virtual machines
US20080177896A1 (en) Service insertion architecture
US7818454B2 (en) Host migration system
US20060193252A1 (en) Active-active data center using RHI, BGP, and IGP anycast for disaster recovery and load distribution
US20030220946A1 (en) Resource list management system
US6202169B1 (en) Transitioning between redundant computer systems on a network
US6421321B1 (en) Apparatus and a method for transferring a packet flow in a communication network
US6606316B1 (en) Gathering network statistics in a distributed network service environment

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1) EPC OF 290306, FORM 1205A

122 Ep: pct app. not ent. europ. phase
NENP Non-entry into the national phase in:

Ref country code: JP