JPH0450780B2 - - Google Patents

Description

[Detailed description of the invention]

A. INDUSTRIAL APPLICATIONS The present invention relates to communication networks, and more particularly, to networks in which the path or route taken by a message is dynamically calculated, i.e., between two users of the network. It relates to a network in which a new path is determined each time a communication session is established. B. Prior Art and its Problems A communication network is a network that enables computers, communication control devices, related peripheral devices, and "end users" at remote locations within the network to establish and maintain information communications. Refers to the arrangement of links. Here, an end user is a person who handles a terminal device (hereinafter also referred to as a terminal), an application program running on a host computer, or an intelligent device controller (i.e., a workstation, a personal computer, display control device, etc.). FIG. 1 shows a small communications network 10. FIG. There, two IBM®
System 370 host computers 12, 14 and three IBM 3725 communication controllers 16, 18,
20 are interconnected to support five terminals 22, 24, 26, 28, 30 connected as shown. Communication links 32, 34, 36,
38, 40, 44 interconnect the computers 12, 14 and the communication control devices 16, 18, 20 as shown. Communication between, for example, terminal 30 and host computer 12 in FIG. 1 can take several different paths. In order to visualize communications in a network, a convention has been adopted according to which computers and communication controllers in a network are collectively called nodes, and connections between nodes are called links. End user devices, whether displays or printers, are collectively referred to as terminals. FIG. 2 is a node-link diagram of the network 10 in FIG.
Similar elements in the figures have the same reference numerals (but with primes) as in FIG. 1. Although the terminal is not shown in the figure, this is because the terminal is not directly involved in the communication establishment and control processing related to the present invention. A conversation (referred to as a session) between an end user at terminal 30 of FIG. 1 and an application program on host computer 12.
are nodes 12 and 18, i.e. 1 in FIG.
It means communication between 2' and 18'. Several different paths are possible for such a session. For example, communication may simply be via link 34', or may be a path including links 32', 40', and node 16'. or links 32', 36', 38' and nodes 16', 1
It may be a path including 4'. The range of choices increases with the size and complexity of the network. Except in very limited environments where the network is fully connected, the information entered at the base node (supporting one end user)
via one or more intermediate nodes (at the other end)
support the user) to reach the destination node. Information sent by one node to another must pass through the links that interconnect the nodes. In some networks, all information transmitted between two end users during a particular communication session traverses the same path (in that case called a route). The mechanism for generating routes (hereinafter referred to as the route mechanism) depends on the particular network architecture. Most network routing mechanisms use a routing table at each (source, intermediate, or destination) node to route messages to the next node. Although there are various routing mechanisms,
Some use a routing table index (either a route identifier or a combination of source or destination node identifiers) to determine which outbound link and therefore which neighboring network node should be next. Specify whether to send a message. Naturally, once a message arrives at the destination node, it is not sent to another intermediate node. Instead, processing is done by the end user. The routing table for each network node can be established statically or dynamically. In the static case, the routing definitions are fixed when the network operation is started. Static mechanisms are not relevant to the present invention and will not be discussed. Dynamic routing uses route creation techniques to dynamically create an end-to-end route from a source node to a destination node that can be used during a particular communication session. This end-to-end route remains defined and active until all sessions using it are completed. The route can then be removed, freeing network resources, such as routing table entries, to be used for other dynamically generated routes. Several methods can be used to generate dynamic routes within a network. One method uses a topology database containing the identities of all the physical nodes and links of the network, including connectivity, status, and physical characteristics for dynamically building routes. According to this method, appropriate nodes and links are selected based on the memorized situation, and a message containing a list of nodes and links to be used in the route (hereinafter referred to as a route setup message) is generated. be done. The route setup message passes through each node in the list, allowing each node to build an entry in its routing table. As a result, subsequent messages for sessions assigned to the route can pass through the same physical node identified in the route setup. Both forward and backward pointers are placed in the node's routing table. Routing in communication networks is
()IBM Systems Journal, Vol.22, No.4
(1983) “SNA Routing: Past, Present,
and Possible Future”, () IEEE
Transactions on Communications, Vol.COM
−29, No. 4 (1981) “Routing and Flow
Control in TYMNET”, and () IEEE
Transactions on Communications, Vol.COM
−28, No. 5, (1980) “The New Routing
``Algorithm for the ARPANET''.Clearly important is the
The base has current information about available nodes and links for communication. Otherwise, an attempt may be made to generate a route that includes unavailable nodes or links, and then by the time a usable route is actually found,
A situation may arise in which route generation must be attempted several times. This represents an unnecessary waste of network resources. In addition to manual input by operators, the initial status, failure, and reactivation of network nodes and links (hereinafter referred to as network elements) can be determined by broadcasting status changes by neighboring nodes. There have been reports of. The above-mentioned papers () and () describe an update method using such broadcast communication. Status updates via broadcast communication have the advantage of not requiring operator intervention. However, this has the problem of significantly increasing network overhead traffic, especially in large and complex networks. In some situations, it is preferable to accept a rather less complete knowledge of the network situation in order to reduce this overhead. In fact, in such networks it is necessary to have some mechanism for ``killing'' broadcast messages that are disseminated throughout the system or otherwise echo forever within the network. Typical mechanisms include integration of cutoff times. Note that after the cutoff time, the message is discarded from the network. However, even with such a limiting mechanism, status update messages occupy a large portion of the overall message processing capacity of the network, reducing the available capacity for user messages. Therefore, it is clear that updating topology databases in a dynamic routing environment places significantly less demand on the message processing capacity of the network than traditional schemes for updating topology databases. A method is needed. C. Means for Solving the Problems The present invention provides for establishing communication paths between nodes in a data transmission network including a plurality of network elements consisting of message sending/receiving nodes and communication links interconnecting said nodes. A method for collecting data regarding the availability of network elements, comprising: (a) storing data about network elements potentially available for communication in a storage element associated with each node attempting to establish a communication path; (b) using the stored data to select a communication path of selected elements interconnecting the originating node with another node of the network; and (c) establishing the path. (d) if all selected elements are available for communication, establish said path; and (e) if unavailability of a network element in said path causes said path to be established during or after establishment of said path. generating data regarding the unavailability of the element at the node in response to the detection at the node included in the path, and transmitting the data via the network elements included in the path to the origin node and storing it in its storage element. It is characterized in that it is used when selecting a communication path later. As a result, the present invention significantly reduces overall status message traffic even in complex communication networks, since only the specific elements involved in the use of the failed element are informed of the status of that element. be able to. D Overview of Embodiments The feedback mechanism of the present invention is based on topology.
A method and apparatus are provided that can be used to dynamically inform a database of the status of network nodes and links. As a result, it is possible to know the status of the physical route elements and efficiently generate route setup messages. For example, the following description as a node is
It is applicable to an IBM SNA network consisting of an IBM System 370 computer and an IBM 3725 communications controller, and appropriate communications links for network interconnection. However, the principles and protocols are presented generally enough to rely on one or more topology databases for route generation and on each node's local routing table for establishing and maintaining communication sessions. It can be applied to any communication network with dynamic routing. In the preferred embodiment, each topology data
The base is first given information about all nodes and links and their alternating connectivity with neighboring nodes. This information is entered via traditional input statements, either interactively or by batch definition. Link and node statements specify defined characteristics such as line (link) transmission speed, node buffer size, and component data transmission security. These are used by end users to request routes. The properties will be explained later in the rules for operation, definitions, and status. Additionally, each network element in the topology database is initially
It can be marked as ``tentatively active,'' or available for use. This initial situation is independent of the actual situation of the corresponding element, but the selection of the element for a route setup attempt by route selection techniques, and the actual active state of the element using the feedback mechanism of the present invention. (operational) or inactive status. The information is conventionally stored for scanning and comparison when a route request is received. This information is entered for (1) routes, (2) links, and (3) nodes. Thus, assuming an interactive input method (as opposed to batch), route statements are used to enter information that defines the route between two nodes that are allowed to communicate. The statement specifies the root links and nodes in order and an identifier (ID) for the root. For each pair of nodes that may communicate, as many route statements may be entered as there are distinct routes between those nodes. FIG. 3 shows the topology data for potential routes between nodes 16' and 14' in FIG.
Indicates base entry. In this case, 50,5
There can be three routes: 2,54. Fourth
The figure shows the format of root statement 58. Link name and node name60
are arranged in the order that a message traverses the route, starting from the origin node and ending at the destination node. Statement type 62 identifies the statement as a root statement. Figures 5 and 6 illustrate link statements 64 and node statements 66, respectively. It identifies the element and contains data for the characteristics described above. Various fields 68, 70
It is shown. statement type 72,
74 identifies the statement as a link statement or a node statement, respectively. Information entered via route, link, and node statements is conventionally stored for use in scanning and comparison when a route request is received. As a result, all identified routes between the specified end nodes are first explored, and then the characteristics of the elements in the selected routes are matched to find the best one for the specified characteristics. . In this way,
The best route is selected. When an end user desires to communicate with another end user, a request for a session is made to a control program residing at the base node. The session request includes the names of the source and destination nodes supporting the end user and the name of the class of service. A service class is a conventional shorthand for selecting a set of such characteristics for a route. In the preferred embodiment, the session request information is sent in the form of a message (hereinafter referred to as a route request message) to the nearest available topology database for route selection. FIG. 7 shows a route request message 76. This includes a request code 78 that identifies the message as a route request, a base node name 79, a destination node name 80,
and service class name 82. Upon receiving a route request message, the topology database selects potential routes whose included elements conform to the characteristics identified in the specified service class. If a route with exactly the same set of elements is already used with the same characteristics, the session is assigned to the already created route. If a route has not been generated, the topology database is scanned and the best route between the source and destination nodes is selected based on matching the characteristics of the actual elements to the requested characteristics. In this process,
assumed to be active. Or only known nodes and links may be selected. The selected route is marked with a unique identifier for the route (root
A message containing a list of nodes and links that make up the route (hereinafter referred to as route ID) as well as a list of nodes and links that make up the route
It is written in the form of a setup message (called a setup message). FIG. 8 shows a route setup message 84. Request code 86 identifies the message as a root setup message. Route ID 87 identifies the route.
Node and link names 88 appear in the order in which the message traverses the route, as in route statement 58 of FIG. 4 above. The root element is initially assumed to be active.
This is because the status of each network element is unknown when the topology database is activated. Rather than initially obtaining the status of each element defined in the topology database through operator input, exchange with other databases, or interrogation of each network element.
As in the preferred embodiment of the present invention, the situation is known when a session is requested. As route setup messages traverse the network, each active node conventionally generates routing table entries for communication in both directions. That is, when a route setup message is processed, an entry is made in the routing table. Its contents are the route ID (including the origin and destination node names or addresses) and the outgoing link address. As is known, this allows rapid routing of the message thereafter via the route ID accompanying the message. When a message arrives with this information, a table is simply scanned to generate enough outbound link addresses to send the message. In other embodiments, the root ID is reduced to a single local path identifier (LPID) at each node. An LPID is assigned to a route when a route setup message arrives. The numbers may be sequentially selected starting from zero. The LPID is entered into the table and sent back to the previous node to be entered into that node's routing table.
Each routing table in this embodiment has an LPID assigned to it by the outgoing link to the next node and the next node of its route. When a message arrives at a node in this embodiment, the LPID for that node is retrieved from the header and used to place a table entry for the session. Subsequently, the LPID of the next node placed in the table is
Replaced with the input LPID. Next, the message passes through the assigned outbound link, etc.
Sent to next node. FIG. 9 shows a routing table 90 containing unidirectional entries 88 for hypothetical routes using the LPID method. As shown, for one entry, three elements,
That is, there is an LPID 94, an outbound link ID 96, and an LPID 98 for the next node. After the information needed for the routing table entry is extracted from the route setup message, the message is passed on to the next element, etc. to generate all the table entries needed for the route. If end-to-end
If all nodes and links in the route are active, the route setup is successful and an end-to-end route is generated. Each routing table entry for each node that is traversed is marked active.
If a node cannot send a root setup message to the next node because either the link or the node itself is inactive, a root failure message is generated that identifies the inactive or node; and It is sent back to the root origin and then to the topology database. In the topology database, the inactive status is marked. The element is then not used in subsequent route setup messages until the situation changes. As route failure messages return through each node identified in route setup, the status of the route is marked inactive, but each node's routing table entry remains unchanged. These table entries are used by end nodes (and their topology) when the failed element is reactivated.
used for feedback mechanism to databases). Root failure messages are traced from the root setup message that caused the failure.
It is transmitted by tracking the node routing table entries that are set up. FIG. 10 shows a route failure message 100 for an LPID compliant network. This includes a request code 102 that identifies the message as a root fault message, a node ID 104 of the node that detects the fault, a fault occurrence element ID 106,
and the following LPID 108 are included. The node that signaled the route failure (the "adjacent node")
detects that an inactive element has subsequently become active, a root element activity message is generated and sent to the base node and then to the topology.
Sent to the database. The topology database then resets the element's status entry to "active." As a result, the element is available for subsequent root setup attempts. The root element activity message is
It is the same as root failure message 100 (FIG. 10) except that it is identified as a root element activity message by the request code. If one or more routes attempt to use an inactive element, one or more sets of routing table entries are created at neighboring nodes. and as many entries as the set of generated entries.
A root element activity message is generated and sent back to the corresponding base node to reset the topology database entry for the element to "active". Such a notification flow is similar to that for route failure messages, when the failed route
From the setup message, the root base node is reached by following the setup node routing table entries. The same process is used after an end-to-end route is successfully established and a link or node of the route fails. The same route failure message is returned to both end nodes in this case, i.e., the origin node and the destination node,
Sent to each end node's topology database. The root failure message identifies the failed element. Then, as in the case of the initial route setup failure, when the message returns to the end node, the routing table entries for the route segments leading to the end node remain unchanged. As in the previous case, when a failed element becomes active, a node routing table entry is sent to the end by a root element active message (one in each direction around the point of failure). Used to trace the route back to a node. The message is sent to a topology database indicating the active status of the network element. In either case, as the root element activity message flows to the topology database, the routing table entries are removed from the nodes along the route, as if the end-to-end
The end route regains space in the routing table as if it were being killed normally after all sessions using the route are finished. As discussed in more detail below, the feedback mechanism works in the face of failures at either single points or multiple points along the route. The basic elements of the preferred embodiment feedback mechanism can be described by a set of rules, definitions, states and protocols that are applicable to any communications network with dynamic routing as described herein. The protocol describes four operational cases. RULES OF OPERATION, DEFINITION, AND STATE 1 Topology Databases There are one or more topology databases, the contents of which are network nodes, connectivity, and status data that are It can be used to select an end-to-end route through a workpiece. Each root element (that is, each network node and each link; a node can be a source, a destination, an intermediate node host, or a communication processor; a link can be a teleprocessing link, a channel connection, a local - may be a teleprocessing loop, local area network, fiber optic line, or any other medium capable of connecting two hosts or communication processor nodes);
There is a set of parameters as shown in the table.

[Table] War
Confidentiality (tentative)
protection

[Table] Inactive

Link·
Reliability unknown/
address
Confidentiality (tentative)
protection
These properties are well known. Entries and knowledge of elements can be created in the topology database using a variety of methods. These include operator input, system generation processes, automatic element identification during element activation, etc. 2 Route Selection Algorithms The algorithms used to select routes (i.e. security, minimum delay, maximum bandwidth, etc.) are:
Adherence to the list of routes selected and the element conditions described above will not affect the operability of the invention in the network. 3. Route Request Mechanism A mechanism is provided that allows a user to request an end-to-end route through the network from a source node to a destination node. Such requests are sent to the topology database with instructions regarding desired characteristics (security, minimum delay, etc.). The request initializes the route selection process in the topology database and generates a route setup message. 4 Route Setup Message This is a message containing a list of nodes and links selected to create an end-to-end route from a source node to a destination node. A route setup message traverses the network from source to destination, alternating between links and nodes in the order specified in the message. As the message traverses the proposed route, a routing table is generated at each node traversed, in which entries indicate connections to forward and reverse neighboring nodes. The answer to a route setup is either a route setup answer message or a route failure message. 5 Route Setup Reply Message This message is issued from the destination and returns to the source when route generation is successful. 6 Route Failure Message This message is returned for a failed route setup attempt and for failure of an element in a route that has already been successfully created. In the case of a failure of a route setup attempt, a network node generates a route failure message when it is no longer able to continue sending route setup messages to its neighbors. This message, shown in Figure 10, is
It is sent back to the source and then to the topology database. This route failure message is
Indicates which node detected the inactive network resource. The topology database records the status of an inactive element and prevents it from responding to other root setup attempts until it is later informed by a root element activity message that the element has become active. Do not reuse this element. In case of failure of an element on an established route, the same route failure message is generated and sent for the same purpose, but in this case to both ends involved.
The message is sent to the node. 7 Root Element Activity Message This message is generated by a node when it detects the reactivation of an inactive element. The root element activity message is generated and sent if a root setup message was flowing before the element changed from inactive to active. Root element activity messages use routing table entries from previous root setup messages to traverse the network and return to the origin node. 8 Route Delete Message This message is sent on a route to notify that the route is no longer needed. The message is generated by a route end point (source or destination node) upon completion of all sessions assigned to a particular end-to-end route. As a route deletion message traverses the network, each node along the path releases the routing table entry assigned to the particular route and sends the message on the route that is being deleted. The root deletion message is
It has no effect on the status of the element in the database. This is because this message is emitted only on the active route and the status of the element does not change from its current active state. 9 Resource status Each element (node, link) can have three statuses. i.e., unknown-tentative (UNK);
Active (OP) or inactive. element is OP
or UNK state, the element can be used for route selection purposes. When in INOP state, until marked UNK or OP,
The element cannot be used for route selection. Setting the Unknown-Temporary Active State 1 When a topology database is activated or a new element is added to an existing topology database, all elements are considered UNK. 2 On the same INOP root, but with different topology
An element in the INOP state changes to UNK if another element closer to the database fails. In this way, it is ensured that an element does not remain in INOP indefinitely due to a second fault outage preventing notification of root element activity from reaching the topology database. b Active Setting 1 When a Root Setup Answer message is received, the element changes to OP from UNK. 2. When an element that prevents the root setup request from succeeding becomes active, the element changes from INOP to OP and a root element activity message is generated. c. Setting Inactive State 1 If a route setup attempt results in a route failure, the state of the request identified as inactive changes to INOP if the route setup cannot proceed. 2. Notification of a route failure on an active route changes the status of the identified failure request to INOP. 10 Node Routing Table Each network node contains a node routing table that is used to route messages through the network. The node routing table is configured as required by the route.
Created dynamically using the root setup mechanism. Each entry consists of forward and backward pointers to outbound queues associated with the "next leg" of the message's journey in each direction, as well as the status or state of the entry. If a node is the source or destination node for that route, this is also indicated in the table entry. There are two possible states for each node routing table entry: OP or INOP. The OP state is set when the route is created. The INOP state is set when the following conditions are met: a Failure notifications come back to the root from the root setup attempt. b. A route failure notification is received on the active route. The state entry in the routing table is
Can be used by the operator for informational purposes (eg operator verification). The entry can also be used by nodes to cut off messages on established routes that cause route failure messages to be disseminated back. In this way, valuable link time is freed up. 11 Protocols The feedback mechanism of the preferred embodiment of the present invention integrates specific protocols to provide appropriate notification to the topology database regarding the status of resources on dynamically generated routes within the network. I guarantee that. These protocols are described using the following four cases that cover critical network events. 1 Notification to the topology database when a failed element (one of the previously used routes) is reactivated. 2 A double failure case where two elements fail on an active or pending active route. 3. Discovery of inactive elements during route setup attempts. 4. Failure of an element in the pending active route after the route setup message has passed the failed link but before the route setup reply has returned through the failed link. Case 1: Route Failure and Subsequent Post-Recovery Notification In the network 110 depicted in FIG. 11, for a session between nodes A and E,
Route A-L1-B-L2-C-L3-D-L4
-Assume that E has been generated. Node A,
In B, C, D, and E, the state of the route table entry is OP. Assume that the topology database 112 was used at node A to select the root elements that make up this route, and that the state of all network elements in the database is OP. .
Assuming a failure of link L2, and nodes B and A
When considering the processing in , the operating rules are as follows. Note that the processing at nodes C and E is also similar. a L2 failure is detected by both nodes B and C. b In this example, node B generates and sends a route failure message to node A. The message is further sent to the topology database. c. As a route failure notification traverses the network to node A, the routing table entry for that route at each node in the direction away from the failed element (i.e. from B to A) is: Although marked INOP, it remains in the node routing table. d After receiving the route failure notification, A's topology
The database marks link L2 as INOP. As a result, another route setup attempt through L2 will not be initialized. e When link L2 becomes active, Node B searches its routing table. and is marked INOP and previously L
2. Find the entry that used the outward path. Subsequently, Node B generates a root element activity message for the root corresponding to each such entry. In this example, the root element activity message is
It indicates that it is OP and is transmitted along the route to node A. When each node on the path sends this root element activity message,
Delete the entry for the route from the node routing table. f When the root element activity message arrives at node A, it is further sent to the topology database supporting node A. Then,
The topology database updates the L2 element status to OP. As a result, L2 can be used for new route setup attempts. Similar processing is performed in the opposite direction from node C to node E, including node D, and further to the topology database supporting node E if it is different from the topology database of node A. . Case 2: Double Failure Case Consider the same network as depicted in Figure 11. Again, from A to E to L
It is assumed that a route passing through each node using 1, L2, L3, and L4 has been generated. Then, first, a failure occurs in link L3, and then link L
Consider the case where a failure occurs in 2. Then the following happens: a Node C detects an L3 failure. Node C
scans its node routing table and, if it finds an entry with an L3 outbound link, sends a route failure notification in the opposite direction (ie, to Node B). Nodes C, B and A
The routing table entries in
Although it remains in the routing table,
It can be marked as INOP. At node A,
Root failure messages are sent to topology data
given to the base. There, the element entry for L3 is marked INOP.
Processing in the direction of node E, where node D detects a failure in L3, is performed in a similar manner. b Node B detects the L2 failure and scans its node routing table. It then sends a route failure identifying that L2 has failed to A using the already inactive route. Node A sends this notification to the topology database. The routing table entries for nodes A and B are both
Remains in INOP state. c. Scan the topology database when the topology database receives this second route failure notification for the same route, albeit for a different element failure. and,
Since L3 exists in another route, L3
Unless it turns out to be an INOP, mark the first failed element L3 as UNK, and mark the newly failed element L2.
Mark it as INOP. Here, several situations may arise regarding the treatment of the time when L2 or L3 becomes active. Each state is described below. 1 Assume that L2 becomes active while L3 remains inactive. Once L2 becomes active, Node B uses the method described in Case 1 to inform the topology database that AL2 is now available. The routing table entries for B and A are deleted. Subsequently, the topology database is transferred to L2.
Mark as OP. Although it is possible to send a route setup request for route establishment (assuming the session wishes to use the route), it will fail on the L3 link. The partially created root segment remains and waits for L3 to become active again. 2 Assume that L3 becomes active but L2 does not. In this case, the topology database receives no notification because L2 is inactive and blocks the path to base node A. However, this does not cause any problems. Because the topology
This is because the database assumed that L3 was active (ie, UNK) after the L2 failure anyway. 3 Assume that L2 becomes active, followed by L3. In this case, item 2 above,
It is treated the same as 1. However, the difference is that since L3 is active, root setup is successful. The handling of this double failure from the point of view of nodes D and E is similar to that of nodes B and A, except that the directions are opposite. Because of the traffic flowing in the direction towards the fault, node D,
E's node routing table entry is marked INOP. Note: In both directions, when a routing table entry becomes INOP, it is removed from the table. In this case, the node is
Obstacles on each side cause them to become independent at certain points along the route. Routing table entries are then not needed for later root element activity notifications. In this case, node C deletes its routing table entry and
Only nodes B and D transmit root element activity messages to the terminals of the root. Case 3: When attempting to set up a route,
Finding Inactive Elements This case is similar to the processing of case 1.
The difference, however, is that instead of route failure notification being issued on the existing route, the failure notification becomes part of the route setup failure notification. Case 1
Elements in the topology database that stop a route setup attempt are marked INOP, such as . When an inactive element becomes active, the same processing as described for items e and f in case 1 is performed. Case 4: Resource failure after route setup message passes through just failed element This case is similar to case 1. The difference is that the failure notification is for a pending active node routing table entry (because the route setup reply has not arrived) and not for a fully activated entry. The process for neighboring nodes detecting a failure is the same. Notification that the failed element has become active is issued as described in Case 1, items e and f. The above protocol, as previously stated, can be implemented in virtually any dynamic routing network and can effectuate the principles of the preferred embodiment of the present invention. Furthermore, additional standard measures can be added if desired. Examples include message code realization, routing
Operator status matching commands for values of table entries, etc. can be mentioned. Processing Filled Routing Tables at Network Nodes During a network operation, the routing tables of one or more network nodes are filled to capacity, and as a result, the routing tables on those nodes are no longer available until the condition is alleviated. Routing entries may not be created. The usual way to bring about such mitigation is for sessions to terminate and for routes that are no longer used to be purged from the network. Automatically intervene with the topology database to kill a root segment awaiting reactivation or recovery of some resource, or request that the topology database, through the network operator, It is also desirable to require the implementation of such interventions. Accordingly, embodiments of the present invention include notifying a topology database of the occurrence of a "full" condition of a routing table at a network node. The network node sends a message to the control node indicating the full routing table status.
The control node then passes the message to its topology database. The topology database either cancels pending route requests involving the affected nodes or requests manual intervention by the network operator to make a decision. This depends on the initial setting of the topology database. In the former case, the network operator may be notified even if the operator's judgment is not required at all. When the topology database itself or the network operator decides to remove a pending route request from the network, the topology
The database sends appropriate route deletion requests along the established route segments to delete the entries from the routing tables of the nodes in the route segments. Removing a Node from a Network A network operator may decide to remove a link or node from a network, either temporarily or permanently. Such link or node resources may be currently active or may be awaiting reactivation or recovery from a previous failure. Therefore, operator commands to the topology database may include removing representations of resources from the network. If a resource is active, user sessions that depend on that resource are aborted or allowed to terminate normally. Thereafter, the route containing the resource is deleted normally by a route deletion request from the topology database. After receiving a command to remove a resource from the network, the topology data
The base ceases to use the resource in new route setup requests. When a link or node resource is removed from the network, pending route requests that depend on it are canceled if it is awaiting reactivation or recovery. After receiving a command to remove a resource from the network, the topology database issues a route deletion request for all pending route requests that include the resource being removed and requests the establishment of a new route using the resource. No more trying. E. Effects of the Invention As shown in the above description, the present invention provides a system for informing a network topology database of the availability of alternative communications between various communication network elements. It's hot,
It can provide a significant reduction in network traffic compared to traditional solutions. The significant proliferation of status messages in the network is significantly reduced by applying the present invention. Then, minimal but sufficient availability information is given to the nodes of the class, and session routes can be generated efficiently. Unnecessary use of network resources is minimized.

[Brief explanation of the drawing]

FIG. 1 is an explanatory diagram of a simple mesh type communication network. FIG. 2 is a diagram representing an overview of the network shown in FIG. 1. Third
The figure is a diagram representing an overview of the topology database route table. FIG. 4 is a diagram representing an outline of the root statement. FIG. 5 is a diagram representing an outline of a link statement. FIG. 6 is a diagram representing an outline of a node statement. FIG. 7 is a diagram representing an outline of a route request message.
FIG. 8 is a diagram representing an outline of the route setup message. FIG. 9 is a diagram representing an overview of the routing table. 10th
The figure is a diagram representing an overview of a route failure message according to the present invention. Figure 11 shows the topology
1 is a diagram representing an overview of a network involving a database; FIG.

Claims (1)

[Scope of Claims] 1. In a data transmission network including a plurality of network elements consisting of message sending/receiving nodes and communication links interconnecting the nodes, a method for establishing communication paths between the nodes and regarding the availability of the network elements. A method for collecting data comprising: (a) storing data about network elements potentially available for communication in a storage element associated with each of the nodes attempting to establish a communication path; and (b) comprising: selecting, using the stored data, a communication path of selected elements interconnecting the originating node with another node of the network; (c) attempting to establish said path; and (d) selecting. (e) if the unavailability of a network element in the path is detected at a node included in the path during or after the establishment of the path; In response to this, data regarding the unavailability of the element is generated at the node and sent to the origin node via the network elements included in the path to be stored in its storage element, and to be stored in its storage element for subsequent communication paths. A communication path establishment/unavailability data collection method for a data transmission network, characterized in that it is used when selecting a data transmission network.