WO1997006643A1 - Route finding in communications networks - Google Patents

Route finding in communications networks Download PDF

Info

Publication number
WO1997006643A1
WO1997006643A1 PCT/GB1996/001912 GB9601912W WO9706643A1 WO 1997006643 A1 WO1997006643 A1 WO 1997006643A1 GB 9601912 W GB9601912 W GB 9601912W WO 9706643 A1 WO9706643 A1 WO 9706643A1
Authority
WO
WIPO (PCT)
Prior art keywords
route
node
signature
finder
end node
Prior art date
Application number
PCT/GB1996/001912
Other languages
French (fr)
Inventor
David Johnson
Raymond Soo Kaiaw Chng
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to EP96926490A priority Critical patent/EP0843941B1/en
Priority to AU66651/96A priority patent/AU698097B2/en
Priority to MX9800754A priority patent/MX9800754A/en
Priority to CA002228028A priority patent/CA2228028C/en
Priority to US09/011,028 priority patent/US6147966A/en
Priority to NZ315055A priority patent/NZ315055A/en
Priority to DE69632786T priority patent/DE69632786T2/en
Priority to JP9508238A priority patent/JPH11510347A/en
Publication of WO1997006643A1 publication Critical patent/WO1997006643A1/en
Priority to NO980523A priority patent/NO980523D0/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0062Provisions for network management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/64Distributing or queueing
    • H04Q3/66Traffic distributors

Definitions

  • This invention relates to a method of finding, or determining, a route in a communication network; to a node arranged to perform the method; and to a network comprising such nodes.
  • a route may be needed to replace an existing route which has failed, and such a route is referred to as a restoration route, or a route may be required to supplement an existing route which is becoming congested.
  • the term "additional route" embraces both restoration routes and supplementary routes.
  • the failure nodes determine on the basis of their unique network identities (IDs) which node acts as Sender and which node acts as Chooser (also known as Master and Slave, respectively) .
  • IDs unique network identities
  • a node For each of the links of the failed span the Sender repeatedly transmits (floods) respective route-finder signatures to its neighbouring nodes (known as Tandem nodes) which forward flood the signatures to their neighbouring nodes.
  • a node knows only its own identity (ID) and learns the ID of the node to which connectivity has been lost by reading the last valid contents of a receive signature register on the affected port(s) corresponding to the failed l ⁇ nk(s), and in an alternative embodiment, a node stores and maintains a neighbour node ID table.
  • the node which decides to act as Chooser now enters a waiting state and remains in it until it receives a route-finder signature. Then it responds by transmitting a respective complementary reverse-linking signature (also known as a confirmation or return signature) to the Tandem node from which the route-finder signature was received.
  • a respective complementary reverse-linking signature also known as a confirmation or return signature
  • the confirmation signature travels back through the Tandem nodes establishing the required switch connections between node input and output ports, and eventually arrives at the Sender node, which then ceases transmitting the respective route-finder signatures, and proceeds to transmit on that newly established restoration route the traffic which would have been transmitted on the corresponding link of the failed span.
  • the restoration mechanism can be used for automatic provisioning of new circuit routes in a network by placing two nodes, between which it is desired to provision additional (i.e. supplementary) circuit routes, directly into Sender and Chooser states with regard to an artificial fault between the selected nodes.
  • the nodes would be supplied with artificial fault information including the number of circuit routings that are being sought.
  • a method of determining an additional route in a fully or partly meshed communications network of nodes comprising the steps of :- determining, in response to a first predetermined circumstance and in accordance with a respective predetermined master/slave relationship, at each of a pair of the nodes between which there is an existing route, the one node of said pair which is to act as master end node with respect to said existing route and the other node which is to act as slave end node; sending from said one node to its neighbouring nodes a forward route- finder signature for said existing route; receiving at a node a said forward route-finder signature, determining whether such receiving node is the slave end node for said existing route and, in the event that it is not, forwarding such received forward route-finder signature to its neighbouring nodes; determining at said other node in response to a second predetermined circumstance a potential additional route and sending from said other node on said potential additional route
  • said third predetermined circumstance is the receipt of a backtrack signature thereby indicating that there is insufficient capacity for said potential additional route at an intermediate node on said potential additional route.
  • said second predetermined circumstance is the expiry of a predetermined timeout triggered by said first predetermined circumstance.
  • said third predetermined circumstance is the absence of any received forward route-finder signatures at the expiry of said predetermined timeout of said second predetermined circumstance.
  • Said fourth predetermined circumstance may be the receipt of said reverse route-finder signature.
  • said fourth predetermined circumstance may be the expiry of a predetermined timeout triggered by the receipt of said reverse route-finder signature.
  • route-finder signatures comprise a count field
  • the step of sending a forward route-finder signature from said one node comprises a substep of setting the respective count field to a first predetermined number of one parity on the first occasion that said one node sends a forward route-finder signature and setting the respective count field to the respective next successive number of said one parity on each successive occasion that said one node switches to act as master end node
  • the step of sending said reverse route-finder signature from said other node comprises a substep of setting the respective count field to a first predetermined number of opposite parity on the first occasion that said other node sends a reverse route-finder signature and setting the respective count field to the respective next successive number of said other parity on each successive occasion that said other node switches to act as master end node.
  • a node for use in a fully or partly meshed communications network of nodes, the node being arranged :- to respond, in use, to a first predetermined circumstance with respect to an existing route for which it is an end route to determine whether it will act as master end node or slave end node; to send, in use, to its neighbouring nodes, in response to a determination that it will act as master end node, a forward route-finder signature; to receive, in use, a route-finder signature and to determine whether or not it is an end node for the existing route identified by the route-finder signature, and, in response to a determination that it is not such an end node, to forward such received route-finder signature to its neighbouring nodes, or, in response to a determination that it is such an end node and subsequent to a preceding determination that the node is the slave end node for the existing route, to determine, in response to a second " predetermined circumstance, a potential additional route, and to send on
  • the node is arranged to detect, in use, receipt of a predetermined message identifying an existing route for which the node is an end node, said receipt constituting said first predetermined circumstance.
  • the node may be arranged to detect, in use, receipt thereat of a backtrack signature for a said potential additional route for which the node is an end node, said receipt constituting said third predetermined circumstance.
  • the node may be arranged to trigger, when acting as slave end node, a predetermined timeout upon said first predetermined circumstance, the expiry of said predetermined timeout constituting said second predetermined circumstance.
  • the node is arranged to switch, when acting as slave end node, to act as master end node in the absence of any received forward route-finder signatures at the expiry of said predetermined timeout, such absence constituting said third predetermined circumstance.
  • the node may be arranged to switch, when acting as master end node, to act as slave end node upon receipt thereat of a said reverse route-finder signature, such receipt constituting said fourth predetermined circumstance.
  • the node is arranged to determine, when acting as master end node, said respective potential additional route, upon expiry of a predetermined timeout triggered by the receipt of a said reverse route-finder signature for the existing route, said expiry constituting said fourth predetermined circumstance.
  • the node may be arranged to incorporate, in use, a count field in said route-finder signatures, and to set, when initially acting as master end node, the count field of a forward route-finder signature to a first predetermined number of one parity on the first occasion that the node sends a forward route- finder signature and to set the respective count field to the respective next successive number of said one parity on each successive occasion thereafter that the node switches to act as master end node, and also to set, when initially acting as slave end node, the count field of a reverse route finder-signature to a first predetermined number of opposite parity on the first occasion that the node sends a reverse route-finder signature and to set the respective count field to the respective next successive number of said other parity on each successive occasion thereafter that the node switches to act as master end node.
  • a fully or partly meshed communications network of nodes wherein the nodes are substantially identical and in accordance with the second aspect of the present invention.
  • Figure 1 is a diagram of a network of interconnected nodes.
  • the specific embodiment of the present invention relates to a real-time restoration process for establishing a restoration route in a communications network and the following description will be limited to this although it will be appreciated that such a process need not be the sole restoration process in a network but can be combined with a pre-planned restoration process.
  • the spans between the nodes comprise working links and spare links, and each working link is part of a respective unique route.
  • the failure nodes will, correspondingly, act to find a respective restoration route for each of the other routes which use links of the span CD.
  • the order in which these restoration routes are established may be predetermined by ranking the routes in priority order, but such ranking is not part of the present invention and will not be described.
  • the failure nodes will as the result of the abovementioned decision generate a respective help signature (referred to herein as a help message) for the route X, and for any other route affected by the failure of span CD, and send these help messages to the respective end nodes of the routes.
  • a help message for the route X, and for any other route affected by the failure of span CD, and send these help messages to the respective end nodes of the routes.
  • a single help message is used containing the route IDs of all the affected routes.
  • Each of the various signatures used in the restoration process has a header and a trailer, the header including a four bit signature type field.
  • the various types are normal route-finder (also known as forward route-finder), reverse route-finder (also known as backward route- finder), route-tracer, alarm, help, backtrack, return (also known as confirmation), and priority return.
  • the information section of a signature comprises a four bit flood count field, an *e ⁇ ght bit* accumulated route length field, a four bit hop count field, a four bit route ID count field, one or more sixteen bit route ID fields, and a corresponding number of eight bit circuit number fields.
  • help messages pass through their respective intermediate nodes they break down connections in the corresponding failed route.
  • Each node will forward a received help message on tFie link which corresponds to the route ID contained in the help message.
  • node C having determined that it is experiencing a failure of route
  • help message X sends a help message to node B, because it knows that span CB contains the outgoing link for route X, and, similarly, node D sends a help message to node E.
  • These help messages contain in respective route ID fields the unique ID of the failed route, and of any other route having a circuit in the failed span CD.
  • Each node knows its own network ID and contains a table storing the route IDs for which it is an end node, and the network IDs of the other end nodes
  • node B When node B receives the help message, it will check its stored table to find out whether it is an end node for the identified route, and where, as in this case, it is not an end node, it will transmit the help message on the outgoing link associated with that route (a link of the span BA), and break down the connection for that route by removing the route and link data from its connection table.
  • node A When node A receives the help message, it will determine that it is an end node for the route X, and proceed to determine whether it is higher-ranking or lower-ranking relative to the stored ID of the other end node (E) for that route, based on the unique network IDs (ordinal numbers) of the nodes. If the former, then it will act as a master node (also known as a sender node), and if the latter then it will act as a slave node (also known as a chooser node), and in this example node A has a higher-ranking network ID than node E, and thus on receipt of the help message will, for establishing a restoration route for route X, assume the role of master. Similarly, when node E receives the respective help message, it will determine that it is an end node for the route X, and proceed to determine whether it is higher-ranking or lower-ranking relative to the stored ID of the other end node
  • node E has a lower-ranking network ID than node A, and thus on receipt of the help message will, for establishing a restoration route for route X, assume the role of slave.
  • Node A now broadcasts for the failed route X a route-finder signature which floods through the network.
  • This signature contains the ID of the route X, the requested capacity for the route, and has its flood count field set to one.
  • the forwarding or relaying nodes increment the hop count field, and update the accumulated route length field by the length of the span on which the signature was received. In variants, this latter field is updated by the length of the span on which the signature is to be forwarded.
  • flooding control additionally or alternatively comprises checking a time of origin field in the signature and taking no action if the signature is older than a predetermined limit, or checking the accumulated route length field and taking no action if the accumulated route length is greater than a predetermined limit, or any combination of these control mechanisms.
  • the master node A when it has broadcast the route-finder signature, will, enter a quiescent state to await receipt of a return signature.
  • node E Upon node E determining that it is to act as slave for the failed route X, it starts (triggers) a timeout to await receipt of corresponding route-finder signatures containing the same route ID as in the help message. Each such signature received within the timeout period is stored.
  • the slave node E selects from all received route-finder signatures for the failed route X, the optimum restoration route, for example that having lowest hop count or lowest route length, and sends a return signature (also called a route confirmation signature) back via the node from which the selected route-finder signature was received.
  • This return signature is identical to the route- finder signature except that the content of the signature type field is changed to identify the signature as a return signature travelling towards the master node A, but in variants node E additionally deletes any route ID and associated required capacity other than that for route X.
  • each of these nodes checks that the requested capacity is still available, makes the connection between the corresponding switch ports, creates an eight bit node ID field and writes its node ID into this field so that the master node A can know all the nodes of the ro ' ute.
  • the master node A Upon receipt of the return signature, the master node A knows that a restoration route now exists, as identified by the intermediate or relaying node IDs in the signature, and now sends a route-tracer signature to node E, via the restoration route, to inform it of the intermediate nodes of the restoration route and then proceed with traffic transmission.
  • the route-tracer signature can be sent on the existing route. This use of a route-tracer signature is known in the art and does not form part of the present invention. It may be that, although a relaying node had sufficient capacity and was able to forward the route-finder signature, this capacity has been taken by establishment of another restoration route before receipt of the corresponding return signature. In this event the relaying node sends to the slave node E a backtrack signature which breaks down any connections already made at intermediate nodes on that route and indicates to the slave node E that the selected restoration route is no longer available.
  • the slave node E On receipt of such a backtrack signature, the slave node E changes to act as a master node for that route, generates a route-finder signature with its flood count field set to two and sends it to its neighbouring nodes.
  • This signature is also referred to as a reverse route-finder signature. It will be appreciated that signatures with odd flood counts can be identified as successive attempts made by the original master to find a restoration route, and that signatures with even flood counts can be correspondingly identified as successive attempts made by the original slave.
  • the first receipt at the master node A of a reverse route-finder signature for the route X causes node A to change from acting as a master node to acting as a slave node for that route.
  • the node A now acting as a slave node, responds by immediately sending a return signature on the link on which the reverse route-finder signature was received.
  • This signature has the appropriate code for a return signature in its signature type field, and also has its flood count field set to two.
  • the master node A starts a timeout in response to receipt of a reverse route-finder signature, stores all reverse route-finder signatures received within the timeout period, and selects the optimum restoration route at the end of the timeout period.
  • the slave node E is arranged to switch to act as a master node if no route- finder signatures have been received by the end of its timeout period.
  • a route- finder signature is subsequently received after the node E has switched to act as a master, the node E will still act as a slave for that route-finder signature and send a priority return signature having a flood count of one.
  • this signature travels back along the corresponding restoration route, it is recognised by the intermediate nodes as requiring priority handling and placed at the front of any queue of signatures awaiting processing. In this way the restoration route will be established with minimum delay and it is likely that such a priority return signature will overtake the reverse route-finder signature.
  • the master node A will respond normally, but will know by the signature type that the node E has changed roles from slave to master and has sent a reverse route-finder signature to its neighbouring nodes. Node A will thus expect to receive reverse route-finder signatures, but these are redundant and can be ignored.
  • the node E acting as a master and having sent out reverse route-finder signatures, and possibly also acting as slave and having sent a priority return signature, will now be in a waiting state. If there is insufficient capacity on the restoration route for the priority return signature to go all the way to the end node
  • a backtrack message will be sent from the appropriate blocking node and on receipt at the node E (now acting as a master) will be ignored since node E has already sent out reverse route-finder signatures, and node E will continue to wait for a reverse return signature from the other end node A.
  • the node A will act as a slave node upon first receipt of a reverse route-finder signature of flood count two, send back a reverse return signature (also of flood count two) and then subsequently receive the priority return signature and simultaneously act as a master node for this signature.
  • the master node A If the master node A does not receive within a timeout a return signature or a reverse route-finder signature, it will send another forward route-finder signature, this time with the flood count field incremented by two. Similariy, the slave node E, if it does not receive within a respective timeout from switching to act as master a return signature or a forward route-finder signature, it will send another reverse route-finder signature with its flood count field incremented by two. This process can be terminated at a predetermined time at which it is deemed unlikely that a restoration or an additional route can be found.
  • the abovedescribed method of finding a restoration route in a network can be used to find a supplementary route by sending instructions from a network control centre to the two end nodes of a congested route so that they treat the congested route as failed and initiate the method of the invention to find an additional route (also known as an alternative route) between the two end nodes.

Abstract

A method of determining a restoration route (or an additional route) in a fully or partially meshed communications network of nodes, comprising setting, at a node which initially determines itself to be the slave end node for an existing route, a timeout for receiving a number of forward route-finder signatures from which it will select the signature representing the potential restoration route having the shortest length and return a route confirmation signature; switching, if no route-finder signatures have been received by the expiry of the timeout, to act as master end node for the existing route and send reverse route-finder signatures to its neighbouring nodes; switching, upon receipt of a reverse route-finder signature at a node which initially determines itself to be the master end node for an existing route, to act as slave end node, and send a corresponding return signature. Where a slave end node receives a backtrack signature indicating that the potential restoration route no longer has sufficient capacity, the node will switch to act as master end node. Where a forward route-finder signature is received after a node has sent a reverse route-finder signature, a priority route confirmation signature is sent. The route-finder signatures have a count field to indicate the direction of travel and the number of times that the sending node has switched to act as master end node, forward signatures have counts 1,3, etc..., and reverse signatures have counts 2,4, etc... Where a node has sent a forward route-finder signature, received a reverse route-finder signature, sent a confirmation signature, and subsequently receives a priority confirmation signature, then unless a backtrack signature is received two restoration routes will be established and the nodes will select the better one.

Description

ROUTE FINDING IN COMMUNICATIONS NETWORKS BACKGROUND OF THE INVENTION
1 . Field of the Invention
This invention relates to a method of finding, or determining, a route in a communication network; to a node arranged to perform the method; and to a network comprising such nodes. A route may be needed to replace an existing route which has failed, and such a route is referred to as a restoration route, or a route may be required to supplement an existing route which is becoming congested. As used herein, the term "additional route" embraces both restoration routes and supplementary routes.
2. Description of Related Art
It is known, for example from the article "The Self-Healing Network: A Fast Distributed Restoration Technique For Networks Using Digital Cross-Connect Machines" , W.D. Grover, IEEE Globecom 87, and from US patent 4,956,835 (Wayne D. Grover) to respond at the two nodes (known as failure nodes) connected to a failed span to receipt of a span failure alarm to initiate a real-time restoration process.
The failure nodes determine on the basis of their unique network identities (IDs) which node acts as Sender and which node acts as Chooser (also known as Master and Slave, respectively) .
For each of the links of the failed span the Sender repeatedly transmits (floods) respective route-finder signatures to its neighbouring nodes (known as Tandem nodes) which forward flood the signatures to their neighbouring nodes. In one embodiment in the abovementioned US patent a node knows only its own identity (ID) and learns the ID of the node to which connectivity has been lost by reading the last valid contents of a receive signature register on the affected port(s) corresponding to the failed lιnk(s), and in an alternative embodiment, a node stores and maintains a neighbour node ID table.
The node which decides to act as Chooser now enters a waiting state and remains in it until it receives a route-finder signature. Then it responds by transmitting a respective complementary reverse-linking signature (also known as a confirmation or return signature) to the Tandem node from which the route-finder signature was received. The confirmation signature travels back through the Tandem nodes establishing the required switch connections between node input and output ports, and eventually arrives at the Sender node, which then ceases transmitting the respective route-finder signatures, and proceeds to transmit on that newly established restoration route the traffic which would have been transmitted on the corresponding link of the failed span.
The abovementioned US patent also discloses that the restoration mechanism can be used for automatic provisioning of new circuit routes in a network by placing two nodes, between which it is desired to provision additional (i.e. supplementary) circuit routes, directly into Sender and Chooser states with regard to an artificial fault between the selected nodes. The nodes would be supplied with artificial fault information including the number of circuit routings that are being sought.
SUMMARY OF THE INVENTION According to a first aspect of the present invention, there is provided a method of determining an additional route in a fully or partly meshed communications network of nodes, the method comprising the steps of :- determining, in response to a first predetermined circumstance and in accordance with a respective predetermined master/slave relationship, at each of a pair of the nodes between which there is an existing route, the one node of said pair which is to act as master end node with respect to said existing route and the other node which is to act as slave end node; sending from said one node to its neighbouring nodes a forward route- finder signature for said existing route; receiving at a node a said forward route-finder signature, determining whether such receiving node is the slave end node for said existing route and, in the event that it is not, forwarding such received forward route-finder signature to its neighbouring nodes; determining at said other node in response to a second predetermined circumstance a potential additional route and sending from said other node on said potential additional route a route confirmation signature identifying said potential additional route; and storing details of said potential restoration route at said one node upon receipt thereat of the route confirmation signature; and the method being characterised by the steps of :- responding at said other node to a third predetermined circumstance to switch to act as master end node; sending from said other node to its neighbouring nodes a reverse route- finder signature for said existing route; and responding at said one node to receipt thereat of said reverse route-finder signature to switch to act as slave end node for said existing route, to determine in response to a fourth predetermined circumstance a respective potential additional route, and to send a corresponding route confirmation signature. Preferably, said first predetermined circumstance is the receipt of a predetermined message from an intermediate node of said existing route.
Preferably, said third predetermined circumstance is the receipt of a backtrack signature thereby indicating that there is insufficient capacity for said potential additional route at an intermediate node on said potential additional route. Preferably, said second predetermined circumstance is the expiry of a predetermined timeout triggered by said first predetermined circumstance.
Preferably, said third predetermined circumstance is the absence of any received forward route-finder signatures at the expiry of said predetermined timeout of said second predetermined circumstance. Said fourth predetermined circumstance may be the receipt of said reverse route-finder signature.
Alternatively, said fourth predetermined circumstance may be the expiry of a predetermined timeout triggered by the receipt of said reverse route-finder signature. Preferably, there is included the'step of responding at said one node, when acting as slave end node and having sent said corresponding route confirmation signature, to receipt of a corresponding backtrack signature thereby indicating that there is insufficient capacity for said respective potential additional route at an intermediate node thereof, to switch back to act as master end node for said existing route and to send a respective forward route-finder signature.
Preferably, route-finder signatures comprise a count field, and there is included the step of sending a forward route-finder signature from said one node comprises a substep of setting the respective count field to a first predetermined number of one parity on the first occasion that said one node sends a forward route-finder signature and setting the respective count field to the respective next successive number of said one parity on each successive occasion that said one node switches to act as master end node, and the step of sending said reverse route-finder signature from said other node comprises a substep of setting the respective count field to a first predetermined number of opposite parity on the first occasion that said other node sends a reverse route-finder signature and setting the respective count field to the respective next successive number of said other parity on each successive occasion that said other node switches to act as master end node.
According to a second aspect of the present invention, there is provided a node for use in a fully or partly meshed communications network of nodes, the node being arranged :- to respond, in use, to a first predetermined circumstance with respect to an existing route for which it is an end route to determine whether it will act as master end node or slave end node; to send, in use, to its neighbouring nodes, in response to a determination that it will act as master end node, a forward route-finder signature; to receive, in use, a route-finder signature and to determine whether or not it is an end node for the existing route identified by the route-finder signature, and, in response to a determination that it is not such an end node, to forward such received route-finder signature to its neighbouring nodes, or, in response to a determination that it is such an end node and subsequent to a preceding determination that the node is the slave end node for the existing route, to determine, in response to a second "predetermined circumstance, a potential additional route, and to send on said potential additional route a route confirmation identifying the existing route; and to store, in use, details of a said potential additional route upon receipt thereat of a route confirmation signature for an existing route for which it is acting as master end node; and characterised in that it is arranged :- to respond, when acting as slave end node, to a third predetermined circumstance to switch to act as master end node and to send a reverse route- finder signature for the existing route to its neighbouring nodes; and to respond, when acting as master end node, to receipt thereat of a said reverse route-finder signature for the existing route to switch to act as slave end node, to determine in response to a fourth predetermined circumstance a respective potential additional route, and to send a corresponding route confirmation signature on the respective potential additional route.
Preferably, the node is arranged to detect, in use, receipt of a predetermined message identifying an existing route for which the node is an end node, said receipt constituting said first predetermined circumstance.
The node may be arranged to detect, in use, receipt thereat of a backtrack signature for a said potential additional route for which the node is an end node, said receipt constituting said third predetermined circumstance. Alternatively, the node may be arranged to trigger, when acting as slave end node, a predetermined timeout upon said first predetermined circumstance, the expiry of said predetermined timeout constituting said second predetermined circumstance.
Preferably, the node is arranged to switch, when acting as slave end node, to act as master end node in the absence of any received forward route-finder signatures at the expiry of said predetermined timeout, such absence constituting said third predetermined circumstance.
The node may be arranged to switch, when acting as master end node, to act as slave end node upon receipt thereat of a said reverse route-finder signature, such receipt constituting said fourth predetermined circumstance.
Preferably, the node is arranged to determine, when acting as master end node, said respective potential additional route, upon expiry of a predetermined timeout triggered by the receipt of a said reverse route-finder signature for the existing route, said expiry constituting said fourth predetermined circumstance. More preferably, the node may be arranged to incorporate, in use, a count field in said route-finder signatures, and to set, when initially acting as master end node, the count field of a forward route-finder signature to a first predetermined number of one parity on the first occasion that the node sends a forward route- finder signature and to set the respective count field to the respective next successive number of said one parity on each successive occasion thereafter that the node switches to act as master end node, and also to set, when initially acting as slave end node, the count field of a reverse route finder-signature to a first predetermined number of opposite parity on the first occasion that the node sends a reverse route-finder signature and to set the respective count field to the respective next successive number of said other parity on each successive occasion thereafter that the node switches to act as master end node.
According to a third aspect of the present invention, there is provided a fully or partly meshed communications network of nodes, wherein the nodes are substantially identical and in accordance with the second aspect of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS A specific embodiment of the present invention will now be described by way of example with reference to the drawing in which :-
Figure 1 is a diagram of a network of interconnected nodes.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
The specific embodiment of the present invention relates to a real-time restoration process for establishing a restoration route in a communications network and the following description will be limited to this although it will be appreciated that such a process need not be the sole restoration process in a network but can be combined with a pre-planned restoration process.
Consider a route through network 10 between end nodes A and E, passing through intermediate nodes B, C and D, and comprising a sequence of bidirectional links within spans AB, BC, CD, and DE,"and let this route have the unique route ID
"X". The spans between the nodes comprise working links and spare links, and each working link is part of a respective unique route.
Consider also that an excavator has severed the span CD and that the nodes C and D, the failure nodes, upon detecting the failure of span CD, have decided that a restoration route is to be found between nodes A and E. This decision may be based on one or more criteria, for example the use of a potential link restoration (bypass) solution between the failure nodes would result in the overall route length (total number of spans) exceeding a predetermined limit. Such criteria are not part of the present invention and will not be further described.
The failure nodes will, correspondingly, act to find a respective restoration route for each of the other routes which use links of the span CD. The order in which these restoration routes are established may be predetermined by ranking the routes in priority order, but such ranking is not part of the present invention and will not be described.
The failure nodes will as the result of the abovementioned decision generate a respective help signature (referred to herein as a help message) for the route X, and for any other route affected by the failure of span CD, and send these help messages to the respective end nodes of the routes. In variants, if more than one route is affected, a single help message is used containing the route IDs of all the affected routes.
Each of the various signatures used in the restoration process has a header and a trailer, the header including a four bit signature type field. The various types, as will be described in more detail later, are normal route-finder (also known as forward route-finder), reverse route-finder (also known as backward route- finder), route-tracer, alarm, help, backtrack, return (also known as confirmation), and priority return. The information section of a signature comprises a four bit flood count field, an *eιght bit* accumulated route length field, a four bit hop count field, a four bit route ID count field, one or more sixteen bit route ID fields, and a corresponding number of eight bit circuit number fields.
As the help messages pass through their respective intermediate nodes they break down connections in the corresponding failed route. Each node will forward a received help message on tFie link which corresponds to the route ID contained in the help message.
Thus, node C, having determined that it is experiencing a failure of route
X, sends a help message to node B, because it knows that span CB contains the outgoing link for route X, and, similarly, node D sends a help message to node E. These help messages contain in respective route ID fields the unique ID of the failed route, and of any other route having a circuit in the failed span CD.
Each node knows its own network ID and contains a table storing the route IDs for which it is an end node, and the network IDs of the other end nodes When node B receives the help message, it will check its stored table to find out whether it is an end node for the identified route, and where, as in this case, it is not an end node, it will transmit the help message on the outgoing link associated with that route (a link of the span BA), and break down the connection for that route by removing the route and link data from its connection table.
When node A receives the help message, it will determine that it is an end node for the route X, and proceed to determine whether it is higher-ranking or lower-ranking relative to the stored ID of the other end node (E) for that route, based on the unique network IDs (ordinal numbers) of the nodes. If the former, then it will act as a master node (also known as a sender node), and if the latter then it will act as a slave node (also known as a chooser node), and in this example node A has a higher-ranking network ID than node E, and thus on receipt of the help message will, for establishing a restoration route for route X, assume the role of master. Similarly, when node E receives the respective help message, it will determine that it is an end node for the route X, and proceed to determine whether it is higher-ranking or lower-ranking relative to the stored ID of the other end node
(A) for that route. In this example node E has a lower-ranking network ID than node A, and thus on receipt of the help message will, for establishing a restoration route for route X, assume the role of slave.
Node A now broadcasts for the failed route X a route-finder signature which floods through the network. This signature contains the ID of the route X, the requested capacity for the route, and has its flood count field set to one. As the signature floods through the network, the forwarding or relaying nodes increment the hop count field, and update the accumulated route length field by the length of the span on which the signature was received. In variants, this latter field is updated by the length of the span on which the signature is to be forwarded.
The relaying nodes forward the signature on only those spans which can provide the requested capacity (i.e. have a sufficient number of spare circuits), but they do not mark that capacity as reserved. Also, they check the hop count of a received signature and take no action if the count is greater than a predetermined maximum. This sets a limit to the geographical extent of flooding. In variants, flooding control additionally or alternatively comprises checking a time of origin field in the signature and taking no action if the signature is older than a predetermined limit, or checking the accumulated route length field and taking no action if the accumulated route length is greater than a predetermined limit, or any combination of these control mechanisms.
The master node A, when it has broadcast the route-finder signature, will, enter a quiescent state to await receipt of a return signature.
Upon node E determining that it is to act as slave for the failed route X, it starts (triggers) a timeout to await receipt of corresponding route-finder signatures containing the same route ID as in the help message. Each such signature received within the timeout period is stored.
At timeout the slave node E selects from all received route-finder signatures for the failed route X, the optimum restoration route, for example that having lowest hop count or lowest route length, and sends a return signature (also called a route confirmation signature) back via the node from which the selected route-finder signature was received. This return signature is identical to the route- finder signature except that the content of the signature type field is changed to identify the signature as a return signature travelling towards the master node A, but in variants node E additionally deletes any route ID and associated required capacity other than that for route X.
As the return signature passes through the nodes of the selected restoration route, each of these nodes checks that the requested capacity is still available, makes the connection between the corresponding switch ports, creates an eight bit node ID field and writes its node ID into this field so that the master node A can know all the nodes of the ro'ute.
Upon receipt of the return signature, the master node A knows that a restoration route now exists, as identified by the intermediate or relaying node IDs in the signature, and now sends a route-tracer signature to node E, via the restoration route, to inform it of the intermediate nodes of the restoration route and then proceed with traffic transmission. Where the invention is used to find a supplementary route, the route-tracer signature can be sent on the existing route. This use of a route-tracer signature is known in the art and does not form part of the present invention. It may be that, although a relaying node had sufficient capacity and was able to forward the route-finder signature, this capacity has been taken by establishment of another restoration route before receipt of the corresponding return signature. In this event the relaying node sends to the slave node E a backtrack signature which breaks down any connections already made at intermediate nodes on that route and indicates to the slave node E that the selected restoration route is no longer available.
On receipt of such a backtrack signature, the slave node E changes to act as a master node for that route, generates a route-finder signature with its flood count field set to two and sends it to its neighbouring nodes. This signature is also referred to as a reverse route-finder signature. It will be appreciated that signatures with odd flood counts can be identified as successive attempts made by the original master to find a restoration route, and that signatures with even flood counts can be correspondingly identified as successive attempts made by the original slave.
The first receipt at the master node A of a reverse route-finder signature for the route X causes node A to change from acting as a master node to acting as a slave node for that route.
The node A, now acting as a slave node, responds by immediately sending a return signature on the link on which the reverse route-finder signature was received. This signature has the appropriate code for a return signature in its signature type field, and also has its flood count field set to two. In variants, the master node A starts a timeout in response to receipt of a reverse route-finder signature, stores all reverse route-finder signatures received within the timeout period, and selects the optimum restoration route at the end of the timeout period. The slave node E is arranged to switch to act as a master node if no route- finder signatures have been received by the end of its timeout period. If a route- finder signature is subsequently received after the node E has switched to act as a master, the node E will still act as a slave for that route-finder signature and send a priority return signature having a flood count of one. As this signature travels back along the corresponding restoration route, it is recognised by the intermediate nodes as requiring priority handling and placed at the front of any queue of signatures awaiting processing. In this way the restoration route will be established with minimum delay and it is likely that such a priority return signature will overtake the reverse route-finder signature. In this case the master node A will respond normally, but will know by the signature type that the node E has changed roles from slave to master and has sent a reverse route-finder signature to its neighbouring nodes. Node A will thus expect to receive reverse route-finder signatures, but these are redundant and can be ignored.
The node E, acting as a master and having sent out reverse route-finder signatures, and possibly also acting as slave and having sent a priority return signature, will now be in a waiting state. If there is insufficient capacity on the restoration route for the priority return signature to go all the way to the end node
A, a backtrack message will be sent from the appropriate blocking node and on receipt at the node E (now acting as a master) will be ignored since node E has already sent out reverse route-finder signatures, and node E will continue to wait for a reverse return signature from the other end node A. In the case where a priority return signature does not overtake flooding reverse route-finder signatures, the node A will act as a slave node upon first receipt of a reverse route-finder signature of flood count two, send back a reverse return signature (also of flood count two) and then subsequently receive the priority return signature and simultaneously act as a master node for this signature. If the reverse return signature does not go through and a backtrack message is returned to node A, then no further action is necessary since there is in existence an established restoration route. If, on the other hand, the reverse return signature is received at the slave node E (acting as a master node), then a corresponding restoration route is thus established. Subsequently, both end nodes A and E will become aware, by means of further messages which identify the nodes of the routes that there are two restoration routes and one of end nodes A and E (the original master node A, say) will decide which route to break down and will take suitable action.
If the master node A does not receive within a timeout a return signature or a reverse route-finder signature, it will send another forward route-finder signature, this time with the flood count field incremented by two. Similariy, the slave node E, if it does not receive within a respective timeout from switching to act as master a return signature or a forward route-finder signature, it will send another reverse route-finder signature with its flood count field incremented by two. This process can be terminated at a predetermined time at which it is deemed unlikely that a restoration or an additional route can be found.
The abovedescribed method of finding a restoration route in a network can be used to find a supplementary route by sending instructions from a network control centre to the two end nodes of a congested route so that they treat the congested route as failed and initiate the method of the invention to find an additional route (also known as an alternative route) between the two end nodes.

Claims

CLAIMS 1 . A method of determining an additional route in a fully or partly meshed communications network of nodes, the method comprising the steps of :- determining, in response to a first predetermined circumstance and in accordance with a respective predetermined master/slave relationship, at each of a pair of the nodes between which there is an existing route, the one node of said pair which is to act as master end node with respect to said existing route and the other node which is to act as slave end node; sending from said one node to its neighbouring nodes a forward route- finder signature for said existing route; receiving at a node a said forward route-finder signature, determining whether such receiving node is the slave end node for said existing route and, in the event that it is not, forwarding such received forward route-finder signature to its neighbouring nodes; determining at said other node in response to a second predetermined circumstance a potential additional route and sending from said other node on said potential additional route a route confirmation signature identifying said potential additional route; and storing details of said potential restoration route at said one node upon receipt thereat of the route confirmation signature; and the method being characterised by the steps of :- responding at said other node to a third predetermined circumstance to switch to act as master end node; sending from said other node to its neighbouring nodes a reverse route- finder signature for said existing route; and responding at said one node to receipt thereat of said reverse route-finder signature to switch to act as slave end node for said existing route, to determine in response to a fourth predetermined circumstance a respective potential additional route, and to send a corresponding route confirmation signature.
2. A method as claimed in Claim 1 , wherein said first predetermined circumstance is the receipt of a predetermined message from an intermediate node of said existing route.
3. A method as claimed in either Claim 1 or Claim 2, wherein said third predetermined circumstance is the receipt of a backtrack signature thereby indicating that there is insufficient capacity for said potential additional route at an intermediate node on said potential additional route.
4. A method as claimed in either Claim 1 or Claim 2, wherein said second predetermined circumstance is the expiry of a predetermined timeout triggered by said first predetermined circumstance.
5. A method as claimed in Claim 4, wherein said third predetermined circumstance is the absence of any received forward route-finder signatures at the expiry of said predetermined timeout of said second predetermined circumstance.
6. A method as claimed in any one of Claims 1 to 5, wherein said fourth predetermined circumstance is the receipt of said reverse route-finder signature.
7. A method as claimed in any one of Claims 1 to 5, wherein said fourth predetermined circumstance is the expiry of a predetermined timeout triggered by the receipt of said reverse route-finder signature.
8. A method as claimed in any one of Claims 1 to 7, including the step of responding at said one node, when acting as slave end node and having sent said corresponding route confirmation signature, to receipt of a corresponding backtrack signature thereby indicating "that there is insufficient capacity for said respective potential additional route at an intermediate node thereof, to switch back to act as master end node for said existing route and to send a respective forward route-finder signature.
9. A method as claimed in any one of Claims 1 to 8, wherein route-finder signatures comprise a count field, and wherein the step of sending a forward route-finder signature from said one node comprises a substep of setting the respective count field to a first predetermined number of one parity on the first occasion that said one node sends a forward route-finder signature and setting the respective count field to the respective next successive number of said one parity on each successive occasion that said one node switches to act as master end node, and the step of sending said reverse route-finder signature from said other node comprises a substep of setting the respective count field to a first predetermined number of opposite parity on the first occasion that said other node sends a reverse route-finder signature and setting the respective count field to the respective next successive number of said other parity on each successive occasion that said other node switches to act as master end node.
10. A node for use in a fully or partly meshed communications network of nodes, the node being arranged :- to respond, in use, to a first predetermined circumstance with respect to an existing route for which it is an end route to determine whether it will act as master end node or slave end node; to send, in use, to its neighbouring nodes, in response to a determination that it will act as master end node, a forward route-finder signature; to receive, in use, a route-finder signature and to determine whether or not it is an end node for the existing route identified by the route-finder signature, and, in response to a determination that it is not such an end node, to forward such received route-finder signature to its neighbouring nodes, or, in response to a determination that it is such an end node and subsequent to a preceding determination that the node is the slave end node for the existing route, to determine, in response to a second predetermined circumstance, a potential additional route, and to send on said potential additional route a route confirmation identifying the existing route; and to store, in use, details of a said potential additional route upon receipt thereat of a route confirmation signature for an existing route for which it is acting as master end node; and characterised in that it is arranged :- to respond, when acting as slave end node, to a third predetermined circumstance to switch to act as master end node and to send a reverse route- finder signature for the existing route to its neighbouring nodes; and to respond, when acting as master end node, to receipt thereat of a said reverse route-finder signature for the existing route to switch to act as slave end node, to determine in response to a fourth predetermined circumstance a respective potential additional route, and to send a corresponding route confirmation signature on the respective potential additional route.
1 1 . A node as claimed in Claim 10, and arranged to detect, in use, receipt of a predetermined message identifying an existing route for which the node is an end node, said receipt constituting said first predetermined circumstance.
1 2. A node as claimed in either Claim 10 or Claim 1 1 , and arranged to detect, in use, receipt thereat of a backtrack signature for a said potential additional route for which the node is an end node, said receipt constituting said third predetermined circumstance.
1 3. A node as claimed in either Claim 10 or Claim 1 1 , and arranged to trigger, when acting as slave end node, a predetermined timeout upon said first predetermined circumstance, the expiry of said predetermined timeout constituting said second predetermined circumstance.
14. A node as claimed in Claim 13, and arranged to switch, when acting as slave end node, to act as master end node in the absence of any received forward route-finder signatures at the expiry of said predetermined timeout, such absence constituting said third predetermined circumstance.
1 5. A node as claimed in any one of Claims 10 to 14, and arranged to switch, when acting as master end node, to act as slave end node upon receipt thereat of a said reverse route-finder signature, such receipt constituting said fourth predetermined circumstance.
1 6. A node as claimed in any one of Claims 10 to 14, and arranged to determine, when acting as master end node, said respective potential additional route, upon expiry of a predetermined timeout triggered by the receipt of a said reverse route-finder signature for the existing route, said expiry constituting said fourth predetermined circumstance
1 7. A node as claimed in any one of Claims 10 to 1 6, and arranged to respond, when acting as slave end node and having sent a said route confirmation signature for the existing route, to receipt of a corresponding backtrack signature thereby indicating that there is insufficient capacity for said respective potential additional route at an intermediate node thereof, to switch back to act as master end node for said existing route and to send a respective forward route-finder signature.
1 8. A node as claimed in any one of Claims 10 to 1 7, and arranged to incorporate, in use, a count field in said route-finder signatures, and to set, when initially acting as master end node, the count field of a forward route-finder signature to a first predetermined number of one parity on the first occasion that the node sends a forward route-finder signature and to set the respective count field to the respective next successive number of said one parity on each successive occasion thereafter that the node switches to act as master end node, and also to set, when initially acting as slave end node, the count field of a reverse route finder-signature to a first predetermined number of opposite parity on the first occasion that the node sends a reverse route-finder signature and to set the respective count field to the respective next successive number of said other parity on each successive occasion thereafter that the node switches to act as master end node.
19. A node for use in a fully or partly meshed communications network of nodes, the node being substantially as herein described with reference to the drawings.
20. A fully or partly meshed communications network of nodes, wherein the nodes are substantially identical and as claimed in any one of Claims 10 to 1 9.
21 . A method of determining an additional route in a fully or partly meshed communications network of nodes, the method being substantially as described herein with reference to the drawings.
PCT/GB1996/001912 1995-08-07 1996-08-06 Route finding in communications networks WO1997006643A1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
EP96926490A EP0843941B1 (en) 1995-08-07 1996-08-06 Route Finding in Communications Networks
AU66651/96A AU698097B2 (en) 1995-08-07 1996-08-06 Route finding in communications networks
MX9800754A MX9800754A (en) 1995-08-07 1996-08-06 Route finding in communications networks.
CA002228028A CA2228028C (en) 1995-08-07 1996-08-06 Route finding in communications networks
US09/011,028 US6147966A (en) 1995-08-07 1996-08-06 Route finding in communications networks
NZ315055A NZ315055A (en) 1995-08-07 1996-08-06 Route finding in communications networks
DE69632786T DE69632786T2 (en) 1995-08-07 1996-08-06 Path search in communication networks
JP9508238A JPH11510347A (en) 1995-08-07 1996-08-06 Route search in communication networks
NO980523A NO980523D0 (en) 1995-08-07 1998-02-06 Road selection in communication networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP95305495 1995-08-07
EP95305495.4 1995-08-07

Publications (1)

Publication Number Publication Date
WO1997006643A1 true WO1997006643A1 (en) 1997-02-20

Family

ID=8221286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1996/001912 WO1997006643A1 (en) 1995-08-07 1996-08-06 Route finding in communications networks

Country Status (12)

Country Link
US (1) US6147966A (en)
EP (1) EP0843941B1 (en)
JP (1) JPH11510347A (en)
KR (1) KR19990036154A (en)
CN (1) CN1117488C (en)
AU (1) AU698097B2 (en)
CA (1) CA2228028C (en)
DE (1) DE69632786T2 (en)
MX (1) MX9800754A (en)
NO (1) NO980523D0 (en)
NZ (1) NZ315055A (en)
WO (1) WO1997006643A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2331208A (en) * 1997-08-13 1999-05-12 Telecomm Res Lab Restoring failed telecoms. links using software agents
EP1067807A1 (en) * 1999-07-03 2001-01-10 TELEFONAKTIEBOLAGET L M ERICSSON (publ) System, arrangement and method for load control in a telecommunications network
KR100390586B1 (en) * 2001-01-15 2003-07-07 박영필 Stack Type Piezoelectric Actuator
US7230916B2 (en) 1997-07-11 2007-06-12 Demetrios Stamatelakis Distributed preconfiguration of spare capacity in closed paths for network restoration

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6831895B1 (en) * 1999-05-19 2004-12-14 Lucent Technologies Inc. Methods and devices for relieving congestion in hop-by-hop routed packet networks
US7342873B1 (en) * 2000-06-06 2008-03-11 Lucent Technologies Inc. Efficient architectures for protection against network failures
US7177927B1 (en) * 2000-08-22 2007-02-13 At&T Corp. Method for monitoring a network
JP3695362B2 (en) * 2001-07-12 2005-09-14 日本電気株式会社 Communication connection detour system
US6978394B1 (en) * 2002-02-22 2005-12-20 Cisco Technology, Inc. Linear program-based technique for placing FRR TE tunnels with bandwidth guarantee
US7406033B2 (en) * 2002-02-28 2008-07-29 Nortel Networks Limited Methods, devices and software for combining protection paths across a communications network
US8199636B1 (en) * 2002-10-18 2012-06-12 Alcatel Lucent Bridged network system with traffic resiliency upon link failure
CN100455035C (en) * 2003-09-02 2009-01-21 华为技术有限公司 Routing method of forward constraint backward selecting
US7590055B2 (en) * 2004-02-09 2009-09-15 Alcatel Lucent High availability broadband connections through switching from wireline to diverse wireless network
KR101337126B1 (en) * 2005-05-12 2013-12-05 삼성전자주식회사 Method and apparatus for achieving re-association of handover in a wireless local area network mesh network
US7835271B2 (en) * 2005-12-29 2010-11-16 Alcatel-Lucent Usa Inc. Signaling protocol for p-cycle restoration
US8400912B2 (en) * 2007-06-27 2013-03-19 World Wide Packets, Inc. Activating a tunnel upon receiving a control packet

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4956835A (en) * 1987-11-06 1990-09-11 Alberta Telecommunications Research Centre Method and apparatus for self-restoring and self-provisioning communication networks
US5065399A (en) * 1988-11-24 1991-11-12 Bell Communications Research, Inc. Telecommunication network trouble recovery system
EP0538853A2 (en) * 1991-10-22 1993-04-28 Fujitsu Limited Distributed control of telecommunication network for setting up an alternative communication path
JPH05151292A (en) * 1991-11-27 1993-06-18 Fujitsu Ltd Processing method for searching route

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0569913B1 (en) * 1992-05-14 1999-12-29 Alcatel Connection path selection method for cross-connect communications networks
US5357564A (en) * 1992-08-12 1994-10-18 At&T Bell Laboratories Intelligent call screening in a virtual communications network
US5435003A (en) * 1993-10-07 1995-07-18 British Telecommunications Public Limited Company Restoration in communications networks
US5705998A (en) * 1994-08-24 1998-01-06 Siemens Aktiengesellschaft Method for routing telecommunication calls in a network
DE19531609A1 (en) * 1994-09-13 1996-03-28 Siemens Ag Communications network traffic management
US5623481A (en) * 1995-06-07 1997-04-22 Russ; Will Automated path verification for SHN-based restoration
CN1110210C (en) * 1995-08-07 2003-05-28 英国电讯有限公司 Route finding in communications networks
US5805686A (en) * 1995-12-22 1998-09-08 Mci Corporation Telephone fraud detection system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4956835A (en) * 1987-11-06 1990-09-11 Alberta Telecommunications Research Centre Method and apparatus for self-restoring and self-provisioning communication networks
US5065399A (en) * 1988-11-24 1991-11-12 Bell Communications Research, Inc. Telecommunication network trouble recovery system
EP0538853A2 (en) * 1991-10-22 1993-04-28 Fujitsu Limited Distributed control of telecommunication network for setting up an alternative communication path
JPH05151292A (en) * 1991-11-27 1993-06-18 Fujitsu Ltd Processing method for searching route

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CORSON ET AL.: "A distributed routing algorithm for mobile radio networks", IEEE MILITARY COMMUNICATIONS CONFERENCE, vol. 1, 15 October 1989 (1989-10-15), BOSTON US, pages 210 - 213, XP000130735 *
PATENT ABSTRACTS OF JAPAN vol. 17, no. 546 (P - 1623) 30 September 1993 (1993-09-30) *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7230916B2 (en) 1997-07-11 2007-06-12 Demetrios Stamatelakis Distributed preconfiguration of spare capacity in closed paths for network restoration
US8988990B2 (en) 1997-07-11 2015-03-24 Telecommunications Research Laboratories Distributed preconfiguration of spare capacity in closed paths for network restoration
GB2331208A (en) * 1997-08-13 1999-05-12 Telecomm Res Lab Restoring failed telecoms. links using software agents
US6377543B1 (en) 1997-08-13 2002-04-23 Telecommunications Research Laboratories Path restoration of networks
GB2331208B (en) * 1997-08-13 2002-12-11 Telecomm Res Lab Path restoration of networks
EP1067807A1 (en) * 1999-07-03 2001-01-10 TELEFONAKTIEBOLAGET L M ERICSSON (publ) System, arrangement and method for load control in a telecommunications network
KR100390586B1 (en) * 2001-01-15 2003-07-07 박영필 Stack Type Piezoelectric Actuator

Also Published As

Publication number Publication date
CN1192840A (en) 1998-09-09
CA2228028A1 (en) 1997-02-20
EP0843941B1 (en) 2004-06-23
US6147966A (en) 2000-11-14
DE69632786D1 (en) 2004-07-29
KR19990036154A (en) 1999-05-25
AU698097B2 (en) 1998-10-22
EP0843941A1 (en) 1998-05-27
CA2228028C (en) 2001-10-09
NO980523L (en) 1998-02-06
DE69632786T2 (en) 2005-07-14
NO980523D0 (en) 1998-02-06
MX9800754A (en) 1998-04-30
CN1117488C (en) 2003-08-06
JPH11510347A (en) 1999-09-07
AU6665196A (en) 1997-03-05
NZ315055A (en) 1998-10-28

Similar Documents

Publication Publication Date Title
EP0843942B1 (en) Route finding in communications networks
US5435003A (en) Restoration in communications networks
CA2369437C (en) Progressive routing in a communications network
US6147966A (en) Route finding in communications networks
US5537532A (en) Restoration in communications networks
US5748611A (en) System and method for restoring a telecommunications network using conservative bandwidth reservation and selective message rebroadcast
US6272139B1 (en) Signaling protocol for rerouting ATM connections in PNNI environments
US5235599A (en) Self-healing network with distributed failure restoration capabilities
US7126921B2 (en) Packet network providing fast distribution of node related information and a method therefor
US20020118636A1 (en) Mesh network protection using dynamic ring
JPH088972A (en) Path setting control system
CA2228294C (en) Route finding in communications networks
MXPA98000754A (en) Search for route in communication networks
AU695595C (en) Route finding in communications networks
WO1999002009A2 (en) Loop detection
AU695859C (en) Route finding in communications networks
JP2000232481A (en) Bypassing method and system in data communication network without communication
JP2001268101A (en) Network system

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 96196153.8

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1996926490

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 315055

Country of ref document: NZ

ENP Entry into the national phase

Ref document number: 2228028

Country of ref document: CA

Ref document number: 2228028

Country of ref document: CA

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: PA/a/1998/000754

Country of ref document: MX

ENP Entry into the national phase

Ref document number: 1997 508238

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1019980700822

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 09011028

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1996926490

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1019980700822

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1019980700822

Country of ref document: KR

WWG Wipo information: grant in national office

Ref document number: 1996926490

Country of ref document: EP