Multiplex communications – Fault recovery – Bypass an inoperative channel
Reexamination Certificate
2000-09-28
2004-05-04
Vincent, David (Department: 2661)
Multiplex communications
Fault recovery
Bypass an inoperative channel
C370S242000
Reexamination Certificate
active
06731598
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
This invention relates to communication systems and, more particularly, to a virtual Internet Protocol (IP) Framework and interfacing method that provides a fault-tolerant and scalable interface between a plurality of servers and a packet data network such as the Internet.
2. Description of Related Art
Many companies now build a large percentage or all of their revenue stream through business conducted over the Internet. These companies, therefore, require access and switching technology with very high reliability. If these companies lose Internet access for even a short period, they lose a large amount of revenue. Thus, increasing the fault tolerance of Internet access technology is highly desirable. Additionally, these types of companies need network access technology that allows for growth in their data trafficking needs. If they need to obtain more bandwidth, for example, they need to be able to do this easily. Therefore, a solution providing scalability is also desirable.
Different technologies that exist in the IP world today all have problems or limitations. Systems that address only fault tolerance generally cannot be combined with systems emphasizing scalability to achieve both requirements because the portion of the system emphasizing scalability is not fault tolerant, and this negatively impacts the fault tolerance of the entire system. Generally, one of the requirements is traded off against the other.
When clients are accessing a Web server, for example, a browser first gets the name of the Uniform Resource Locator (URL) translated into a unique IP address using a Domain Name Server (DNS). The unique IP address then enables the client to reach the server that will handle its Hypertext Transfer Protocol (HTTP) request. A solution is needed, therefore, that presents a single IP address to the clients. The solution should provide scalability and fault tolerance, and should impose no additional requirements on the clients. Furthermore, the solution should not be limited specifically to HTTP traffic or TCP traffic. It is desirable that the solution be applicable to all types of IP traffic.
There exists in the market a Round Robin DNS that provides a degree of scalability. The Round Robin DNS provides, for the same URL name, a different IP address each time. The DNS can use any algorithm to balance the load between the different servers. Additional servers may be added, and the DNS will distribute the load over the larger number of servers. The Round Robin DNS solution, however, has the limitation that the client must make a DNS request in order to guarantee a balanced distribution. The clients have the capability to cache the IP address, and for future accesses may use the cached IP address rather than obtaining a new IP address from the DNS. This can defeat the scalability feature because whenever the client caches the IP address returned by the DNS, the Round Robin DNS cannot guarantee the distribution. The fault tolerance of the system can also be adversely affected if the client caches a server's IP address and that server later develops a fault. Thus, the scalability and fault tolerance are bound by the behavior of the client. It is desirable to provide scalability and fault tolerance without constraints on clients. Therefore the Round Robin DNS is not sufficient.
Another solution is to route every message to a focal point that redirects the packets to different end-hosts. This type of solution is shown in WO 99/33227 in which a network flow switch (NFS) is utilized. However, this solution does not allow the capacity of the system to be increased since the NFS is a limiting factor. The NFS is implemented like a standard router having network cards and Internet controllers controlled by a CPU, with traffic going between the CPU and the cards. A capacity limitation in the CPU, therefore, could limit overall system capacity. The NFS is also a single point of failure greatly reducing the system's fault tolerance.
In EP 0 865 180 A2, two alternatives are described for distributing requests to a plurality of servers, but neither of the alternatives provides scalability. In one alternative, a Dispatcher is used to direct incoming traffic. A router requests the Dispatcher to determine which server should take the traffic. The Dispatcher is a single point, and when its capacity is fully utilized, additional servers cannot be added. The Dispatcher also routes the data, so it is a single point of failure, thereby reducing fault tolerance of the system. The other alternative uses broadcasting over a bus. However, if the bandwidth of the bus is limited, the scalability of the system is similarly limited.
Another product known as a LocalDirector also provides a single focal point that guarantees correct packet reassembly before the packets reach an end-host. The LocalDirector acts as a VIP termination and then forwards the request to the real end-host using either:
1. MAC address translation. All end-hosts support the VIP termination. The LocalDirector transmits an IP datagram to a specific end-host using the MAC address of this end-host. The end-host can then transmit in the reverse direction directly to the originating end.
2. Tunneling. IP datagrams are encapsulated in another protocol layer in order to forward them to the end-host. The end-host must support this encapsulation. Then the end-host can transmit in the reverse direction directly to the originating end or go through the LocalDirector.
3. Network Address Translation (NAT). The LocalDirector modifies the IP header replacing the VIP address with the real IP address of the target end-host. The end-host has to transmit in the reverse direction to the LocalDirector.
The problem with implementations such as the LocalDirector is that they use “hot standby” techniques to solve the fault tolerance problem. Hot standby systems maintain a fully capable secondary system that is ready to take over if the primary system fails. This addresses fault tolerance, but does not address scalability since the capacity of the primary or the secondary system limits the system capacity. Therefore an architecture using a LocalDirector does not meet the scalability requirement.
In order to overcome the disadvantage of existing solutions, it would be advantageous to have a Virtual IP (VIP) Framework that provides a fault-tolerant and scalable interface between a plurality of servers and a packet data network such as the Internet. Additionally, the Framework would have limited impact on clients, application designers, and the existing network infrastructure. Finally, the Framework would be applicable to multiple protocols. The present invention provides such a Framework.
SUMMARY OF THE INVENTION
The present invention is an interfacing method and Framework that provides high fault tolerance and linear scalability of the servers and the network interfaces. The Framework is transparent to the clients and the servers, and has minimal impact on the surrounding network infrastructure. In addition, since the preferred embodiment operates at the IP level, the invention can operate with any application that runs on top of IP.
Thus, in one aspect, the present invention is a fault-tolerant and scalable method of interfacing a plurality of application servers with a packet data network (PDN). For incoming messages, the method begins by receiving in a plurality of network terminations, incoming data packets and packet fragments from the PDN. Each of the network terminations are associated with one of a plurality of forwarding processes, and each of the forwarding processes is connected to a plurality of fragmenter/de-fragmenters. Each forwarding process then selects a single fragmenter/de-fragmenter to receive all of the incoming data packets and packet fragments having a common source address. This is followed by sending the incoming data packets and packet fragments having a common source address to the selected fragmenter/de-fragmenter, where incoming data packets are reassembled
Andersson Per
Beliveau Andre
Franzen Anders
Hennert Lars
Beauchesne Sandra
Smith Steven W.
Telefonaktiebolaget L M Ericsson (publ)
Vincent David
LandOfFree
Virtual IP framework and interfacing method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Virtual IP framework and interfacing method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Virtual IP framework and interfacing method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3240528