The present invention relates to computer network communication techniques. In particular it relates to a method and system for providing reconfiguration of network elements after a failure of such an element.
The present invention is generally applicable in computer networks comprising a plurality of node computers.
Particular additional advantages can be profited from when said plurality of node computers has some inner structure of ‘competence distribution’, in particular a structure in which a first type of serviced computers, in particular embedded controllers, and a second type of server computers, exist in a non-public network, closed network system.
The present invention will next be discussed with the particular prior art being disclosed in the RFC1542 specification because it describes a client server communication protocol which can be well used with a hardware environment schema as sketched out above, where the first type of (client) computers are diskless computing units, and the second type computers are the respective servers which are provided with some permanent storage facility.
Within the Internet domain the BOOTP protocol has been architected by Request for Comment RFC 1542 to service diskless computer systems by supplying an executable load image. A so-called boot server host is attached to the same physical LAN that also connects the diskless, mostly embedded controller computer nodes. When the embedded nodes receive stand-by power they typically load an initial bootstrap code—mostly called BIOS (Basic Input Output Service)—from flash ROM and start executing it. In the course of this execution important information that personalizes this local node is read from special hardware interfaces. This information is usually divided into two categories:                (I). Data that is required to service the BOOTP protocol, for instance and most important for the sake of the present invention the unique network MAC address of the first type computer.        (II). Vendor specific data that is unique to the environment of the implementation.        
The data of type (II) is typically used to supply information that is required to build up a configuration encompassing all embedded nodes in a subject system. The BIOS code starts sending out BOOTP messages over one or all of its local LAN interfaces. Sending is repeated upon expiration of an appropriate timeout until a reply is received from a boot server. The sending is performed as a “limited broadcast” on the LAN by supplying a MAC address with all bits turned on. Such a message is restricted to the physical LAN where the omitting interface is attached to. It will not be routed into other LANs by means of IP routing.
These message contain data of both types (I) and (II). These BOOTP messages will be intercepted by the boot server host, i.e., the above mentioned second type of (server) computer. Based on the data content the boot server decides whether it is entitled to serve this particular requester. The typical boot server accesses a data file, e.g., the (“/etc/bootptab” file) that contains information about “acceptable” requesters. If accepted a dialogue between the boot server program and the target BIOS code will be conducted. At the end of this dialogue a loadable code image will be shipped to the embedded node, and this image will be started then.
In parallel the data content being sent with the BOOTP message will be exploited by the boot server program in a way that supports the construction of a configuration consisting of all the acquired data from all nodes. This configuration is the essential data set that is typically maintained by a configuration server on the subject boot server host.
The regular scenario of the prior art BOOTP RFC 1542 ends here.
But in an environment that features redundant network structures with redundant boot servers that are an integral part of a system with common power supply structures for server and client nodes, and an a priori unknown number of requesting client computer nodes with unknown identity new problem areas are opened up. Being interchangeably attached to a common power supply structure enforces the implementation of a dynamic network configuration for the boot servers based on their relative location within the network structure. This requirement fosters increased availability and flexibility by avoiding ‘single point of failures’ (SPOF) within such a system.
Once there is more than one, i.e., a redundant boot server host, each embedded node is assumed to send out its BOOTP message over all LAN interfaces in order to potentially reach at least one boot server. More than one boot server may send a reply to such a BOOTP request. Then the requesting embedded node decides with which server it executes the boot dialogue. From now on the other servers are excluded from further information. The crucial problems to be solved are:                First, the other boot servers need to be informed about the progress of the boot and startup process of each embedded controller, even if they have not participated in the boot dialogue.        Second, the re-attaching server hosts—be it for the first or a later time—have to determine their location relative to the network structure. Thus, it is difficult for it to determine if a server host (SC) is connected to the left or to the right side of the network.        
A solution to the first problem is fundamental for the construction of a configuration by the configuration servers running “behind” the boot server on these redundant server hosts. The underlying problem is equivalent to the problem of re-attaching a boot or configuration service to a network of running embedded controllers and enabling it to re-construct the configuration.
The solution of the second problem determines the IP definitions according to a predefined physical network design this server has to apply to its local LAN interfaces in order to be able to participate in the IP network traffic, i.e., to be able to send and receive IP packets from running embedded nodes.
USPTO Backgrounds
USPTO Backgrounds