SVC ROUTING IN NETWORK WITH STATIC ROUTING TABLES

Abstract: A method is disclosed for establishing a switched virtual circuit in a digital network having network nodes with static routing tables. The static routing tables contain at least primary and alternate routing data. When a node is unable to forward a call over its outgoing primary route due to congestion or physical failure and its alternate route is the same as the route on which a call setup request arrived, it clears the call at that node and sends a crankback message to the preceding node, which responds to the crankback message to attempt to dynamically re-route the call over the alternate route stored in the routing table of the preceding node. If the attempt is unsuccessful, it sends the message back to the next preceding node and so on.

Description: SVC ROUTING IN NETWORK WITH STATIC ROUTING TABLES This invention relates to a method of establishing a switched virtual circuit in digital networks with static routing tables. The invention is applicable to any technology in which switched virtual circuits are set up through a packet switched network, for example, ATM and Frame Relay networks. Congestion may occur on a network link if many incoming streams of traffic all terminate on the same outbound link, or the outbound link may busy or down due to a failure. Congestion is a problem in all networks. In packet switched networks, congestion is handled by end to end applications. There are no methods for handling congestion at the packet routing level. In circuit switched networks, bandwidth is reserved for each circuit by the network operator. Once again, there are no methods for handling congestion. In networks which use switched virtual circuits (SVCs), a method is needed to reroute around congested or failed links. In the P-NNI protocol, which applies to dynamically routed SVC networks, a crankback IE (Information Element) is used for rerouting. When a node receives a call set-up request with which it is unable to comply, it sends a crankback IE back through the network. This IE passes through several nodes until it reaches a node which is programmed to respond to a crankback IE. This node, which is equipped to respond to a crankback element, then attempts to re-route the call on the basis of its current routing table. This method, however, cannot been used in statically routed SVC networks, where the nodes contain manually pre-configured routing tables, which predetermine the path through the network that a call between any two endpoints will take. Furthermore, there is no mechanism to prevent continuous crankback attempts. In a network with static routing tables, failure in one of the configured links will result in failure ofthe call set-up process. Routing loops may occur due to configuration errors, the use of alternate routes when failures occur, or transient routing tables after a failure in the network. Routing loops are also a problem in all networks. In statically routed packet and circuit switched networks, loops are assumed to be detected by the network operator. No loop detection mechanisms are present in these networks. In networks which use switched virtual circuits, both transient loops and permanent loops are a problem. A reliable method of loop detection is therefore needed in these networks. The P-NNI protocol uses source routing to avoid loops. This adds unnecessary complexity to SVC routing. An object ofthe invention is to alleviate these disadvantages. According to the present invention there is provided a method of establishing a switched virtual circuit in a digital network having network nodes with static routing tables, characterized in that said static routing tables contain at least primary and alternate routing data, and that when a node is unable to forward a call over its outgoing primary route due to congestion or physical failure and its alternate route is the same as the route on which a call setup request arrived, it clears the call at that node and sends a crankback message to the preceding node which responds to said crankback message to attempt to dynamically re-route the call over the alternate route stored in the routing table ofthe preceding node, and if not sends the message back to the next preceding node and so on. This method gives statically routed SVC networks some of the capabilities of dynamically routed networks, in that a failure on the primary route does not necessarily means that the call set-up attempt will fail. This method can prevent routing loops from occurring without the added processing and memory burden of source routing. Preferably, the crankback IE has a predetermined lifetime to prevent continuous crankback attempts. The invention will now be described in more detail, by way of example only, with reference to the accompanying drawings, in which:- Figure 1 shows a portion of a digital network showing how the system routes SVCs around failures; and Figure 2 illustrates the network with a different trunk group down and showing an extra node. Figure 1 shows a digital network comprising three switching nodes A. B. C, referred to as node A, node B, and node C, for example. ATM switches, and four users 5, 6, 7, 8, referred to as user 1, user 2, user 3. and user 4. User 1 and user 4 are connected to Node A, user 2 is connected to node C. and user 3 is connected to through a "foreign" network 9 to Node B. The nodes are connected via trunks 1 carrying SVCs (Switched Virtual Circuits). Each node contains a routing table 1 1 which is manually preconfigured when the network is setup to store the routes to possible endpoints from the node. The routing tables 1 1 contain information pertaining to a primary route and an alternate route to use in the event that there is a failure or congestion on the primary route. Suppose that the Primary Route for Node A, as stored in its routing table 1 1. to reach User 2 is via Node B and the Alternate Route is via Node C. On Node B , the Primary Route to User 2 is via Node C and an Alternate Route is via Node A. In this example, all Trunk Groups between Node B and Node C are assumed to be down. A Setup message from User 1 to User 2 is routed by Node A to Node B in accordance with the infoπnation stored in its routing table 1 1. Node B detects that the Trunk Group in its Primary Route (via Node C) is down, so its Primary Route cannot be used. Node B also detects that its Alternate Route to User 2 is the same Route on which the setup message was received. Routing the call out the Alternate Route would therefore cause a loop and Node B therefore determines that it cannot forward the call to User 2 and clears the call back to Node A with a Release message indicating Crankback. Node A receives the Crankback message, notes that its Primary Route didn't work and forwards the call on its Alternate Route, as stored in its routing table 1 1 , to Node C. Node C then forwards the call to User 2. Without Crankback, the Trunk Group failure between Node B and Node C would prevent User 1 from establishing an SVC to User 2. If this attempt fails, node A attempts to repeat the process back to the next preceding node and so on back through the network. In this example, the next preceding node is the originating user 1 , so the call is cleared. Crankback thus operates by regressing a call in progress back to a previous node in the call setup path to try an alternate route from that point. When a node cannot forward a call along its configured path, it clears the call at that node and sends a Release message to the previous node (called the Crankback destination) and includes a Crankback Information Element in the Release message to indicate Crankback (as opposed to normal call clearing). The Crankback destination has a record ofthe Route and Route List it used to forward this call. Upon receiving the Crankback, the Crankback destination knows that the Route it chose cannot be used to establish this call. It therefore chooses the next best Route from the Route List to forward the call. This newly-selected Route will take the call to a different node in an attempt to route around the failure. If there are no other Routes to chose from in the Route List, then the call is cranked back one more hop. If Crankback reaches the originating node and an alternate Route cannot be found, then the call is cleared back to the calling party. In order to bound the number of SVC re-routing attempts, Crankback will be attempted only up to a maximum number of times before the call is cleared back to the originator. This is controlled using a hop count or time-to-live field in the signalling message. This field starts at a specific value and is decremented each time the signalling message is forwarded by an intermediate switch. When the field reaches a predetermined value, for example, zero, the call is cleared. The use of static routing with alternate routes may also cause routing loops during failure conditions. Manually configuring SVC routing tables node by node, can also cause routing loops to be erroneously introduced. Loop detection is used to detect a looped Set-up or Add Party message and will either clear the call or use Crankback to indicate to previous nodes in the setup path that an alternate route must be chosen. In the network shown in Figure 2, and additional node 10, referred to as node D is located between node C and user 2. If we assume that user 1 is establishing an SVC to User 2, node A's Primary Route to User 2 is via Node C, with its Alternate Route via Node B. The Primary Route from Node C to User 2 is via Node D with an Alternate Route via Node B. When the Setup message arrives at Node C from Node A, Node C determines that its Primary Route is inoperative, and forwards the call along its Alternate Route, to Node B. Node B sends the call along its primary route to Node A. Node A detects the routing loop and clears the call back to Node B in a Release message indicating Crankback. Node B then chooses its Alternate Route and forwards the call to Node D. which delivers the call to User 2. Looping of SVC Setup or Add Party messages can occur due to routing configuration errors or due to the use of alternate routes when failures occur. SVC looping in case 2 is detected with the use of a proprietary Transit List Information Element (IE) in the signalling messages. This IE (Information Element) records the nodes visited during the call setup. Upon detection of SVC looping, the detecting node cranks the call back to the previous node to allow rerouting to occur. The described method enhances the crankback mechanism and allows its use in statically routed SVC networks. It also prevents looping in a simple and effective manner.

Claims: Claims: 1. A method of establishing a switched virtual circuit in a digital network having network nodes with static routing tables, characterized in that said static routing tables contain at least primary and alternate routing data, and that when a node is unable to forward a call over its outgoing primary route due to congestion or physical failure and its alternate route is the same as the route on which a call setup request arrived, it clears the call at that node and sends a crankback message to the preceding node which responds to said crankback message to attempt to dynamically re-route the call over the alternate route stored in the routing table of the preceding node, and if not sends the message back to the next preceding node and so on. 2. A method as claimed in claim 1, characterized in that said call is cleared when the crankback message reaches the originating endpoint. 3. A method as claimed in claim 1, characterized in that said crankback message has a predetermined lifetime to prevent continuous crankback attempts. 4. A method as claimed in claim 1 , characterized in that said crankback message includes a field containing a hop count, said field is decremented each time the message is forwarded by a network node, and said crankback message self destructs when the hop count reaches a predetermined value. 5. A method as claimed in claim 1, characterized in that when a receiving node detects a routing loop in a call setup request message received from an adjacent node, said receiving node returns said setup request message to said adjacent node with a crankback message, and said adjacent node responds to said crankback message to forward said setup request message on its alternate route stored in its routing tables.

Inventors: BEHKI NUTAN, CHAN RICHARD, MCALLISTER SHAWN, BEHKI, NUTAN, CHAN, RICHARD, MCALLISTER, SHAWN
Applicants: BEHKI NUTAN, CHAN RICHARD, MCALLISTER SHAWN, NEWBRIDGE NETWORKS CORP, BEHKI, NUTAN, CHAN, RICHARD, MCALLISTER, SHAWN, NEWBRIDGE NETWORKS CORPORATION
Application year: 1996
Main classification: H04L12
IPC codes: H04L12, H04Q3, H04Q11