1 / 18

Design of a Fault-Tolerant Link Establishment Protocol

Design of a Fault-Tolerant Link Establishment Protocol. Stephen Horan and Giriprassad Deivasigamani Telemetering Center Klipsch School of Electrical and Computer Engineering New Mexico State University Las Cruces, NM 88003-8001.

zelda
Download Presentation

Design of a Fault-Tolerant Link Establishment Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design of a Fault-Tolerant Link Establishment Protocol Stephen Horan and Giriprassad Deivasigamani Telemetering Center Klipsch School of Electrical and Computer Engineering New Mexico State University Las Cruces, NM 88003-8001 This material is based upon work supported by the National Aeronautics and Space Administration under Award No. NAG5-13189.

  2. Topics • Goals and Assumptions • Background • Comparison with Ad Hoc Routing Protocols • Software Design • Protocol Testing • Results • Next Steps • Conclusions • References Fault-Tolerant Link Establishment Protocol

  3. Goals and Assumptions • Develop a protocol to address link establishment for satellite clusters • Assume 10’s to 100’s of nodes are possible in the network • Assume not all nodes are mutually visible at all times • Assume channel errors are possible • Assume satellites may fail and recover Fault-Tolerant Link Establishment Protocol

  4. Goals and Assumptions • Operational assumptions • Satellite cluster access from the ground will be limited to well-known access points and trusted users • Many nodes and access points can be pre-loaded before launch. In particular, the entire expected cluster membership roster may be known before launch. • Wish to minimize the amount of overhead in transmitting path information. Fault-Tolerant Link Establishment Protocol

  5. Background • Look to the world of ad hoc networking for possible solutions • Settled on a method proposed by Chaing et al. [1] based on its ability to work in impaired channels and having minimal path overhead • Also looked at routing protocols such as Ad hoc On-Demand Distance Vector (AODV) [2] –[3] and Dynamic Source Routing (DSR) [3] –[4] Fault-Tolerant Link Establishment Protocol

  6. Comparison with Ad Hoc Routing Protocols • Some of the main differences are between AODV, DSR, and the approach chosen in this study are: • AODV and DSR assume no a priori node information while our approach assumes that the network may be pre-seeded with participating nodes, • AODV and DSR assume that the networks will be open while our approach assumes that network access will be limited to “trusted” nodes, • AODV and DSR use routing caches for routing information while our approach uses a routing table to hold the routing information, Fault-Tolerant Link Establishment Protocol

  7. Comparison with Ad Hoc Routing Protocols • Comparison with AODV and DSR (cont.) • AODV and DSR obtain routing information in an on-demand manner while our approach keeps the routing information in a Routing Table, • AODV and DSR can drop a link due to a single link error while our approach will not declare a link to be down until after several messages have failed, • DSR send all of the required routing information in the data package header, while AODV and our approach requires that all intermediate nodes have sufficient path information locally, • AODV and DSR assume that the inter-node link range is < 500 m (802.11-type link) while the satellite cluster algorithm needs to cover in excess of 1000 km. Fault-Tolerant Link Establishment Protocol

  8. Software Design • The protocol specification details can be found in [5] and they can be summarized as follows: • Use a Routing Table pre-seeded with the expected cluster nodes and allow new, trusted nodes to be added later; • Use periodic Heartbeat messages to probe the channel for broken links and let the message interval be user-defined and only send the messages to neighbors within one hop; • Use a periodic Token passing mechanism to control access within a subnet under the assumption that the overall cluster may need to be partitioned because not every node may be visible to every other node; Fault-Tolerant Link Establishment Protocol

  9. Software Design • Software design (cont.) • Send Routing Table updates from a given node to its one-hop neighbors only when that node detects link connectivity changes or it receives better link information from one of its neighbors; • Use Cluster Heads to control Token passing within each sub-net where the Cluster Head is defined as that node in the sub-net with the lowest IP address that is one hop away from all members of the sub-net; • When a Cluster Head fails or moves away from a sub-net, the survivors determine the next Cluster Head by the one with the lowest IP address. Fault-Tolerant Link Establishment Protocol

  10. Software Design • Use the LabVIEW toolkit State Diagram to design the protocol software • Designing a modular state diagram to realize the algorithm • Will also allow us to try different state processing to experiment with alternatives States in the Cluster control VI that will be on every node in the cluster. Fault-Tolerant Link Establishment Protocol

  11. Software Design • States can be expanded to describe the state machine for the individual states • Cluster Head and Slave nodes have the same state diagram except for Token generation • The toolkit allows easy manipulation of the state diagrams. Example: Cluster Head state diagram Fault-Tolerant Link Establishment Protocol

  12. Software Design • Finally, the toolkit is used to describe the lower level states. • Again, the processing can be easily modified to change the processing approach. • At this point, the states are nearly all single-function modules. Example: processing a Heartbeat message Fault-Tolerant Link Establishment Protocol

  13. Protocol Testing • Testing program to-date [6] has concentrated on verifying the functional correctness of the modules relative to the specifications we developed in [5]. • Testing included scenarios where Cluster Head failed, link failed, etc. and then returned. • Current testing is with three nodes. It can be expanded to seven nodes easily. Fault-Tolerant Link Establishment Protocol

  14. Results • The capabilities demonstrated in this testing included: • The ability to use IP addresses as the means to control node designations as either a Cluster Head or Cluster Slave and have these designations based upon the current contents of the Routing Table. • The ability to use the contents of the Routing Table to • determine the path of the Token through the Cluster members, • determine which cluster members are to receive a Heartbeat message from each node, • determine which cluster members have become inactive or unreachable. • The ability to transmit Heartbeat messages with a predetermined re-issue period to probe the cluster for unreachable members. • The ability to transmit Token messages with a predetermined re-issue period to allow nodes to control data traffic. Fault-Tolerant Link Establishment Protocol

  15. Results • The capabilities demonstrated in this testing included: • The ability to exchange Routing Table messages between the cluster members and update this Table based upon changing conditions. • Persistence in the transmission of Heartbeat messages until the time-out period is exceeded. • Persistence in issuing Token messages and nodes are not removed from the Token path until the time-out period has expired. • The ability of the Cluster Head to control the issuing of Token messages. • The ability of the cluster nodes to select a new Cluster Head if the original Cluster Head fails or becomes unreachable. Fault-Tolerant Link Establishment Protocol

  16. Next Steps • Make a version of the protocol in C so that it can be used with the NASA/GSFC SDR testbed • Introduce channel errors as well as link failures into the testing scenario • Develop quantitative metrics of performance for different test scenarios Fault-Tolerant Link Establishment Protocol

  17. Conclusions • We have shown that we can use the State Diagram toolkit to design and realize a cluster link establishment protocol that can operate on several nodes. • The testing so far has shown basic functionality of the selected routing and control algorithm. • Next testing is to integrate with NASA testbed and add channel errors into the evaluation process. • State diagram is highly modular so that algorithm alternatives can also be investigated. Fault-Tolerant Link Establishment Protocol

  18. References • [1] C-C Chiang, H-K Wu, W. Liu, M. Gerla, “Routing in Clustered Multihop, Mobile Wireless Networks with Fading Channel,” IEEE Singapore International Conference on Networks, 1997, p. 197 - 211. • [2] C. E. Perkins, E. M. Royer, I. D. Chakeres, “Ad hoc On-Demand Distance Vector (AODV) Routing,” Internet Draft draft-perkins-manet-aodvbis-00.txt, October 2003. • [3] C. E. Perkins, E. M. Royer, S. R. Das, and M. K. Marina, “Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks,” IEEE Personal Communications, Feb. 2001, 16 – 28. • [4] J. Broch, D. B. Johnson, and D. A. Maltz, “The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks,” Internet Draft draft-ietf-manet-dsr-01.txt, December 1998. • [5] S. Horan and G. Deivasigamani, “Link Establishment Algorithm Development – Phase I,” NMSU-ECE-04-004, Las Cruces, NM, May 2004. • [6] S. Horan and G. Deivasigamani, “Link Establishment Algorithm Development – Test Report,” NMSU-ECE-04-005, Las Cruces, NM, May 2004. Fault-Tolerant Link Establishment Protocol

More Related