 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Related Patent Applications
U.S. Pat. No. 4,827,411 by A. H. Arrowood et al, issued May 2, 1989, and
entitled "Method of Maintaining a Topology Database" discloses a technique
for maintaining a common database of information distributed at plural
nodes of a network relating to the topology of physical links between
nodes as well as the topology of physical and logical resources at said
nodes.
Copending patent application Ser. No. 062,280 by A. E. Baratz et al, filed
June 15, 1987, and entitled "Method for Exchanging Network Control
Information," discloses a technique for facilitating the flow of control
information between nodes in networks capable of distributed control.
2. Field of the Invention
The present invention relates to computer networks. More particularly, it
relates to a method for finding a target resource in a network.
3. Prior Art
Computer networks for processing and transmitting data are well known. A
typical computer network system comprises at least one host computer
running under some type of operating system, communication controllers,
communications media and a plurality of end users (terminals, printers,
displays, etc.). The host computer is connected, via communications media,
to either a communication controller or an end user terminal. The
communication controller interfaces with other communication controllers
or end user terminals via communications media. The communications media
may be telephone lines, channels, satellites, etc. By entering a request
at a user's terminal, the user may extract data from the host computer.
Similarly, a user may enter information on a terminal through which it is
transmitted to a host computer for processing and/or to another terminal
in the network.
Computing systems are controlled by a system architecture that ensures the
orderly flow of information throughout the system. The prior art describes
several types of architectures. For example, an overview of the
architecture used in computer networks is given in an article entitled,
"Computer Network Architecture," by S. Wecker in Computer, September 1979.
Another overview, including a description of System Network Architecture
(SNA) is given in an article entitled, "An Introduction to Network
Architectures and Protocols," by P. E. Green in the IBM Systems Journal,
Vol 18, No. 2, 1979. In these articles, the various computer networks such
as SNA DNA, ARPANET, etc. are described by means of hierarchical
architectural layers, where the lowest layer relates to the physical
communication lines interconnecting various user nodes of the network and
where the highest level concerns the conversation per se between the
various end users of the network.
As networks become more dynamic, the addition and relocation of resources
and end users occur more frequently. New procedures are needed to allow
customer networks to grow and change more easily. Among other things these
procedures must minimize the amount of coordinated system definitions
needed and tolerate errors and race conditions in the network.
An article by Baratz et al entitled: "SNA Networks of Small Systems," IEEE
J. Selected Areas in Communications, Vol. SAC-3, No. 3, May 1985,
addresses the minimization of coordinated system definitions. However, it
does not address adequately the means and methods to accomplish the
minimization.
Further information on SNA terms and concepts can be found in Systems
Network Architecture Technical Overview, IBM Publication GC30-3073-2,
September 1986.
SUMMARY OF THE INVENTION
It is, therefore, an object of our invention to improve the way resources
in a computing network are found.
Another object of our invention is to dynamically find resources in a
network to establish a session between nodes.
It is yet another object to provide this improvement in a way that
minimizes the network operator's efforts.
These and other objects are achieved by means of a method, termed a LOCATE
search, which dynamically locates resources (e.g., logical units (LUs) and
transaction programs and files contained in LUs) in the network so that an
LU-LU session can be established between the origin LU and the destination
LU of the search.
In our preferred embodiment, an end node first searches its local resources
(those that reside in it). (An end node is a node at the edge of the
network that uses, but does not provide, network services). If the
resource (destination) is not found, the end node sends a search request
to its network (server) node. (A network node is an intermediate node in
the network that provides network services to components in itself and in
end nodes attached to it.) (Alternatively, the search may be instituted
initially at the network node.) The server node searches its directory of
domain resources first (those resources that reside in the server node
doing the search and in those resources known by the server node to reside
in the end nodes served by it). If the resource is not its domain
directory, the server node performing the search checks resources of other
network nodes that are known. By the word "known" we mean that a resource
is listed in any of the directories of a node. If the resource is known to
be in another node, a directed search is sent to the node believed to
contain the requested resource. If the resource is not known or is not
found with the directed search, the server broadcasts to end nodes in its
domain that have indicated that they may be searched for resources of the
requested type. If the resource is not located in the server's domain and
a central directory exists in the network, then the request is forwarded
to a central directory using a directed search. If a central directory
does not exist or if the node is unable to route to a directed search to a
central directory because of link outages, a broadcast search is
performed. If the resource is not found by the broadcast and the network
ID of the resource indicates a network other than the present network, the
request is forwarded with a directed search to a gateway node, if one
exists.
Our invention also includes novel messages which flow in the network to
perform the search requests and replies.
A principal advantage of our invention is that the user need only define
the local resources at a node. Other nodes in the network acquire, (by
directed or broadcast search), information concerning a resource as they
require it.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of the physical components of a computer network.
FIG. 2 shows the standard format for the SNA basic link unit and the
standard format for a general data stream (GDS) variable in SNA.
FIG. 3 shows the formats for a search request, successful search reply and
an unsuccessful search reply, respectively, all in accordance with our
invention.
FIG. 4 shows the format for the LOCATE GDS variable base as well as the
formats for a directed search request, a broadcast search request, and a
failed search reply of the LOCATE procedure, all in accordance with our
invention.
FIG. 5 shows the format for the GDS variable FIND RESOURCE as well as the
formats for the search argument control vectors and the caching control
vectors contained in FIND RESOURCE, all in accordance with our invention.
FIG. 6 shows a format for the GDS variable FOUND RESOURCE in accordance
with our invention.
FIGS. 7A-7D shows formats for the control vectors termed Associated
Resource Entry, Directory Entry, Search Argument Associated Resource FIND,
and Search Argument Directory FIND in accordance with our invention.
FIG. 8 shows the format for a Search Scope Control Vector in accordance
with our invention.
FIG. 9 shows the format for a Fully Qualified Procedure Correlation
Identifier (FQPCID) Control Vector.
FIG. 10 shows the format for a Route Selection Control Vector as used in a
directed search.
FIG. 11 shows the format for a Network Control Vector.
FIG. 12 shows the format for an Extended Sense Date Control Vector.
FIGS. 13 and 14A-14D are flow charts of a computer program illustrating the
operation of our invention.
FIGS. 15A-15E are a flow chart of a computer program illustrating other
aspects of our invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Our invention is a general method to locate resources that are in a
computer network. The use of our invention is not restricted to any
specific type of computer network. It works well with the IBM SNA
architecture and will be described in that environment.
An overview of methods for dynamically locating resources is given in the
article entitled "SNA Networks of Small Systems" by Baratz et al in the
IEEE J. Selected Areas in Communications, Vol. SAC-3, No. 3, May 1985.
This article is incorporated herein by reference. However, this
description in terms of SNA systems should not be construed as a
limitation on the scope of our invention, as it is within the capabilities
of one skilled in the computing art to use the invention in other types of
networks.
There are two types of nodes in a system which can utilize the invention:
network nodes (NNs) and end nodes (ENs). An NN provides session
establishment, directory services and session traffic routing services to
other nodes for its own Logical Units (LUs) and for LUs in lower function
nodes, ENs.
Each node, EN or NN, is responsible for maintaining a directory of its
local resources. In addition, each NN is responsible for maintaining
directory information about resources that reside in ENs served by it.
This is done by system definition (sysdef), either of all of the resource
names or of the EN's status as an authorized node that is allowed to
dynamically inform its serving NN of its resources. Such as NN is termed a
server, and the combination of a server NN and the ENs it serves is termed
a domain.
All nodes communicate via control-point-to-control-point (CP-CP) sessions.
An network node has two CP-CP sessions with each physically adjacent
network node. Each session can be characterized as a one-way pipe over
which very short transactions flow; each of the two sessions between
adjacent network nodes carries traffic in one direction only. Thus, CP-CP
communication between network nodes can be thought of as a full-duplex
connection. Upon link activation, each network node attempts to set up a
CP-CP session with the node at the other end of the link if it is a
network node. CP-CP sessions between network nodes always begin with a
CP-Capabilities exchange. There is also a CP-CP session established
between an end node and the network node that serves it. This is described
fully in copending application Ser. No. 062,290 by Baratz et al.
The directory search procedure is a part of the directory services
component of an network node. Its function is to find the location of the
target resource of a session request. The resource locations are dynamic.
The ability of the directory search procedure to find the current location
of a requested resource enables session services to direct its session
establishment flows (BINDs) and decreases the occurrence of failed session
establishment requests.
FIG. 1 is a representation of a typical network in which the LOCATE method
is preferably used to find the location of a target resource. Block 50 is
a sub-network which includes a set of network nodes, abbreviated as NN,
another set of End Nodes, abbreviated as EN, and a central directory, CD.
Each of these nodes contain one or more network addressable units (NAUs). A
NAU represents an entity to the network and allows traffic to be routed to
it. A logical unit (LU) is a user NAU through which an end user accesses
the network. Each EN and NN typically supports one or more LUs. In
addition, each EN and NN contains a control point (CP) that provides
control functions such as LU-LU session initiation and termination. CPs
communicate with each other via CP-CP sessions.
Typically, each EN and NN is also provided with associated application
programs, I/O devices and data bases (not shown), which are contained in
its associated LUs. The LUs of ENs and NNs, such as 230 and 310 or 120 and
4, communicate over a logical connection called a "session."
Multiple sessions can also be established between two LUs, as is well known
in the prior art. A session is established when one LU sends another an
SNA request known as the "BIND" which specifies the protocols that both
partners agree to abide by for the duration of the session. The "BIND"
sender and receiver are known respectively as the primary LU (PLU) and
secondary LU(SLU).
A more detailed description relative to session establishment, etc. can be
found in the "IBM Systems Network Architecture Format & Protocol Reference
Manual: Architecture Logic" (SC30-3112).
A network may have one or more central directory (CD) nodes. These are
network nodes which provide a large cache of directory entries and may be
used by other nodes to find resources that have already been located by
other requesters.
Connections between sub-networks are accomplished via Gateway NNs. In FIG.
1, Gateway NN 8 connects sub-networks 50 and 51.
Each node CP maintains directory information about resources in the node.
That information includes the resource name, type, and, for non-LU
resources, the LU associated with the resource. The composite of all of
the directories of local resources provides a distributed network
directory.
In addition to the local resource directory, there are three kinds of
directory entries in an NN: its own domain resources, cross-domain
resources, and cross-network resources. All directory entries contain the
CP name at which the resource is located; for resources other than LUs,
the directory entry also contains the LU associated with the resource.
Entries for cross-domain resources additionally contain the network node
control point (NNCP) that provides directory and session services for that
control point and entries for cross-network resources further contain the
NNCP providing gateway network node (GNN) services for sessions between
the origin LU and the destination resource.
These entries may be accumulated in several ways: by system definition
input; by retaining the results of earlier successful searches (caching)
and by searching the topology database for a CP name match.
Cache entries, whether added dynamically or at system definition, are only
to direct the subsequent LOCATE. If the LOCATE search fails or if the
search succeeds, but the BIND fails because the resource is not found
(e.g., the resource moved or failed in the window between receipt of the
LOCATE and receipt of the BIND), then the erroneous cache entry is
deleted. As necessary, a "least recently used" algorithm may be applied to
dynamically added cache entries to make room for new entries. This type of
algorithm is well known in the art and forms no part of our invention.
LOCATE PROCEDURE
The objective of the LOCATE procedure is to locate resources (e.g., LUs,
transaction programs or files) in the network so that a session can be
established between the originator and the LU which is the target of the
search (also referred to as the destination node or destination). The
location of a resource is defined to be the owning CP of that resource. A
route to the location of the destination resource can be computed by route
selection services. Session services then uses the path computed by route
selection services to route its session establishment request (BIND).
If an EN initiates the search, it searches its own resources first and, if
the resource is not found, forwards the request to its server NN.
The structure of the LOCATE procedure in an NN is to search and local
resources first (those that reside in the node doing the search and in
those known to reside in end nodes served by it). If the resource is not a
local one, the node performing the search checks known resources of other
network nodes. These resources may be known to the searching node because
they were cached from an earlier search or because the resource being
sought is an LU that also is a CP and therefore is in the topology
database. In either case, a search is sent to the node believed to contain
the target resource. This is known as a "directed" search. If the resource
is not known or the directed search fails, the end nodes attached to the
NN that are capable of receiving a LOCATE for the resource type of the
target resource are searched.
If the resource is not known locally, then the request is forwarded to a CD
in the form of a directed search if one exists. If a CD does not exist, a
broadcast search is performed. The broadcast search, then, is used only if
the location of the resource cannot be found by other means. If the
broadcast search fails and the resource name indicates that the resource
is in another network, a directed search is sent to a gateway node, if one
exists.
BROADCAST SEARCH
The broadcast search floods the network with requests for the location of
the target (requested) resource. As the requests flow through the network,
they dynamically build a spanning tree of the intermediate routing
network. Upon receiving a request, a node sends the request to all of its
neighboring nodes, except the one that it came from (referred to as the
parent or uptree node), over the CP-CP sessions. Any neighboring node that
has already seen this request immediately returns a negative reply because
it is already part of the spanning tree and will report the results of its
search to its parent, or uptree node. In many cases, adjacent nodes will
send out the search request to each other such that they cross during
transmission; the receipt of a request from a neighboring node to which a
request has already been sent is equivalent to a negative reply.
Any neighboring node that has not yet seen the request searches its local
resource directory and all end nodes that it serves that will accept
requests for resources of the type requested. The neighboring node also
propagates the request to each of its neighboring nodes regardless of
whether the local search is successful or not.
There are three reasons for continuing the search even when the resource is
found. The first is to guarantee expeditious termination of the search.
The second is to assure that only a single response is returned for each
copy of the resource. Third, this procedure allows all copies of a
resource to be found, which can be useful for situations that require
checking the uniqueness of a resource or where the "closest" of a generic
resource is sought.
An intermediate node creates a control block for the pending search,
indicating the nodes to which it sent the search request (referred to as
the children or downtree nodes), and does not consider the search complete
until a reply has been received from each of its children. A node does not
clean up this control block until the search is complete; at that time a
final reply is returned up the tree and the control block is discarded. If
a node receives a reply to a search that it does not recognize, it
discards the reply, and takes no further action.
Only network nodes participate in a broadcast search; a network node will
query the end nodes that it serves that will accept LOCATE messages; but
those end nodes do not in turn propagate the broadcast search to other end
nodes or to network nodes to which they are connected. An end node will
return either a positive or negative reply only to its serving network
node.
Each search procedure carries a unique identifier called a fully-qualified
procedure correlation identifier (FQPCID), assigned by the originating
node. This unique FQPCID is used by a node to correlate a search reply
with a search request and to recognize duplicate requests. Since the
directory broadcast search method depends on the ability of a parent node
to correlate a request with a reply, it is important that the FQPCID be
unique in the network. In order to assure uniqueness, when a node
originates a directory search, it generates a procedure correlation
identifier (PCID) that is locally unique--that is, it does not duplicate
any other PCID generated by the node. The node then adds to the front of
this PCID its control point (CP) name, which yields a FQPCID. Since CP
names are unique within a network, each FQPCID is unique in the network.
When a node receives a search reply from a child node, it uses the FQPCID
and the CP name of the replying node to mark an entry in the pending
search table of the appropriate control block. If the reply is positive
(i.e., contains the location of the requested resource), the node forwards
the reply up the tree immediately with an indicator that the search has
not completed at that node. When all the children of a node have replied,
the node sends a reply that indicates "search complete" to its parent.
Once the search of its subtree is complete, a node discards any knowledge
of the search. A search can be completed under several error or race
conditions since a negative reply is implied by any of the following
conditions:
1. a search reply received with the same FQPCID as the search request,
indicating search complete but with no location information;
2. a search request received with the same FQPCID as the request sent on
the same link; or
3. a failure in the CP-CP session across which the search request was sent.
The reply indicating "search complete" causes the parent node to mark one
entry in the appropriate control block. The directory procedure ensures
that when the search completes at a given node, knowledge of the search
has been discarded by all nodes downtree in the search spanning tree.
Hence, when the search has completed at the origin, there should be no
network resources wasted by search control blocks still waiting for
replies.
The search is successful (although it may not be complete) when a positive
reply is received; the search has failed when negative replies have been
received for all search requests sent by the origin of the search.
SEARCH FAILURES
When a search fails, the LOCATE reply carries a sense code value indicating
the cause of the failure. Some failures are retryable while others are
not. When a broadcast has been sent, multiple replies will be received,
several of which may be negative. In our preferred embodiment, the search
must be classified as one failure type only. The sense code values are
hierarchically related in that once a negative reply is received with a
higher failure type than the previous type, the search failure is promoted
to the new higher type. Thus, at any given time the search origin retains
only one sense code for a given search. This sense code determines whether
or not the search is retryable.
TERMINATION OF SEARCHES
There are no timing considerations in the directory searches. The
procedures are set up in such a way that nodes wait for certain
information to be received before sending their replies. This waiting is
asynchronous to network events. In the directory search procedures a link
outage and an adjacent node failure are treated as a negative reply. If
the following conditions are met, the search is guaranteed to terminate
regardless of whether or not there is a CP-CP session outage along the
search path.
1. Before sending a LOCATE search request to another node, a node checks
that there are CP-CP sessions with the adjacent node that enable the node
to receive the request and return a reply. If these sessions do not exist,
a request is not sent. Since a node waits for a search reply from a
partner to which a request has been sent, it is essential that the sending
node know if the partner either cannot receive the search or cannot send a
reply. Thus, the CP-CP session connectivity needed for sending and
receiving is checked.
2. A node must retain knowledge of a search request it has sent until its
entire subtree completes (i.e., it receives replies from every node to
which it sent the search). When a broadcast is sent, a control block is
built listing the adjacent nodes at that time. If, while the broadcast is
completing, a new link to the origin node comes up, it is recognized (via
the control block) that this link was not included in the search, and
therefore no reply is expected from that new adjacent node. Optionally,
the node may forward the search down this new subtree in which case this
link would be added to the control block.
3. A CP-CP session outage with an adjacent node is treated as a negative
reply.
4. In broadcast search, crossing searches with the same correlator are
treated at each side as a negative reply. For example, if server 1 sends a
search request to server 2 and then receives the same search from server
2, server 1 considers that as a negative reply to its request and does not
send a reply. Server 2 does the same.
5. If a node receives the same request that it is currently processing, and
this is not a node that it has sent a search request to (as opposed to #4
above), it returns a negative reply and discards this new request; it does
not start a new search procedure. For example, server 2 is processing the
request from server 0 when it receives the same request from server 1.
Server 2 will send a negative reply to server 1, discard that request, and
continue processing the request from server 0.
6. If there is a CP-CP session outage along the path of a directed search,
nodes on either side of the outage send a negative reply to their
respective endpoints.
7. If, at some time, a node receives a reply for a search procedure that it
does not recognize, this reply is discarded and no reply is sent by this
node.
DEADLOCK DETECTION FOR BROADCAST SEARCHES
Because broadcast searches require the reservation of control blocks to
retain information about broadcasts in progress, deadlocks can occur when
nodes run out of storage for these control blocks. The following explains
how a network node recognizes when a deadlock might occur and performs
recovery procedures to guarantee that it does not occur. Instead of using
a flow control mechanism (which is the explicit granting of permission to
send data) to prevent deadlock, this approach reduces the overhead of
messages requesting and granting permission to send data. This tradeoff is
beneficial if the frequency of deadlocks and hence the average cost of the
subsequent recovery are small.
The directory services component in a network node has a number of LOCATE
control blocks and has one LOCATE receive buffer per partner node. A
LOCATE control block is the storage used by a node to receive and process
a directory search request, including the space to remember the replies
from the requests it propagated "downstream" in a broadcast search. A
LOCATE receive buffer is used to hold a LOCATE request when sufficient
storage is not available to create a LOCATE control block. This buffer
enables a node that is out of LOCATE control blocks to at least return a
negative reply (indicating the node does not have storage to process the
request) to a received LOCATE request thus allowing the requestor to
continue with its processing. Since directory requests can be initiated
from any node in the network, there is the possibility for two partner
nodes (i.e., nodes connected via a CP-CP session) (e.g., NN1 and NN5 in
FIG. 1) to send each other directory requests for different objects. If
each node is running low on storage, there is the potential for the two
nodes to become deadlocked when the LOCATE requests are exchanged
simultaneously using the remaining storage in each node and leaving no
room for either node to receive the reply to its request. Now each node is
waiting for the other to return a reply that would enable it to free up
the storage for that request.
The following situation can potentially cause a deadlock. If the directory
services component has used all its LOCATE control blocks, then receives
one request which fills up its LOCATE receive buffer and then receives
enough requests to fill up the session pacing buffers the node will be
forced to drop its receive pacing count to zero. (Pacing is described in
publication GC30-3073-2, referenced earlier.) If a node detects that it is
out of LOCATE control blocks and its LOCATE receive buffer is full, and
its send and receive pacing counts across the sessions upon which it sent
the last request are zero, the node assumes that the adjacent node is in
the same situation and that they are deadlocked. This is a conservative
scheme for deadlock detection: the LOCATE control block pool is shared
amongst all partner nodes so replies from other partner nodes (that are
not deadlocked) could eventually free control blocks removing the storage
shortage at each deadlocked partner.
For an example of a deadlock situation, consider the two nodes of FIG. 1,
NN1 and NN5. Each has two LOCATE control blocks and one LOCATE receive
buffer. Table I illustrates a situation where deadlock can occur. In this
example, NN1 sends two requests to NN5; these requests (1 and 3) are
received by NN5 after NN5 sends two requests (2 and 4) to NN1. When NN1
sends the requests, it uses up its two LOCATE control blocks. When NN1
receives request 2 from NN5, it stores the request in its LOCATE receive
buffer since there are no remaining LOCATE control blocks. NN1 prepares to
return a negative reply to request 2. Now NN1 receives request 4 which
fills its last session pacing buffer. The session pacing buffer cannot be
emptied into the LOCATE receive buffer since that buffer is full. NN1
cannot free buffers and its receive pacing count on that session is zero.
Meanwhile, NN5 is in a similar situation. Requests 2 and 4 filled NN5's
two LOCATE control buffers; receiving request 1 filled NN5's LOCATE
receive buffer; receiving request 3 filled the last session buffer and NN5
cannot free buffers to increase its receive pacing count from zero. Each
node would like to return a negative reply to the request it has in its
LOCATE receive buffer thus freeing up that buffer (and possibly the
corresponding control block on the other node), but neither can send
because neither has any send pacing count. Nodes NN1 and NN5 are in
deadlock. Each is in the situation where all LOCATE control blocks are
full, the LOCATE receive buffer is full, and the receive and send pacing
counts across the CP-CP sessions to the partner sending the request in the
LOCATE buffer are zero. The same situation arises no matter how one
changes the actual values for the number of control blocks in each node,
the number of receive buffers reserved per CP-CP session, or the initial
pacing counts.
TABLE I
______________________________________
##STR1##
______________________________________
The solution to the deadlock problem is for each node to UNBIND (i.e.,
disconnect) the CP-CP session across which it received the LOCATE request
that it could not process. Unbinding the session has two beneficial
effects. The node that detected the deadlock will throw away this latest
LOCATE thus freeing its LOCATE receive buffer. Also, the clean-up
processing invoked when a session fails may cause some other LOCATE
control blocks to be cleaned up. This would happen if another search
request for a different target resource had been sent to that partner but
a reply has not been received. When the CP-CP session is disconnected, an
implicit negative reply is assumed to have been received. A negative reply
will be entered into the control block, and if this is the last
outstanding reply for that downtree search, a final reply will be sent to
the parent node for the search and the control block will be freed. On the
other side of the CP-CP session, the same cleanup will occur, and one or
more of its LOCATE control blocks could be freed.
Deadlock detection is also described hereinbelow with respect to FIG. 15.
DIRECTED SEARCHES
Directed searches may be sent by the NNCP of the origin LU, a CD or a
gateway node. They are sent by the NNCP to the cached destination CP, to a
CD, or to a gateway node.
The NNCP of the origin LU routes the LOCATE on the best path to the
destination CP. A route selection control vector is computed that
indicates the concatenation of CP-CP sessions that are traversed. The
route selection control vector (RSCV) describes the concatenation of
sessions between control points instead of specific transmission groups as
is done on a BIND and is used to route the directed search. For example,
if in FIG. 1, NN1 wishes to send a directed search to NN3, it might select
a route of NN1-NN4-NN3 and build an RSCV that indicates a path NN4-NN3.
Each NN along the path, after determining that it is not the destination
NN, forwards the directed LOCATE to the next NNCP in the RSCV (e.g., NN4
in the above example); intermediate NNs (those NNs along the path that are
not the destination node) do not search their directories (either local or
cross-domain) for the search argument upon receipt of directed LOCATEs. In
the event that an intermediate network node control point is unable to
route the directed LOCATE as indicated, a negative reply LOCATE(discard)
is returned.
The destination CP searches its domain resources directory for the search
argument resource. If the resource is not in the domain directory, the CP
will search end nodes capable of receiving LOCATES for this resource type.
If the resource has still not been located, a negative reply is returned.
Directed Searches are also described hereinbelow with respect to FIG. 15.
FORMATS
FIG. 2 illustrates the format of the SNA basic link unit (BLU) and of a
general data stream (GDS) variable. As illustrated, the GDS is contained
in the request/response unit (RU) of the BLU. An RU may contain multiple
GDS variables. Further details concerning the SNA BLU may be found in the
IBM manual, "Systems Network Architecture Format and Protocol Reference
Manual: Architecture Logic", No. SC30-3112, Chapter 2. Details concerning
the GDS variable may be found in the IBM manual, "Systems Network
Architecture Format and Protocol Reference Manual: Architecture Logic for
LU6.2", NO. SC30-3269, Appendix 1. Both of these manuals are hereby
incorporated by reference.
As shown in FIG. 2, the BLU comprises a data link control (DLC) header, a
transmission header (TH), a request/response header (RH), a
request/response unit (RU) and a DLC trailer. The GDS variable comprises a
GDS header, which is the combination of length (LL) and identifier (ID)
followed by data or information.
As is well known, the BLU fields are concatenated and transmit information
through the network. The BLU, when encoded according to the teachings of
our invention, is a LOCATE message. In particular, we have invented new
GDS variables which are encoded in the RU of the BLU for practicing our
invention. The directory searches, in accordance with our invention, use
the GDS variables as a means of communication. It should be noted that the
order of GDS variables or control vectors within a GDS variable is
arbitrary except where a given order is explicitly stated. For simplicity,
we have shown a single order throughout the remainder of the
specification.
GENERAL LOCATE FORMATS
The LOCATE message is the flow that nodes exchange in an effort to locate
the destination resource. FIG. 2 illustrates the general format for the
LOCATE message. LOCATE message is a short-hand term for a message that
contains either a LOCATE GDS Variable and FIND RESOURCE GDS Variable for a
search request or a LOCATE GDS Variable and a FOUND RESOURCE GDS Variable
for a search reply when the resource has been located (successful search
reply). When a resource is not found (unsuccessful search reply), the
negative reply contains only a LOCATE GDS variable. The order of the GDS
variables in these flows is unimportant. LOCATE GDS Variable contains
information to control the delivery of the search messages in the network.
FIND RESOURCE and FOUND RESOURCE GDS Variables contain information used in
the directories: data about origin resources that should be cached by the
destination and resource type and name being requested (referred to as the
"Search Argument") are in the former, and located resource information is
in the latter. The located resource information is also cached at the NNCP
(originating LU or OLU). A significant feature of the LOCATE message is
that it is independent of other functions which may be performed by other
GDS variables that accompany during the searching process, such as
initiating a "BIND", notification of the availability of the resource,
etc. The length of a LOCATE message (including any other GDS variables
that might be included) is limited to 1000 bytes in our embodiment.
LOCATE X'12C4') GDS VARIABLE FORMAT
Turning now to FIG. 4, LOCATE (X'12C4') is used to transport the required
information between directory servers in the network's distributed
directory and from EN to its serving NN. It has the following format:
Bytes 0-1: Length (in bytes), in binary, of the GDS Variable including the
Length field.
Bytes 2-3: LOCATE GDS Variable key: X'12C4'.
Byte 4, bit 0: The Procedure Status Indicator is used to signal the end of
the procedure. This Indicator is reset on the last reply to a LOCATE
search to indicate that the directory service procedure is completed. The
procedure may complete normally when replies are received for all
outstanding requests; it may complete abnormally when a CP-CP session
outage causes the procedure chain to be broken. In our preferred
embodiment, bit value 0 indicates "discard" and bit value 1 indicates
"keep." The use of the Procedure Status Indicator will be more fully
discussed hereinafter.
Byte 4, bits 1-2 | | |
