 | This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Temporally ordered routing algorithm" – news · newspapers · books · scholar · JSTOR (July 2013) (Learn how and when to remove this message) |
The Temporally Ordered Routing Algorithm (TORA) is an algorithm for routing data across Wireless Mesh Networks or Mobile ad hoc networks.
It was developed by Vincent Park and Scott Corson at the University of Maryland and the Naval Research Laboratory. Park has patented his work, and it was licensed by Nova Engineering, who are marketing a wireless router product based on Park's algorithm.
Operation
The TORA attempts to achieve a high degree of scalability using a "flat", non-hierarchical routing algorithm. In its operation the algorithm attempts to suppress, to the greatest extent possible, the generation of far-reaching control message propagation. In order to achieve this, the TORA does not use a shortest path solution, an approach which is unusual for routing algorithms of this type.
TORA builds and maintains a Directed Acyclic Graph (DAG) rooted at a destination. No two nodes may have the same height.
Information may flow from nodes with higher heights to nodes with lower heights. Information can therefore be thought of as a fluid that may only flow downhill. By maintaining a set of totally ordered heights at all times, TORA achieves loop-free multipath routing, as information cannot 'flow uphill' and so cross back on itself.
The key design concepts of TORA is localization of control messages to a very small set of nodes near the occurrence of a topological change. To accomplish this, nodes need to maintain the routing information about adjacent (one hop) nodes. The protocol performs three basic functions:
- Route creation
- Route maintenance
- Route erasure
During the route creation and maintenance phases, nodes use a height metric to establish a directed acyclic graph (DAG) rooted at destination. Thereafter links are assigned based on the relative height metric of neighboring nodes. During the times of mobility the DAG is broken and the route maintenance unit comes into picture to reestablish a DAG routed at the destination.
Timing is an important factor for TORA because the height metric is dependent on the logical time of the link failure. TORA's route erasure phase is essentially involving flooding a broadcast clear packet (CLR) throughout the network to erase invalid routes.
Route creation
A node which requires a link to a destination because it has no downstream neighbours for it sends a QRY (query) packet and sets its (formerly unset) route-required flag. A QRY packet contains the destination id of the node a route is sought to. The reply to a query is called an update UPD packet. It contains the height quintuple of the neighbour node answering to a query and the destination field which tells for which destination the update was meant for. A node receiving a QRY packet does one of the following:
- If its route required flag is set, this means that it doesn't have to forward the QRY, because it has itself already issued a QRY for the destination, but better discard it to prevent message overhead.
- If the node has no downstream links and the route-required flag was not set, it sets its route-required flag and rebroadcasts the QRY message.
A node receiving an update packet updates the height value of its neighbour in the table and takes one of the following actions:
- If the reflection bit of the neighbours height is not set and its route required flag is set it sets its height for the destination to that of its neighbours but increments d by one. It then deletes the RR flag and sends an UPD message to the neighbours, so they may route through it.
- If the neighbours route is not valid (which is indicated by the reflection bit) or the RR flag was unset, the node only updates the entry of the neighbours node in its table.
Each node maintains a neighbour table containing the height of the neighbour nodes. Initially the height of all the nodes is NULL. (This is not zero "0" but NULL "-") so their quintuple is (-,-,-,-,i). The height of a destination neighbour is (0,0,0,0,dest).
Node C requires a route, so it broadcasts a QRY.
The QRY propagates until it hits a node which has a route to the destination, this node then sends an UPD message.
The UPD is also propagated, while node E sends a new UPD.
Route Maintenance
Route maintenance in TORA has five different cases according to the flowchart below as an example:
Partition Detection and Route Erasure
- The links between Nodes D-F and E-F reverse.
- Node D propagates the reference level.
- Node E "reflects" the reference level. The reference heights of the neighbors are equal, with the reflection bit not set. E sets the reflection bit to indicate the reflection and sets its offset to 0.
- Node C propagates the new reference level.
- Node A propagates the reference level.
Route Erasure
When a node has detected a partition it sets its height and the heights of all its neighbours for the destination in its table to NULL and it issues a CLR (Clear) packet. The CLR packet consists of the reflected reference level (t,oid,1) and the destination id.
If a node receives a CLR packet and the reference level matches its own reference level it sets all heights of the neighbours and its own for the destination to NULL and broadcasts the CLR packet. If the reference level doesn't match its own it just sets the heights of the neighbours its table matching the reflected reference level to NULL and updates their link status.
References
- Lakhtaria, Kamaljit I. (31 March 2012). Technological Advancements and Applications in Mobile Ad-Hoc Networks: Research Trends: Research Trends. IGI Global. ISBN 978-1-4666-0322-6.
External links
- TORA Specification (Internet Draft 2001, expired)
- MODIS Group Management of Data and Information Systems