 |
Claims  |
|
|
What is claimed is:
1. A method for a querying node to obtain configuration information from a
plurality of nodes, said querying node and said plurality of nodes being
connected to a network, said method comprising the steps of:
requesting that said plurality of nodes send configuration information to
said querying node;
receiving said configuration information from nodes which respond to said
requesting step;
determining from said configuration information which of said plurality of
nodes are capable of communicating with said querying node; and
creating a connection list based on said determining step, said connection
list comprising connection information about each of said nodes that
responded to said querying node and that am capable of communicating with
said querying node.
2. The method of claim 1 wherein said requesting step further comprises the
step of:
sending query information to said plurality of nodes, said query
information comprising a network address of said querying node.
3. The method of claim 2 wherein said sending step further comprises the
step of:
sending a private query message to said plurality of nodes.
4. The method of claim 1 wherein said creating step further comprises the
steps of:
selecting a target node from said connection list; and
establishing a connection between said querying node and said target node
via a path, said connection being established along said path by utilizing
said connection information contained in said connection list.
5. The method of claim 4 wherein said establishing step further comprises
the step of:
choosing an alternate path to said target node from said connection list,
said alternate path being an alternate to said path; and
connecting said querying node to said target node via said alternate path.
6. A method for an informer node to inform a plurality of nodes about said
informer node, said informer node and said plurality of nodes being
connected to a network, said method comprising the steps of:
assembling informer node configuration information, said informer node
configuration information comprising location, capability, and protocol
information about said informer node; and
sending said informer node configuration information to said plurality of
nodes.
7. The method of claim 6 wherein said assembling step comprises the step of
creating a public query message and wherein said sending step comprises
the step of sending said public query message to said plurality of nodes.
8. The method of claim 6 wherein said sending step comprises the steps of:
selecting a subset of said plurality of nodes through the use of said
informer node configuration information, said informer node configuration
information being contained in a first connection list: and
sending said informer node configuration information to said subset of said
plurality of nodes.
9. The method of claim 8 wherein said sending step of claim 8 further
comprises the steps of:
requesting that said plurality of nodes each send their respective
configuration information to said informer node;
receiving said respective configuration information from all of said
plurality of nodes which replied to said informer node;
building a list of nodes based on said respective configuration
information, said list of nodes being a second connection list, said
second connection list comprising at least part of said respective
connection information about each of said nodes that replied to said
informer node.
10. A method for a node to obtain and supply configuration information
from/to other nodes, said node and said other nodes being connected to a
network, said method comprising the steps of:
obtaining respective configuration information about each of said other
nodes by:
requesting that said other nodes each send said respective configuration
information to said node;
receiving said respective configuration information from nodes which
responded to said node;
determining from said respective configuration information which of said
other nodes are capable of communicating with said node; and
creating a connection list of nodes based on said determining step, said
connection list comprising at least part of said respective configuration
information about each of said other nodes which responded to said node
and that are capable of communicating with said node;
supplying node specific configuration information by:
assembling said node specific configuration information, said node specific
configuration information comprising location, capability, and protocol
information about said node; and
sending said node specific configuration information to said other nodes.
11. A method for a node to respond to requests for configuration
information, said method comprising the steps of:
receiving at said node a request for configuration from a querying node;
determining whether said node should respond to said request based on a
security list; and
responding to said request when the outcome of said determining step
indicates that a response is appropriate.
12. A querying node, said querying node comprising means for obtaining
configuration information from a plurality of nodes, said querying node
and said plurality of nodes being connected to a network, said querying
node further comprising:
means for requesting that said plurality of nodes send configuration
information to said querying node;
means for receiving said configuration information from nodes which respond
to said querying node:
means for determining from said configuration information which of said
plurality of nodes are capable of communicating with said querying node;
and
means for creating a connection list, said connection list comprising
connection information about each of said plurality of nodes that
responded to said querying node and that are capable of communicating with
said querying node.
13. The querying node of claim 12 wherein said means for requesting further
comprises:
means for sending query information to said plurality of nodes, said query
information comprising a network address of said querying node.
14. The querying node of claim 13 wherein said means for sending further
comprises:
means for sending a private query message to said plurality of nodes.
15. The querying node of claim 12 wherein said means for creating further
comprises:
means for selecting a target node from said connection list; and
means for establishing a connection between said querying node and said
target node via a path, said connection being established along said path
by utilizing said connection information contained in said connection
list.
16. The apparatus querying node of claim 15 wherein said means for
establishing further comprises:
means for choosing an alternate path to said target node from said
connection list, said alternate path being alternate to said path; and
means for connecting said querying node to said target node via said
alternate path.
17. An informer node, said informer node comprising means for informing a
plurality of nodes about said informer node, said informer node and said
plurality of nodes being connected to a network, said informer node
further comprising:
means for assembling informer node configuration information, said informer
node configuration information comprising location, capability, and
protocol information about said informer node; and
means for sending said informer node configuration information to said
plurality of nodes.
18. The informer node of claim 17 wherein said means for assembling
comprises means for creating a public query message and wherein said means
for sending comprises means for sending said public query message to said
plurality of nodes.
19. The informer node of claim 17 wherein said means for sending comprises:
means for selecting a subset of said plurality of nodes through the use of
said informer node configuration information, said informer node
configuration information being contained in a first connection list; and
means for sending said informer node configuration information to said
subset of said plurality of nodes.
20. The informer node of claim 19 wherein said means for sending of claim
19 further comprises:
means for requesting that said plurality of nodes each send their
respective configuration information to said informer node;
means for receiving said respective configuration information from all of
said plurality of nodes which replied to said informer node;
means for building a list of nodes based on said respective configuration
information, said list of nodes being a second connection list, said
second connection list comprising at least part of said respective
connection information about each of said nodes that replied to said
informer node.
21. A node, said node comprising means for obtaining and supplying
configuration information from/to other nodes, said node and said other
nodes being connected to a network, said node further comprising:
means for obtaining respective configuration information about each of said
other nodes, said means for obtaining said respective configuration
information comprising:
means for requesting that each of said other nodes send said respective
configuration information to said node;
means for receiving said respective configuration information from nodes
which responded to said node;
means for determining from said respective configuration information which
of said other nodes are capable of communicating with said node; and
means for creating a connection list of nodes based on said means for
determining, said connection list comprising at least part of said
respective connection information about each of said nodes which responded
to said node and that are capable of communicating with said node;
means for supplying node specific configuration information, said means for
supplying said node specific configuration information comprising:
means for assembling said node specific configuration information, said
node specific configuration information comprising location, capability,
and protocol information about said node; and
means for sending said node specific configuration information to said
other nodes.
22. A node, said node comprising means for responding to requests for
configuration information, said node further comprising:
means for receiving at said node a request for configuration information
from a querying node;
means for determining whether said node should respond to said request
based on a security list; and
means for responding to said request when the outcome of said determining
step indicates that a response is appropriate. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
FIELD OF THE INVENTION
This invention relates to the data processing field. More specifically,
this invention relates to a mechanism and protocol for providing
configuration information to the nodes of a network.
BACKGROUND OF THE INVENTION
The computer systems of the past usually included a single mainframe
computer and several non-programmable terminals. After a non-programmable
terminal was connected to the mainframe computer, it was rarely moved.
Therefore, even though the amount of effort necessary to connect the two
devices was often significant, the task was not thought to be overly
burdensome since it was seldom performed.
Unlike the computer systems of the past, modern day computer systems often
involve a complex network of computers. The computer systems of modern day
computer networks come in many different shapes and sizes. Large mainframe
computers can be linked with other mainframe computers and/or smaller
mid-sized computers. Similarly, mid-sized computers, usually called
mid-range computers or minicomputers, can themselves be combined to form a
computer network. Unlike their predecessors, the terminals of today--are
powerful personal computers (also known as programmable workstations)
which are also full function computer systems. Since the modern day
terminal is a self-contained computer system, the distinction between
network components which are considered computers and those which are
considered terminals has become blurred. For this reason, the different
entities that make up a computer network are now called nodes.
A variety of high level network protocols have been developed to allow the
individual nodes of a computer network to communicate with one another.
Examples of these high level protocols include: Advanced Program to
Program Communications (APPC), Transmission Control Protocol/Internet
Protocol (TCP/IP), Open Systems Interconnection (OSI), Network Basic
Input/Output System (NETBIOS), and Digital Equipment Corporation's
"DecNet." However, inherent in every network protocol is the need for
individual nodes--be "configured" with sufficient information to
communicate with other nodes in the network. Configuration information can
be broken out into three categories: location information, negotiation
information, and capability information. Location information is used to
address a particular node in much the same way as postal addresses are
used to specify a particular residence or business. Negotiation
information is the network protocol used by a particular node or nodes. In
some sense, protocols are--analogous to the various languages and dialects
used by human beings. Understanding what protocol is to be used allows the
nodes of a network to "speak the same language." Capability information is
used to inform individual users of which nodes perform which function or
functions
Without configuration information, the addition of a new node to a network
is, in some sense, meaningless. Stated another way, the new node cannot be
of benefit to the network and the network cannot be of benefit to the new
node if the new node and the network cannot communicate. Hence, the
absence of this information means that end users are unable to fully
utilize the very network resources which were put in place to benefit
them. It is easy to see that this is an important concern for network
users--and owners a like.
Maintaining this configuration information is a difficult task. Large
computer networks are often made up of several smaller networks (called
sub-networks) which themselves may include a significant number of nodes.
The problem is exacerbated when one remembers that even minor changes to
the network may require a significant amount of work. For example,
whenever a node changes system parameters or becomes accessible through an
additional path, reconfiguration of the entire network may be required to
ensure that all the nodes of the network discover the new configuration
information for the changed node. Conventional solutions to this problem
are rigid, time consuming, and usually involve a large amount of human
interaction. Whenever a change to the network is required, technicians
manually configure (or reconfigure) each node of the network to include
the updated configuration information.
An automated solution to a related problem is IBM's Remote Program Load
(RPL) protocol for Token-Ring Networks. RPL is used on networks to boot
medialess Personal Computers (PC). When a medialess PC that is running RPL
is initially connected to a network, it requests location information from
any node which can supply it with a boot program. Included in this request
is location information about the medialess PC (hereafter medialess node).
The medialess node need not know the whereabouts of any of these "loading"
nodes because it simply sends out a "broadcast message" requesting that
any node that is capable of supplying a boot program respond with location
information. When a loading node receives the request, it responds with
its own location information. The medialess node then accepts the first
response and proceeds to use the loading node's location information to
request that the subject loading node provide it with a boot program. The
loading node responds by sending the requested boot program to the
medialess node. This accomplished, the medialess node then boots itself
with the newly acquired boot program.
Although RPL is sufficient to provide medialess nodes with boot programs,
it does not solve the complex configuration problem inherent in today's
computer networks. The configuration information provided by RPL includes
only location, and in some sense, capability information about one other
node. Further, once the medialess node is fully loaded and running, it
discards even this minor amount of information. With regard to other nodes
of the network, RPL only provides location information about the medialess
node to the loading node. RPL does not provide the loading node, nor the
other nodes, with configuration about one another. With regard to
capability information, RPL provides nothing more than location
information about a particular node that can provide a boot program.
SUMMARY OF THE INVENTION
It is a principle object of this invention to provide an enhanced method
and apparatus for supplying configuration information to the nodes of a
network without having to manually configure each node.
It is another object of this invention to provide an enhanced method and
apparatus for informing the nodes of a network of the presence of a new
node.
It is yet another object of this invention to provide all enhanced method
and apparatus for informing the nodes of a network of a change to an
existing node.
It is still another object of this invention to provide an enhanced method
and apparatus for providing alternate path information to the nodes of a
network.
These and other objects are accomplished by the automatic configuration
mechanism (ACM) and query protocol disclosed herein.
A mechanism for monitoring and responding to the changes of a local area
network (LAN) is disclosed. The ACM of the present invention is initiated
as part of the normal "startup" of a network node. Once initialized, the
ACM has three functions. First, nodes use the ACM to obtain configuration
information from other nodes. Second, nodes use the ACM to provide
configuration information to the other nodes of the network. Lastly, nodes
use the ACM to respond to other nodes which seek configuration
information.
To obtain configuration information from other nodes, the ACM of a
"querying node" dispatches private query messages. A private query message
can be directed to a specific node or nodes, or to the network as a whole.
Private query messages include the querying node's address and address
information for target nodes (i.e., those nodes to which the message is to
be sent). The querying node's address allows target nodes to respond with
the requested configuration information, while the target address
information allows the network to ensure that the correct nodes have
access to the message. A node which is located on a remote sub-network
will receive as many private query messages as there are connections
(called bridges) between the sub-networks.
When a node receives a private query message, the node may use a security
list to determine whether a reply is in order. Security lists contain node
identification information for other nodes which are secure with respect
to the subject node. In other words, the subject node may determine that a
reply is inappropriate if the querying node is not identified in the
subject node's security list. If the node that receives the query message
does elect to respond, it dispatches a response message. Included--in the
response message is the requested configuration information (i.e.
location, connection, and capability information).
When the querying node receives response messages from the other nodes, it
uses the configuration information contained therein to create or update a
connection list. Since nodes located on remote sub-networks reply with one
response message for every private query message, the connection list may
have more than one entry (i.e., one for each path) for a particular node
or nodes. Included in the connection list is all location, negotiation,
and capability information for each of the nodes that responded. The
connection list is then used by the querying node to establish connections
with other nodes of the network.
When a node is added to the network, an "informer node" uses the ACM to
supply configuration information to the other nodes of the network. To
accomplish this task, the ACM dispatches public query messages which,
unlike the private query messages, can only be directed to the network as
a whole. As with the private query messages, public query messages include
the address of the informer node and target address information. Also
included in the public query message is configuration information about
the informer node. Included within the configuration information is
location, negotiation, and capability information about the informer node.
As with the private query message, a target node which is located on a
remote sub-network will receive as many public query messages as there are
bridges connecting the sub-networks.
When a node receives a public query message, the node uses the
configuration information contained in the message to update its
connection list to include the new node's location, negotiation, and
capability information.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of the local area network of the present
invention.
FIG. 2 is a block diagram of two systems (or nodes) of the present
invention.
FIG. 3 is a message flow diagram of how a querying node can obtain
configuration information from the other nodes of the network.
FIG. 4 is a block diagram of the format of the private query message.
FIG. 5 is a block diagram of the format of the response message.
FIG. 6 is a message flow diagram of how an informer node can provide
configuration information to the other nodes of the network.
FIG. 7 is the format of the public query message.
FIG. 8A is a logic flow diagram of the ACMs.
FIG. 8B is the format of the connection list.
FIG. 8C is the format of the path list.
FIG. 8D is the format of the security list.
DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 is a topographical view of the network of the preferred embodiment.
Network 100 is a local area network (LAN). Network 100 comprises token
ring networks 105, 110, and 115 connected by bridges 130, 145, and 150.
Although network 100 comprises three token ring sub-networks, it should be
understood that the present invention applies equally to any network which
may have any number of sub-networks which themselves may have any number
of nodes. It should be further understood that although the preferred
embodiment uses the IBM Token Ring protocol, any low level protocol could
be used. Examples of other possible low level protocols include: ethernet,
token bus, FDDI, and wireless LAN.
Token ring 105 is connected to token ring 110 by single bridge 130;
whereas, token ring 110 is connected to token ring 115 via redundant
bridges 145 and 150. Redundant bridges are often incorporated into LANs to
improve fault tolerance or to accommodate different transmission
requirements (e.g., transmission speed and frame size). Connected to token
ring 105 is RS/6000 node 120 and node 125. RS/6000 node 120 is connected
to token ring 105 by token ring interface 122 while node 125 is connected
via redundant token ring interfaces 123 and 124. As with redundant
bridges, redundant token ring interfaces appear in LANs to improve fault
tolerance or to accommodate different transmission requirements. Token
rings 110 and 115 are similarly populated. FAX node 135 is redundantly
connected to token ring 110 while PS/2 node 140 is singly connected to
token ring 110. Likewise, AS/400 node 165 and nodes 155 and 160 are singly
connected to token ring 115.
Although the computer systems of the nodes of network 100 are shown as IBM
RS/6000 Personal Workstations, IBM Personal System/2 personal computers,
and AS/400 computers, any device capable of operating as a member of a
connection oriented network could be used. Examples include: other models
of the IBM Personal System/2, the IBM 390 mainframe computer, the SUN
Sparkstation, Digital Equipment's VAX computer systems, Hewlett Packard's
HP 3000, and the Apple Macintosh. Also, nodes of network 100 which do--not
have specific node type designations should be understood to be "any type
of node." In addition to the ability to operate with a variety of node
types, the present invention is also applicable to networks which support
a plurality of different high level network protocols. The high level
network protocols used in the preferred embodiment are the APPC and TCP/IP
network protocols; however, any high level network protocol could be used.
FIG. 2 shows an exploded, block diagram view of AS/400 node 165 and FAX
server node 135. Beginning with AS/400 node 165, AS/400 midrange computer
207 is shown to be connected to programmable workstation 205 via user
interface 217 and to network 100 via non-redundant network interface 163.
Although only programmable workstation 205 is shown to be connected to
AS/400 midrange computer 207, it is well known in the art that a plurality
of workstations can be connected to a single computer system.
AS/400--computer 207 is also shown to contain central processing unit 222
and storage 255. Storage 255 is shown to contain ACM 245, connection
manager 244, security list 252, application programs 225, protocol handler
247, and connection list 250.
ACM 245 is used by AS/400 node 165 to obtain configuration information from
the other nodes of network 100 and/or to provide the other nodes of
network 100 with configuration information. Connection manager 244 uses
the configuration information of AS/400 node 165 to establish connections
with other nodes. Application programs 225 are higher level programs which
may from time to time request that a particular connection to another node
be made or that a particular service, such as the sending of a FAX or the
printing of a document, be performed. Many other services are easily
envisioned by those skilled in the art. Protocol handler 247 is used by
AS/400 node 165 to support various network protocols. Although the network
protocols used in the preferred embodiment are APPC and TCP/IP, it should
be understood that the present invention applies equally to any network
protocol. Connection list 250 is used as a repository for the
configuration information of AS/400 node 165. Security list 252 is used
by--ACM 245 to determine whether AS/400 node 165 should respond to a query
request.
PS/2 personal computer 212 is shown to be connected to facsimile machine
210 via FAX interface 217 and to network 100 via redundant network
interfaces 136 and 137. FIG. 2 has been drafted in this manner to point
out that the present invention applies equally to fault tolerant nodes
which often incorporate a plurality of redundant network connection
points. Since FAX node 135 is a standalone personal computer as well as a
FAX server, a keyboard and display are also connected to PS/2 computer 212
via a--user interface (not shown). As with AS/400 computer 207, PS/2
computer 212 is shown to contain central processing unit 220 and storage
240. Storage 240 is similarly shown to contain ACM 226, connection manager
230, connection list 235, security list 238, application programs 236, and
protocol handler 237. Since the function of these entities is identical to
those of AS/400 node 165, their details will not be reiterated here.
Facsimile application 233 is used by application programs 236 to handle
facsimile requests from the user of FAX node 135 or from the other nodes
of network 100.
While storage 255 and 240 are shown as monolithic entities, it should be
understood that they may comprise a variety of devices, and that not all
programs and files shown will necessarily be contained in any one device.
For example automatic configuration mechanisms 225 and 226 will typically
be loaded into primary memory to execute, while connection lists 250 and
235 will typically be stored on magnetic or optical storage devices.
FIG. 3 shows a message flow diagram of how a querying node can obtain
configuration information from the other nodes of the network. For the
purposes of explanation, assume that a user of AS/400 node 165 wants to
send a FAX to an external location. Further assume that the connection
list of AS/400 node 165 does not include information about any FAX server
nodes on network 100. Lastly, assume that AS/400 node 165 supports the
APPC and TCP/IP network protocols while FAX node 135 supports only the
APPC--network protocol.
To satisfy its user's request to send a FAX, AS/400 node 165 uses ACM 245
to attempt to obtain configuration information about possible FAX node(s)
on network 100. (For a more thorough description of the ACMs of the
preferred embodiment, refer to FIGS. 8A-D and the accompanying
description.) ACM 245 begins the process by dispatching private query
message (PRQM) 300. FIG. 4 shows the format of the PRQM of the preferred
embodiment. PRQM format 400 comprises media header 405, target node
address 410, querying node address 415, media specific information 420,
logical link control information 435, and media trailer 445. Other than
the message type indication of media header 405 (here, "private query
message"), the information contained in these transmission layer fields
(i.e., media header 405, media trailer 445, and media specific information
420) depends upon the particular LAN protocol used in the preferred
embodiment. The LAN protocol of the preferred embodiment is the IBM Token
Ring protocol; however, any low level protocol could be used.
Target node address 410 and querying node address 415 are the unique LAN
addresses of the respective nodes. If PRQM 300 were to be sent to a single
node, target node address 410 would be the address of that particular
node. However, since AS/400 node 165 requires configuration information
about "any" FAX server node, target address 410 of PRQM 300 will contain a
generic address. A generic address is an address that allows all of the
nodes of network 100 to receive PRQM 300. Routing information 421
of--media specific information 420 comprises frame size field 422, number
of hops field 423 (this field indicates the number of bridges that were
encountered over a particular path), bridge ID field 424, and ring ID
field 425. The contents of these fields are shown to be "xxxxxxxxx." This
should be taken to mean that the fields are empty upon dispatch (i.e., do
not contain meaningful information when the message is sent out). The
significance of this "emptiness" will be explained in forthcoming
paragraphs.
Logical link control information 435 comprises target node type 436,
querying node type 437, target system name 438, and configuration
information 440. Target node type 436 contains the type of node to which
the PRQM is to be directed, while querying node type 437 contains the type
designation of the querying node (i.e., AS/400 midrange computer). In our
FAX example, AS/400 node 165 is not concerned, at least at this point,
with a particular node's type--AS/400 node 165 is only concerned with
whether a particular node has the capability of sending a FAX. Hence, as
with target node address 410, target node type 437 will contain a generic
node type to allow all the nodes of network 100 to receive PRQM 300. Also
included within target node type 437 is a capability request field (not
shown). The capability request is used to indicate what type of capability
is requested. In this example, ACM 245 could use the capability request
field to narrow the scope of the responses desired to only those nodes
which are capable of handling facsimile requests. However, assume for the
purposes of this example that the scope of the request is not narrowed in
this manner. As with target node address 410 and target node type 437,
target system name 438 of PRQM 300 will contain a generic system name to
allow all the nodes of network 100 to receive PRQM 300.
Configuration information 440 comprises capability information 445,
protocol information, 450, and location information 455. The contents of
these fields are shown to be "xxxxxxxxx." This should be taken to mean
that the fields are empty upon dispatch. This absence of information is
what makes a PRQM "private." Without the location, protocol, and
capability information contained in configuration information 440, the
nodes that receive PRQM 300 will be unable to connect to AS/400 node 165.
This "privateness" is by design. AS/400 node 165 wants only to locate and
connect to a FAX server node, there is no need, at least at this point, to
share configuration information with other nodes.
Since the bridges and token ring interfaces of network 100 (shown on FIG.
3) appear as single entities on any given token ring, they each receive an
instance of each message. (Since the function of token ring bridges and
interfaces is well known in the art, their details will not be elaborately
described herein.) Hence, as PRQM 300 propagates through network 100,
redundant bridges and redundant token ring interfaces will cause a
duplication of the message. Each duplication represents a different path
that was taken by the subject message. When a particular bridge receives a
message, it changes, or adds to, routing information 421 of PRQM format
400. As stated above, these fields are empty upon dispatch of the message.
For example, when bridge 150 receives PRQM 300, it changes bridge ID 424
of routing information field 421 to indicate that PRQM 300 passed through
bridge 150 on its way to the particular receiving node. Unlike bridges,
network interfaces do not themselves modify routing information--field
421. Instead, single nodes which are redundantly connected to a token ring
receive multiple copies of each message. This occurs because there is a
unique token ring address associated with each token ring interface.
Although the nodes of the preferred embodiment are shown to include at
most two token ring interfaces, it should be understood that the present
invention applies equally to nodes which have any number of network
interfaces.
Since the nodes of token ring 115 are located on the same node as AS/400
node 165, they will receive only a single instance of PRQM 300. However,
because of redundant bridges 150 and 145, the nodes of token ring 100 will
receive at least two instances of PRQM 300 (shown as PRQM 300A and PRQM
300B). Since bridge 130 and PS/2 node 140 are singly connected to token
ring 110, they will each receive PRQM 300A and PRQM 300B. However, since
FAX node 135 is redundantly connected to token ring 110, it will receive
two copies of PRQM 300A and two copies of PRQM 300B (i.e., one copy for
each token ring interface).
FAX node 135 will use its automatic configuration manager (shown on FIG. 2
as automatic configuration manager 226) to respond to each of the PRQMs it
received. Each PRQM will have an associated response message (shown on
FIG. 3 as response messages 305, 310, 315, and 320). Response messages 305
and 310 are respectively responsive to the PRQMs received on network
interface 136, while response messages 315 and 320 are similarly
responsive to the PRQMs received on network interface 137.
FIG. 5 shows response message format 500. Response message format 500
comprises media header 505, target node address 510, responding node
address 515, media specific information 520, logical link control
information 550, and media trailer 580. As mentioned above, other than the
message type indication of media header 505 (here, "response message"),
the information contained in these transmission layer fields (i.e., media
header 505, media trailer 580, and media specific information 520) depends
upon--the particular LAN protocol used.
Target node address 510 contains the unique LAN address for the target
node. Since each of the response messages are to be sent directly to
AS/400 node 165, target node address 510 (of each of the response
messages) contains the unique LAN address for AS/400 node 165. Responding
node address 515 contains the unique LAN address for the responding node.
Since in our example FAX node 135 is redundantly connected to LAN 110
(i.e., has two different LAN addresses), response messages 305 and 310
will have a--different responding node address than response messages 315
and 320. Routing information 525 of media specific information 520
comprises frame size field 530, number of hops field 535, bridge ID field
540, and ring ID field 545. ACM 226 of FAX node 135 will copy the routing
information of each instance of PRQM 300 into a separate response message.
In our example, PRQM 300A arrived at FAX node 135 via bridge 150, while
PRQM 300B arrived at FAX node 135 via bridge 145. Hence, the response
messages that are responsive to instances of PRQM 300A (i.e., response
messages 305 and 315) will contain the routing information of PRQM 300A.
In contrast, the response messages that are responsive to instances of
PRQM 300B (i.e., response messages 310 and 320) will contain the routing
information of PRQM 300B. These fields, and the responding node address,
comprise the path that a particular instance of PRQM 300 took to get to
FAX node 135. This path information will | | |
