 |
Claims  |
|
|
We claim:
1. A transport agent for providing full multihoming support in processing network communication service requests from a number of application processes being run on a host system
connected to communicate with a number of networks and subnetworks connected to an internetwork which connects to a number of destination host systems, the host system including a plurality of front end processors (FEPs), each FEP having a network
protocol stack and being connected to either a different one of the networks or subnetworks or to a different portion of the same network or subnetwork so as to process communications network requests between the host system and the other host systems,
the host system further including host operating system software having an application runtime interface and input/output supervisor and driver facilities, the transport agent being located between the runtime interface and supervisor and driver
facilities and including a transport service support component operatively coupled to the runtime interface and to the input/output supervisor and driver facilities for servicing the communications network requests including establishing communications
between application processes and processes running on the other host systems, the transport agent further comprising:
(a) a multihoming and routing component operatively coupled to the transport service support component and to the FEPs;
(b) a plurality of table structures operatively coupled to the multihoming and routing component, a first one of the table structures containing a plurality of locations initially configured to store static route information defining available
connection paths to the destination host systems and a second one of the table structures containing a plurality of locations for storing entries indicating the FEPs of the plurality of FEPs configured in the host system; and
(c) the transport service support component including functions for invoking the multihoming and routing component in response to each predetermined type of request specifying that an application process wants to bind to any and all local host
network addresses, the multihoming and routing component when invoked being operative to attempt to bind each configured FEP to the application process in accordance with the entries stored in the first and second tables, the multihoming and routing
component upon successfully binding to one of the configured FEPs signaling the application process that binding has been completed while continuing to bind remaining configured FEPs to the application process so as to maintain path redundancy and
increased load capacity during communications with destination host systems.
2. The transport agent of claim 1 wherein the runtime interface utilizes sockets and the predetermined type of request includes a special constant INADDR.sub.-- ANY for enabling the application process to receive information sent to any of the
host system's EP addresses.
3. The transport agent of claim 1 wherein the first table structure defines a number of routing tables and the second table structure defines a number of FEPs tables.
4. The transport agent of claim 3 wherein the host system further includes a configuration file for storing pertinent information files defining configured FEPs and initial static routes, the transport agent further including a startup component
operatively coupled to the transport service support component and to the multihoming and routing component, the startup component being operative during host system initialization to read the contents of the files and invoke the transport service
support component and the multihoming and routing component for building entries in the FEPs tables and routing tables in accordance with the contents of the pertinent information files.
5. The transport agent of claim 3 wherein the pertinent information files include a plurality of administratively entered ifconfig directives and the transport service support component upon being invoked by the startup component is operative to
create the entries in the FEP tables based on processing the ifconfig directives pertaining to FEP interfaces.
6. The transport agent of claim 5 wherein the transport service support component in response to the startup component, operates to invoke the multihoming and routing component after creating entries in the FEP tables causing the multihoming and
routing component to add predetermined entries in a portion of the FEP tables for specifying multihoming FEP interface connections.
7. The transport agent of claim 6 wherein the portion of the FEP tables defines a FEPNET table comprising an array structure having a plurality of rows and columns, each row allocated to represent a different subnetwork and the columns of each
row for storing information defining the different multihoming FEP interfaces associated with the different subnetwork entered by the multihoming and routing component.
8. The transport agent of claim 7 wherein the multihoming and routing component includes an Add FEPNET entry function, the Add FEPNET function when invoked determines if that the subnetwork is being specified a first time by an ifconfig
directive, upon determining that the subnetwork is specified a first time the Add FEPNET function allocates a next unused row of the array defined by an FEP index value to the subnetnetwork and then adds an entry to a first column of the next row for the
particular FEP interface.
9. The transport agent of claim 8 wherein the Add FEPNET function upon determining that the subnetwork has been previously specified by an ifconfig directive operates to add an entry for the particular FEP interface to an appropriate one of the
columns of the row allocated to the subnetwork.
10. The transport agent of claim 8 wherein the Add FEPNET function determines if the subnetwork is present in the FEPNET table by ascertaining that the FEP index value specifies a subnet IP address which equals a result of anding the FEP ip
address bits with the subnet mask and that the FEPNET netmask equals the FEP subnet mask.
11. The transport agent of claim 8 wherein each allocated row of the array includes a column for storing predetermined network information including a localnet subnetwork ip address, a netmask and a localnet number entry, the Add FEPNET function
being operative to generate and enter appropriate values for the localnet subnet ip address, netmask and localnet number entry as part of adding an entry to a row.
12. The transport agent of claim 10 wherein the Add FEPNET function sets the localnet subnetwork ip address value equal to a result of anding information included in a corresponding FEP table entry defining FEP ip address bits and FEP netmask
bits, sets the localnet netmask equal to the FEP netmask value and increments by one, the localnet number entry.
13. The transport agent of claim 6 wherein the startup component upon completing storage of all entries in the FEP and FEPNET tables invokes the multihoming and routing component for building the routing tables in a predetermined manner in
accordance with routing information contained in the pertinent information files constructed using administratively entered commands.
14. The transport agent of claim 13 wherein the routing tables include an FEP route hash table structure and the multihoming and routing component further includes an Add Route function, the Add Route function upon being invoked operates to
create a node structure entry in the FEP route hash table, the node structure entry being constructed to contain predetermined values verified in a predetermined manner and being linked to the FEP route hash table.
15. The transport agent of claim 14 wherein the node structure entry containing the predetermined values which include a destination address value defining routes to specific host systems, networks including default routes, a gateway value
defining a gateway IP address, an fepmask value having bit positions corresponding to the configured FEPs, an fepmask count value indicating a number of valid FEPs specified in the fepmask value and a metric value defining cost of route in hops.
16. The transport agent of claim 14 wherein the multihoming and routing component further includes a get route mask function invoked by a call from the transport service support component when an application process requests connection to one of
the destination host systems, the get route mask function being operative to build a route mask structure in accordance with the information contained in the FEP route table entry for a particular route for return to the transport service support
component along with the destination address of the host system.
17. The transport agent of claim 16 wherein the transport agent further includes a socket table structure having a plurality of locations indexed by socket numbers assigned to the application processes, each location being allocated to an
application process when a socket is called using an unused location and used for maintaining items of context data including a set of transport endpoints on the configured FEPs which exist to support the socket, the transport service support component
being operative to store the mask route structure along with the destination address in the location of the socket table allocated to the application process.
18. The transport agent of claim 17 wherein the multihoming and routine component further includes an FEP selection function, the FEP selection function being invoked by call from the transport service support component following receipt of the
application process connection request which includes the previously passed mask route structure and the FEP selection function when invoked being operative to carry out selection of an FEP in a predetermined manner.
19. The transport agent of claim 18 wherein the selection of an FEP is carried out utilizing a pseudo random number.
20. The transport agent of claim 18 wherein the route mask structure includes a number of locations organized according to a predetermined metric, each location containing a count value designating a number of FEPs in the fep mask of the fep
route table structure and a FEP mask value having bit positions set to a predetermined state for designating the valid FEPs for a particular metric value, the FEP selection function being operative in response to each call in which the connection to a
FEP fails to reset a corresponding one of the bit positions of the FEP mask value until no further candidate FEPs can be found.
21. A method of constructing a transport agent for providing full multihoming support for processing network communication service requests from a number of application processes being run on a host system
connected to communicate with a number of networks and subnetworks connected to an internetwork which connects to a number of destination host systems, the host system including a plurality of front end processors (FEPs), each FEP having a
network protocol stack and being connected to either a different one of the networks or subnetworks or to a different portion of the same network or subnetwork so as to process communications network requests between the host system and the other host
systems, the host system further including host operating system software having an application runtime interface and input/output supervisor and driver facilities, the transport agent being located between the runtime interface and supervisor and driver
facilities and including a transport service support component operatively coupled to the runtime interface and to the input/output supervisor and driver facilities for servicing the communications network requests including establishing communications
between application processes and processes running on the other host systems, the method comprising the steps of:
(a) including in the transport agent, a multihoming and routing component which operatively coupled to the transport service support component and to the FEPs;
(b) including a plurality of table structures operatively coupled to the multihoming and routing component, a first one of the table structures containing a plurality of locations initially configured to store static route information defining
available connection paths to the destination host systems and a second one of the table structures containing a plurality of locations for storing entries indicating the FEPs of the plurality of FEPs configured in the host system; and
(c) including in the transport service support component functions for invoking the multihoming and routing component in response to each predetermined type of request specifying that an application process wants to bind to any and all local host
network addresses, the multihoming and routing component when invoked being operative to attempt to bind each configured FEP to the application process in accordance with the entries stored in the first and second tables, the multihoming and routing
component upon successfully binding to one of the configured FEPs signaling the application process that binding has been completed while continuing to bind remaining configured FEPs to the application process so as to maintain path redundancy and
increased load capacity during communications with destination host systems.
22. The method of claim 21 wherein the runtime interface utilizes sockets and the predetermined type of request includes a special constant INADDR.sub.-- ANY for enabling the application process to receive information sent to any of the host
system's IP addresses.
23. The method of claim 21 wherein the first table structure defines a number of routing tables and the second table structure defines a number of FEPs tables.
24. The method of claim 23 wherein the host system further includes a configuration file for storing pertinent information files defining configured FEPs and initial static routes, the transport agent further including a startup component
operatively coupled to the transport service support component and to the multihoming and routing component, the method further including the steps of:
invoking the transport services support component and the multihoming and routing component by the startup component during reading of the contents of the files during host system initialization for building entries in the FEPs tables and routing
tables in accordance with the contents of the pertinent information files.
25. The method of claim 24 wherein the method further includes the steps of:
invoking the multihoming and routing component upon completing storage of all entries in the FEP and FEPNET tables for building the routing tables in a predetermined manner in accordance with routing information contained in the pertinent
information files constructed using administratively entered commands.
26. The method of claim 25 wherein the routing tables include an FEP route hash table structure and the method further includes the step of:
including in the multihoming and routing component, an Add Route function which upon being invoked operates to create a node structure entry in the FEP route hash table, the node structure entry being constructed to contain predetermined values
verified in a predetermined manner and being linked to the FEP route hash table.
27. The transport agent of claim 26 wherein the method further includes the step of:
including in the multihoming and routing component a get route mask function operative to build a route mask structure in accordance with the information contained in the FEP route table entry for a particular route for return to the transport
service support component along with the destination address of the host system.
28. The method of claim 27 further including the step of:
including in the multihoming and routine component, an FEP selection function operative to carry out selection of an FEP in a predetermined manner utilizing a pseudo number value.
29. The method of claim 23 wherein the pertinent information files include a plurality of administratively entered ifconfig directives and the method further including the step of:
the transport service support component upon being invoked by the startup component creating the entries in the FEP tables based on processing the ifconfig directives pertaining to FEP interfaces.
30. The method of claim 29 wherein the method further includes the step of: to invoking the multihoming and routing component after creating entries in the FEP tables to add predetermined entries in a portion of the FEP tables for specifying
multihoming FEP interface connections.
31. The method of claim 30 wherein the portion of the FEP tables defines a FEPNET table comprising an array structure having a plurality of rows and columns, each row allocated to represent a different subnetwork and the columns of each row for
storing information defining the different multihoming FEP interfaces associated with the different subnetwork entered by the multihoming and routing component.
32. The method of claim 31 further including the steps of:
including in the multihoming and routing component an Add FEPNET entry function; next determining by the Add FEPNET function if that the subnetwork is being specified a first time by an ifconfig directive; and,
upon determining that the subnetwork is specified a first time, allocating a next unused row of the array defined by an FEP index value to the subnetnetwork and adding an entry to a first column of the next row for the particular FEP interface.
33. The method of claim 32 further including the step of: adding an entry for the particular FEP interface to an appropriate one of the columns of the row allocated to the subnetwork upon determining that the subnetwork has been previously
specified by an ifconfig directive. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of Use
The present invention relates to systems and methods for supporting network communications and more particularly to systems and methods for providing a multihoming capability.
2. Prior Art
As is well known in the art, a computer network is a communication system for connecting end-systems referred to as hosts. An internet or internetwork is the connection of two or more distinct networks so that the computers on one network are
able to communicate with computers on another network. One way of connecting two distinct physical networks is to have a gateway that is attached to both networks. The gateway is used to pass information from one network to the other network. In the
well-known Open Systems Interconnection (OSI) seven layer network reference model, the term used to describe the interconnection depends on the layer at which the connection takes place. For example, a specific kind of "gateway" called a router
typically operates at the third or network layer which is defined as the layer that builds data packets and indicates the type of frame which has been built or must be built by the second or data link layer that controls the movement of data frames and
rearranges the data to identify various fields.
The network layer sends data packets to the fourth or transport layer which ensures reliable delivery of data packets by following a specific protocol which adds to the error correction facilities of the lower levels. In the case of the TCP/IP
protocol suite, the term gateway refers to a network level router. In the UNIX based systems, a host system may have more than one network connection, possibly employing more than one type of communications interface, as for example, an Ethernet
interface and a token ring interface. When a host system is connected to more than one interface thus having more than one IP address, the host system is said to be "multihomed".
A traditional reason for having a system "multihomed" has been for the purpose of operating the system as a router. Such systems are usually small and low in cost. Hence, the more costly, enterprise systems are not typically used to function as
routers or gateways. However, it has been noted that there are several other important reasons for an enterprise system to have multihoming capabilities. These reasons are: (1) to allow a host system to communicate with separate networks in certain
situations (e.g. for security reasons); (2) to allow a large host system to survive the loss of hardware components in the paths of the communication interface, particularly in those systems which have multiple I/O processors; and, (3) to allow a large
host system to have communication bandwidth in excess of the capability of a single communication interface.
In prior art arrangements, the multihomed host system traditionally uses a single stack implementation in which kernel software allows sharing of a single network protocol stack by multiplexing the IP layer (i.e., OSI layer 3). An example of
such a multihomed host system in a network router application is described in Chapter 4 of the text entitled "Unix Network Programming" by W. Richard Stevens, copyright 1990 by PTR Prentice Hall.
While such arrangements provide the ability to manage different network interfaces, such hosts do not operate as enterprise systems providing multiple network connections which would provide greater capacity and the ability to off-load
communications processing.
The ability to off-load communications protocol functions by using front-end processors (FEPs) is particularly advantageous for host systems. An example of this type of system is described in an article entitled "GCOS 8 System Interoperability
in Heterogeneous Distributed Networks" by Mort Davis published in Volume 6, No.2 of the Groupe Bull Technical Update, copyright 1996 by Bull HN Information Systems Inc. and Bull S. A.
By way of background, in this type of system, the host system supports applications and performs the functions associated with the presentation and, when applicable, session layers while the FEPs perform the functions associated with the
transport, network, link and physical layers. In greater detail, the host system TCP/IP applications request transport services via Sockets or XTI APIs from a TCP/IP Transport Agent, which in turn requests the actual transport services from an FEP
actually providing the network access connection. Traditionally, each particular application has been able to only easily use a single IP address, associated with a particular FEP, which provides network access. In the case of a default request or a
request to use any or all IP addresses (i.e., in sockets terms "INADDR.sub.-- ANY"), the system had to chose or designate a default FEP and IP address, in fact not honoring the request for "any and all". Hence, this arrangement precludes the use of more
than one FEP, unless the application was explicitly coded to access them. Thus, this arrangement is unable to provide full multihoming support. For further information on multihoming, reference may be made to the publications entitled, "Communications
Sockets, Sockets Administrator's Guide, GCOS 8", Copyright 1996, Bull HN Information Systems Inc. Publication Number RG44, Rev02, and "Communications SOCKET LIBRARY, Programmer's Guide, Socket Internetworking, GCOS 8", Copyright 1995, Bull HN
Information Systems Inc. Publication Number LC02, Rev02.
An additional issue inherent in FEP-based solutions is that FEPs are independent entities from the host system, which can crash or fail independently of the host. Traditionally, applications were very sensitive to FEP failures. For full
multihoming support, applications must be isolated from FEP failures as much as possible.
Accordingly, it is a primary object of the present invention to provide a multihoming capability for a host system which can support multiple network connections for providing redundancy and greater capacity, without application involvement.
More specifically, it is an object to provide a system which allows full support of the "INADDR.sub.-- ANY" concept on a system with FEPs.
It is a further more specific object of the present invention to provide a multihomed host system which is able to spread communications load between network connections and provide the ability to recover from network connection failures through
the use of redundant components and paths.
SUMMARY OF THE INVENTION
The above objects are achieved in a preferred embodiment of the multihomed host of the present invention. The multihomed host system is configured with independent TCP/IP transport providers corresponding to front end processors (FEPs), each
having its own network protocol stack. The FEPs can be connected to different TCP/IP networks or subnetworks, or to different portions of the same network which in turn can connect to an internetnetwork. In the host system, each FEP operates as a
peripheral device which operatively connects to the host system's operating system.
In the previous art, the host operating system software includes a "TCP/IP Transport Agent" located between one or more application interfaces (e.g. sockets, XTI) and the host system's input/output supervisor and driver facilities. The TCP/IP
Transport Agent provides a set of common system wide transport interface services for supporting the different user application interfaces without having to make any changes to such interfaces. The invention is directed to enhancing the TCP/IP Transport
Agent through the addition of a FEP Multihoming and Routing Component which provides full multihoming support, using configuration information to determine how to best use the available FEPs. The TCP/IP Transport Agent through the use of one or more
FEP-specific transport provider protocols obtains services from multiple FEP transport providers as if the host included only a single stack implementation while still maintaining the advantages of using an FEP based architecture.
In the preferred embodiment, the FEP Multihoming and Routing Component utilizes a number of components such as routing and FEP tables which are built and manipulated by specific functions included in the FEP Multihoming and Routing Component.
The routing table contains a plurality of locations which are initially configured to store static route information which defines available connection paths to destination hosts based on the configuration of host FEPs. More specifically, each entry
contains a destination address (host or network), an address of the IP gateway to use to locate the configured destination and a metric value defining the number of "hops" to get to the destination, with default information specifying the route to use if
no specific routes are appropriate. The FEP table stores entries defining the configured FEPs.
In the preferred embodiment, configuration files are constructed by a system administrator which contain pertinent information about the set of configured FEPs and initial static routes. At system initialization, in addition to being provided to
the configured FEPs for organizing their TCP/IP stacks, the same information contained in the configuration files can be used to configure the routing and FEP tables. During operation, depending on the type of application, the TCP/IP Transport Agent
uses its FEP Multihoming and Routing component to provide full multihoming support.
For example, in the case of a server type application wherein the application is "bound" to a specific TCP or UDP port ("well-known" port) on INADDR.sub.-- ANY, the TCP/IP Transport Agent invokes a multibind support function of the FEP
Multihoming and Routing component which attempts to bind to the specified port on each configured FEP. When one of the configured FEPs successfully binds to the port, the bind operation is defined to have "completed" from an application point of view.
For each bind request that cannot be immediately handled by an FEP, the TCP/IP Transport Agent FEP table entry associated with that FEP is marked as restartable and the TCP/IP Transport Agent will periodically retry these requests at an established time
interval until binding succeeds.
For a client type application wherein the UDP or TCP port is arbitrarily assigned, the TCP/IP Transport Agent's FEP Multihoming and Routing component will utilize certain support routines to obtain the same "arbitrary" port on each configured
FEP. It does this by assigning an available port from a host-resident table and then attempts to obtain the same port on each subsequent FEP, returning control to the application when at least one FEP has bound the port, and periodically retrying the
other FEPs until they succeed. In this case, all port assignments on all FEPs are recorded in a resident port table within the TCP/IP Transport Agent.
When the client application issues an outbound TCP "connect" request to another system, or attempts to send a UDP datagram to another system over a socket bound to INADDR.sub.-- ANY, the FEP Multihoming and Routing component utilizing a specific
support function selects one FEP from a prioritized set of FEPs to carry out the requested operation and retries until it finds an FEP in the list through which it can reach the destination system. If the selection step results in no candidate FEPs,
then the TCP/IP Transport Agent notifies the application of the failed call.
Because the present invention enables FEPs to be connected to different TCP/IP networks or subnets or to different portions of the same network or subnet, this provides path redundancy for maintaining operation in the event of a path component
failure (e.g. I/O processor, channel, FEP, network connection). Additionally, this capability through proper configuration enables increased communication load capacity in cases where the communications load may be greater than a single FEP can reliably
handle (i.e., the traffic can be spread over several FEPs).
The above objects and advantages of the present invention will be better understood from the following description when taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an overall block diagram of a system having a TCP/IP Transport Agent which includes the FEP Multihoming and Routing component of the present invention.
FIG. 2 illustrates in greater detail, the system of FIG. 1 which includes the FEP Multihoming and Routing component of the present invention.
FIGS. 3a through 3g illustrate different control structures utilized in conjunction with the FEP Multihoming and Routing component of the present invention.
FIGS. 4a through 4j are diagrams illustrating the specific functions utilized by the present invention.
FIG. 5 is a sockets protocol flow diagram used in describing the operation of the TCP/IP Transport Agent as augmented by the FEP Multihoming and Routing component of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
For ease of explanation, a glossary of some of the terms utilized within the following description has been included as an Appendix.
FIG. 1
FIG. 1 is a block diagram of a conventional data processing system 10 which includes a host processor 10-2 connected to a plurality of front-end processors (FEPs) 10-4a through 10-4d which in turn provide network access as indicated. The
connections between the host processor 10-2 and FEPs can be any channel connections supported by the host.
In the preferred embodiment, the host processor 10-2 is proprietary system such as the DPS9000 system manufactured by Bull HN Information Systems Inc. The host system 10-2 operates under the control of a proprietary operating system, such as the
GCOS 8 operating system marketed by Bull HN Information Systems Inc. Each FEP can be an FCP 8, OPEN 8 or a DXE adapter, connected over standard I/O channels including the FIPS (Federal Information Processing Standard) channel. For further information
regarding the types of FEPs, reference may be made to Sockets Administrator's Guide, Bull order number 67 A2 RG44.
It will be noted in FIG. 1 that the complement of four FEPs are configured in a number of different ways. By way of example, FEPs 10-4a and 10-4b are shown as both connecting via separate network connections 12a and 12b to the same Network A 14
which in turn connects to the Internet 18 via Network B through network connections 12c and 12e as indicated. The FEP 10-4c is shown as being connected to Network B 16 via network connection 12d. Lastly, FEP 10-4d connects to Private Network 20 via
network connection 12f.
FIG. 2
FIG. 2 shows in greater detail, portions of the system 10 of FIG. 1 including the TCP/IP Transport Agent 10-250 which incorporates the FEP Multihoming and Routing component 10-254 of the present invention. As shown, host system 10-2 includes a
memory area 10-20 which is divided up into a user space section 10-20a and a system space section 10-20b as indicated. The user space section 10-20a contains the applications 10-200 being run on the host system 10-2 and a runtime interface 10-204. The
runtime interface 10-204 enables the use of existing APIs within the host system 10-2 and therefore, obviates the need to make changes to applications utilizing such services.
In the preferred embodiment, the runtime interface 10-204 supports the Sockets API. Hence, "Sockets" terminology will be used herein. It will be appreciated, however, that Sockets is only an API and not a protocol specification. For example,
the XTI API may also be utilized. That is, runtime interface 10-204 is not in any way precluded from providing support of XTI or another transport API as a matter of design choice.
Application transport service requests to the TCP/IP Transport Agent 10-250 invoke routines contained within a Transport Service Support component 10-258 included therein as indicated in FIG. 2 to create transport endpoints on FEPs, to bind
addresses and ports, to manage FEP and network information, to listen for incoming connections, to initiating connections to remove hosts, and to send, and receive data. The FEP Multihoming and Routing component 10-254 includes mechanisms/functions to
select FEPs. Additionally, the TCP/IP Transport Agent 10-250 contains a number of memory data structures such as Routing Tables structure 10-252 and FEP Tables structure 10-256 for supporting multihoming and a startup component 10-251 for initializing
such data structures as discussed herein.
In greater detail, as shown in FIG. 2, the system space section 10-20b contains the different components of the enhanced TCP/IP Transport Agent 10-250 of the present invention, a configuration files component 10-260 labeled Config. Files which
operatively couples to the Agent 10-250 and a system I/O supervisor and device drivers component 10-270 which serves as the interface between the FEPS 10-4a through 10-4c and the TCP/IP Transport Agent 10-250. Additionally, as shown, the TCP/IP
Transport Agent 10-250 further includes a Socket Table structure 10-259 and a port management table structure 10-257 used by Transport Service Support component 10-258 and FEP Multihoming and Routing component 10-254 for servicing requests as discussed
herein.
Startup component 10-251 includes a set of routines executed when the operating system is initialized (i.e., booted) which serve to initialize/populate the contents of the Routing Tables structure 10-252 and the FEP Tables structure 10-256 by
reading the appropriate files within Config Files component 10-260. Transport Service Support component 10-258 contains a state of the art set of transport agent service functions/routines which translate socket API calls into the transport provider
protocols used to communicate with the FEPs through interface 10-262. This set of functions/routines has been augmented by a subset of functions of FIGS. 4i and 4j designed for enhancing operation through the use of FEP Multihoming and Routing component
10-254 as described herein.
The FEP Multihoming and Routing component 10-254 includes a set of support functions/routines of FIGS. 4a through 4j which are used in processing application requests as described herein. As discussed above, both the Routing Tables structure
10-252 and FEP Tables component 10-256 are configured by FEP information obtained from the Config Files component 10-260 as explained herein. Thus, the TCP/IP Agent 10-250 provides Route Tables and FEP Tables components 10-252 and 10-256 at the system
level configured for enabling multihomed operation on host system 10-2.
As indicated in FIG. 2, the TCP/IP Transport Agent 10-250 communicates with component 10-270 via interface 10-262. The I/O Supervisor and Devices component 10-270 communicates with FEPs 10-4a through 10-4c via interfaces 10-280a through 10-280c.
FIG. 2 further illustrates the basic allocation of networking functions between the host system 10-2 and FEPs 10-4a through 10-4d. As indicated, the host system 10-2 provides the functions associated with the Application layer in addition to
providing a common layer which supports all of the functions of each FEP while each FEP provides the I/O functions associated with the Transport, Network, Data Link and Physical layers. This organization is illustrated by FEP 10-4c which includes a host
interface section for providing the FEP-specific Transport Provider Protocol, and TCP/IP stack layers.
Control Structures--FIGS. 3a-3g
FIG. 3a shows in greater detail, the structure of the FEP table component 10-252. FEP table 10-252 is organized for fast access to the appropriate FEP entry in response to an input destination IP address. As shown, the FEP table 10-252 is
represented as a set of route nodes 10-252b which are dynamically created and linked together from a fixed length hash table structure 10-252a labeled as FEP.sub.-- ROUTE.sub.-- HASH in FIG. 3a. The
hash table structure 10-252a has a hash modulo value (i.e., size) of typically 512-1024.
The hash algorithm/function used to provide fast access is a standard algorithm such as the algorithm which is described at page 89 of the text entitled "Internetworking with TCP/IP, Vol II: Design, Implementation and Internals" by Douglas E.
Comer, and David L. Stevens published by Prentice-Hall, copyright 1991, 1994. Briefly, the hash function for a given address is obtained by summing the individual | | |
