US6954794B2 - Methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster - Google Patents

Methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster Download PDF

Info

Publication number
US6954794B2
US6954794B2 US10274744 US27474402A US6954794B2 US 6954794 B2 US6954794 B2 US 6954794B2 US 10274744 US10274744 US 10274744 US 27474402 A US27474402 A US 27474402A US 6954794 B2 US6954794 B2 US 6954794B2
Authority
US
Grant status
Grant
Patent type
Prior art keywords
node
ip address
virtual
reachability
network
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
US10274744
Other versions
US20040078481A1 (en )
Inventor
Joseph Michael Rudd
Benjamin Crawford Robinson
Jeffrey Lynn Ellis
David F. Knierim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tekelec Global Inc
Original Assignee
Tekelec Global 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
Grant date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/1233Mapping of addresses of the same type; Address translation
    • H04L29/12339Internet Protocol [IP] address translation
    • H04L29/12349Translating between special types of IP addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • 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
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/25Network arrangements or network protocols for addressing or naming mapping of addresses of the same type; address translation
    • H04L61/2503Internet protocol [IP] address translation
    • H04L61/2507Internet protocol [IP] address translation translating between special types of IP addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1002Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers, e.g. load balancing
    • H04L67/1004Server selection in load balancing
    • H04L67/101Server selection in load balancing based on network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • H04L69/169Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • H04L29/0602Protocols characterised by their application
    • H04L29/06047Protocols for client-server architecture
    • H04L2029/06054Access to distributed or replicated servers, e.g. using brokers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1002Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers, e.g. load balancing

Abstract

Methods and systems for exchanging reachability information and for switching between redundant interfaces in a network cluster are disclosed. Nodes in the network cluster are connected via redundant links and exchange reachability messages at periodic intervals. Each node includes a kernel routing table used to route messages and a reachability application routing table for storing reachability information used to update entries in the kernel routing table. Each node executes a predetermined algorithm for selecting entries in the reachability application routing table to be written to the kernel routing table.

Description

TECHNICAL FIELD

The present invention relates to methods and systems for exchanging reachability information in a network cluster. More particularly, the present invention relates to methods and systems for exchanging reachability information and for switching between redundant interfaces in a network cluster.

RELATED ART

In Internet protocol (IP) networks, routers exchange reachability information using routing protocols. One of the most widely used routing protocols in autonomous systems in today's IP networks is the routing information protocol (RIP). According to RIP, routers exchange reachability messages with neighboring routers by broadcasting routing information messages. The routing information messages include IP network addresses and hop counts indicating the distance to each network address from the advertising router. Each router runs a distance vector algorithm to build its kernel or network routing table based on the shortest path to each destination.

While RIP has been an effective routing protocol for large IP networks, it is unsuitable and overly complex for network clusters. As used herein, the term “network cluster” refers to a set of network nodes connected via the same local area network (LAN) or LANs. In network clusters, because the nodes are directly connected, it is unnecessary to run distance vector algorithms or to exchange hop count information. However, in such networks, it is desirable to exchange reachability information for reliability purposes. For example, if one path between two nodes in a cluster fails, the routing protocol preferably detects the failure and switches to another available route.

RIP is also unsuitable for fast switchover in network clusters because of its slow timeout period for unavailable routes. For example, in RIP, a router in active mode broadcasts a message every thirty seconds. The message includes IP network addresses and integer distances to each network. Other routers receive these messages and store the reachability information in their kernel routing tables. However, a route does not become invalid unless 180 seconds pass without the route being advertised again. Such a slow timeout period is unsuitable for switching between redundant interfaces in a network cluster when one of the interfaces fails. For example, data rates in the network cluster may be on the order of megabits or gigabits per second. A switchover period that is on the order of seconds will thus result in significant loss of data.

Accordingly, in light of the problems associated with applying conventional routing protocols to network clusters, there exists a long felt need for improved methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster.

DESCRIPTION OF THE INVENTION

The present invention includes improved methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster. According to one aspect of the invention, first and second nodes in a cluster are connected via LAN connections between LAN interfaces of the first and second nodes. Each LAN interface of the first and second nodes periodically broadcasts a reachability message associating a physical IP address of each LAN interface with a virtual IP address associated with each node. The first node receives the reachability messages from the second node and stores virtual-to-physical IP address mappings for each of the LAN interfaces associated with the second node in a reachability application routing table. The reachability application routing table is used only to update entries in a kernel routing table, which is used to route packets.

In order to add entries to the kernel routing table, the first node extracts one of the virtual-to-physical IP address mappings for the second node from the reachability application routing table and stores the selected mapping in the kernel routing table. For example, the first node may store the first-received or the most recently received route in the kernel routing table. The second node performs similar steps to maintain reachability application and kernel routing tables for the interfaces of the first node.

At each node, the entries in the reachability application routing table are scanned periodically. In one example, the scanning period is 200 milliseconds. A pass count is associated with each entry in the reachability application routing table. The pass count is altered each time a node scans a particular entry. When a reachability message is received for a particular route, the pass count is reset for the corresponding entry in the reachability application routing table. If the pass count reaches a predetermined value, the entry is deleted from the reachability application routing table. If the route is being used in the node's kernel routing table, it is also deleted from that routing table. If a backup route exists, the backup route is stored in the kernel routing table.

Thus, the present invention exchanges reachability information between directly connected nodes and greatly reduces the time required for switching to new routes when a route fails when compared to the time required by conventional routing protocols, such as RIP.

Accordingly, it is an object of the invention to provide improved methods and systems for exchanging reachability information between directly connected nodes.

It is another object of the invention to provide improved methods and systems for quickly switching to a new route in a cluster when one route fails.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be explained with reference to the accompanying drawings of which:

FIGS. 1A and 1B are a block diagram of a network cluster including a system for exchanging reachability information between cluster nodes and for switching between cluster nodes according to an embodiment of the present invention;

FIG. 2 is a message flow diagram illustrating the exchange of reachability messages between cluster nodes according to an embodiment of the present invention;

FIG. 3 is a flow chart illustrating exemplary steps that may be performed by a cluster node in updating reachability information in its routing tables according to an embodiment of the present invention;

FIG. 4 is a flow chart illustrating exemplary steps that may be performed by a cluster node 100A-100N in FIG. 1 in deleting routes from its routing tables according to an embodiment of the present invention; and

FIG. 5 is a flow chart illustrating exemplary steps that may be performed by a cluster node 102A-102N illustrated in FIG. 1 in deleting routes from its routing tables according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention includes improved methods and systems for exchanging reachability information and for switching between redundant interfaces in a network cluster. FIGS. 1A and 1B illustrate a network cluster including a system for exchanging reachability information and performing fast switchover according to an embodiment of the present invention. Referring to FIGS. 1A and 1B, a plurality of first cluster nodes 100A-100N are connected to a plurality of second cluster nodes 102A-102N via a local area network 104. First cluster nodes 100A-100N may be any type of nodes capable of sending and receiving messages to other nodes in a network cluster. In one example, cluster nodes 100A-100N may be communications modules in a signaling message routing node, such as a signal transfer point or an SS7/IP gateway. Such modules receive and process signaling messages received over SS7 and IP signaling links. One function of such modules is to copy signaling messages received on external signaling links and send message copies to external network monitoring processors. Accordingly, second cluster nodes 102A-102N may be network monitoring processors coupled to the signal transfer point or SS7/IP gateway. However, the present invention is not limited to exchanging reachability information between communications modules in a signaling message routing node and network monitoring processors. The reachability exchange and switchover protocols described herein may be applied to any type of directly connected nodes.

In order to provide redundant connectivity, each first cluster node 100A-100N includes first and second network interfaces 106A and 106B. In the illustrated example, interfaces 106A and 106B may each be an Ethernet interface. Similarly, each cluster node 102A-102N includes first and second network interfaces 108A and 108B. Network interfaces 108A and 108B of each second cluster node 102A-102N may also be Ethernet interfaces. Ethernet interfaces 106A and 106B of each cluster node 100A-100N are connected to Ethernet interfaces 108A and 108B of each second cluster node 102A-102N through LAN 104. It is understood that the Ethernet interfaces on each redundantly connected pair of cluster nodes may have different IP network addresses to conform with IP routing protocols.

Applications on cluster nodes 100A-100N may use LAN 104 to communicate with applications on cluster nodes 102A-102N. For example, if cluster nodes 100A-100N include signaling message copying functions, the signaling message copying functions may send copies of signaling messages to network monitoring applications resident on cluster nodes 102A-102N via LAN 104.

Although the example illustrated in FIGS. 1A and 1B shows cluster nodes 100A-100N being connected to cluster nodes 102A-102N via a single LAN 104, the present invention is not limited to such an embodiment. In an alternate embodiment, cluster nodes 100A-100N and cluster nodes 102A-102N may be connected by more than one LAN for redundancy purposes.

In addition to Ethernet interfaces 106A and 106B, each cluster node 100A-100N may also include an additional Ethernet interface 110 for communicating with other processing modules via LAN 114. For example, if cluster nodes 100A-100N are located in a signaling message routing node, Ethernet interfaces 110 may be used for interprocessor communication within the signaling message routing node. Similarly, each cluster node 102A-102N may also include Ethernet interfaces 116 for communicating with each other and with other nodes via LAN 117.

In the illustrated example, each cluster node 100A-100N is redundantly connected to each cluster node 102A-102N. Thus, if any single network interface fails, a method needs to be provided in order to switch to the available interface without disrupting communications between applications. Some applications, such as network monitoring applications, may use TCP/IP connections or SCTP/IP connections that are set up in advance to exchange data. In a TCP/IP connection, each endpoint of the connection must bind a local IP address with the connection. This IP address is usually associated with a physical interface. Thus, if a physical interface fails, it is necessary to set up a new TCP/IP connection using another IP address and another physical interface. Because TCP/IP connections require a message exchange between endpoints to be established, requiring a new TCP/IP connection to be established in the event of an interface failure could result in significant loss of data.

In order to avoid this difficulty, cluster nodes 100A-100N and 102A-102N use virtual IP addresses for TCP connections. By “virtual IP address,” it is meant that the IP address is not associated with a physical interface. In one example, cluster nodes 100A-100N use a single virtual IP address to route messages over network interfaces 106A and 106B. Each cluster node 102A-102N may use a separate virtual IP address used to route messages over network interfaces 108A and 108B. The present invention is not limited to using one virtual IP address for cluster nodes 100A-100N and separate virtual IP addresses for each of cluster nodes 102A-102N. In an alternate embodiment of the invention, cluster nodes 100A-100N may each use a separate virtual IP address and/or cluster nodes 102A-102N may use the same virtual IP address. Table 1 shown below illustrates possible combinations of virtual IP (VIP) addresses between nodes 100A-100N and 102A-102N.

TABLE 1
Virtual IP Address Combinations
100A-100N 102A-102N
one VIP for all nodes one VIP per node
one VIP for all nodes one VIP for all nodes
one VIP per node one VIP for all nodes
one VIP per node one VIP per node

Using a virtual IP address to decouple TCP connections from physical interfaces allows switching between physical interfaces without requiring the setting up of a new TCP connection. Even though virtual IP addresses remove the association between TCP connections and physical interfaces, it is still necessary to determine particular physical interface to which message should be sent. Accordingly, each cluster node 100A-100N includes kernel routing software 118 and kernel routing table 120 for mapping virtual IP addresses of cluster nodes 102A-102N to physical IP addresses of interfaces 108A and 108B associated with cluster nodes 102A-102N. Similarly, each cluster node 102A-102N includes kernel routing software 118 and a kernel routing table 122 for mapping virtual IP addresses of cluster nodes 100A-100N to physical IP addresses of interfaces 106A and 106B of each cluster node 100A-100N.

Table 2 shown below illustrates an example of a kernel routing table that may be used at each cluster node 100A-100N. In Table 2, it is assumed that cluster nodes 102A, 102B, and 102N each have virtual IP addresses VIP1, VIP2, and VIP3, respectively.

TABLE 2
Kernel Routing Table for Cluster Nodes 100A-100N
VIP PHYS. IP
VIP1 IP3
VIP2 IP7
VIP3 IP11

According to Table 2, the virtual IP address VIP1 is associated with the physical IP address IP3. The physical IP address IP3 corresponds to Ethernet interface 108A in cluster node 102A. Cluster nodes 102B and 102N also have physical IP addresses associated with their respective virtual IP addresses in the kernel routing table 120 of cluster node 100A. Accordingly, when an application on cluster node 100A sends a message to an application on cluster node 102A, the application will insert the virtual IP address VIP1 in the destination address field of the IP header of the packet. Kernel routing software 118 on cluster node 100A interrogates the kernel IP routing table and determines how the IP packet is to be routed. Based on the IP destination VIP1, kernel routing software 118 determines that the physical IP address IP3 should be used as the next hop IP address. Kernel routing software 118 obtains the associated MAC address associated with IP3 and uses it to encapsulate the outbound packet in an Ethernet frame. The Ethernet frame is sent to Ethernet interface 106A, which transmits the frame on LAN 104. Ethernet interface 108A receives the frame and passes the frame up the stack until the data reaches the intended application.

Kernel routing software 118 and kernel routing table 122 on cluster node 102A may perform similar functions when routing messages to cluster node 100A. Table 3 shown below illustrates an example of kernel routing table 122. In Table 3, it is assumed that cluster nodes 100A-100N utilize a single virtual IP address VIP4.

TABLE 3
Kernel Routing Table for Cluster Nodes 102A-102N
VIP PHYS. IP
VIP4 IP1

Table 3 illustrates a routing table including a virtual-to-physical IP address mapping that may be stored by one of cluster nodes 102A-102N. Since cluster nodes 100A-100N share a single virtual IP address, it is desirable to ensure that messages from cluster nodes 102A-102N are evenly distributed between cluster nodes 100A-100N. The routing table illustrated in Table 3 includes a single entry that maps the virtual IP address shared by cluster nodes 100A-100N to the physical IP address IP1 associated with Ethernet interface 106A on cluster node 100A. The kernel routing tables on the remaining cluster nodes 102B-102N may include different virtual-to-physical IP address mappings in order to ensure even distribution of messages to cluster nodes 100A-100N. An exemplary method for ensuring that kernel routing tables 122 evenly distribute messages among cluster nodes 100A-100N will be described in detail below.

In order to maintain reliable communications between cluster nodes 100A-100N and cluster nodes 102A-102N, the information in kernel routing tables 120 and 122 must be maintained current and must be rapidly updated in the event that a particular network interface fails. For example, if Ethernet interface 108A on cluster node 102A fails, the entry in Table 2 for virtual IP address VIP1 is preferably changed to associate VIP1 with IP address IP4. Conventional routing protocols, such as RIP, may be used to exchange such reachability information. However, as stated above, RIP is overly complex and not fast enough for communications in network clusters.

Accordingly, in order to exchange reachability information and update kernel routing tables 120 and 122 quickly, each cluster node 100A-100N includes a reachability application 124 and a reachability application routing table 126. Similarly, each cluster node 102A-102N includes a reachability application 128 and a reachability application routing table 130. Reachability applications 124 broadcast reachability messages to cluster nodes 102A-102N advertising virtual-to-physical IP address mappings associated with cluster nodes 100A-100N. Similarly, reachability applications 128 broadcast reachability messages to cluster nodes 100A-100N to advertise virtual-to-physical IP address mappings associated with cluster nodes 102A-102N. Reachability applications 124 store reachability information received from cluster nodes 102A-102N in reachability application routing tables 126. Similarly, reachability applications 128 store virtual-to-physical IP address mappings received from cluster nodes 100A-100N in reachability application routing tables 130.

Reachability application routing tables 126 and 130 are each used to update their respective kernel routing tables 120 and 122. Reachability applications 126 and 130 are preferably not used for routing messages. Detailed procedures for using information in reachability application routing tables 126 and 130 to update kernel routing tables 120 and 122 will now be described.

FIG. 2 is a message flow diagram illustrating an exemplary exchange of reachability information between nodes 100A-100N and 102A-102N. In the illustrated example, each interface on nodes 100A-100N sends a reachability message advertising its virtual-to-physical IP address mapping. Similarly, each interface on nodes 102A-102N sends a reachability message to nodes 100A-100N advertising its virtual-to-physical IP address mapping. Two messages are sent for each node 100A-100N and 102A-102N because in FIG. 1, each node has two network interfaces. However, the present invention is not limited to sending reachability information between nodes with only two network interfaces. Sending reachability information between any number of network interfaces between directly connected nodes is intended to be within the scope of the invention. If the nodes include more than two Ethernet interfaces, a reachability message will be sent for each Ethernet interface on the LAN interconnecting the nodes.

The reachability messages may be sent via UDP broadcasts. Accordingly, reachability applications 128 on nodes 102A-102N may listen on a predetermined UDP port for reachability messages from nodes 100A-100N. Similarly, reachability applications 124 on nodes 100A-100N may listen on a different UDP port for reachability messages broadcast from nodes 102A-102N. The time interval for reachability messages is preferably short enough so that routing information and routing tables is updated quickly. In the illustrated example, the time interval between reachability messages is set to 200 milliseconds. However, the present invention is not limited to using a 200 millisecond broadcast interval. Any suitable interval that allows routing table entries to be updated rapidly is intended to be within the scope of the invention.

The following is an example of source code for a data structure used by reachability applications 124 and 128 for building reachability messages.

1 struct s_trp_udp_message
2  {
3 t_u8 version;
4 e_trp_message_type type;
5 t_u8 num_ip_addrs;
6 t_u8 pad; /* used to stay on 4 byte boundary */
7 t_ip_addr submask;
8 union
9  {
10  t_ip_addr pvn;
11  t_ip_addr vip;
12  }addr[1];
13
14 };
15
16 typedef struct s_trp_udp_message t_trp_udp_message;

In the source code listed above, “pvn” represents “private virtual network” and “vip” represents “virtual IP address.” In this example, the pvn variable is used to store the virtual IP address of cluster nodes 100A-100N. The pvn variable is used to store the individual virtual IP addresses of nodes 102A-102N.

The struct command defines a data structure for the reachability message. Line 3 of the source code defines the version of the message in order to allow for updates and compatibility. Line 4 of the source code identifies the message type, which in this case will be a reachability advertisement message. Line 5 of the source code indicates the number of IP addresses associated with the particular reachability message so that if multiple IP addresses are being advertised in a single message, the receiver will know how to parse the reachability message. Line 6 of the data structure is used for padding. Line 7 of the data structure identifies the subnet mask associated with the IP address. Lines 10 and 11 of the data structure are used to store the virtual IP addresses of nodes 100A-100N and 102A-102N.

The reachability information illustrated in the source code above is exchanged between nodes 100A-100N and 102A-102N and used to update reachability application routing tables. Reachability applications 124 and 128 extract the virtual IP address from the reachability messages and extract the corresponding physical IP address from the source address field of the IP header of the messages in order to build reachability application routing tables 126 and 130. Table 4 shown below illustrates an example of a reachability application routing table 126 that may be maintained by cluster nodes 100A-100N.

TABLE 4
Reachability Application Routing Table
VIP PHYS IP Pass Count
VIP1 IP3 2
VIP1 IP4 2
VIP2 IP7 1
VIP2 IP8 0
VIP3 IP11 1
VIP3 IP12 2

In Table 4, it is assumed that cluster nodes 102A-102N include virtual IP addresses VIP1, VIP2, and VIP3, respectively. As can be seen from Table 4, each virtual IP address is associated with multiple physical IP addresses. Exemplary methods for selecting the proper mapping to update the kernel routing tables will be described in detail below. In Table 4, each entry also includes a pass count. The pass count is used to age out entries in the event of a network interface failure. The use of the pass count to age out entries will be described in detail below.

FIG. 3 is a flow chart illustrating exemplary steps that may be performed by reachability applications 124 and 128 in updating reachability application routing tables 126 and 130 and for using information in reachability application routing tables 126 and 130 to update kernel routing tables 120 and 122. Referring to FIG. 3, in step 300, the reachability applications receive reachability messages broadcast from other nodes. For example, reachability applications 124 receive reachability message broadcasts from nodes 102A-102N. Similarly, reachability applications 128 receive reachability message broadcasts from nodes 100A-100N. In step 302, the reachability applications determine whether the virtual-to-physical IP address mapping in the particular reachability message has already been received. In step 304, if the mapping has already been received, control proceeds to step 306, where the reachability application simply updates the pass count in the existing entry in the reachability application routing table. Updating the pass count may include resetting the pass count to its original value. In the example illustrated in Table 4 above, the possible pass count values are 0, 1, and 2. 2 is the highest value of the pass count. Accordingly, updating the pass count in step 306 may include resetting the pass count to 2. Control then returns to step 300 to process the next reachability message.

In step 308, if the virtual-to-physical IP address mapping in the reachability message has not already been received, the reachability application writes the new virtual-to-physical IP address mapping in the reachability application routing table. The pass count for the entry is preferably set to 2.

In step 310, the reachability application selects one of the virtual-to-physical IP address mappings for each interface to store in the kernel routing table. The method for selecting which entry is written to the kernel routing table may vary between cluster nodes 100A-100N and cluster nodes 102A-102N because cluster nodes 100A-100N may only advertise a single virtual IP address, while cluster nodes 102A-102N may each advertise individual virtual IP addresses. Accordingly, for cluster nodes 100A-100N, reachability applications 124 may select the first mapping received for each interface on cluster nodes 102A-102N and store that mapping in kernel routing tables 120. Alternatively, reachability applications 124 may store the most recently received mapping for each interface on cluster nodes 102A-102N in kernel routing tables 120.

For cluster nodes 102A-102N, it is desirable to prevent all messages from being sent to the same physical interface on cluster nodes 100A-100N. Accordingly, a method for load balancing messages among cluster nodes 100A-100N is preferably provided. One exemplary embodiment of the invention, cluster nodes 102A-102N are assigned sequential virtual IP addresses. The sequential nature of the virtual IP addresses can be used to perform load balancing. One exemplary formula that may be used is as follows:
Host byte of virtual IP address % num_routes_100A-100N=index to reachability application routing table
In the formula above, the “%” symbol represents the modulus function, in accordance with standard programming languages, such as C and C++. The modulus function is used to select an index to the reachability application routing tables based on the host byte of the virtual IP address of cluster nodes 102A-102N. For example, if only one interface on one of cluster nodes 100A-100N broadcasts a reachability message, there will only be one route in reachability application routing tables 130. Thus, reachability applications 128 will each modulo the virtual IP addresses of their respective nodes with 1 (the number of routes to nodes 100A-100N). The result of the modulus operation will be 0, so each reachability application 128 will choose the 0 index to reachability application routing table 130, which causes all cluster nodes 102A-102N to select the same single advertised route. If another interface on cluster nodes 100A-100N begins broadcasting a reachability message, all of the even IP addressed cluster nodes 102A-102N will still use the same route, since their IP address modulo 2 (the number of routes broadcast by cluster nodes 100A-100N) will be 0. However, all of the odd numbered nodes 102A-102N will switch to the new route because their virtual IP addresses modulo 2 will result in an index of 1 to the reachability application routing table 130. If another route is broadcast by cluster nodes 100A-100N, one third of the cluster nodes 102A-102N will choose the new route. Thus, reachability applications 128 automatically rebalance routes among interfaces associated with a single virtual IP address. This automatic rebalancing may be useful when nodes are added or go out of service.

In order to dynamically switch to a new route when a route goes down, it is necessary to delete an old route from a kernel routing table and write the new route from the reachability application routing table to the kernel routing table. FIG. 4 illustrates exemplary steps that may be performed by reachability applications 124 on cluster nodes 100A-100N in deleting routes from reachability and kernel routing tables and switching to new routes. Referring to FIG. 4, in step 400, each reachability application 124 scans its reachability application routing table 126. In the illustrated example, each entry is scanned at an interval of 200 milliseconds. In step 402, it is determined whether the pass count is 0. In step 404, if the pass count is not 0, the pass count is decremented by 1. Control then returns to step 400 for the next entry.

If the pass count for a particular entry is 0 before reachability application 124 attempts to decrement the pass count, reachability application 124 checks whether the route is in use or whether the route is a secondary route. By “in use,” it is meant that the route is present in the kernel routing table and being used to route messages. By “secondary route,” it is meant that the route is a redundant route stored in the reachability application routing table but not in the kernel routing table. If the reachability application determines that the route is a secondary route, the route is simply deleted from the reachability application routing table and control returns to step 400 where the reachability application routing table is continuously scanned.

If, on the other hand, the reachability application determines that the route is in use, the reachability application deletes the route from the reachability application and kernel routing tables (410). Deleting the route from the kernel routing tables eliminates the route to a particular virtual IP address. Accordingly, in steps 412 and 414, the reachability application checks whether a secondary route exists in the reachability application routing table. If a secondary route is not present, then all routes to the particular destination IP address are unavailable and control returns to step 400 to wait for a new reachability message. If a secondary route is present, in step 414, the reachability application stores the secondary route in the kernel routing table.

Thus, using the steps illustrated in FIG. 4, a reachability application is able to quickly and transparently switch to a new route. Because the entries in the reachability application routing table are scanned every 200 milliseconds and the pass count is decremented from 2 to 1 to 0, the convergence time to detect an unusable route is no more than 600 milliseconds. This is a tremendous improvement over conventional routing protocols, such as RIP, where the convergence for a new route is 180 seconds or more.

FIG. 5 illustrates exemplary steps that may be performed by reachability applications 128 on cluster nodes 102A-102N in deleting and rebalancing routes. The steps illustrated in FIG. 5 are similar to those in FIG. 4. However, because cluster nodes 100A-100N only advertise a single virtual IP address, some modification is required. Referring to FIG. 5, steps 500-506 are similar to those illustrated in FIG. 4. For example, the reachability applications scan the reachability application routing tables every 200 milliseconds, decrement the pass counts, and delete entries from the reachability applications routing tables when the pass count is 0 before the decrementing occurs. However, due to the dynamic rebalancing algorithm discussed above, loss of a route to one interface may or may not affect the routes in a particular kernel routing table. Accordingly, in step 508, the reachability applications recalculate routes using the rebalancing algorithm discussed above. In step 510, the reachability application on each node checks whether a route to the virtual IP address has changed. If the route has not changed, the entry in the kernel routing table remains the same and control proceeds to step 500 where the scanning continues. In step 512, if the route has changed, the reachability application deletes the old route from its kernel routing table and adds the new route to its kernel routing table. Thus, FIG. 5 illustrates exemplary steps for dynamically re-routing messages around failed links and for rebalancing message flow among remaining links. In addition, convergence time is reduced over conventional routing algorithms, such as RIP.

Thus, as described above, the present invention includes improved methods and systems for exchanging reachability information between cluster nodes and for switching traffic between redundant links in the event of a network failure. A virtual IP address is associated with multiple physical IP addresses to make switching between redundant interfaces seamless to applications. In addition, the convergence time of the methods and systems of the present invention is greatly reduced over that of conventional network routing protocols.

It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation—the invention being defined by the claims.

Claims (36)

1. A method for exchanging reachability information in a network cluster, the method comprising:
(a) connecting first and second nodes in a cluster via local area network connections between local area network (LAN) interfaces of the first and second nodes;
(b) from each LAN interface of the second node, transmitting a reachability message associating a physical Internet protocol (IP) address of the LAN interface with a virtual IP address of the second node;
(c) at the first node, receiving the reachability messages and storing virtual-to-physical IP address mappings for each of the LAN interfaces associated with the second node in a first routing table;
(d) at the first node, selecting one of the virtual-to-physical IP address mappings for the second node from the first routing table and storing the selected mapping in a second routing table; and
(e) repeating step (b) at predetermined time intervals, and, at the first node, in response to failing to receive a reachability message for a LAN interface of the second node within one or more of the predetermined time intervals, deleting the virtual-to-physical IP address mapping for the LAN interface from the first and second routing tables.
2. The method of claim 1 wherein connecting first and second nodes in a cluster via local area network connections includes connecting first and second nodes in a cluster via Ethernet connections.
3. The method of claim 1 wherein transmitting a reachability message associating a network address of each LAN interface of the second node with a virtual IP address of the second node includes transmitting a user datagram protocol (UDP) message from each LAN interface of the second node, the UDP message having a source address corresponding to the physical IP address of the transmitting LAN interface and a data portion carrying the virtual IP address of the second node.
4. The method of claim 1 wherein storing the virtual-to-physical IP address mappings for each of the LAN interface associated with the second node in a first routing table includes storing the virtual-to-physical IP address mappings in a reachability application routing table maintained by a reachability application, the reachability application routing table being used only to update the virtual-to-physical IP address mapping in the second routing table.
5. The method of claim 1 wherein selecting one of the virtual-to-physical IP address mappings for the second node from the first routing table and storing the selected mapping in the second routing table includes extracting a first-received virtual-to-physical IP address mapping from the first routing table and storing the first-received virtual-to-physical IP address mapping in the second routing table.
6. The method of claim 1 wherein extracting one of the virtual-to-physical IP address mappings for the second node from the first routing table and storing the selected mapping in the second routing table includes extracting a most recently received virtual-to-physical IP address mapping from the first routing table and storing the most recently received virtual-to-physical IP address mapping in the second routing table.
7. The method of claim 1 comprising, in response to deleting the virtual-to-physical IP address mapping for a LAN interface from the first and second routing tables, if an additional virtual-to-physical IP address mapping for the second node exists in the first routing table, storing the additional virtual-to-physical IP address mapping in the second routing table.
8. The method of claim 1 comprising:
(a) maintaining a pass count for each virtual-to-physical IP address mapping stored in the first routing table; and
(b) altering the pass count for a virtual-to-physical IP address mapping in the first routing table in response to failing to receive a reachability message for the mapping within the predetermined time interval, and wherein deleting the virtual-to-physical IP address mapping for the LAN interface from the first and second routing tables includes deleting the mapping in response to the pass count reaching a predetermined value.
9. The method of claim 8 comprising resetting the pass count for each virtual-to-physical IP address mapping associated with a LAN interface of the second node in response to receiving a reachability message for the LAN interface.
10. The method of claim 1 comprising forwarding application-level messages from the first node to the second node using the virtual-to-physical IP address mapping stored in the second routing table.
11. The method of claim 1 comprising:
(a) from each LAN interface of the first node, transmitting a reachability message associating a physical IP address of each LAN interface of the first node with a virtual IP address of the first node;
(b) at the second node, receiving the reachability messages and storing virtual-to-physical IP address mappings for each of the LAN interfaces associated with the first node in a first routing table associated with the second node;
(c) at the second node, selecting one of the virtual-to-physical IP address mappings from the first routing table associated with the second node and storing the selected mapping in a second routing table associated with the second node; and
(d) repeating step (a) at predetermined time intervals, and at the second node, in response to failing to receive a reachability message from a LAN interface of the first node within one or more of the predetermined time intervals, deleting the virtual-to-physical IP address mapping for the LAN interface from the first and second routing tables associated with the second node.
12. The method of claim 11 wherein the first routing table associated with the second node comprises a reachability application routing table used only to update the virtual-to-physical IP address mapping in the second routing table associated with the second node.
13. The method of claim 11 wherein selecting one of the virtual-to-physical IP address mappings for the first node from the first routing table associated with second node and storing the selected mapping in the second routing table associated with the second node includes selecting the virtual-to-physical IP address mapping based on the virtual IP address associated with the second node.
14. The method of claim 11 comprising:
(a) maintaining a pass count associated with each virtual-to-physical IP address mapping stored in the first routing table associated with the second node; and
(b) altering the pass count associated with each virtual-to-physical IP address mapping in the first routing table associated with the second node in response to failing to receive a reachability message corresponding to the mapping within the predetermined time period, and wherein deleting the virtual-to-physical IP address mapping from the first and second routing tables associated with the second node includes deleting the virtual-to-physical IP address mapping in response to the pass count reaching a predetermined value.
15. The method of claim 11 comprising using the virtual-to-physical IP address mapping stored in the second routing table associated with the second node to forward messages to the first node.
16. The method of claim 1 wherein repeating step (b) at predetermined time intervals includes repeating step (b) at a time interval of 200 milliseconds.
17. A system for exchanging reachability information between redundantly connected nodes in a network cluster, the system comprising:
(a) a first network node having first and second network interfaces, the first network node being adapted to associate first and second physical Internet protocol (IP) addresses with the first and second network interfaces and a first virtual IP address with the first and second physical IP addresses;
(b) a second network node having third and fourth network interfaces connected to the first and second network interfaces of the first network node via a local area network (LAN) connection, the second network node being adapted to associate third and fourth physical IP address with the third and fourth network interfaces and a second virtual IP address with the third and fourth physical IP address;
(c) a reachability application associated with the second network node for periodically transmitting reachability messages from the third and fourth network interfaces to the first network node, the reachability messages for each network interface advertising a virtual-to-physical IP address mapping for the third and fourth network interfaces; and
(d) a reachability application associated with the first network node for receiving the reachability messages from the second network node, storing the virtual-to-physical IP address mappings for each of the third and fourth network interfaces in a first routing table, selecting one of the mappings from the first routing table and storing the selected mapping in a second routing table used for routing outbound packets.
18. The system of claim 17 wherein the first, second, third, and fourth network interfaces comprise Ethernet interfaces.
19. The system of claim 17 wherein the reachability messages comprise UDP messages having a source address equal to one of the third and fourth physical IP addresses and a data portion carrying the virtual IP address of the second network node.
20. The system of claim 17 wherein the reachability application associated with the first network node is adapted to delete virtual-to-physical IP address mappings from the first and second routing tables in response to failing to receive a reachability message corresponding to the virtual-to-physical IP address mapping from the second network node within a predetermined time period.
21. The system of claim 20 wherein the reachability application associated with the first network node is adapted to maintain a pass count associated with each of the virtual-to-physical IP address mappings stored in the first routing table and to alter the pass count in response to failing to receive a reachability message corresponding to a virtual-to-physical IP address mapping within the predetermined time period, and wherein the reachability application associated with the first node is adapted to delete virtual-to-physical IP address mappings in response to the pass count being equal to a predetermined value.
22. The system of claim 20 wherein, in response to deleting one of the mappings from the first and second routing tables, the reachability application associated with the first node is adapted to extract a remaining virtual-to-physical IP address mapping from the first routing table and store the remaining mapping in the second routing table.
23. The system of claim 17 wherein the reachability application associated with the first node is adapted to use the first routing table only to update entries in the second routing table.
24. The system of claim 17 wherein the reachability application associated with the first node is adapted to select a first received mapping from the first routing table and to store the first-received mapping in the second routing table.
25. The system of claim 17 wherein the reachability application associated with the first node is adapted to store a most recently received mapping from the first routing table and to store the most recently received mapping in the second routing table.
26. The system of claim 17 wherein the reachability application associated with the first network node is adapted to transmit reachability messages from the first and second network interfaces to the second network node, the reachability messages from the first and second network interfaces each including a virtual-to-physical IP address mapping for the first and second network interfaces, and wherein the reachability application associated with the second network node is adapted to receive the reachability messages from the first network node, to store the virtual-to-physical IP address mappings for each of the first and second network interfaces in a first routing table associated with the second network node, and to select one of the mappings from the first routing table associated with the second network node and to store the selected mapping in a second routing table associated with the second network node.
27. The system of claim 26 wherein the reachability messages from the first network node comprise UDP messages, each UDP message having a source address being equal to one of the physical IP addresses of the first and second network interfaces and a data portion including the virtual IP address of the first network node.
28. The system of claim 26 wherein the reachability application associated with the second network node is adapted to delete virtual-to-physical IP address mappings from the first and second routing tables associated with the second network node in response to failing to receive reachability messages from the first network node within a predetermined time period.
29. The system of claim 28 wherein the reachability application associated with the second network node is adapted to maintain a pass count associated with each entry in the first routing table associated with the second network node and to alter the pass count in response to failing to receive a reachability message within a predetermined time period, and wherein the reachability application associated with the second network node is adapted to delete the virtual-to-physical IP address mappings in response to the pass count reaching a predetermined value.
30. The system of claim 29 wherein in response to deleting a virtual-to-physical IP address mapping from the first and second routing tables, the reachability application associated with the second network node is adapted to select a remaining virtual-to-physical IP address mapping from the first routing table associated with the second network node and to store the selected virtual-to-physical IP address mapping in the second routing table associated with the second network node.
31. The system of claim 26 wherein the reachability application associated with the second network node is adapted to use the first routing table associated with the second network node only to update the second routing table associated with the second network node.
32. The system of claim 26 wherein the reachability application associated with the second network node is adapted to select the virtual-to-physical IP address mapping to be stored in the second routing table associated with the first network node based on the IP address of the second network node.
33. A method for exchanging reachability information in a network cluster, the method comprising:
(a) connecting first and second nodes in a cluster via local area network connections between local area network (LAN) interfaces of the first and second nodes;
(b) from each LAN interface of the second node, transmitting a reachability message associating a physical Internet protocol (IP) address of the LAN interface with a virtual IP address of the second node;
(c) at the first node, receiving the reachability messages and storing virtual-to-physical IP address mappings for each of the LAN interfaces associated with the second node in a first routing table;
(d) at the first node, selecting one of the virtual-to-physical IP address mappings for the second node from the first routing table and storing the selected mapping in a second routing table;
(e) repeating step (b) at predetermined time intervals, and, at the first node, in response to failing to receive a reachability message for a LAN interface of the second node within one or more of the predetermined time intervals, deleting the virtual-to-physical IP address mapping for the LAN interface from the first and second routing tables;
(f) from each LAN interface of the first node, transmitting a reachability message associating a physical IP address of each LAN interface of the first node with a virtual IP address of the first node;
(g) at the second node, receiving the reachability messages and storing virtual-to-physical IP address mappings for each of the LAN interfaces associated with the first node in a first routing table associated with the second node;
(h) at the second node, selecting one of the virtual-to-physical IP address mappings from the first routing table associated with the second node and storing the selected mapping in a second routing table associated with the second node; and
(i) repeating step (f) at predetermined time intervals, and at the second node, in response to failing to receive a reachability message from a LAN interface of the first node within one or more of the predetermined time intervals, deleting the virtual-to-physical IP address mapping for the LAN interface from the first and second routing tables associated with the second node,
wherein selecting one of the virtual-to-physical IP address mappings for the first node from the first routing table associated with second node and storing the selected mapping in the second routing table associated with the second node includes selecting the virtual-to-physical IP address mapping based on the virtual IP address associated with the second node, and
wherein selecting the virtual-to-physical IP address mapping based on the virtual IP address of the second node includes computing an index to the first routing table associated with the second node based on a modulus of a host byte of the virtual IP address associated with the second node and a number of available routes to the first node.
34. A method for exchanging reachability information in a network cluster, the method comprising:
(a) connecting first and second nodes in a cluster via local area network connections between local area network (LAN) interfaces of the first and second nodes;
(b) from each LAN interface of the second node, transmitting a reachability message associating a physical Internet protocol (IP) address of the LAN interface with a virtual IP address of the second node;
(c) at the first node, receiving the reachability messages and storing virtual-to-physical IP address mappings for each of the LAN interfaces associated with the second node in a first routing table;
(d) at the first node, selecting one of the virtual-to-physical IP address mappings for the second node from the first routing table and storing the selected mapping in a second routing table; and
(e) repeating step (b) at predetermined time intervals, and, at the first node, in response to failing to receive a reachability message for a LAN interface of the second node within one or more of the predetermined time intervals, deleting the virtual-to-physical IP address mapping for the LAN interface from the first and second routing tables,
wherein the first node comprises a link interface module in a telecommunications signaling message routing node and wherein the second node comprises a network monitoring processor coupled to the signaling message routing node.
35. A system for exchanging reachability information between redundantly connected nodes in a network cluster, the system comprising:
(a) a first network node having first and second network interfaces, the first network node being adapted to associate first and second physical Internet protocol (IP) addresses with the first and second network interfaces and a first virtual IP address with the first and second physical IP addresses;
(b) a second network node having third and fourth network interfaces connected to the first and second network interfaces of the first network node via a local area network (LAN) connection, the second network node being adapted to associate third and fourth physical IP address with the third and fourth network interfaces and a second virtual IP address with
(c) a reachability application associated with the second network node for periodically transmitting reachability messages from the third and fourth network interfaces to the first network node, the reachability messages for each network interface advertising a virtual-to-physical IP address mapping for the third and fourth network interfaces; and
(d) a reachability application associated with the first network node for receiving the reachability messages from the second network node, storing the virtual-to-physical IP address mappings for each of the third and fourth network interfaces in a first routing table, selecting one of the mappings from the first routing table and storing the selected mapping in a second routing table used for routing outbound packets,
wherein the first network node comprises a link interface module in a telecommunications network signaling message routing node and the second node comprises a network monitoring processor coupled to the telecommunications network signaling message routing node.
36. A system for exchanging reachability information between redundantly connected nodes in a network cluster, the system comprising:
(a) a first network node having first and second network interfaces, the first network node being adapted to associate first and second physical Internet protocol (IP) addresses with the first and second network interfaces and a first virtual IP address with the first and second physical IP addresses;
(b) a second network node having third and fourth network interfaces connected to the first and second network interfaces of the first network node via a local area network (LAN) connection, the second network node being adapted to associate third and fourth physical IP address with the third and fourth network interfaces and a second virtual IP address with the third and fourth physical IP address;
(c) a reachability application associated with the second network node for periodically transmitting reachability messages from the third and fourth network interfaces to the first network node, the reachability messages for each network interface advertising a virtual-to-physical IP address mapping for the third and fourth network interfaces; and
(d) a reachability application associated with the first network node for receiving the reachability messages from the second network node, storing the virtual-to-physical IP address mappings for each of the third and fourth network interfaces in a first routing table, selecting one of the mappings from the first routing table and storing the selected mapping in a second routing table used for routing outbound packets,
wherein the reachability application associated with the first network node is adapted to transmit reachability messages from the first and second network interfaces to the second network node, the reachability messages from the first and second network interfaces each including a virtual-to-physical IP address mapping for the first and second network interfaces, and wherein the reachability application associated with the second network node is adapted to receive the reachability messages from the first network node, to store the virtual-to-physical IP address mappings for each of the first and second network interfaces in a first routing table associated with the second network node, and to select one of the mappings from the first routing table associated with the second network node and to store the selected mapping in a second routing table associated with the second network node,
wherein the reachability application associated with the second network node is adapted to select the virtual-to-physical IP address mapping to be stored in the second routing table associated with the first network node based on the IP address of the second network node, and
wherein the reachability application associated with the second network node is adapted to compute a modulus of the virtual IP address of the second network node and a number of routes to first network nodes to select the virtual-to-physical IP address mapping to be stored in the second routing table associated with the second network node.
US10274744 2002-10-21 2002-10-21 Methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster Active US6954794B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10274744 US6954794B2 (en) 2002-10-21 2002-10-21 Methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US10274744 US6954794B2 (en) 2002-10-21 2002-10-21 Methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster
EP20030774906 EP1556778B1 (en) 2002-10-21 2003-10-21 Methods and systems for exchanging reachability information and switching between redundant interfaces in a network cluster
DE2003618878 DE60318878D1 (en) 2002-10-21 2003-10-21 Methods and systems for exchanging reachability information and for switching between redundant interfaces in a network cluster
DE2003618878 DE60318878T2 (en) 2002-10-21 2003-10-21 Methods and systems for exchanging reachability information and for switching between redundant interfaces in a network cluster
PCT/US2003/033347 WO2004038597A8 (en) 2002-10-21 2003-10-21 Methods and systems for exchanging reachability information and switching between redundant interfaces in a network cluster

Publications (2)

Publication Number Publication Date
US20040078481A1 true US20040078481A1 (en) 2004-04-22
US6954794B2 true US6954794B2 (en) 2005-10-11

Family

ID=32093122

Family Applications (1)

Application Number Title Priority Date Filing Date
US10274744 Active US6954794B2 (en) 2002-10-21 2002-10-21 Methods and systems for exchanging reachability information and for switching traffic between redundant interfaces in a network cluster

Country Status (4)

Country Link
US (1) US6954794B2 (en)
EP (1) EP1556778B1 (en)
DE (2) DE60318878T2 (en)
WO (1) WO2004038597A8 (en)

Cited By (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030056138A1 (en) * 2001-08-22 2003-03-20 Wenge Ren Method and system for implementing OSPF redundancy
US20050198049A1 (en) * 2004-03-08 2005-09-08 Ho Yong B. Method and apparatus for inferring address and subnet relationships
US20050240737A1 (en) * 2004-04-23 2005-10-27 Waratek (Australia) Pty Limited Modified computer architecture
US20050257219A1 (en) * 2004-04-23 2005-11-17 Holt John M Multiple computer architecture with replicated memory fields
US20050262513A1 (en) * 2004-04-23 2005-11-24 Waratek Pty Limited Modified computer architecture with initialization of objects
US20050262313A1 (en) * 2004-04-23 2005-11-24 Waratek Pty Limited Modified computer architecture with coordinated objects
US20060020913A1 (en) * 2004-04-23 2006-01-26 Waratek Pty Limited Multiple computer architecture with synchronization
US20060087962A1 (en) * 2004-10-27 2006-04-27 Anthony Golia Fault tolerant network architecture
US20060095483A1 (en) * 2004-04-23 2006-05-04 Waratek Pty Limited Modified computer architecture with finalization of objects
US20060253844A1 (en) * 2005-04-21 2006-11-09 Holt John M Computer architecture and method of operation for multi-computer distributed processing with initialization of objects
US20070100828A1 (en) * 2005-10-25 2007-05-03 Holt John M Modified machine architecture with machine redundancy
US20070100954A1 (en) * 2005-10-25 2007-05-03 Holt John M Modified machine architecture with partial memory updating
US20070101057A1 (en) * 2005-10-25 2007-05-03 Holt John M Modified machine architecture with advanced synchronization
US20070101080A1 (en) * 2005-10-25 2007-05-03 Holt John M Multiple machine architecture with overhead reduction
US20070126750A1 (en) * 2005-10-25 2007-06-07 Holt John M Replication of object graphs
US20070174734A1 (en) * 2005-10-25 2007-07-26 Holt John M Failure resistant multiple computer system and method
US20080114945A1 (en) * 2006-10-05 2008-05-15 Holt John M Contention detection
US20080114943A1 (en) * 2006-10-05 2008-05-15 Holt John M Adding one or more computers to a multiple computer system
US20080114896A1 (en) * 2006-10-05 2008-05-15 Holt John M Asynchronous data transmission
US20080114853A1 (en) * 2006-10-05 2008-05-15 Holt John M Network protocol for network communications
US20080120477A1 (en) * 2006-10-05 2008-05-22 Holt John M Contention detection with modified message format
US20080120478A1 (en) * 2006-10-05 2008-05-22 Holt John M Advanced synchronization and contention resolution
US20080126516A1 (en) * 2006-10-05 2008-05-29 Holt John M Advanced contention detection
US20080126703A1 (en) * 2006-10-05 2008-05-29 Holt John M Cyclic redundant multiple computer architecture
US20080126721A1 (en) * 2006-10-05 2008-05-29 Holt John M Contention detection and resolution
US20080126506A1 (en) * 2006-10-05 2008-05-29 Holt John M Multiple computer system with redundancy architecture
US20080126508A1 (en) * 2006-10-05 2008-05-29 Holt John M Synchronization with partial memory replication
US20080123642A1 (en) * 2006-10-05 2008-05-29 Holt John M Switch protocol for network communications
US20080133689A1 (en) * 2006-10-05 2008-06-05 Holt John M Silent memory reclamation
US20080133688A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple computer system with dual mode redundancy architecture
US20080133884A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple network connections for multiple computers
US20080133859A1 (en) * 2006-10-05 2008-06-05 Holt John M Advanced synchronization and contention resolution
US20080133869A1 (en) * 2006-10-05 2008-06-05 Holt John M Redundant multiple computer architecture
US20080130652A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple communication networks for multiple computers
US20080134189A1 (en) * 2006-10-05 2008-06-05 Holt John M Job scheduling amongst multiple computers
US20080133871A1 (en) * 2006-10-05 2008-06-05 Holt John M Hybrid replicated shared memory
US20080140975A1 (en) * 2006-10-05 2008-06-12 Holt John M Contention detection with data consolidation
US20080155127A1 (en) * 2006-10-05 2008-06-26 Holt John M Multi-path switching networks
US20080250213A1 (en) * 2007-04-06 2008-10-09 Holt John M Computer Architecture And Method Of Operation for Multi-Computer Distributed Processing Having Redundant Array Of Independent Systems With Replicated Memory And Code Striping
US7464151B1 (en) * 2006-01-25 2008-12-09 Sprint Communications Company L.P. Network centric application failover architecture
US20090190581A1 (en) * 2008-01-29 2009-07-30 International Business Machines Corporation Overhead reduction for multi-link networking environments
US20090257440A1 (en) * 2006-12-22 2009-10-15 Huawei Technologies Co., Ltd. Method, system and router for communication between ip devices
US20100121935A1 (en) * 2006-10-05 2010-05-13 Holt John M Hybrid replicated shared memory
US7761595B1 (en) 2006-01-25 2010-07-20 Sprint Communications Company L.P. Dynamic server addition using virtual routing
US7787611B1 (en) * 2004-09-17 2010-08-31 Cisco Technology, Inc. Packet telephony bridging server
US9553658B1 (en) 2013-10-09 2017-01-24 Satcom Direct, Inc. Router for aircraft communications with simultaneous satellite connections
US9554275B1 (en) 2014-10-19 2017-01-24 Satcom Direct, Inc. Voice and SMS communication from a mobile device over IP network and satellite or other communication network
US9565618B1 (en) * 2013-10-09 2017-02-07 Satcom Direct, Inc. Air to ground management of multiple communication paths
US9577742B1 (en) 2013-10-10 2017-02-21 Satcom Direct, Inc. Data compression and acceleration for air to ground communications
US10049508B2 (en) 2014-02-27 2018-08-14 Satcom Direct, Inc. Automated flight operations system

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050268151A1 (en) * 2004-04-28 2005-12-01 Nokia, Inc. System and method for maximizing connectivity during network failures in a cluster system
US7969907B2 (en) 2005-02-16 2011-06-28 Cisco Technology, Inc. System for scheduling scans of interior nodes of a network domain for reachability events
JP4193820B2 (en) * 2005-07-05 2008-12-10 ブラザー工業株式会社 Management apparatus, and program
US20080186990A1 (en) * 2007-02-02 2008-08-07 International Business Machines Corporation Translation module, method and computer program product for providing multiple infiniband address support for vm migration using infiniband address translation
US8874789B1 (en) * 2007-09-28 2014-10-28 Trend Micro Incorporated Application based routing arrangements and method thereof
US8180896B2 (en) * 2008-08-06 2012-05-15 Edgecast Networks, Inc. Global load balancing on a content delivery network
US8159935B1 (en) * 2009-01-12 2012-04-17 Shoretel, Inc. Failover system and method for IP telephony
CN101820381B (en) * 2009-02-27 2013-06-12 华为技术有限公司 Method, system and device for routing service
US8474009B2 (en) 2010-05-26 2013-06-25 Novell, Inc. Dynamic service access
US8639748B2 (en) 2010-09-01 2014-01-28 Edgecast Networks, Inc. Optimized content distribution based on metrics derived from the end user
US8745128B2 (en) 2010-09-01 2014-06-03 Edgecast Networks, Inc. Optimized content distribution based on metrics derived from the end user
US8977766B2 (en) 2010-09-21 2015-03-10 Edgecast Networks, Inc. Scalability and redundancy enhancements for content streaming
US9065864B2 (en) * 2010-12-29 2015-06-23 Bce Inc. Method and system for transmitting a network-initiated message to a mobile device
US8745177B1 (en) 2011-11-01 2014-06-03 Edgecast Networks, Inc. End-to-end monitoring and optimization of a content delivery network using anycast routing
US8738766B1 (en) 2011-11-01 2014-05-27 Edgecast Networks, Inc. End-to-end monitoring and optimization of a content delivery network using anycast routing
US9720676B2 (en) * 2012-02-09 2017-08-01 International Business Machines Corporation Implementing updates to source code executing on a plurality of compute nodes
US9218356B2 (en) * 2013-01-31 2015-12-22 Cumulus Networks, Inc. Systems and methods for accelerating networking functionality
JP2016058883A (en) * 2014-09-09 2016-04-21 日立金属株式会社 Relay system and relay device
EP3148132B1 (en) * 2015-09-28 2018-09-12 Deutsche Telekom AG Method for transmitting and/or receiving network layer reachability information by a network node of a telecommunications network, telecommunications network, network node, program and computer program product

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6041049A (en) * 1997-05-06 2000-03-21 International Business Machines Corporation Method and apparatus for determining a routing table for each node in a distributed nodal system
US6088333A (en) * 1996-11-20 2000-07-11 Electronics And Telecommunications Research Institute Multicast routing method using path overlapping efficiency in VP-based on ATM networks
US6167444A (en) * 1998-05-08 2000-12-26 International Business Machines Corporation Method and system for exchanging routing information
US6385649B1 (en) * 1998-11-06 2002-05-07 Microsoft Corporation Routers and methods for optimal routing table compression
US6392997B1 (en) * 1999-03-16 2002-05-21 Cisco Technology, Inc. Technique for group-based routing update with limited per neighbor/adjacency customization
US20020138628A1 (en) * 2001-01-25 2002-09-26 Crescent Networks, Inc. Extension of address resolution protocol (ARP) for internet protocol (IP) virtual networks
US6567380B1 (en) * 1999-06-30 2003-05-20 Cisco Technology, Inc. Technique for selective routing updates
US6701377B2 (en) * 1997-09-08 2004-03-02 Phoenix Contact Gmbh & Co. Kg Automation system and connecting apparatus for communication between two networks that use two different protocols with conversion between TCP/IP and PCP
US6707820B1 (en) * 1999-12-16 2004-03-16 Intervoice Limited Partnership Virtual circuit network dynamic channel management
US6778498B2 (en) * 2001-03-20 2004-08-17 Mci, Inc. Virtual private network (VPN)-aware customer premises equipment (CPE) edge router

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2786121B2 (en) * 1995-01-26 1998-08-13 日本電気株式会社 Lan connection between router
US5917997A (en) * 1996-12-06 1999-06-29 International Business Machines Corporation Host identity takeover using virtual internet protocol (IP) addressing
US6392990B1 (en) * 1999-07-23 2002-05-21 Glenayre Electronics, Inc. Method for implementing interface redundancy in a computer network

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088333A (en) * 1996-11-20 2000-07-11 Electronics And Telecommunications Research Institute Multicast routing method using path overlapping efficiency in VP-based on ATM networks
US6041049A (en) * 1997-05-06 2000-03-21 International Business Machines Corporation Method and apparatus for determining a routing table for each node in a distributed nodal system
US6701377B2 (en) * 1997-09-08 2004-03-02 Phoenix Contact Gmbh & Co. Kg Automation system and connecting apparatus for communication between two networks that use two different protocols with conversion between TCP/IP and PCP
US6167444A (en) * 1998-05-08 2000-12-26 International Business Machines Corporation Method and system for exchanging routing information
US6385649B1 (en) * 1998-11-06 2002-05-07 Microsoft Corporation Routers and methods for optimal routing table compression
US6392997B1 (en) * 1999-03-16 2002-05-21 Cisco Technology, Inc. Technique for group-based routing update with limited per neighbor/adjacency customization
US6567380B1 (en) * 1999-06-30 2003-05-20 Cisco Technology, Inc. Technique for selective routing updates
US6707820B1 (en) * 1999-12-16 2004-03-16 Intervoice Limited Partnership Virtual circuit network dynamic channel management
US20020138628A1 (en) * 2001-01-25 2002-09-26 Crescent Networks, Inc. Extension of address resolution protocol (ARP) for internet protocol (IP) virtual networks
US6778498B2 (en) * 2001-03-20 2004-08-17 Mci, Inc. Virtual private network (VPN)-aware customer premises equipment (CPE) edge router

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Steven, W. Richard, TCP/IP Illustrated, vol. 1, 1994, Addison-Wesley, pp. 143-144. *

Cited By (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7490161B2 (en) * 2001-08-22 2009-02-10 Nokia Inc. Method and system for implementing OSPF redundancy
US20030056138A1 (en) * 2001-08-22 2003-03-20 Wenge Ren Method and system for implementing OSPF redundancy
US20050198049A1 (en) * 2004-03-08 2005-09-08 Ho Yong B. Method and apparatus for inferring address and subnet relationships
US7577670B2 (en) * 2004-03-08 2009-08-18 Hewlett-Packard Development Company, L.P. Method and apparatus for inferring address and subnet relationships
US7849452B2 (en) 2004-04-23 2010-12-07 Waratek Pty Ltd. Modification of computer applications at load time for distributed execution
US20050262313A1 (en) * 2004-04-23 2005-11-24 Waratek Pty Limited Modified computer architecture with coordinated objects
US20060020913A1 (en) * 2004-04-23 2006-01-26 Waratek Pty Limited Multiple computer architecture with synchronization
US7707179B2 (en) 2004-04-23 2010-04-27 Waratek Pty Limited Multiple computer architecture with synchronization
US20060095483A1 (en) * 2004-04-23 2006-05-04 Waratek Pty Limited Modified computer architecture with finalization of objects
US7860829B2 (en) * 2004-04-23 2010-12-28 Waratek Pty Ltd. Computer architecture and method of operation for multi-computer distributed processing with replicated memory
US20090198776A1 (en) * 2004-04-23 2009-08-06 Waratek Pty Ltd. Computer architecture and method of operation for multi-computer distributed processing with initialization of objects
US7844665B2 (en) 2004-04-23 2010-11-30 Waratek Pty Ltd. Modified computer architecture having coordinated deletion of corresponding replicated memory locations among plural computers
US7788314B2 (en) 2004-04-23 2010-08-31 Waratek Pty Ltd. Multi-computer distributed processing with replicated local memory exclusive read and write and network value update propagation
US20050262513A1 (en) * 2004-04-23 2005-11-24 Waratek Pty Limited Modified computer architecture with initialization of objects
US20050257219A1 (en) * 2004-04-23 2005-11-17 Holt John M Multiple computer architecture with replicated memory fields
US20050240737A1 (en) * 2004-04-23 2005-10-27 Waratek (Australia) Pty Limited Modified computer architecture
US7787611B1 (en) * 2004-09-17 2010-08-31 Cisco Technology, Inc. Packet telephony bridging server
US7450498B2 (en) * 2004-10-27 2008-11-11 Morgan Stanley Fault tolerant network architecture
US20060087962A1 (en) * 2004-10-27 2006-04-27 Anthony Golia Fault tolerant network architecture
US20090235034A1 (en) * 2005-04-21 2009-09-17 John Matthew Holt Computer architecture and method of operation for multi-computer distributed processing with synchronization
US7818296B2 (en) 2005-04-21 2010-10-19 Waratek Pty Ltd. Computer architecture and method of operation for multi-computer distributed processing with synchronization
US20060253844A1 (en) * 2005-04-21 2006-11-09 Holt John M Computer architecture and method of operation for multi-computer distributed processing with initialization of objects
US8028299B2 (en) 2005-04-21 2011-09-27 Waratek Pty, Ltd. Computer architecture and method of operation for multi-computer distributed processing with finalization of objects
US20070126750A1 (en) * 2005-10-25 2007-06-07 Holt John M Replication of object graphs
US7958322B2 (en) 2005-10-25 2011-06-07 Waratek Pty Ltd Multiple machine architecture with overhead reduction
US8122198B2 (en) 2005-10-25 2012-02-21 Waratek Pty Ltd. Modified machine architecture with partial memory updating
US7996627B2 (en) 2005-10-25 2011-08-09 Waratek Pty Ltd Replication of object graphs
US7849369B2 (en) * 2005-10-25 2010-12-07 Waratek Pty Ltd. Failure resistant multiple computer system and method
US7761670B2 (en) 2005-10-25 2010-07-20 Waratek Pty Limited Modified machine architecture with advanced synchronization
US20080195617A1 (en) * 2005-10-25 2008-08-14 Holt John M Modified machine architecture with machine redundancy
US8015236B2 (en) 2005-10-25 2011-09-06 Waratek Pty. Ltd. Replication of objects having non-primitive fields, especially addresses
US7660960B2 (en) 2005-10-25 2010-02-09 Waratek Pty, Ltd. Modified machine architecture with partial memory updating
US8122200B2 (en) 2005-10-25 2012-02-21 Waratek Pty Ltd. Modified machine architecture with advanced synchronization
US20070174734A1 (en) * 2005-10-25 2007-07-26 Holt John M Failure resistant multiple computer system and method
US20080189385A1 (en) * 2005-10-25 2008-08-07 Holt John M Multiple machine architecture with overhead reduction
US8209393B2 (en) 2005-10-25 2012-06-26 Waratek Pty Ltd. Multiple machine architecture with overhead reduction
US20070101080A1 (en) * 2005-10-25 2007-05-03 Holt John M Multiple machine architecture with overhead reduction
US20070101057A1 (en) * 2005-10-25 2007-05-03 Holt John M Modified machine architecture with advanced synchronization
US20070100954A1 (en) * 2005-10-25 2007-05-03 Holt John M Modified machine architecture with partial memory updating
US20070100828A1 (en) * 2005-10-25 2007-05-03 Holt John M Modified machine architecture with machine redundancy
US20080215593A1 (en) * 2005-10-25 2008-09-04 Holt John M Replication of object graphs
US20080215701A1 (en) * 2005-10-25 2008-09-04 Holt John M Modified machine architecture with advanced synchronization
US20080215928A1 (en) * 2005-10-25 2008-09-04 Holt John M Failure resistant multiple computer system and method
US7464151B1 (en) * 2006-01-25 2008-12-09 Sprint Communications Company L.P. Network centric application failover architecture
US7761595B1 (en) 2006-01-25 2010-07-20 Sprint Communications Company L.P. Dynamic server addition using virtual routing
US20080133870A1 (en) * 2006-10-05 2008-06-05 Holt John M Hybrid replicated shared memory
US20080140801A1 (en) * 2006-10-05 2008-06-12 Holt John M Multiple computer system with dual mode redundancy architecture
US20080137662A1 (en) * 2006-10-05 2008-06-12 Holt John M Asynchronous data transmission
US20080140975A1 (en) * 2006-10-05 2008-06-12 Holt John M Contention detection with data consolidation
US20080141092A1 (en) * 2006-10-05 2008-06-12 Holt John M Network protocol for network communications
US20080140863A1 (en) * 2006-10-05 2008-06-12 Holt John M Multiple communication networks for multiple computers
US20080140976A1 (en) * 2006-10-05 2008-06-12 Holt John M Advanced contention detection
US20080140856A1 (en) * 2006-10-05 2008-06-12 Holt John M Multiple communication networks for multiple computers
US20080140805A1 (en) * 2006-10-05 2008-06-12 Holt John M Multiple network connections for multiple computers
US20080140982A1 (en) * 2006-10-05 2008-06-12 Holt John M Redundant multiple computer architecture
US20080155127A1 (en) * 2006-10-05 2008-06-26 Holt John M Multi-path switching networks
US20080133694A1 (en) * 2006-10-05 2008-06-05 Holt John M Redundant multiple computer architecture
US20080184071A1 (en) * 2006-10-05 2008-07-31 Holt John M Cyclic redundant multiple computer architecture
US20080133861A1 (en) * 2006-10-05 2008-06-05 Holt John M Silent memory reclamation
US20080133711A1 (en) * 2006-10-05 2008-06-05 Holt John M Advanced contention detection
US20080133871A1 (en) * 2006-10-05 2008-06-05 Holt John M Hybrid replicated shared memory
US20080134189A1 (en) * 2006-10-05 2008-06-05 Holt John M Job scheduling amongst multiple computers
US20080130652A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple communication networks for multiple computers
US8473564B2 (en) 2006-10-05 2013-06-25 Waratek Pty Ltd. Contention detection and resolution
US20080133869A1 (en) * 2006-10-05 2008-06-05 Holt John M Redundant multiple computer architecture
US20080133692A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple computer system with redundancy architecture
US20080130631A1 (en) * 2006-10-05 2008-06-05 Holt John M Contention detection with modified message format
US20080133859A1 (en) * 2006-10-05 2008-06-05 Holt John M Advanced synchronization and contention resolution
US20080133884A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple network connections for multiple computers
US20080133688A1 (en) * 2006-10-05 2008-06-05 Holt John M Multiple computer system with dual mode redundancy architecture
US20080151902A1 (en) * 2006-10-05 2008-06-26 Holt John M Multiple network connections for multiple computers
US20080133690A1 (en) * 2006-10-05 2008-06-05 Holt John M Contention detection and resolution
US20080133689A1 (en) * 2006-10-05 2008-06-05 Holt John M Silent memory reclamation
US20080126505A1 (en) * 2006-10-05 2008-05-29 Holt John M Multiple computer system with redundancy architecture
US20100121935A1 (en) * 2006-10-05 2010-05-13 Holt John M Hybrid replicated shared memory
US20080126322A1 (en) * 2006-10-05 2008-05-29 Holt John M Synchronization with partial memory replication
US20080123642A1 (en) * 2006-10-05 2008-05-29 Holt John M Switch protocol for network communications
US20080126508A1 (en) * 2006-10-05 2008-05-29 Holt John M Synchronization with partial memory replication
US20080126506A1 (en) * 2006-10-05 2008-05-29 Holt John M Multiple computer system with redundancy architecture
US20080126721A1 (en) * 2006-10-05 2008-05-29 Holt John M Contention detection and resolution
US20080126703A1 (en) * 2006-10-05 2008-05-29 Holt John M Cyclic redundant multiple computer architecture
US7831779B2 (en) 2006-10-05 2010-11-09 Waratek Pty Ltd. Advanced contention detection
US20080126516A1 (en) * 2006-10-05 2008-05-29 Holt John M Advanced contention detection
US8095616B2 (en) 2006-10-05 2012-01-10 Waratek Pty Ltd. Contention detection
US20080120478A1 (en) * 2006-10-05 2008-05-22 Holt John M Advanced synchronization and contention resolution
US7849151B2 (en) 2006-10-05 2010-12-07 Waratek Pty Ltd. Contention detection
US7852845B2 (en) 2006-10-05 2010-12-14 Waratek Pty Ltd. Asynchronous data transmission
US20080120477A1 (en) * 2006-10-05 2008-05-22 Holt John M Contention detection with modified message format
US7894341B2 (en) 2006-10-05 2011-02-22 Waratek Pty Ltd. Switch protocol for network communications
US7949837B2 (en) 2006-10-05 2011-05-24 Waratek Pty Ltd. Contention detection and resolution
US20080114853A1 (en) * 2006-10-05 2008-05-15 Holt John M Network protocol for network communications
US7958329B2 (en) 2006-10-05 2011-06-07 Waratek Pty Ltd Hybrid replicated shared memory
US7962697B2 (en) 2006-10-05 2011-06-14 Waratek Pty Limited Contention detection
US7971005B2 (en) 2006-10-05 2011-06-28 Waratek Pty Ltd. Advanced contention detection
US20080114944A1 (en) * 2006-10-05 2008-05-15 Holt John M Contention detection
US20080114896A1 (en) * 2006-10-05 2008-05-15 Holt John M Asynchronous data transmission
US20080114943A1 (en) * 2006-10-05 2008-05-15 Holt John M Adding one or more computers to a multiple computer system
US20080114945A1 (en) * 2006-10-05 2008-05-15 Holt John M Contention detection
US8090926B2 (en) 2006-10-05 2012-01-03 Waratek Pty Ltd. Hybrid replicated shared memory
US8086805B2 (en) 2006-10-05 2011-12-27 Waratek Pty Ltd. Advanced contention detection
US20090257440A1 (en) * 2006-12-22 2009-10-15 Huawei Technologies Co., Ltd. Method, system and router for communication between ip devices
US8155131B2 (en) * 2006-12-22 2012-04-10 Huawei Technologies Co., Ltd. Method, system and router for communication between IP devices
US8316190B2 (en) 2007-04-06 2012-11-20 Waratek Pty. Ltd. Computer architecture and method of operation for multi-computer distributed processing having redundant array of independent systems with replicated memory and code striping
US20080250213A1 (en) * 2007-04-06 2008-10-09 Holt John M Computer Architecture And Method Of Operation for Multi-Computer Distributed Processing Having Redundant Array Of Independent Systems With Replicated Memory And Code Striping
US7813341B2 (en) * 2008-01-29 2010-10-12 International Business Machines Corporation Overhead reduction for multi-link networking environments
US20090190581A1 (en) * 2008-01-29 2009-07-30 International Business Machines Corporation Overhead reduction for multi-link networking environments
US9553658B1 (en) 2013-10-09 2017-01-24 Satcom Direct, Inc. Router for aircraft communications with simultaneous satellite connections
US9565618B1 (en) * 2013-10-09 2017-02-07 Satcom Direct, Inc. Air to ground management of multiple communication paths
US9577742B1 (en) 2013-10-10 2017-02-21 Satcom Direct, Inc. Data compression and acceleration for air to ground communications
US10049508B2 (en) 2014-02-27 2018-08-14 Satcom Direct, Inc. Automated flight operations system
US9554275B1 (en) 2014-10-19 2017-01-24 Satcom Direct, Inc. Voice and SMS communication from a mobile device over IP network and satellite or other communication network
US9923863B2 (en) 2014-10-19 2018-03-20 Satcom Direct, Inc. Voice and SMS communication from a mobile device over IP network and satellite or communication network

Also Published As

Publication number Publication date Type
EP1556778A1 (en) 2005-07-27 application
EP1556778A4 (en) 2005-12-14 application
DE60318878T2 (en) 2008-05-21 grant
WO2004038597A8 (en) 2004-07-29 application
DE60318878D1 (en) 2008-03-13 grant
WO2004038597A1 (en) 2004-05-06 application
EP1556778B1 (en) 2008-01-23 grant
US20040078481A1 (en) 2004-04-22 application

Similar Documents

Publication Publication Date Title
US6754220B1 (en) System and method for dynamically assigning routers to hosts through a mediator
US7248579B1 (en) System and method for providing a link state database (LSDB) snapshot for neighbor synchronization
US6253230B1 (en) Distributed scalable device for selecting a server from a server cluster and a switched path to the selected server
US7428209B1 (en) Network failure recovery mechanism
US20050105524A1 (en) System and method for provisioning of route information in a meshed communications network
US20020114326A1 (en) Address mapping mechanism enabling multi-domain addressing in communication networks
US20030123457A1 (en) Apparatus and method for distributed software implementation of OSPF protocol
US20020184387A1 (en) Method for connecting between networks, virtual router, and system for connecting between networks by using this virtual router
US6556547B1 (en) Method and apparatus providing for router redundancy of non internet protocols using the virtual router redundancy protocol
US6567403B1 (en) Virtual-chassis switch network topology
US7450498B2 (en) Fault tolerant network architecture
US20080186968A1 (en) Triple-tier anycast addressing
US6343330B1 (en) Arrangement for preventing looping of explorer frames in a transparent bridging domain having multiple entry points
US20120182866A1 (en) System and method for virtual fabric link failure recovery
US20020012352A1 (en) Internet protocol handler for telecommunications platform with processor cluster
US7002924B2 (en) Zero configuration networking
US20090141621A1 (en) Bandwidth reservation reuse in dynamically allocated ring protection and restoration technique
US6065062A (en) Backup peer pool for a routed computer network
US20020021689A1 (en) Method and apparatus for transparent internet mobility management
US20040054799A1 (en) Enhanced mobility and address resolution in a wireless premises based network
US6751191B1 (en) Load sharing and redundancy scheme
US7269135B2 (en) Methods and systems for providing redundant connectivity across a network using a tunneling protocol
US20020196802A1 (en) Data forwarding method and apparatus
EP1006702A2 (en) Method and apparatus providing for an improved VRRP (Virtual Router Redundancy Protocol)
US5717687A (en) Data communication system with adaptive routing, and switching node intended to be used in such a system

Legal Events

Date Code Title Description
AS Assignment

Owner name: TEKELEC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RUDD, JOSEPH M.;ROBINSON, BEN C.;ELLIS, JEFF L.;AND OTHERS;REEL/FRAME:013607/0677;SIGNING DATES FROM 20021113 TO 20021114

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, MINNESOTA

Free format text: SECURITY INTEREST;ASSIGNORS:TEKELEC;CAMIANT, INC.;REEL/FRAME:028035/0659

Effective date: 20120127

AS Assignment

Owner name: TEKELEC GLOBAL, INC., NORTH CAROLINA

Free format text: CHANGE OF NAME;ASSIGNOR:TEKELEC;REEL/FRAME:028078/0287

Effective date: 20120130

REMI Maintenance fee reminder mailed
SULP Surcharge for late payment

Year of fee payment: 7

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12