1 / 23

MANET Extension of OSPF Using CDS Flooding draft-ogier-manet-ospf-extension-03.txt

IETF Meeting - OSPF WG. MANET Extension of OSPF Using CDS Flooding draft-ogier-manet-ospf-extension-03.txt. Richard Ogier March 2, 2005. Basic Idea – Generalize Designated Router to Multihop Wireless Networks.

tim
Download Presentation

MANET Extension of OSPF Using CDS Flooding draft-ogier-manet-ospf-extension-03.txt

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. IETF Meeting - OSPF WG MANET Extension of OSPF Using CDS Floodingdraft-ogier-manet-ospf-extension-03.txt Richard Ogier March 2, 2005

  2. Basic Idea – Generalize Designated Router to Multihop Wireless Networks • In an OSPF broadcast network, the DR and its adjacencies form a tree with n-1 edges. • The DR is the only interior node of the tree, and is a connected dominating set (CDS). • All nodes agree on a single DR, by selecting the node with largest (RtrPri, RID). • In a multihop wireless network, a CDS can have multiple nodes. These are again the interior nodes of a spanning tree. • The CDS nodes generalize the notion of a DR, and the edges of the spanning tree become the adjacencies. • The set of DRs can again be kept small by selecting nodes with largest (RtrPri, RID). • For faster convergence, the tree can be “approximate”, with more than n-1 edges, based on 2-hop neighbor information.

  3. Also Generalize Backup Designated Router for Biconnected Redundancy • In an OSPF broadcast network, a BDR is added for redundancy. • The adjacencies of the DR and BDR form a biconnected subgraph. • Each non-DR/BDR node is adjacent with the DR and the BDR. • In a multihop wireless network, BDRs can be added so that each node is a neighbor of at least two DR/BDR nodes. • Additional adjacencies can then be added to form a biconnected subgraph. • Each non-DR/BDR node is adjacent with one DR and one BDR (or a 2nd DR). • The DR/BDR selection and adjacencies shown in the example were computed by the proposed Essential CDS algorithm.

  4. Essential CDS Algorithm • Uses 2-hop neighbor information obtained from Hellos. • Essential CDS Algorithm: • If the router has a larger (RtrPri, RID) than all of its neighbors, it selects itself as a DR, and selects all neighbors as Dependent Neighbors, which become adjacent. (Same as DR selection in OSPF.) • Else, if there does not exist a path (based on 2-hop neighbor information) from the neighbor j with largest (RtrPri, RID) to some other neighbor, via neighbors with larger values of (RtrPri, RID), then the router selects itself as a DR, and selects j and each neighbor for which such a path does not exist, as Dependent Neighbors, which become adjacent. • BDR selection is similar, but requires 2 node-disjoint paths from neighbor j to each other neighbor, to avoid selecting itself as BDR. • “Persistent” version gives higher priority to existing DRs and BDRs. • Algorithm runs in O(d2) time, where d is the number of neighbors.

  5. Example of Essential CDS Algorithm 1 • Node numbers indicate RIDs. • Thin lines indicate neighbors. • Red nodes indicate DRs. • Green nodes indicate BDRs. • Red lines indicate adjacencies associated with DRs, which form a tree in this case. • Green lines indicate adjacencies added to form a biconnected subgraph. • Note that each non-DR/BDR node is adjacent to one DR and one BDR (or a 2nd DR). • For example, node 6 does not select itself as DR, since there is a path from node 8 to each other neighbor via nodes with larger ID. But node 6 selects itself as BDR, since there do not exist two such paths from node 8 to neighbors 2, 3, 4, and 7. 2 3 4 5 6 7 8

  6. Family of Interoperable CDS Algorithms • A larger CDS may be preferred in some cases, e.g., to provide flooding along shorter paths (smaller stretch factor). • The following optional algorithms are interoperable because the CDS computed by each algorithm contains the CDS computed by the Essential CDS algorithm. • Maximum Priority Neighbor (MPN) CDS algorithm: Requires that the path computed from the neighbor with largest (RtrPri, RID) to each other neighbor in the Essential algorithm, be at most k hops. • All Neighbor Pairs (ANP) CDS algorithm: Requires that the path computed from each neighbor to each other neighbor be at most k hops. • Simulation results show that the MPN and ANP algorithms (with k = 2 and 3) reduce stretch factor at the cost of a larger CDS.

  7. Choice of Router Priority Each router can select its Router Priority dynamically, e.g., using the following criteria: • The Bandwidth capacity of node: higher priority for higher bandwidth • Neighbor stability (average lifetime of neighbors): selecting nodes with stable neighbors will increase the lifetime of adjacencies. • Node degree: higher priority for larger degree reduces number of DRs for small networks, but not for large networks (see simulation results). Makes CDS less stable since node degree changes. • Willingness to be a relay (e.g., due to battery life). • A router that has been a DR or BDR for a certain amount of time can reduce its Router Priority, so that the burden of being a DR/BDR can be shared among all routers.

  8. Adjacencies • Adjacencies are formed only between each DR/BDR router and its (Backup) Dependent Neighbors as selected by the CDS algorithm. • The following enhancement greatly reduces the rate at which new adjacencies are formed, when the persistent version of the Essential CDS algorithm is used: • Each DR/BDR router forms an adjacency with each (Backup) Dependent Neighbor that is a DR/BDR router. • Each non-DR/BDR router selects two DR/BDR neighbor (one of which must be a DR), and forms adjacencies only with these two neighbors. These adjacencies are kept as long as both are DR/BDR neighbors and one of them is a DR. • The two selected DR/BDR neighbors are included in the DR and BDR fields of each Hello, as in legacy OSPF.

  9. Link State Advertisements • Since a network LSA cannot describe a general topology, each router originates a router LSA that represents neighbors as point-to-point links. • The choice of which neighbors to include in LSAs is flexible, allowing partial or full topology information to be disseminated. • Each router MUST include all fully adjacent neighbors in its router LSA. (Provides suboptimal paths to all nodes.) • Each router may include any “synchronized” neighbor in its router LSA, where a neighbor j is considered synchronized if a path to node j can be calculated from the link-state database (implying there exists a path to node j via fully adjacent links). • To disseminate partial topology information from which min-hop paths can be computed, each router may include all “Min-Hop Dependent Neighbors” in its LSA (computed using the ANP algorithm as described in the draft). • To disseminate full topology information, each router may include all synchronized neighbors in its router LSA.

  10. Flooding Procedure • Each DR forwards a new LSA the first time it is received, regardless of which neighbor it was received from (source independent flooding). • If the router has multiple interfaces, then the new LSA is forwarded only on interfaces associated with Dependent Neighbors that are not covered by the neighbor from which the LSA was received. • Each BDR forwards a new LSA after a small delay, if the neighbors from which the LSA has been received do not cover all Backup Dependent Neighbors. • If the router has multiple interfaces, then the new LSA is forwarded only on interfaces associated with Backup Dependent Neighbors that are not covered by neighbors from which the LSA was received. • Source-dependent flooding is allowed as an option, to provide flooding along min-hop paths if desired. • Note that the flooding procedure is described without mentioning adjacencies. This allows it to be used in other MANET applications.

  11. Retransmitting LSAs • LSAs are retransmitted only along adjacencies, as in OSPF. • Thus, retransmitted LSAs are sent only between DR/BDR routers and non-DR/BDR routers. • One advantage: DR/BDR routers can group together several retransmitted LSAs into the same LSU packet, thus reducing overhead and avoiding a large number of retransmitted LSAs between non-DR/BDR routers. • Link State Acknowledgments are always multicast. An LSA received as a multicast is acknowledged only the first time it is received, and must be processed even if received from a 2-way neighbor that is not adjacent.

  12. Differential Hellos • Differential Hellos report only changes in neighbor states. • Hellos also report full or partial neighbor information periodically, to provide 2-hop neighbor information to neighbors. • Using differential Hellos allows Hellos to be sent more frequently, allowing faster response to topology changes. Changes to 2-hop neighbor information are reported quickly in differential Hellos. • The CDS algorithms require only partial 2-hop neighbor information, i.e., the (Backup) Dependent Neighbors of each neighbor. • Thus, only Dependent Neighbors need to be reported periodically in Hellos. In particular non-DR/BDR routers (which have no Dependent Neighbors) only need to send differential Hellos, and never need to send full Hellos or report any neighbor information periodically. • Advantage of CDS approach: A non-DR/BDR router never needs to include all of its neighbors in either a Hello or an LSA.

  13. Proposed Enhancements • Non-ackable LSAs for periodic flooding • For LSAs that are updated frequently due to topology changes. • Each DR periodically retransmits each non-ackable LSA as a multicast (until a new instance is received). • Non-ackable LSAs are never ACKed or retransmitted as a unicast. • Multicast retransmitted LSAs • Avoids separate unicast retransmissions to several neighbors. • Includes a list of neighbors that must ACK the LSA. • Optimized database exchange. • Only the master needs to include all LSA headers in DD packets. • After receiving DD packets from the master, the slave only sends LSA headers that the master does not have.

  14. Simulation Results for CDS Size • Table shows average number of DRs computed by Essential CDS algorithm. • Better scalability to 300 nodes is achieved if node degree is not used (probably because nodes with largest degree are concentrated near the center of the cluster). • Another advantage of not using node degree: CDS is more stable.

  15. Simulation in Mobile Networks • Algorithm simulated: Essential CDS algorithm, persistent version. • Mobile network model: • Nodes are placed randomly in unit square. • Random direction is selected initially for each node. At each step, each node moves 1/10 of transmission radius in its selected direction, bouncing off sides of square as in billiards. Simulation is run for 500 steps. (Each step can be 1 sec for very fast mobility.) • Two values used for transmission radius: 0.3 and 0.5. • Performance measures: • Average number of DRs and BDRs. • Average number of adjacencies, compared to average number of total edges. • Average rate of new adjacencies per step, compared to average rate of new edges per step. (Important since database exchange must be performed for each new adjacency.)

  16. Simulation in Mobile Networks (cont.) 100 nodes placed randomly in unit square (elongated for easier viewing).

  17. Simulation in Mobile Networks (cont.) For radius = 0.5, there are about 2384 edges (shown). Should all edges be adjacencies? Probably not.

  18. Simulation in Mobile Networks (cont.) Biconnected backbone consisting of DRs (red), BDRs (green), and adjacencies between them (red lines). Computed by Essential CDS algorithm.

  19. Simulation in Mobile Networks (cont.) Gray lines indicate adjacencies of non-DR/BDR routers. Note that each non-DR/BDR router is adjacent to exactly two DR/BDR routers. Total number of adjacencies for this scenario is about 200 (twice the number of nodes).

  20. Simulation in Mobile Networks (cont.) Animation showing movement of nodes in simulation. Note that most adjacencies are relatively stable as nodes move. In this scenario, the rate of new edges is 7.19 times the rate of new adjacencies.

  21. Simulation in Mobile Networks (cont.) Results for persistent version of Essential CDS algorithm, for radius 0.5

  22. Conclusions from Simulations • While the number of edges (and rate of new edges) increases quadratically with the number of nodes, the number of adjacencies (and rate of new adjacencies) with the CDS algorithm increases only linearly. • Also, the number of DRs and BDRs increases only slightly as the number of nodes increases from 100 to 300. • Therefore, the CDS approach is more scalable than the approach of forming adjacencies with all neighbors. • Main conclusion:The DR/BDR approach of OSPF generalizes naturally and efficiently to MANETs. Therefore, it is not necessary to replace this approach with something completely different.

  23. Summary of Features • A scalable CDS algorithm (and family of interoperable CDS algorithms) is proposed, which generalizes the OSPF concept of a DR and BDR in a natural way. • The set of DRs forms a CDS, and the set of DRs and BDRs forms a biconnected CDS for robustness. • The number of DRs and BDRs, the number of adjacencies, and the rate at which new adjacencies are formed, are all found to be scalable in simulations. • The CDS algorithm uses only 2-hop neighbor information from differential Hellos, allowing fast convergence following topology changes. • Only partial 2-hop neighbor information is required. Thus, a non-DR/BDR router never needs to include all of its neighbors in either a Hello or an LSA. • The computed CDS provides source-independent flooding of LSAs (or other packets). The flooding procedure also allows source-dependent flooding as an option, if it is desired to flood packets along min-hop paths. • The choice of which neighbors to include in LSAs is flexible, allowing dissemination of partial or full topology information.

More Related