LightBlog
Contact at mumbai.academics@gmail.com or 8097636691/9323040215
Responsive Ads Here

Monday, 12 February 2018

Always Acyclic Distributed Path Computation(2010)



Always Acyclic Distributed Path

 Computation(2010)

Abstract:-
Distributed routing algorithms may give rise to transient loops during path recomputation, which can pose significant stability problems in high-speed networks. We present a new algorithm, Distributed Path Computation with Intermediate Variables (DIV), which can be combined with any distributed routing algorithm to guarantee that the directed graph induced by the routing decisions remains acyclic at all times. The key contribution of DIV, besides its ability to operate with any routing algorithm, is an update mechanism using simple message exchanges between neighboring nodes that guarantees loop-freedom at all times. DIV provably outperforms existing loop-prevention algorithms
in several key metrics such as frequency of synchronous updates and the ability to maintain paths during transitions. Simulation results quantifying these gains in the context of shortest path routing are presented. In addition, DIV’s universal applicability is illustrated by studying its use with a routing that operates according to a nonshortest path objective. Specifically, the routing seeks robustness against failures by maximizing the number of next-hops available at each node for each destination.
Algorithm Used:
Link-state algorithms (LSA) and distance-vector algorithms (DVA)
Algorithm Explanation:
The two algorithms: (i) link-state algorithms (also known as topology broadcast) and (ii) distance-vector algorithms .In both approaches, nodes choose successor (next-hop) nodes for each destination based only on local information, with the objective that the chosen paths to the destination be efficient in an appropriate sense e.g., having the minimum cost. Because end-to-end paths are formed by concatenating computational results at individual nodes, achieving a global objective implies consistency across nodes both in computation and in the information on which those computations are based.
Proposed System:

Link-state algorithms, of which the OSPF protocol is a well-known embodiment; disseminate the state of each node’s local links to all other nodes in the network by means of reliable flooding. After receiving link-state updates from the rest of the nodes, each node independently computes a path to every destination. The period of potential information inconsistency across nodes is small so that routing loops, if any, are very short-lived. On the flip side, link-state algorithms can have quite high overhead in terms of communication storage, and computation. These are some of the reasons for investigating alternatives as embodied in distance-vector algorithms, which are the focus of this paper.
Modules:
1. Distributed Time-to-Live Module:
Time-to-Live (TTL) field in packet headers or a TTL set to a large value. In the presence of a routing loop, a packet caught in the loop comes back to the same nodes repeatedly, thereby artificially increasing the traffic load many folds on the affected links and nodes. The problem, a significant issue even with unicast packets, is further aggravated by broadcast packets, which not only are always caught in any loop present in the network, but also generate replicated packets on all network links. The emergence of a routing loop then often triggers network-wide congestion, which can lead to the dropping or delaying of the very same control (update) packets that are needed to terminate the loop; thereby creating a situation where a transient problem has a lasting effect. Avoiding transient routing loops remains a key requirement for path computation in both existing and emerging network technologies
2. Loop Free Routing Module
The Loop free  routing information dissemination and computation can also result in slower convergence. This is because each node depends on the  computation results of its neighbors, which can introduce cyclic dependencies that increase the number of steps needed to reach a final, correct result. Indeed, when destinations become unreachable, a distance-vector algorithm may not even converge in a finite number of steps. This is known as the counting-to-infinity problem, which is absent from link-state algorithms where nodes compute paths independently.
Loop frees routing Main Features:
1).Separation of Routing and Loop prevention:
DIV separates routing algorithms from the task of transient loop prevention. Emancipating routing decisions from the task of loop-prevention simplifies routing algorithms. In addition, DIV is not restricted to shortest path computations; it can be integrated with other distributed path computation algorithms. We illustrate this in, where we explore a routing algorithm that attempts to increase the robustness of the network in terms of being able to reroute packets immediately (i.e., without the need for any route update) without causing a loop after a link or node failure.
2).Reduced overhead:
When applied to shortest path computations, DIV triggers synchronous updates less frequently as well as reduces the propagation radius of synchronous updates ,where synchronous updates are time and resource consuming updates that might need to propagate to all upstream2 nodes before the originator is in a position to update its path. In fact, synchronous updates may altogether be removed if counting-to-infinity is not a significant issue, alternate mode.
3).Maintaining a path:
A node can potentially switch to a new successor more quickly, while provably still guaranteeing loop prevention This is particularly useful in situations where the original path is lost due to a link failure.
4) Convergence Time:
When a node receives multiple overlapping cost updates3 from its neighbor, DIV allows the node to process and respond to the updates in an arbitrary manner, thus enabling an additional dimension for optimization
5) Robustness:
DIV can tolerate arbitrary packet reordering and losses without sacrificing correctness.
3. Robust Routing Module:
We illustrate the benefits of this decoupling using a cost function that instead of the standard shortest path distance function, seeks to maximize the number of next-hops available at all nodes for each destination. The availability of multiple next-hops ensures that the failure of any one link or neighbor does not impede a node’s ability to continue forwarding traffic to a destination. A failure results in the loss of at most one next hop to a destination, so that the node can continue forwarding packets on the remaining ones without waiting for new paths to be computed. In other words, the routing is robust to local failures. This may be an appropriate objective in settings where end-to-end latency is small and bandwidth plentiful,
4. shortest-path computation Module (or) shortest-path Simulation Module:
The shortest-path Simulations are performed on random graphs with fixed average degree of 5, but in order to generate a reasonable range of configurations, a number of other parameters are varied. Networks with sizes ranging from 10 to 90 nodes are explored in increments of 10 nodes. For each network-size, 100 random graphs are generated. Link costs are drawn from a bimodal distribution: with probability 0.5 a link cost is uniformly distributed in [0,1]; and with probability 0.5 it is uniformly distributed in [0,100]. For each graph, 100 random link-cost changes are introduced, again drawn from the same bimodal distribution. All three algorithms are run on the same graphs and sequences of changes. Processing time of each message is random: it is 2 s with probability 0.0001, 200 ms with probability 0.05, and 10 ms otherwise.
System Specifications:
Hardware Requirements
• SYSTEM            : Pentium IV 2.4 GHz
• HARD DISK      : 40 GB
• FLOPPY DRIVE : 1.44 MB
• MONITOR         : 15 VGA colour
• MOUSE              : Logitech.
• RAM                   : 256 MB
• KEYBOARD      : 110 keys enhanced.
Software Requirements
• Operating system :-  Windows XP Professional
• Front End           :-  Java Technology
• Tool                    :Eclipse 3.3

No comments:

Post a Comment