Enhanced Directory Services in Compound Wide/Local Area Networks

This invention relates to enhanced central directory services in Wide Area Networks (WANs) and, more particularly, to the registration of user resources residing on nodes, possibly themselves interconnected by Local Area Networks (LANs), in such WANs, across boundaries between logical partitions or topology domains of the WAN.

Distributed directory services for computer networks are disclosed in A. E. Baratz et al. U.S. Pat. No. 4,914,571, granted Apr. 3, 1990. Resource identifications in the Baratz patent, however, are stored only by the network nodes (a network node being the node in a domain to which all that domain's end nodes are connected). As a result, the directory data base is generally limited to a very small proportion of all of the resources in the network. This limitation greatly increases the number of broadcast searches needed to create routes in the network, i.e., all cross-domain searches must be initially broadcast. Thereafter remote resource data is cached in the network node initiating the search.

The directory services of the Baratz patent can be further enhanced by the central directory server disclosed in "Advances in APPN Architecture," by R. Bird et al., IBM Systems Journal, Vol. 4, No. 3, pages 430-451 (1995). Before conducting broadcast searches, Bird's network nodes consult a central directory server, which may have a larger storage and hold entries for more resources. The total number of directory broadcasts in the logical partition of a network served by one such central directory server is thereby reduced from n.times.m, where n is the number of network nodes and m is the number of resources, to m. That is, only the central directory need conduct broadcast searches, and resource information obtained on behalf of one network node may later be supplied to satisfy a different network node's query. While the Bird technique does reduce the number of broadcast searches, it does not eliminate such broadcast searches.

It has become increasingly common to use Wide Area Networks to interconnect large numbers of Local Area Networks (LANs). It is difficult, however, to provide resource directory services in such compound networks because the LAN resources often pre-exist the interconnecting WAN and hence are not constrained to utilize LAN resource identifications which are necessarily different from the previously assigned WAN resource identifications. In addition, the size of topology data bases used to control interconnections in the WAN are normally chosen to reflect the number of nodes and links in the WAN network. Typically, these topology data bases are therefore often too small to contain all of the possibly non-unique identification information about all of the LAN resources which are connected to that WAN. This forces a very serious limitation on the maximum size to which such compound WAN/LAN networks can grow. Indeed, network users would prefer internal interconnection services with no limit on ultimate size. To overcome these perceived limitations, users tend to partition WANs into separate topology domains, each of which may have its own central directory server(s), that can provide directory services only within that topological domain. In such a scheme, a unique high-level qualifier, called the "NETID," precedes the resource identifier for all network nodes and most end user resources within the same topological domain Providing unique resource identifications across the set of interconnected topological domains despite these pre-existing resource naming conventions is difficult. For example, for flexibility such naming schemes may permit end nodes to attach to topological domains with NETIDs different than their own, since an end node might well access multiple networks through dial-up transmission facilities.

This searching problem is exacerbated when the WAN takes the form of an Advanced Peer-to-Peer Networking (APPN.RTM.) network. APPN networks offer a powerful, flexible and easy-to-use networking solution for client/server and distributed applications. Such applications create many additional directory service problems, however, when attempting to use APPN for very large networks interconnecting large pluralities of LANs. The large number of APPN network nodes, and corresponding network node identifications, in such large APPN networks, creates even more serious searching problems across the APPN network.

Finally, existing limitations on the size of the available WAN topology data bases often make it difficult to select routes on the basis of class of service (requiring quality of service information in the data base). Customers would, of course, like to interconnect very large numbers of small LANs as gateways to the customer's branch offices. Each branch site, however, is usually itself configured as a LAN, thereby effectively doubling the possible number of topology data base entries. All of these constraints combine to render the provision of efficient directory services across such a large compound WAN/LAN network, whether or not an APPN network, difficult if not impossible.

In accordance with the illustrative embodiment of the present invention, enhanced directory services are provided in large, unconstrained, compound Wide Area/Local Area Networks by a hierarchical, automatically initiated directory registration process for all new resources added to a network at the time those new resources are initially added to the network. Such a central directory is designed to contain information about all resources in and connected to the WAN/LAN network. To support this registration activity, a central directory services server, together with a large central directory data base, is made available in one of the WAN network nodes. The size of the central directory data base used to store resource information can be made responsive to user requests, and hence be of any size necessary to support routing between any two resources in the compound network and still include Quality of Service parameters.

More particularly, each Local Area Network connected to the Wide Area Network is connected to the WAN through a WAN network node and, together with the connected WAN network node, forms a "resource domain" within which resources can be uniquely identified by identifying the network node domain in which they appear (as well as the resource end node and the resource itself). In order to increase the efficiency in the processing of such identifications, the domain network node identification is added to the end node user resource identifications to form a triplet. This triplet includes the identification of the resource itself, the identification of the domain in which the resource resides, and the identification of the domain network node in which the triplet resource itself resides. This triplet is always necessarily unique in the compound Wide Area Network.

In accordance with one feature of the present invention, as each new end node resource is added to a domain, a triplet resource identification is created, one member of the triplet at a time, by register resource messages initiated automatically at the end node resource, traveling to the domain network node and thence to the central resource directory. This process, called resource registration, takes advantage of the domain network node by including a domain level data base containing a comprehensive set of triplet resource identifications including all of the end node resources "owned" by that domain network node. This feature allows the fastest possible retrieval of an identification by a local end node which can be obtained by referral to the directly connected domain network node without requiring the locate function to be sent on to the central directory data base. The central directory data base, of course, contains the triplet identifications of all of resources connected to the entire compound network. The route calculation algorithms of the WAN network can then retrieve the triplet resource identifications from the central directory data base and use them to calculate optimum routes, using Quality of Service (QoS) criteria if desired. Again, if all of the necessary resource information can be retrieved from a domain or end node storage facility closer to the requester than the central directory, the search is taken only to the closest available source of the information, be it the domain directory or the end node resource itself.

Since network retrofitting is time-consuming and expensive, the enhanced directory services of the present invention have been made compatible with existing network management programming (so as not to require network changes). For example, and in accordance with a final feature of the present invention, during the initial automatic registration activity the triplet resource identification being registered is deliberately corrupted in the domain resource data base by substituting one owning end node identifier for another in that data base. This substitution serves to conceal the true nature of the domain data base server from the balance of the network and thus forces the WAN network to treat the domain node as if it were a single end node. This allows standard search, locate and register messages to be sent on to the central directory without changing the existing network software.

A complete understanding of the present invention may be gained by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 shows a general block diagram of a compound Wide Area/Local Area network in which enhanced directory services might be provided in accordance with the present invention;

FIG. 2 shows a more detailed block diagram of generic network node in the network of FIG. 1, illustrating the types of equipment which may be present in various network nodes of the network of FIG. 1, and which equipment is useful to implement the enhanced directory services in accordance with the present invention;

FIG. 3A shows a graphical and functional representation of the prior art central resource registration processes which might typically take place in prior art networks similar to that of FIG. 1;

FIG. 3B shows a graphical and functional representation of the enhanced central resource registration processes available in a network such as that shown in FIG. 1, using the equipment shown in FIG. 2, in accordance with the present invention;

FIG. 4 shows graphical representations of prior art generic Generalized Data Stream (GDS) variable data format structures including, at the top of the figure, a Generalized Data Stream (GDS) representation of the generic GDS format and, at the bottom of the figure, a generic GDS representation of a typical GDS control vector;

FIG. 5 is a graphical representation of the GDS triplet directory services resource hierarchy identifications coded as three control vectors such as those illustrated in the bottom format of FIG. 4 and which can be used in the enhanced directory services messages in accordance with the present invention;

FIG. 6 is a graphical representation of directory services GDS variables used in the major enhanced directory services provided in accordance with the present invention;

FIG. 7 shows a flow chart of the process used for initial end node resource registration which takes place at the addition of each new end node resource to the compound WAN/LAN network of FIG. 1, and forming part of the enhanced directory services in accordance with the present invention; and

FIG. 8 shows a flow chart of the process of searching for resource identifications previously registered in the central directory, forming part of the enhanced directory services in accordance with the present invention.

To facilitate reader understanding, identical reference numerals are used to designate elements common to the figures.

Referring more particularly to FIG. 1, there is shown a general block diagram of what may be called a compound Wide Area Network (WAN)-Local Area Network (LAN) 10 comprising four network nodes 11, each with a unique resource identifier, i.e., B.1, B.2, B.3 and B.4, respectively. Network nodes 11 are interconnected by five interconnecting transmission links labeled L1, L2, L3, L4 and L5, respectively. Network nodes 11 and transmission links L1-5 are merely illustrative of the numerous nodes and links that might form part of a real network 10. Indeed, network 10 can easily be transcontinental or even intercontinental and involve hundreds or even thousands of nodes and links.

The network nodes 11 can each, in turn, be used to attach or interconnect users, even foreign network users, to the network 10. Such interconnections can be made directly, such as end nodes (ENs) 5, 6 and 7, connected to network node B.3, or interconnected by way of Local Area Networks (LANs). Network node B.2, for example, is connected through end node EN 189 to a ring LAN 13 and thence to end nodes 1-4. Network node B.4 is connected through end node EN 191 to a ring LAN 14 and thence to end nodes 11-13, and through end node EN 192, to a "backbone" LAN 18 (such as ETHERNET.RTM.) and thence to end nodes 8-10. End nodes 12 are merely illustrative of the hundreds or thousands of end nodes which are used to connect user resources to network 10, and which can each be connected to a LAN or user resource. Such resources include Logical Units (LUs), application programs, Point-of-Sale terminals, computers, printers, facsimile machines, file servers and all of the other network resources that might be used to provide network services.

The network nodes 11 to which the end nodes 12 are connected are known as network node control points (NNCPs), and an end node 12 providing services to one or more Logical Unit (LU) resources is called an End Node Control Point (ENCP). The end nodes EN 189, EN 191 and EN 192 connected to an NNCP, and all of the other end nodes 12 connected through the access end nodes EN 189-192, directly or through a LAN, together with the NNCP network node with which they are connected itself, are together known as a topological "domain" in the sense that the NNCP provides directory and other network services for all of the resources in "its" domain. Thus, network node B.2, together with end node EN 189, ring LAN 13 and end nodes EN 1, 2, 3 and 4, form domain 15. Similarly, network node B.4, together with end node EN 191, ring LAN 14, end nodes EN 11-13, end node EN 192, the backbone LAN 18 including end nodes EN 8-10, form domain 16. Network node B.3, together with direct access end nodes 5, 6 and 7, form domain 17.

By convention, all of the network nodes 11 of WAN 10 have the same network identifier B (NETID) and this NETID precedes the identifiers of all of the network nodes (e.g., B.1 in network 10). These identifiers are all stored in a topology data base replicated in each of the network nodes 11 along with identifications and characteristics of the interconnecting links L1-5. In the prior art schemes, none of the end nodes 12 are in the WAN network 10 topology data bases. This lack is due to various reasons particular to the specific prior art embodiments. For example, it may be due to a desire to minimize the topology data base size for economic reasons or it may be because the values of these identifications are not known at the time the network 10 is created. Furthermore, it should be recalled that the network identifiers (NETIDs) of the end nodes 12 are not necessarily constrained to be the same as their network server node (NNCP) 11 and, indeed, are typically assigned independent of the creation of the WAN 10.

As noted, network nodes 11 are linked to others of the network nodes 11 by one or more communication links L1 through L5. Each such communication link may be a permanent connection or a selectively enabled (dial-up) connection, or any other kind of transmission facility, even including a portion of a LAN or a virtual LAN. Network nodes 11 each comprise a data processing system which provides data communications services to all connected nodes, network nodes and end nodes. The network nodes 11 each include one or more decision points within the node, at which point incoming data streams are selectively routed on one or more of the outgoing communication links, i.e., either to an end node attached to and/or served by that network node, or to another network node in network 10 via transmission links L1-L5. Such routing decisions are made in response to information in the header of the data packet. The network node also provides ancillary services such as the calculation of new routes or paths between end nodes, creation of the header, the provision of access control to packets entering the network at that node, and the provision of directory services and topology database maintenance in that node. The network nodes 11 also each can provide enhanced directory services for the domains of network 10 of FIG. 1, all in accordance with the present invention.

In order to transmit packets on the network of FIG. 1, it is necessary to calculate a feasible path or route through the network from the source entity to the destination identifier (server 139 of FIG. 8) entity to be used for the transmission of data streams. One optimal route calculating system is disclosed in H. Ahmadi et al. U.S. Pat. No. 5,233,604 granted Aug. 3, 1993. In prior art Wide Area Networks, the network information in the topology data bases is normally adequate to calculate such routes. If such a route can be calculated, a connection request message is launched on the network, from the source entity to the destination identifier (server 139) entity, explicitly identifying each entity along the route. Data packets may thereafter be transmitted along the calculated route from the originating node 121 to the destination identifier (server 139) node (and from the destination node 139 to the originating node) by placing this route in the header of the data packet. At the end of the transmission session, the process is reversed, taking down the connection. These functions are all well known in the prior and will not be described further.

Unfortunately, since the identifications of all of the end nodes 12 are not even in the topology data bases, such route calculations cannot be made in the large and compound network 10 of FIG. 1. In accordance with the present invention, the network node and end node and user resource information available in the prior art topology data bases of network 10 must be extended considerably to capture the extensive information concerning the domain resources, i.e., the end nodes, Local Area Networks, and the available end user resources. In further accordance with the present invention, the processes for acquiring, updating and using this extended topology information are known as enhanced central directory services and form the subject matter of this invention. The network node interior architecture necessary to support these operations are shown in FIG. 2.

In FIG. 2 there is shown a general block diagram of the generic network node architecture which might be found in all of the network nodes 11 of FIG. 1. The network node control circuits of FIG. 2 comprise a high speed packet switching fabric 33, such as a bus, onto which packets arriving at the node are entered. Such packets arrive over transmission links from other network nodes of the network, such as links L1-5 of FIG. 1, via transmission adapters 34, 35, and 36, respectively, or via transmission lines 200 or 201 and connected end nodes 30 and 31 from other networks (e.g., LANs). Packets can also be received over transmission line 202 from direct connect users i.e., link-adjacent nodes (EN 5-7) in FIG. 1. Note that the elements shown in FIG. 2 above the dashed line are not in the network 10 at all, but are located in the domains 15-17 of user facilities connected to the network nodes like that of FIG. 2. These connections in FIG. 2 are illustrative of the various resources shown in the network nodes 11 of the network 10 of FIG. 1.

Switching fabric 33, under the control of connection management facilities 44, connects each of the incoming data packets to the appropriate one of the outgoing transmission link adapters 34-36, or to the appropriate one of the LAN or direct access i.e., link adjacent end nodes 30, 31, 42, all in accordance with well known packet network operations. Moreover, network management control messages are also launched on, and received from, the network nodes 11 of network 10 (FIG. 1) in the same fashion as data packets. That is, each network packet, data packet or network management control message, transmitted across the network of FIG. 1, can be routed by way of switching fabric 33, as shown in FIG. 2. Connection management facilities 44 relies on the network topology information in network topology data base 45 to calculate packet routes, all as is well known in the prior art. In accordance with the present invention, and as previously discussed, large and complex compound WAN/LAN networks, such as that shown in FIG. 1, typically lack sufficient information in their topology data bases to manage these connections, specifically due to lack of end node location and connectivity information and LAN information which almost certainly would not fit into the topology data base 45. In accordance with the present invention, each network node in the network 10 of FIG. 1 may also include a central directory data base 43, controlled by a central directory server 37, to store additional information about all of the resources in the compound network of FIG. 1. Typically, however, only one of the network nodes in the WAN network acts as a central directory server at any one time. Also found in the generic network node of FIG. 2 is a domain directory data base 39 controlled by a domain directory server 38. The use of blocks 37, 38, 39 and 43 in a particular network node 11 of FIG. 1 depends directly on the services expected to be provided by that network node.

FIG. 3A is a graphical and functional flow chart of the directory services processes which can take place in the central directory services circuits and processes of the prior art. FIG. 3B is a corresponding graphical and functional flow chart of the enhanced directory services processes which can place in the enhanced directory services circuits and processes of the present invention. FIG. 3A will be taken up first.

In FIG. 3A, box 20 represents all of the various central directory services functions which might be performed by the prior art version of central directory server 37 of FIG. 2. These services include such things as the registration of new end node resources 23, 24 and 25 in the central directory data base 43 (FIG. 2), deletion or modification of these entries when appropriate, and searching and retrieving data base entries in response to requests from connection management facilities 44 of in any of the network nodes 21 and 22, corresponding to two of network nodes 11 of FIG. 1. The data base entries are then used to calculate new transmission routes between origin resources and destination identifier (server 139) resources, using the identifiers and possibly other resource characterization information.

Typically, it is desirable to register a newly added resource to the central directory in order to make its whereabouts (its resource identifier) available for future use by other entities in order to calculate routes or provide other services. In the prior art system of FIG. 3A, this is done as follows. Assume, for example, that Logical Unit (LU) resource 27, identified as "NETID3.LU1," is the newly added resource. A newly added resource can be attached to end node 25, as show in FIG. 3A, or may actually be contained inside of end node 25. In either event, when resource 27 is added to the network, functional interconnection 114 is used by end node server 25 to launch a REGISTER RESOURCE message, represented by arrow A, on interconnection 114 to its network node server 22, identified as "NETID1.NN2."

The REGISTER RESOURCE message A, to be described in more detail in connection with FIG. 6, includes information called "directory services control vectors," to be described in more detail in connection with FIG. 5, containing a three-part identification of the resource 27, including the identifier for the resource 27 itself (NETID3.LU1), the end node server 25 (NETID3.EN1), and the network node server 22 (NETID1.NN2) to which end node 25 is connected. These three identifiers are, of course, necessary to fully identify the resource 27 by identifying the particular network node server 22 serving the domain directory data base which can verify the existence of the resource 27. This resource information can also include ancillary data about the resource 27, in information formats called "tail vectors" attached to the REGISTER RESOURCE message. These tail vectors may, for example, comprise Quality of Service specifications which can be used to assist in the calculation of new routes. At registration time, of course, only the resource 27 identifier NETID3.LU1 and the end node identifier NETID3.EN1 are available at end node server 25 for the resource identifier triplet, and the network node identifier portion of the triplet is empty or absent at this time.

In response to the REGISTER RESOURCE message A of FIG. 3A, network node server 22 supplies its identifier (NETID1.NN2) as the third field of the resource 27 triplet identifier, stores the triplet is its own domain data base 39 (FIG. 2), and forwards a new REGISTER RESOURCE message B on to the central directory server 20 via functional connection 111. The contents of message B are used to store the resource identifier triplet in the central directory data base 43 (FIG. 2). This completes the central registration process.

Assume now that Logical Unit 26 wishes to establish a communications session with logical unit 27. End node server 23, which "owns" Logical Unit 26, forwards a LOCATE FIND (FIG. 6) message C on functional connection 112 to its owning network node server 21. Since network node server 21 does not have the requested resource identifier in its domain data base 39 (FIG. 2), network node server 21 checks its topology data base for the presence of a central directory server 20 in the network. Since central directory server 20 is present, server 21 forwards the LOCATE FIND message D on connection 110 to central directory server 20. If, for some reason, the central directory data base 43 (FIG. 2) of central directory server 20 does not contain the LU 27 identifier triplet, central directory server 20 would have to broadcast LOCATE FIND messages to all of the network nodes 11 of the entire network 10 of FIG. 1, a result to be avoided whenever possible.

Assuming that the requested resource (LU 27) identifier is present in the data base 43 (FIG. 2) of the central directory server 20, due to the pre-registration already described, server 20 launches a LOCATE FIND message E on connection 111 to network node server 22, which has been identified in the identifier triplet in the data base of server 20. Network node server 22, in turn, launches a LOCATE FIND message F on connection 114 to end node server 25, serving the sought resource 27. End node server 25 examines its own data base, confirms the existence of resource 27, and initiates a series of LOCATE FOUND messages G, H, and I, containing any "tail vectors" present in the local data base, back through connections 114, 111, and 110 to network node server 21 (the exact same route as the LOCATE FIND messages D, E and F). These tail vectors are not necessarily in the central directory data base, but may be necessary for route calculation by network node server 21. When returned to network node server 21, the connection management facilities 44 (FIG. 2) calculates the route (112-110-111-114) from LU 26 to LU 27, using the tail vectors to select the physical entities to embody this functional route. Network node server 21 then launches a LOCATE FOUND message J on connection 112 to end node server 23 to allow Logical Unit 26 to initiate a communication session on this route.

Note that, while all of the network nodes 11 of the network 10 of FIG. 1 are constrained by syntax convention to have an identical network identifier prefix (NETID1), the identifiers of end nodes 23, 24 and 25, and the Logical Unit resources 26 and 27 can have any arbitrary network identifier prefixes (NETID1, NETID2 and NETID3 in FIG. 3A). That is, end nodes of the network 10 of FIG. 1 can attach to other end nodes, to nodes of other networks, or to named multi-party connection facilities such as LANs (called "connection networks") without regard to the attaching entity's network identifier prefix. The freedom to connect to arbitrarily-named end node results in what are called "casual connections" in the prior art and is deemed to be necessary to allow a given end node to have a unique resource identifier and yet access any one or more different networks at different times, as may be needed. In effect, casual connections allow the creation of implicit network boundaries intersecting any internal link of an existing network that interconnects two nodes with different network identifiers. Although a Logical Unit may also have a different NETID from its owning end node, usually all of the resources attached to or contained in an end node have the same NETID.

All of the functions described in connection with FIG. 3A are available in the prior art. REGISTER RESOURCE and LOCATE FIND messages are allowed to traverse the links between standard network nodes and casually-connected standard end nodes. In accordance with the present invention, and as will be described in connection with FIG. 3B, the enhanced directory services of the invention uses this interconnection capability of the prior art to attach not only a single end node, but also an entire directory services domain (15, 16 or 17 of FIG. 1), not possible in the prior art. As will be apparent, this enhanced capability will allow all of the existing prior art directory services to be used efficiently not only with prior art networks connecting to foreign networks (different NETIDs), but also with the new, large, compound WAN/LAN networks, possibly APPN networks.

Referring more particularly to FIG. 3B, there is shown a graphical and functional flow chart of the enhanced directory services of the present invention. Note that FIG. 3B is identical to FIG. 3A in boxes 20, 21, 22, 23, 25, 26 and 27, and functional connections 110, 111, 112, 114, 116 and 117. That is, the enhanced processes of the present invention take advantage of and use all of the capabilities described in connection with FIG. 3A and already available in the prior art. Moreover, these capabilities are available from the prior art apparatus and processes, and require no directed network retrofitting. Indeed, the enhanced services of the present invention depend on the availability of these prior art services to extend the connectivity of network node servers to foreign networks, WAN or LAN, and permit efficient directory services even in large complex networks such as that illustrated in FIG. 1.

FIG. 3B differs from FIG. 3A only in the attachment of an entire network domain 300 to network node server 21 via functional connection 113. In accordance with the present invention, the contents of the resource triplet in the REGISTER RESOURCE messages launched in FIG. 3B are deliberately corrupted to make all of the resources contained in domain 300 appear to reside at the point of attachment, end node server 24. Because of this deception, all of the other entities in the network illustrated in FIG. 3B act as if any resource in domain 300 is at end node server 24. The prior art directory services in the network will therefore send REGISTER RESOURCE, LOCATE FIND, LOCATE FOUND, and all other messages intended for any resource in domain 300, to end node server 24. In accordance with the present invention, end node server 24 is equipped to relay these messages appropriately within domain 300. The ultimate result of this corruption of resource identifier triplets is to make the prior art central directory resource registration services in one network available in a different network. The prior art arrangements are simply not capable of providing this capability. As a measure of the value of this capability, this enhanced central resource registration can eliminate up to (n-1) * m directory services broadcast searches, where n is the number of network nodes in the entire network, and m is the number of resources to which connections are to be established. The efficiency of large, compound networks is enormously improved by this capability.

An appropriate corruption of resource identifier triplets can be accomplished in several ways. One preferred technique is as follows. Assume that resource 303, in domain 300, is the newly added resource. In accordance with one embodiment of the present invention, end node 302 creates a resource identifier triplet "NETID2.LU1-NETID2.EN3-[null]" (100c, 100b, 100a) for resource 303, leaving the network node control point portion of the triplet blank or empty since this information is not yet available. End node server 302 launches a REGISTER RESOURCE message A, routed onto ring LAN 13 and through connection 118, to reach end node 24 containing the partial resource identifier triplet. End node server 24 receives the REGISTER RESOURCE message A and stores the partial triplet identifier in its data base as the identifier of the added resource 303, along with any information necessary to route messages between resource 302 and end node server 24.

In accordance with the present invention, end node server 24 then deliberately corrupts the resource identifier triplet by placing its own identifier (NETID2.EN1) in the end node identifier field 100b of the resource identifier triplet for resource 303, replacing the NETID2.EN3 identifier previously there. End node server 24 then launches REGISTER RESOURCE message B on connection 113, containing the corrupted resource identifier triplet. Message B flows to network node server 21, which adds its identifier (NETID1.NN 1) in the heretofore empty portion 100c of the triplet identifier and stores this corrupt identifier triplet in its own local directory data base. Using only the prior art directory services, network node server 21 then launches a REGISTER RESOURCE message C on connection 110 to central directory services server 20, containing the corrupted resource identifier triplet. Since this corruption is undetectable to central server 20, or any other network nodes 11 of network 10, this corrupted identifier triplet becomes the centrally stored identifier for resource 303. The corrupted resource identifier can thereafter be used by the network processes to provide directory services to the network. All messages aimed at resource 303 will be sent to end node server 24 which is equipped to forward these messages to resource 303 itself, thus effectively extending these services to any or all resources in domain 300.

If the new resource is actually itself an End Node Control Point (ENCP) such as end node 302, the end node server 302 will launch a REGISTER RESOURCE message A identifying itself as the new resource (identifier=NETID2.EN3-NETID2.EN3-[null](100c, 100b, 100a)). Note the identical resource and owning end node identifiers. When end node server 24 receives this REGISTER RESOURCE message A, server 24 stores this triplet in its own end node data base, along with the routing information necessary to forward messages to end node server 302. End node server 24, as before, corrupts the resource triplet identifier by adding its own identifier (NETID2.EN1) in the end node (100b) portion of the triplet, previously "NETID2.EN3," and leaving the network node identifier portion empty or blank. Network node server 21 inserts its identifier NETID1.NN1 (100a), stores this corrupt triplet identifier in its own data base and launches REGISTER RESOURCE message C on functional connection 110, with the corrupt resource identifier triplet and any attached tail vectors, to central directory server 20. REGISTER RESOURCE message C is thereafter treated as any other registration message, taking advantage of all of the existing directory services facilities available in prior art server 20. All calls for resource 302 are directed to end node server 24 which, in turn, assures delivery to resource 302, all as described in connection with resource 303.

Still referring to FIG. 3B, if central data base server 20 thereafter receives a LOCATE FIND message such as from a network node for the identification of a desired destination resource previously registered to central directory server 20, the requested resource identification triplet identifier is retrieved from the central directory data base and used to forward a LOCATE FIND message back toward the destination network node identified in the stored triplet in order to confirm the identification in the central directory data base. As previously noted, the first encountered directory data base (network node 21 or network node 22 in FIG. 3B), replies to the LOCATE FIND message with a LOCATE FOUND confirmation message, based on the corrupt but matching resource identifier triplet in its own data base. This LOCATE FOUND message is then forwarded back to the originating network node requesting the found resource. The confirmed address can then be used by the requesting network node to compute physical routes between the originating resource and the desired destination identifier (server 139) resource.

The directory services flow chart of FIG. 3B can, of course, be used for many other directory services. An end node server 23, for example, may desire to locate resource 303 for the purpose of establishing a connection between LU 26 and resource 303. End node server 23 launches a LOCATE FIND message on functional connection 112 including a control vector identifying resource 303. As noted in connection with FIG. 3A, most searches (LOCATE FIND messages) require that the message be transmitted all of the way to the destination network node server or central directory server to retrieve the desired information. In accordance with APPN networks based on Baratz 4,914,571, the network node directory data bases contain all of the resource identifier triplets in their own domain. If the resource identifier sought by the LOCATE FIND message is present in the first encountered network node domain directory data base (network node server 21) due to previous registration, it can be used to confirm the identifier. That is, the corrupt but matching entry in the domain level directory data base is used to send a LOCATE FIND message for confirmation and tail vectors directly to the destination resource network node server, and the result placed in a LOCATE FOUND message returned to the requesting node without ever visiting central directory server 20.

In FIGS. 4, 5 and 6 there are shown graphical representations of generic General Data Stream (GDS) formats which implement the various messages which must be created and assembled in order to carry out the present invention. The GDS formats shown in FIGS. 4-6 are not, themselves, any part of this invention, and indeed, are disclosed in J. P Gray U.S. Pat. No. 4,914,571, granted Apr. 3, 1990. Only the prior art GDS formats which might be used to implement this invention are shown in FIGS. 4-6.

In FIG. 4, for example, there is shown a graphical representation of the generic GDS format, having fields 51, 52 and 53. Field 51 is used to store a byte-count representing the length of the variable 50, all as taught in the above-identified Gray reference. Similarly, field 52 contains an identifier of the type or kind of variable 50. Finally, field 53 contains the data to be transmitted in format 50, the operative management message information, or message information.

The generic GDS control vector format 54 at the bottom of FIG. 4 similarly includes three fields 55, 56 and 57. Field 55 contains the length of the control vector, field 56 contains a key identifying the kind of control vector, and field 57 contains the substantive control vectors information. Three control vectors used heavily in the present invention is the resource identifier triplet illustrated in FIG. 5.

In FIG. 5 there is shown a generic GDS format for the resource identifier triplets referred to in the above descriptions. Thus triplet 101 comprises three control vectors 100a, 100b and 100c. Each of vectors 100a-c, in turn, contains a control vector length field 58a-c, identifying the resource type as network node, end node, or user resource, respectively, a control vector key 59a-c, respectively, and information field 60a-c, respectively. The information fields 60a-c, of course, contain the three identifiers of the resource identification as previously described. Field 60a, for example, contains the identifier of the network node server serving that resource, field 60b contains the identifier for the end node server connected to or including that resource, and field 60c contains the identifier for the user resource itself. These identifiers form the triplet which will be used extensively in implementing the present invention, as will be described hereinafter.

In FIG. 6 there are shown prior art GDS formats for four messages which might be used to implement the present invention, as well as to implement the prior art directory services described with respect to FIG. 3A. The messages of FIG. 6 are not a comprehensive set which would be necessary to operate the network of FIG. 1, but only those necessary to provide the enhanced central directory services which form a part of the present invention. In FIG. 6, REGISTER RESOURCE message 61 is used to register resources as described above. In message 61, the first of three fields, field 62 contains a byte-count of the length of message 61. Field 63 of FIG. 5 contains the message identifier of message 61, and field 64 contains the necessary directory services resource vectors of FIG. 5. The three other messages of FIG. 6 (DELETE RESOURCE message 65, LOCATE FIND message 69, and LOCATE FOUND message 73) each includes fields similar to message 61, one difference being the message identifier fields 67, 71, and 75, each identifying the corresponding message. The message formats of FIG. 6 can also contain other fields taught by the prior art for other purposes not taught here, and which form no part of the present invention.

In FIG. 7, there is shown a formal flow chart of the process for registering resources found in different topology subnetworks (domains or LANs) in accordance with the present invention. In FIG. 7, box 80 represents the start of such a process for registering resources. The next box in FIG. 7, box 93, initiates the function of registering a new resource in the network 10 of FIG. 1. Box 81 is the end node server to which the new resource is attached or where the new resource resides. An end node directory data base 89 is connected to end node server 81 and is used to support the server 81 by storing resource identification triplets similar to those illustrated in FIG. 5.

When stimulated by the output of 93, end node server 81 launches a REGISTER RESOURCE message 85, identifying the new resource, to domain directory server 82. A domain directory data base 90 supports the server functions performed by server 82, including the storing resource identification triplets similar to FIG. 5. When message 85 reaches server 82, server 82 searches data base 90 for the resource identification triplet in the REGISTER RESOURCE message 85. If this resource identification in not found in data base 90, it is then registered in data base 90. In response to message 85 node 82 launches a new REGISTER RESOURCE message, modified in accordance with the present invention, containing the identifying triplet from message 85, to a network directory server 83, supported by network directory data base 91. Network server 83 can be a central directory network node, if directly connected to the domain server 83, or the first (or all) of the network nodes in the path to the central directory serving the network in which the central directory resides. In either case, the REGISTER RESOURCE message 86 or the REGISTER RESOURCE message 87 eventually arrives at the central directory server 84, supported by the central directory data base 92. If the resource identification contained in message 86 or message 87 is not already present in data base 92, it is now registered in data base 92. The cross network resource registration procedure of FIG. 7 then terminates in box 88. The central directory server 84 then can send a registration confirmation message launched back along the path of the REGISTER RESOURCE message confirming these registrations to the node initiating the RESISTER RESOURCE message.

In FIG. 8 there is shown a process like the process of FIG. 7 but used to locate resources already stored in the central directory data base. Starting at start box 120, box 124 is entered where, for example, a new physical route is to be calculated between two different resources in two different topology domains of the network of FIG. 1, an originating resource and a destination resource. The originating resource of the desired route, specified by box 124, is connected to or included in originating end node associated with end node server box 121. That is, the origin source address supplied by box 121 includes the address of end node server 121. Box 121 first inspects its local data base 129 for the address of the destination identifier resource supplied by box 124. Not finding the destination identifier in data base 129, box 121 launches a LOCATE FIND message 125 (message 69, FIG. 6) containing the identifier of the destination in a control vector (like vector 54 of FIG. 4), but absent the other two destination vectors of the destination triplet identifier. Note that originating resource triplet identifiers can be used in the network of FIG. 1 for other purposes than routing. For example, such triplet identifiers can also be used for user access control, not disclosed here and no part of the present invention, but forming part of the prior art.

When LOCATE FIND message 125 reaches domain directory server 122, server 122 inspects its domain directory data base 130, looking for the destination identifier triplet. If the destination resource address triplet is found in data base 130, and the destination resource is in server 122's domain, domain directory server will send a LOCATE FOUND message 178 back to end node server 121 without consulting any other nodes. Assuming that the destination identifier resource address triplet is not found in data base 130, however, domain server 122 corrupts the received origin resource identifier triplet by substituting its own identifier in place of the identifier of the real owning end node control point, corresponding to end node server 121 of FIG. 8. Domain directory server 122 then caches the corrupted origin identifier triplet in data base 130 and forwards a new LOCATE FIND message 126 to the next adjacent network node directory server 123, including the corrupted origin identifier triplet and the incomplete destination triplet. The network node associated with network node server 123 may itself contain the central directory services data base for all of network 10 (FIG. 1), or network node server 123 may simply be in the first network node on the route to the central directory services node. In FIG. 8, the latter architecture is assumed, where the route to the centralized directory (server 133) is only a single network node away, i.e., the node corresponding to directory server 123.

Network node server 123 likewise inspects its own data base 128, looking for the destination resource address triplet. Were this destination address triplet to be found in data base 128, and if the triplet indicated that the destination resided in network node server 123's domain network node server 123 would use this address triplet to launch LOCATE FOUND message 177 back to domain directory server 122 which, in turn, would update its data base 122 and launch a LOCATE FOUND message 178 back to end node server 121 to complete the search confirmation. Assuming that the destination resource address triplet is not found in data base 128, network node directory server 123 inserts its own identifier vector into the network node portion of the origin resource identifier triplet. Server 123 then caches this now completed but corrupted origin resource identifier triplet in its own data base 123 (to permit the satisfaction of subsequent new resource searches) and launches a LOCATE FIND message 127 to central directory server 133, possibly traversing other intermediate network nodes as described above.

At central directory server 133, central directory data base 134 is examined for the destination resource identifier triplet. If this entry is not found in central directory data base 134, central directory server 133 would be required to conduct a broadcast search for the missing resource identifier, and, if not found, return a LOCATE NOT FOUND message which would terminate the route selection procedure. In this broadcast search, a reply from any central directory server terminates searches at all other nodes, thus terminating the broadcast search. This process is not illustrated in FIG. 8 since the process is very similar to a successful search.

Assume, however, that central directory data base 134 already contains the destination resource identifier triplet, due to a previous resource registration completed by FIG. 7. The destination resource identifier triplet found in data base 134 is corrupted in accordance with the present invention and as described in connection with FIG. 7, identifying domain directory server 137, connected to network node directory server 135, instead of the destination resource's true address at destination node server 139 (end node 81). In response to the complete but corrupted destination triplet, central directory server 133 updates central directory data base 134 with the origin identifier triplet from the LOCATE FIND message 127. Server 133 then launches LOCATE FIND message 131, containing the completed but corrupted origin identifier triplets to network node directory server 135. When LOCATE FIND message 131 reaches network node server 135, server 135 queries its data base 136 for the destination resource identifier. Finding the destination resource identifier in data base 136 due to a previous registration process, server 135 stores the corrupted origin triplet in data base 136 and then consults the instructions in data base 136 concerning identifier verifications. If the LOCATE FIND messages 125, 126, 127 and 131 contain a "Verification Required" flag, or if destination server 137 had previously provided an "Always Search Me" flag in data base 136, server 135 launches a LOCATE FIND message 132 to domain directory server 137.

When LOCATE FIND message 132 reaches server 137, server 137 consults memory 138 for the destination resource identifier triplet. This identifier triplet is found due to its previous registration. Included with this identifier triplet, of course, is the routing information indicating that the destination resource is not actually connected to or included in server 137, and the routing information necessary to actually reach end node server 139, where the destination resource actually does reside. Domain server 137 also consults its own data base 138 to see if a verification search must be forwarded to the actual destination end node server 139. If so, domain directory server 137 forwards LOCATE FIND message 140 to end node server 139 which, in turn, consults its data base 141, confirms the presence of the destination resource, and launches LOCATE FOUND message 173 back to domain server 137. Whether destination end node verification is required or not, domain server 137 launches a LOCATE FOUND message 174 back to network node server 135. Server 135 relays the LOCATE FOUND as message 175 back along the path traversed by the LOCATE FIND messages 125, 126, 127, and 131 in the form of LOCATE FOUND messages 175, 176, 177 and 178, respectively. Each server along the way (133, 123 122 and 121) stores the verified destination resource identifier triplet in its respective data base. Recall that destination domain server 137 has substituted its own address for that of destination server 139, so that all of the data bases in the system have the same complete but corrupted destination resource identifier triplet. This ensures that all future searches will get the proper value regardless of which data base is used to satisfy the search.

When LOCATE FOUND message 176 reaches network node server 123, server 123 is able to use the verified destination address triplet and the verified origin address triplet, along with tail vectors obtained by the search and other data stored in its copy 181 of the network topology data base (45 in FIG. 2), to compute the route from the apparent (but corrupted) origin resource to the apparent (but corrupted) destination resource. The apparent (but corrupted) resource locations include all of the connectivity information necessary to actually complete the physical route. The apparent origin server may also include Quality of Service requirements which must be observed for each leg of the, calculated physical route. When the physical route is fully calculated in server 123, server 123 returns the LOCATE FOUND message 177, together with the newly computed physical route, to server 122 and thence, via LOCATE FOUND message 178, to end node server 121. This verified physical route is delivered to box 180 where this physical route is used, by way of a connection request message, to initiate communication sessions with the destination resource attached to server 139. This route can, of course, be modified, immediately or in the future, and used for various purposes for reasons present in the prior art and forming no part of the present invention. The process of FIG. 8 terminates in end box 142.

The processes illustrated in detail in FIGS. 7 and 8, and in a general way in FIG. 3, can be implemented by special purpose circuits designed to perform all of the functions described with respect to the various directory servers. Since it is normally faster and less expensive to program these processes on a computer, the preferred embodiment of this invention is believed to be such programmed implementations. The writing of these programs by an experienced network function programmer is believed to be obvious in view the figures of this application together with the above extremely detailed description of those figures. In addition, other detailed implementations of the general principles of this invention are likewise believed to obvious to the programmer of ordinary skill. The GDS format of the various messages describe herein are only illustrative and other formats, suitable for other networks, could readily be used by a programmer of ordinary skill without departing from the spirit and scope of this invention.