US 5,317,566 AGrant
Least Cost Route Selection in Distributed Digital Communication Networks
Issue Date:1994-05-31
•14 Claims
•7 Drawing Sheets
Abstract
A distributed digital communications network has an originating node and a multiplicity of destination nodes. The various nodes are interconnected by links and at least some of the nodes are accessible to other nodes only by multiple links. To save time in establishing the least cost path from an originating node to a destination node, the attributes of the various links are stored in memory at the originating node, a least cost path from the originating node to a destination node is calculated in response to a connection request and stored in memory. Then, when a subsequent connection request to any destination node requires the same link attributes as the least cost path already stored in memory, that same least cost path is used if it is still operational. Significant time saving is achieved in that no new least cost calculation need be made.
Metadata
Assignee
- Ascom Timeplex Trading AG
Inventor
- Ramchandra Joshi
Application Information
Application Number:US 1078690
Filing Date:1993-08-18
Priority Date:1993-08-18
Art Unit:263
Classifications
IPC:
H04Q 1104H04J 324
Field of Search:
37034037936439513;16;54;60;94.1;94.3826;827221200
Patent Drawings (7 sheets)
Description
Field of the Invention
This invention relates generally to distributed digital communication networks and, more particularly, to methods for selecting a route from originating nodes to destination nodes in such networks.
Background of the Invention
A distributed digital communication network typically includes a multiplicity of nodes interconnected by transmission links. At least some nodes are typically accessible to at least some other nodes only by multiple links. In addition, at least some links typically not only have different transmission characteristics, particularly in the sense of transmission bandwidth, transmission delay, bit error rate, and the availability or unavailability of encryption but also have different transmission costs.
In transmitting a message between two nodes in such a distributed digital transmission network, it is normally advantageous to select the route entailing the lowest transmission costs before setting it up. In the past, an algorithm called the Dijkstra Shortest Path First (SPF) algorithm has been widely used for such selections. The SPF algorithm is disclosed, for example, at pages 586 through 589 of the second edition of "Data Structures Using Pascal," by Aaron Tennenbaum and Moshe Augenstein, which was published in 1986 by Prentice-Hall. Specifically, the SPF algorithm includes two separate and distinct steps. In the first step, the transmission distance between an originating node and each other node in the network is calculated. The shortest transmission distance to each potential destination node is saved in the originating node's memory. When a route is needed for transmitting a message to a particular destination node, the second step of the SPF algorithm determines a route with shortest transmission distance to the source node by tracing backwards from the destination node. Unfortunately, the selected route will not necessarily meet all transmission requirements of the message for which the route is being set up. If the selected route fails to meet all transmission requirements of the message, an entirely new calculation is necessary and establishment of a working route will be delayed. Because transmission distance may not be the only factor affecting cost, the selected route may also not really be the least cost route.
Summary of the Invention
The present invention enhances both the speed and the reliability of the route selection process in a multiple node distributed digital communications network, a least in part through realization that the transmission requirements between any specific pair of nodes tend to remain the same from one connection request to the next. In such a network, the various nodes are interconnected by transmission links and at least some nodes are accessible to at least some other nodes only by multiple links.
From one important aspect, the invention is directed to a method for selecting a least cost route from an originating node to a designated destination node. Broadly, the method includes the steps of (1) receiving in a processor serving the originating node a service request including first transmission requirements for a route from the originating node to the designated destination node, (2) storing the first transmission requirements in a memory serving the originating node, (3) calculating in the processor and storing in the memory the least cost route from the originating node to the designated destination node in which each link satisfies the first transmission requirements, (4) establishing the stored route from the originating node to the designated destination node, (5) receiving in the processor a second service request including second transmission requirements for a route from the originating node to the designated destination node, (6) comparing in the processor the second transmission requirements with the first transmission requirements stored in the memory, (7) if the second transmission requirements match the first transmission requirements, validating the stored route to determine that it is still functional, and (8) establishing the stored route from the originating node to the designated destination node. Between the same pair of nodes in a distributed digital communication system, transmission requirements tend to be the same from one connection request to the next. For this reason, the invention provides route selection that not only is considerably faster than that afforded through the prior art SPF algorithm but also is more reliable in that the path selected is always in fact the least cost route.
In specific embodiments of the invention, transmission requirements for individual routes may include such factors as transmission bandwidth, transmission delay, bit error rate, and the presence or absence of an encryption and decryption capability. In various embodiments of the invention, least cost calculations are based upon the cost of using specific transmission links. Link cost is calculated, taking into account the link bandwidth already allocated for transmission and the total bandwidth capacity of the link. The cost of a route is determined by adding the costs of all links that are contained within such a route.
Because the topology of a multiple node distributed digital communications network may change, the invention, from an additional aspect, may include the further steps of (1) recalculating in the processor (advantageously as a background operation) a least cost route from the originating node to each of the destination nodes in which each link satisfies the first connection requirements, (2) replacing routes stored in the memory with the recalculated routes, and (3) if the second connection requirements match the first connection requirements, establishing the recalculated stored least cost route from the originating node to the designated destination node.
The invention, furthermore, is not limited to calculation of a single least cost route between any two nodes. Alternate routes may be calculated as well. From this aspect, the invention takes the form of a method for selecting a least cost route from an originating node to a designated destination node which includes the steps of (1) receiving in the processor a connection request including first transmission requirements for a route from the originating node to the designated destination node, (2) storing the first digital transmission requirements in the memory, (3) calculating in the processor and storing in the memory a least cost route as a primary route from the originating node to the designated destination node in which each link in the primary route satisfies the first transmission requirements, (4) calculating in the processor and storing in the memory a route from the originating node to the designated destination node in which each link in the alternate route satisfies the first transmission requirements, where the cost of the alternate route is no less than the cost of the primary route, (5) selecting the stored primary route from the memory and establishing it from the originating node to the designated destination node, (6) receiving in the processor a second service request including second transmission requirements for a route from the originating node to the destination node, (7) comparing in the processor the second transmission requirements with the first transmission requirements stored in the memory, (8) if the second transmission cost requirements match the first transmission requirements, validating the stored primary route to determine that it is still functional, (9) if the stored primary route is not functional, validating the stored alternate route to determine that it is functional, and (10) establishing the stored alternate route from the originating node to the designated destination node. The cost of the alternate route is, from this aspect of the invention, equal to or greater than the cost of the primary route.
The invention is particularly advantageous in that it gains speed over the prior art SPF algorithm by completely eliminating anything comparable to the second step of the SPF algorithm.
The invention may be more fully understood from the following detailed description of a specific embodiment, taken in the light of the accompanying drawing and the appended claims.
Brief Description of the Drawing
FIG. 1 is a block diagram of a multiple node, multiple link distributed digital communication system of the type to which route selection methods according to the present invention are particularly applicable;
FIG. 2 is a flow chart of a basic route selection process in accordance with the invention;
FIG. 3 is a flow chart of the cost calculation process used in the route selection flow chart of FIG. 2;
FIGS. 4 and 5 are flow charts of functions used in the process of FIG. 3;
FIG. 6 is a flow chart showing a modification, according to the invention, of the basic route selection process illustrated in FIG. 2; and
FIG. 7 is a flow chart of the function illustrated in FIG. 4, modified to meet the needs of the process of FIG. 6.
Detailed Description
An important application of the invention may be found in an enterprise network 10 like that shown in block diagram form in FIG. 1. In FIG. 1, network 10 has a headquarters node 12 with its own internal memory (MEM) 14 and processor (PROC) 16. In addition, by way of further example, network 10 includes five remote nodes 18, 20, 22, 24, and 26 at geographically different sites. By way of example, each of the remote nodes may represent offices or factory locations. Each of the remote nodes may, furthermore, also have its own internal memory and processor.
Interconnecting the various nodes in network 10 are a number of internodal links (INLS) 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, and 52. Thus, link 28 connects headquarters node 12 with remote node 18. Links 30 and 32 are parallel links interconnecting remote nodes 18 and 22. Link 34 connects headquarters node 12 with remote node 22. Links 36 and 38 are parallel links interconnecting remote nodes 18 and 20. Link 40 connects headquarters node 12 with remote node 20. Link 42 connects headquarters node 12 with remote node 24. Links 44 and 46 are parallel links interconnecting remote nodes 20 and 24. Links 48 and 50 are parallel links interconnecting remote nodes 22 and 24. Finally, link 52 interconnects remote nodes 22 and 26, and link 54 interconnects remote nodes 24 and 26. As illustrated, at least some of the remote nodes in network 10 are reachable from headquarters node 12 only through multiple links.
In network 10, each internodal link may be characterized by the attributes of bandwidth, transmission delay, quality, encryption, bandwidth partition, and cost. Bandwidth represents the capacity of a link in bits per second. Transmission delay depends largely upon the nature of the link. A terrestrial link, for example, offers much less delay than does a satellite link. Quality represents the transmission performance of a link and is typically monitored and measured in terms of bit error rate. Bit error rate is a ratio of the number of bits that become corrupted on the link to the number of bits being transmitted over the link. To provide encryption, a link can be equipped with a data encryption circuit allowing the link to carry user data in encrypted form. Bandwidth partition permits a user of network 10 to define a plurality of internodal link groups, in which an individual link may belong to one or more groups. Finally, each link contributes to the cost of an internodal connection, the total cost of the connection being the sum of the costs of its component links.
The cost of a particular link may be defined in a number of ways. First of all, cost may be determined simply in terms of hop count. Each hop, which is a single internodal link, may be assigned a cost equal to unity. In terms of hop count, the connection cost between nodes in network 10 is equal to the total number of hops. A second approach involves user defined cost. Thus, a user may define a connection cost on the basis of propagation delay, with a specific cost figure assigned to each internodal link. Such a cost may, by way of example, be based upon the physical length of an internodal link. Finally, cost may be defined in terms of transit delay. Transit delay is the delay experienced by a user data packet at each node in network 10 and is the sum of any processing delay at each node and any queuing delay incurred while the packet is waiting for an outbound internodal link to be established. Processing delay is constant and queuing delay is based on the total bandwidth of the link and the actual number of packets being transferred on the link at a particular time.
Network 10 permits a user to predefine permanent virtual circuits interconnecting various nodes. At any particular node (such as headquarters node 12), a human node administrator may define the profile of each internodal channel connection and store them in memory 14. Such a profile may include channel speed in bits per second, whether or not encryption is required, acceptable error rate, acceptable transmission delay in terms of maximum number of satellite hops permitted, any bandwidth partition through which the channel connection should be routed, and the cost type. Such an administrator may choose one of the four cost types, i.e., hop count, user defined cost, transit delay, or user defined cost plus transit delay. With the aid of channel profile and the chosen cost criterion, the present invention permits rapid selection of the least cost route for completing a connection.
Because network 10 supports predefined permanent virtual circuits, an administrator needs to define channel connection profiles in advance. Then, when the connection establishment begins, all connection profiles are already known. The connection establishment procedure sorts the profiles so that connections with identical profiles are established sequentially. Also, in an environment where a substantial number of predefined permanent virtual circuits are established between two nodes, the probability that successive connection requests will have identical requirements is very high. In other words, sequential connection requests between the same nodes tend to have a common set of requirements.
An example best illustrates the use of predefined permanent virtual circuits. In network 10, in this example, there are 14 different internodal links. By way of example, links 30, 42, 48, and 54 are encrypted links. All other links are non-encrypted. Each division of the exemplary hypothetical enterprise is connected to its own node and the human administrator at headquarters node 12 wishes to configure the following channel connections between headquarters node 12 and remote node 18:
Connection 1: This connection is for use by a Manufacturing Department at node 18. It needs a bandwidth of 64,000 bits per second (bps) and a link with medium error quality is acceptable. The connection does not need an encrypted link.
Connection 2: This connection is for use by a Sales Department at node 18. It needs a bandwidth of 19,200 bps and a link with medium error quality is acceptable. The connection does not need an encrypted link.
Connection 3: This connection is for use by an Engineering Department at node 18. A link with medium error quality is acceptable. It needs a bandwidth of 64,000 bps and a non-encrypted link is acceptable.
Connection 4: This connection is for use by a Payroll Department at node 18. It needs a bandwidth of 9600 bps and an encrypted link with a low error rate.
As can be seen from the indicated connection requirements, connections 1 through 3 have identical requirements, i.e., a non-encrypted link with medium error rate. Connection 4 is different because it needs an encrypted link with high quality.
The present invention permits the least cost route from node 18 to headquarters node 12 to be calculated in processor 16 and stored in memory 14 when the first connection request is made. In this example, the least cost route is internodal link 28 out of node 18. Link 28 has an available bandwidth of 1,544,000 bps. Thus, after the first connection is made, 1,480,000 bps is still available on the link.
From an important aspect of the invention, when the second connection request is made its connection requirements are compared in processor 16 with the connection requirements stored in memory 14 for the previous connection. Since they are the same and internodal links along the route have enough bandwidth, the same route (already stored in memory 14) is established, i.e., internodal link 28. The same route also satisfies the third connection request. When the fourth connection request is made, since the connection requires an encrypted link, a new least cost route is determined in processor 16 to meet the connection requirements. Such a route is, in this example, a combination of internodal links 30, 48, and 42. All of these links provide encryption and, end to end, provide the necessary transmission path from node 18 to headquarters node 12 by way of remote nodes 22 and 24. Significant time is saved in comparison with prior art practice because new least cost routes do not need to be calculated for connections 2 and 3.
A further aspect of the invention permits selection of an alternate route. To understand this aspect of the invention, consider that when the third connection request is made, a bandwidth of 48,000 bps is available on link 28, the primary least cost route already calculated in processor 16 and stored in memory 14. The third connection needs 64,000 bps. For this example, when connection request 1 was made, it was determined that an alternate route to get to node 12 would be internodal link 32, followed by link 34. This alternate route is stored in memory 14. Each of links 32 and 34 has a bandwidth of 128,000 bps available. Since this bandwidth is adequate for channel connection request 3, this alternate path is provided in response to connection request 3. The alternate path already stored in memory 14 saves time for connection request 3 by avoiding need for a new least cost calculation.
The process which has been described in connection with network 10 in FIG. 1 may be implemented by software provided to control processor 16 in headquarters node 16. An example of such software is illustrated by the flow charts shown in FIGS. 2 through 7 and by the pseudo code contained in Appendix A.
An example of the basic route selection process used in implementation of the invention, is illustrated by the flow chart in FIG. 2 and includes steps 60, 62, 64, 66, 68, 70, 72, and 74. There, the step 60 "GET ROUTE" signifies the beginning of the process. Steps 62, 64, and 66 represent decision steps in the process and have both YES and NO outputs. Step 62 is "STORED ROUTE QUALIFIERS=CONNECTION REQUIREMENTS ?", step 64 is "DOES
ROUTE HAVE REQUIRED BANDWIDTH ?", and step is "ALL INLS IN ROUTE STILL UP ?". Steps 68 and 70 are further steps in the process. Step 68 is "ROUTE QUALIFIERS= CONNECTION REQUIREMENTS ?" and step 70 is "DO COST CALCULATION AGAIN ?". Steps 72 and 74 are process outputs or end results and are both "RETURN PATH TO DESTINATION NODE".
As illustrated, step 60 supplies an input to decision step 62. The YES output of decision step 62 provides input to decision step 64, the YES output of which provides input to decision step 66. The YES output of decision step 66 provides input to output step 72. The NO output of decision step 62 provides input to step 68, which in turn provides input to step 70. Step 70 provides input to output step 74. The NO output of decision step 64 provides input to step 70, as also does the NO output of decision step 66.
In operation, the process illustrated in FIG. 2 first checks through step 62 to see if the current connection requirements (i.e., qualifiers) are the same as the route qualifiers used in the previous connection request. If they are (a YES decision), there is a good chance that the route calculated previously and stored will be applicable for the current qualifiers. The process then checks through step 64 to see if the previously calculated and stored route has enough bandwidth to satisfy the current request. If the bandwidth is adequate (a YES decision) the process checks through step 66 to make sure that the previously calculated and stored route is still operational. If it is (a YES decision), step 72 returns the previously calculated and stored route to the requestor.
In FIG. 2, if step 62 finds that the current connection requirements do not match previous requirements (a NO decision), step 68 saves the current requirements as route qualifiers, step 70 does a new route calculation, and step 74 returns the newly calculated route to the requestor. If step 64 determines that the previously calculated route does not have enough bandwidth (a NO decision) or if step 66 determines that the previously calculated route is no longer operational, step 70 does a new route calculation and step 74 returns the newly calculated route to the requestor.
Because the topology of network 10 in FIG. 1 may change, either by adding or deleting nodes and/or links, the process illustrated in FIG. 2 may also be used to provide continuous updating of the least cost routes stored in memory 14. Such updating may advantageously be accomplished as a background operation in processor 16. Thus, when the topology of network 10 changes, the process shown in FIG. 2 is run in processor 16 to calculate and store in memory 14 a least cost route from headquarters node 12 to each of the remaining nodes. In each such calculation, each link in the resulting least cost route satisfies the connection requirements stored in memory 14 from the most recent connection request. In response to future connection requests, the stored least cost route from the originating node to a designated destination node is established without further calculation if the new connection requirements match those stored in memory 14.
An example of the cost calculation process in step 70 in FIG. 2 is shown by the flow chart in FIG. 3, which includes steps 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, and 98. There, the beginning step 80 is "NODE NUMBER=0", which initiates the process. Steps 82, 83, 84, 85, 86, 87, and 98 represent decision steps in the cost calculation process and have both YES and NO outputs. Decision step 82 is "INL ATTRIBUTES=CONNECTION REQUIREMENTS ?", decision step 83 is "NODE NUMBER=LOCAL NODE NUMBER ?", and decision step 84 is "INL<MAX # OF INL ?". Decision step 85 is "IS NODE NUMBER<TOTAL NODES IN NETWORK ?" and decision step 86 is "NUMBER OF CHECKED NODES<TOTAL NUMBER OF NODES ?". Decision step 98 is "IF MIN.sub.-- NODE.0". Steps 81, 87, 88, 89, 90, and 91 are additional steps in the cost calculation process. Step 81 is "INL=1", where INL stands for internodal link. Step 87 is "INL.SELECT=1", step 88 is "NODE.COST=0", step 89 is "NODE.COST=INFINITY", step 90 is "INL.sub.-- SELECT=0", and step 91 is "INL=INL+1". In this notation, a dot separating sequences of characters represents a structure variable in programming language, and an equality sign indicates the assignment of a value to a variable.
Still additional steps in the cost calculation process are steps 92, 93, 94, 95, 96, and 97. Step 92 is "NODE NUMBER=NODE NUMBER+1", step 93 is a two part step which includes "MARK ALL NODES UNCHECKED" and "NUMBER OF CHECKED NODES=0". Step 94 is "MIN.sub.-- NODE=GET.sub.-- MINCOST.sub.-- NODE()" and step 95 is "UPDATE.sub.-- COST(MIN.sub.-- NODE)". Step 96 is another two part step "NUMBER OF CHECKED NODES=NUMBER OF CHECKED NODES+1" and "MIN.sub.-- NODE.CHECKED=YES". Finally, step 97 is "RETURN". In this notation, expressions within parentheses represent variables modifying recurrences of the variables outside the parentheses and empty parentheses are indicative of a function.
As illustrated, step 80 supplies an input to decision step 83. The YES output of decision step 83 provides input to step 88, which provides input to step 81. The NO output of decision step 83 provides input to step 89, which also provides input to step 81. Step 81 provides input to decision step 82, the YES output of which provides input to step 87 and the NO output of which provides input to step 90. Steps 87 and 90 both provide input to step 91.
Step 91 provides input to decision step 84, the YES output of which provides input to decision step 82. The NO output of decision step 84 provides input to step 92. Step 92 provides input to decision step 85, the YES output of which provides input to decision step 83. The NO output of decision step 85 provides input to step 93, which in turn provides input to step 94. Step 94 provides input to decision step 98, the YES output from which provides input to step 95. Step 95, in turn, provides input to step 96. Step 96 provides input to decision step 86, the NO output of which provides input to step 97. The NO output of decision step 98 provides input to step 97. Finally, the YES output of decision step 86 provides input to step 94.
In operation, the process illustrated in FIG. 3 begins with step 80 by setting the node number equal to zero. Step 83 checks to see whether the node number set by step 80 is equal to the local node number (i.e., that of headquarters node 12). A YES output from step 83 causes step 88 to set the cost to reach the node equal to zero. A NO output from step 83 causes step 89 to set the cost to reach the node equal to infinity. Step 81 then sets INL equal to one. Step 82 checks to determine whether or not the attributes of the first INL match the connection requirements. A NO output from step 82 indicates that there is no match, causing step 90 to mark that INL as not selected. A YES output from step 82 indicates that there is a match, causing step 87 to mark that INL as selected. Step 91 increments the number of the INL by one and step 84 checks to see if the number of INLS checked is less than the maximum number of INLS in the network. A YES output from step 84 reinitiates decision step 82 with an incremented INL. A NO output from step 84 initiates step 92.
Step 92 in FIG. 3 increments the node number by one, causing step 85 to determine whether the incremented node number exceeds the total number of nodes in the network. If it does not, the cost calculation process returns to step 83. If the incremented node number does exceed the total number of nodes in the network, the process passes to step 93, which marks all nodes as unchecked and sets the number of checked nodes at zero.
Step 93 in FIG. 3 sets a cost calculation flag for all nodes as incomplete and sets the number of nodes for which the cost to reach has been calculated to zero. Step 94 (shown in more detail in FIG. 4) is a function which determines the next minimum cost INL and step 95 updates the cost to reach all other nodes through the minimum cost INL. Step 96 increments the number of nodes the MIN.sub.-- NODE.CHECKED flag at YES. Step 86 determines whether the number of checked nodes (whose cost to reach have been calculated) is less than the total number of nodes in the network, the process returns to step 94. Otherwise, the route calculation is completed and the process terminates in step 97 with a return.
An example of the GET.sub.-- MINIMUM.sub.-- COST.sub.-- NODE function in step 102 is illustrated by the flow chart in FIG. 4, which includes steps 112, 114, 116, 118, 120, 121, 122, 124, and 126. There, a step 112 "COST=INFINITY" marks the beginning of the function. Steps 114, 116, and 118 are decision steps and have YES and NO outputs. Decision step 114 is "IS NODE.CHECKED=YES OR NODE.STATUS=OFFLINE ?", decision step 116 is "NODE COST<COST ?", and decision step 118 is "IS NODE<MAXIMUM NODE IN THE NETWORK ?". Steps 120, 121, 122, 124 and 126 are further steps in the function. Step 120 is "COST=INFINITY" and step 121 is "NODE=LAST.sub.-- NODE". Step 122 has two parts, "MIN.sub.-- NODE=NODE" and "COST=NODE.COST". Step 124 is "NODE=NODE+1" and step 126 is "RETURN MIN.sub.-- NODE".
As shown, step 112 provides input to step 120, which in turn provides input to step 121. Step 121 provides input to decision step 114. A YES output from decision step 114 provides input to step 124. A NO output from decision step 114 provides input to decision step 116. A YES output from decision step 116 provides input to step 122, while a NO output from decision step 116 provides input directly to step 124. Step 122 provides input to step 124. Step 124 provides input to decision step 118. A YES output from decision step 118 provides input back to decision step 114, while a NO output from decision step 118 provides input to step 126.
In operation, the GET.sub.-- MINIMUM.sub.-- COST.sub.-- NODE function illustrated in FIG. 4 begins with step 112 setting a local variable called COST to infinity. Step 120 then sets MIN.sub.-- NODE at -1 and step 121 sets NODE equal to 1. The function then proceeds to decision step 114. A YES output from decision step 114 means that the cost of the path for reaching this node has already been calculated, i.e., the cost calculation flag is complete, or that the node is off line, in which case the function proceeds to step 124 A NO output from decision step 114 means that the cost of the path for reaching this node has not yet been calculated and that the node is on line. Decision step then determines whether or not the cost to get to this node, i.e., the INL cost, is less than COST. A YES output from decision step 116 indicates that the cost to get to this node is less than COST, whereupon step 122 sets MIN.sub.-- NODE to the current node number and sets COST equal to the cost to get to this node. A NO output from decision step 166 causes the function to proceed directly to step 124.
Step 124 in the function illustrated in FIG. 4 increments the node number and initiates decision step 118. A NO output from decision step 118 indicates that all nodes in the network have been checked, whereupon the function goes on to step 126, which returns MIN.sub.-- NODE. A YES output from decision step 118 reinitiates decision step 114 with the incremented node number.
An example of the UPDATE.sub.-- COST function in step 104 is shown by the flow chart in FIG. 5, which includes steps 130, 132, 134, 136, 138, 140, 142, and 144. In FIG. 5, the function begins with step 130 "FOR MIN.sub.-- NODE START WITH THE FIRST INTER-NODAL LINK (INL)". Steps 132, 134, 136, and 138 are decision steps and have YES and NO outputs. Step 132 is "INL.SELECT=1 ?", step 134 is "(INL.REMOTE).CHECKED=TRUE ?", step 136 is "(INL.REMOTE).COST>MIN.NODE.COST+INL.COST ?", and step 138 is "INL<TOTAL NUMBER OF LINKS FOR MIN.sub.-- NODE ?". Steps 140, 142, and 144 are additional steps in the function. Step 140 has two parts, "REMOTE.sub.-- NODE.COST=MIN.sub.-- NODE.COST+INL.COST" and "ADD MIN.sub.-- NODE AND INL TO ROUTE". Step 142 is "INL=INL+1" and step 144 is "RETURN".
As illustrated, step 130 provides input to decision step 132. A YES output from decision step 132 provides input to decision step 134 and a NO output from decision step 134 provides input to decision step 136. A YES output from decision step 136 provides input for step 140, which in turn provides input to step 142. A NO output from decision step 132 provides direct input to step 142, as also do a YES output from decision step 134 and a NO output from decision step 136.
Step 142 in the UPDATE.sub.-- COST function shown in FIG. 5 provides input to decision step 138. A NO output from decision step 138 provides a return, while a YES output from decision step 138 provides input to decision step 132.
In operation, step 130 begins with the first INL by setting an INL index equal to one. Decision step 132 determines whether the first INL is selected, decision step 134 determines whether a cost calculation flag for the node at the remote end of the INL is set to incomplete. Decision step 136 determines whether the cost to reach the node at the remote end of the INL is less than the sum of the cost to get to the MIN.sub.-- NODE plus the INL cost. A YES, NO, YES sequence of answers through decision steps 132, 134, and 135 initiates step 140, which sets the cost of reaching the remote node equal to the MIN.sub.-- NODE cost plus the INL cost and then adds MIN.sub.-- NODE and INL to the route to reach the remote node. The function then moves to step 142.
If the INL is not selected in step 132, if the cost calculation flag for the node at the remote end of the INL is set to complete in step 134, or if the sum of MIN.sub.-- NODE cost and INL cost is greater than the cost to get to the remote node, the route to the remote node and the cost to reach that node are not updated. Instead, the function proceeds directly to step 142.
The INL index is incremented in step 142. If decision step 138 determines that the INL index is less than the total number of INLS for MIN.sub.-- NODE and provides a YES output, decision step 132 is reinitiated. A NO output from decision step 138 provides a return through step 144.
An example of a modification to the basic route selection process illustrated in FIG. 2 to provide an alternate path is shown by the flow chart in FIG. 6, which includes steps 152, 154, 156, 158, 160, 162, 164, 166, 168, and 170. In FIG. 6, the process begins with step 150 "GET ROUTE". Steps 152, 154, 156, 158, and 160 are decision steps and have YES and NO outputs. Decision step 152 is "ROUTE QUALIFIERS=CONNECTION REQUIREMENTS?" and decision step 154 is "DOES ROUTE HAVE REQUIRED BANDWIDTH?". Decision step 156 is "ALL INLS IN ROUTE STILL UP?", decision step 158 is "DOES ALTERNATE ROUTE HAVE ENOUGH BANDWIDTH", and decision step 160 is "ALL INLS IN ALTERNATE ROUTE STILL UP?".
Steps 162, 164, 166, 168, and 170 are additional steps in the process illustrated in FIG. 6. Step 162 is "ROUTE QUALIFIERS=CONNECTION REQUIREMENTS" and step 164 is "DO COST CALCULATION". Step 166 is "RETURN PRIMARY ROUTE", step 168 is "RETURN ALTERNATE ROUTE", and step 170 is "RETURN PRIMARY ROUTE".
As illustrated, step 150 provides input to decision step 152. A YES output from decision step 152 provides input to decision step 154 and a YES output from decision step 154 provides input to decision step 156. A NO output from decision step 152 provides input to step 162, which in turn provides input to step 164. Both a NO output from decision step 154 and a NO output from decision step 156 provide input to decision step 158.
A YES output from decision step 158 provides input to decision step 160, while a NO output from decision step 158 provides input to step 164. A YES output from decision step 160 provides input to step 168, while a NO output from decision step 160 provides input to step 164. Step 164, in turn, provides input to step 170.
In operation, the process in FIG. 6 is initiated by a connection request, beginning with step 150. Decision step 152 then checks to determine if the current connection requirements (i.e., qualifiers) are the same as the route qualifiers used in the previous connection request. A YES output indicates that they are and there is a chance that the route calculated previously will be applicable for the current qualifiers. Decision step 154 verifies that the previously calculated route has enough bandwidth to carry the current channel. A YES output from decision step 15 indicates that the bandwidth is adequate, permitting decision step 156 to check to determine if each INL in the previously calculated route is still operational. A YES output from decision step 156 causes step 166 to return the primary route, avoiding any necessity for a recalculation.
A NO output from decision step 152 indicates that current connection requirements do not match previous requirements and initiates step 162, which saves the current requirements as route qualifiers. Step 164 then performs a route calculation and step 170 returns the calculated route to the requestor.
Modification of the route selection process illustrated in FIG. 2 begins in FIG. 6 with a NO output from either decision step 154 or decision step 156. A NO output from decision step 154 indicates that the previously calculated route does not have enough bandwidth. Then, decision step 158 checks to see if the previously calculated and stored alternate route has enough bandwidth. A YES output from decision step 158 indicates that the stored alternate route does have enough bandwidth and initiates decision step 160, which determines whether all INLS in the stored alternate route are still operational. A YES output from decision step 160 indicates that they are and step 168 returns the alternate route, avoiding any need for recalculation.
A NO output from either decision step 158 or decision step 160 triggers a cost calculation by step 164. A NO output from decision step 158 indicates that the stored alternate route does not have enough bandwidth and a NO output from decision step 160 indicates that not all of the INLS in the stored alternate route are still operational. After step 164 performs a new cost calculation, step 170 returns a new primary route.
FIG. 7 is a flow chart of an UPDATE.sub.-- COST function suitable for use as step 164 in the alternate route selection process shown in FIG. 6. In FIG. 7, the function includes steps 176, 178, 180, 182, 184, 186, 188, 190, 192, and 194. Specifically, the function begins with step 176 "FOR MIN.sub.-- NODE, START WITH THE FIRST INTER NODAL LINK (INL)". Steps 178, 180, 182, and 184 are decision steps and have YES and NO outputs. Decision step 178 is "INL.SELECT=1 ?" and decision step 180 is "(INL.REMOTE).CHECKED=TRUE ?". Decision step 182 is "(INL.REMOTE).COST>MIN.sub.-- NODE.COST+INL.COST ?" and decision step 184 is "INL>TOTAL NUMBER OF LINKS FOR MIN.sub.-- NODE ?".
Steps 186, 188, 190, 192, and 194 are additional steps in the function illustrated in FIG. 7. Step 186 is "REMOTE.sub.-- NODE.COST+MIN.sub.-- NODE.COST+INL.COST", step 188 is "COPY PRIMARY ROUTE TO ALTERNATE ROUTE", and step 190 is "ADD MIN.sub.-- NODE AND INL TO PRIMARY ROUTE". Step 192 is "INL=INL+1" and step 194 is "RETURN".
As illustrated, step 176 provides input to decision step 178. A YES output from decision step 178 provides input to decision step 180. A NO output from decision step 180 provides input to decision step 182. A YES output from decision step 182 provides input to step 186, initiating steps 186, 188, and 190 in sequence. Step 190, a NO output from decision step 178, a YES output from decision step 180, and a NO output from decision step 192 all provide input to step 192. Step 192 in turn provides input to decision step 184, a NO output from which initiates step 194. A YES output from decision step 184 provides input to decision step 178.
The function illustrated in FIG. 7 begins in step 176 with the first INL by setting the INL index to 1. If step 178 selects that INL by a YES output, step 180 determines that the cost calculation flag for the node that is at the remote end of the INL is set to incomplete by a NO output, and step 182 determines that the cost to reach the node at the remote end of the INL is less than the sum of the cost to get to the MIN.sub.-- NODE plus the INL cost, then step 186 sets the cost of reaching the remote node equal to the MIN.sub.-- NODE cost plus the INL cost. Step 188 then copies the current primary route to the alternate route.
Step 190 adds MIN.sub.-- NODE and INL to the remote node primary route and step 192 increments the INL index. Decision step 184 determines whether the INL index is less than the total number of INLS for MIN.sub.-- NODE. A YES output from decision step 184 reinitiates decision step 178. A NO output from decision step 184 initiates step 194, which provides a return.
If the INL is not selected, as indicated by a NO output from decision step 178, if the cost calculation flag for the node at the remote end of the INL is set to complete, as indicated by a YES output from decision step 180, or if the sum of MIN.sub.-- NODE cost and INL cost is greater than the cost to get to the remote node, as indicated by a NO output from decision step 182, step 192 is initiated directly. The route to the remote node and the cost to reach the remote node are not updated by steps 186, 188, and 190.
Pseudo code illustrating the manner in which the processes and functions illustrated in FIGS. 2 through 7 may be programmed is given in Appendix A.
It is to be understood that the embodiments of the invention which have been described are illustrative. Numerous other arrangements and modifications may be readily devised by those skilled in the art without departing from the spirit and scope of the invention. ##SPC1##
Claims
What is claimed is:
1. A method for selecting a least cost route from an originating node in a distributed digital communications network to one of a plurality of destination nodes in said network, the nodes in said network being interconnected by links with at least some of said destination nodes being accessible to said originating node only by multiple links, and at least said originating node having a memory and a processor associated therewith, the method comprising the steps of: receiving in said processor a connection request including a first set of transmission requirements for a route from said originating node to a designated one of said destination nodes; storing said first set of transmission requirements in said memory; calculating in said processor and storing in said memory the least cost route from said originating node to said designated destination node in which each link satisfies said first set of transmission requirements; establishing the route stored in said memory from said originating node to said designated destination node; receiving in said processor a second service request including a second set of transmission requirements for a route from said originating node to said designated destination node; comparing, in said processor, said second set of transmission requirements to said first set of transmission requirements stored in said memory; if said second set of transmission requirements matches said first set of transmission requirements, then validating the route stored in said memory to determine that it is still functional; and establishing the route stored in said memory from said originating node to said designated destination node.
2. The method of claim 1 in which both said first and said second sets of transmission requirements include transmission bandwidth.
3. The method of claim 1 in which both said first and said second sets of transmission requirements include transmission delay.
4. The method of claim 1 in which both said first and said second sets of transmission requirements include bit error rate.
5. The method of claim 1 in which both said first and said second sets of transmission requirements include encryption.
6. The method of claim 1 comprising the additional steps, whenever the configuration of said network changes, of: recalculating in said processor a least cost route from said originating node to each of said destination nodes in which each link satisfies said first set of transmission requirements; replacing routes stored in said memory with said recalculated routes; and establishing the recalculated stored least cost route from said originating node to said designated destination node if said second set of transmission requirements matches said first set of transmission requirements.
7. The method of claim 6 in which said recalculation takes place in said processor as a background operation, permitting other operations to be performed as foreground operations.
8. A method for selecting a least cost route from an originating node in a distributed digital communications network to one of a plurality of destination nodes in said network, the nodes in said network being interconnected by links with at least some of said destination nodes being accessible to said originating node only by multiple links, and at least said originating node having a memory and a processor associated therewith, the method comprising the steps of: receiving in said processor a service request including a first set of transmission requirements for a route from said originating node to a designated one of said destination nodes; storing said first digital transmission requirements in said memory; calculating in said processor and storing in said memory a least cost route as a primary route from said originating node to said designated destination node in which each link in said primary route satisfies said first set of transmission requirements; calculating in said processor and storing in said memory an alternate route from said originating node to said designated destination node in which each link satisfies said first set of transmission requirements, where the cost of said alternate route is no less than the cost of said primary route; selecting said stored primary route from said memory and establishing it from said originating node to said designated destination node; receiving in said processor a second service request including a second set of transmission requirements for a route from said originating node to one of said destination nodes; comparing, in said processor, said second transmission requirements to said first set of transmission requirements stored in said memory; if said second set of transmission requirements matches said first set of transmission requirements, then validating the stored primary route to determine that it is still functional; if the stored primary route is not functional, then validating the stored alternate route to determine that it is functional; and establishing the alternate route stored in said memory from said originating node to said designated destination node.
9. The method of claim 8 in which both said first and said second sets of transmission requirements include transmission bandwidth.
10. The method of claim 8 in which both said first and said second sets of transmission requirements include transmission delay.
11. The method of claim 8 in which both said first and said second sets of transmission requirements include bit error rate.
12. The method of claim 8 in which both said first and said second sets of transmission requirements include encryption.
13. The method of claim 8 comprising the additional steps, whenever the configuration of said network changes, of: recalculating in said processor a route from said originating node to each of said destination nodes in which each link satisfies said first set of transmission requirements; replacing routes stored in said memory with said recalculated routes; and establishing the recalculated stored route from said originating node to said designated destination node if said second set of transmission requirements matches said first set of transmission requirements.
14. The method of claim 13 in which said recalculation takes place in said processor as a background operation, permitting other operations to be performed as foreground operations.
Patent Citations (10)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4831649 | 1989-05-01 | Mejane | |
| US4991204 | 1991-02-01 | Yamamoto et al. | |
| US5031093 | 1991-07-01 | Hasegawa | |
| US5068892 | 1991-10-01 | Livanos | |
| US5105424 | 1992-04-01 | Flaig et al. | |
| US5115495 | 1992-05-01 | Tsuchiya et al. | |
| US5128926 | 1992-07-01 | Perlman et al. | |
| US5142531 | 1992-08-01 | Kirby | |
| US5166927 | 1992-11-01 | Iida et al. | |
| US5216591 | 1993-06-01 | Nemirovsky et al. |
Non-Patent Literature (1)
- Article Entitled "Control Architecture for Next-Generation Communication Networks Based on Distributed Databases" by Koso Mukakami and Masafumi Katoh, IEEE Journal On Selected Areas in Communications, vol. 7, No. 3, Apr., 1989.