1 / 17

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

IETF Meeting - OSPF WG. MANET Extension of OSPF Using CDS Flooding draft-ogier-manet-ospf-extension-05.txt. Richard Ogier, SRI International Phil Spagnolo, Boeing November 8, 2005. Changes from Version 04 to Version 05.

gryta
Download Presentation

MANET Extension of OSPF Using CDS Flooding draft-ogier-manet-ospf-extension-05.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-05.txt Richard Ogier, SRI International Phil Spagnolo, Boeing November 8, 2005

  2. Changes from Version 04 to Version 05 • The flooding procedure has been simplified so that the decision to forward a new LSA does not depend on which neighbors are dependent. • To avoid accepting poor quality neighbors, and to employ hysteresis, a router may require that a stricter quality condition be satisfied before changing the state of a MANET neighbor from Down to Init or greater. • To avoid selecting poor quality neighbors as routable neighbors, a router may require that a stricter quality condition be satisfied before declaring a neighbor to be routable. • Subsection 1.1 has been added, which defines commonly used terms.

  3. Changes from Version 03 to Version 04 • The draft was rewritten to specify complete details. • Packet formats are now specified. • The term MANET Designated Router (MDR) is now used instead of Designated Router (DR) for MANET interfaces. • Only a single parameterized MDR selection algorithm is now specified (previously called the MPN CDS algorithm), which includes the Essential CDS algorithm as a special case. This algorithm runs in O(d^2) time, where d is the number of neighbors. • The optional ANP CDS algorithm has been omitted from the draft. • A procedure for selecting the MDR Parent and Backup MDR Parent has been added as Phase 4 of the MDR selection algorithm. • The term "synchronized neighbor" has been changed to "routable neighbor", to reflect that such a neighbor is not perfectly synchronized, but is sufficiently synchronized to be advertised in router-LSAs and used as a next hop. • A new option for partial-topology LSAs, called min-cost LSAs, has been added, which provides minimum cost routes under certain assumptions.

  4. Basic Idea – Generalize Designated Router to MANET Designated Routers (MDRs) • 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 to MDRs, and the edges of the spanning tree become the adjacencies. • The set of MDRs can again be kept small by selecting nodes with largest (RtrPri, RID). • For faster convergence, the MDRs select themselves based on 2-hop neighbor information. As a result, the resulting set of adjacencies is not always a tree.

  5. Also Generalize Backup Designated Router for Biconnected Redundancy • In an OSPF broadcast network, a Backup DR is added for redundancy. • The adjacencies of the DR and Backup DR form a biconnected subgraph. • Each DR Other is adjacent with the DR and the Backup DR. • In a multihop wireless network, Backup MDRs are added so that each node is a neighbor of at least two (Backup) MDRs. • Additional adjacencies can then be added to form a biconnected backbone consisting of MDRs and Backup MDRs. • Each MDR Other selects two (Backup) MDR neighbors called parents, and forms adjacencies with its parents.

  6. Similarities that show (Backup) MDRs are a Natural Generalization of (Backup) DR • In a single-hop MANET, the MDR selection algorithm and OSPF’s DR election algorithm both select the same two routers as DR/MDR and Backup DR/MDR. (The MDR selection algorithm also selects a second Backup MDR to make the backbone biconnected.) • Each DR/MDR Other forms adjacencies with two (Backup) DR/MDR neighbors, and advertises these two neighbors in Hellos. • In both OSPF and OSPF-MDR, if an adjacency exists between two routers, then one of them must be a DR/MDR or Backup DR/MDR. • OSPF-MDR uses the same interface states as OSPF, with the “DR” and “Backup” states implying that the router is an MDR or Backup MDR. • OSPF (in a broadcast network) and OSPF-MDR both allow a non-adjacent neighbor to be used as a next hop, and both originate LSAs (network-LSA for OSPF) that imply that a router can use a non-adjacent neighbor as a next hop. (Due to the general topology of MANETs, a MANET router must explicitly include non-adjacent neighbors in its router-LSA.)

  7. Hello Protocol and 2-Hop Neighbor Info • Each Hello includes a sequence number TLV and potentially includes three node-list TLVs: - Heard Neighbor List(neighbors in Init state)- Reported Neighbor List(bidirectional neighbors)- Lost Neighbor List(recently lost neighbors) • A full state Hello includes all neighbors in state Init or greater. (Each neighbor is in the Heard or Reported Neighbor List.) A full state Hello is sent every 2HopRefresh Hellos (on each MANET interface). • A differential Hello includes only neighbors whose list has changed within the last HelloRepeatCount (default 3) Hellos. Differential Hellos reduce overhead and allow Hellos to be sent more frequently for faster response to topology changes. • Each router maintains each neighbor’s Reported Neighbor List (RNL) obtained from Hellos, which defines the 2-hop neighbor information used by the MDR selection algorithm. • A router may optionally employ hysteresis by requiring a stricter quality condition (e.g., receiving two consecutive Hellos) before changing the state of a new neighbor from Down to Init.

  8. MDR Selection Algorithm (slide 1 of 2) • Phase 1 – Create the Neighbor Connectivity Matrix. The 2-hop neighbor information is used to determine which pairs of neighbors have a bidirectional link between them. • Phase 2 – Determine whether the router is an MDR, and select Dependent Neighbors. • Runs in O(d2) time using BFS to compute paths from the neighbor with largest value of (MDR Level, RtrPri, RID) to the other neighbors, using only neighbors with a larger value of (MDR Level, RtrPri, RID) as intermediate nodes. • Parameter MDRConstraint (default 3) constrains the number of hops allowed in the computed paths. A smaller value (2) results in a larger CDS with a smaller stretch factor. • Using MDR Level gives priority to existing MDRs for increased stability (similar to OSPF’s DR election algorithm). • Dependent Neighbors are used to determine which MDR neighbors to become adjacent with, to ensure the backbone of MDRs is connected. • RtrPri can depend on bandwidth capacity, battery life, node degree, neighbor stability, etc. RtrPri can also be changed dynamically to share the burden of being an MDR among all routers.

  9. MDR Selection Algorithm (slide 2 of 2) • Phase 3 – Determine whether the router is a Backup MDR, and select Backup Dependent Neighbors. • Runs in O(d2) time using an algorithm that computes two node-disjoint paths from the neighbor with largest value of (MDR Level, RtrPri, RID) to the other neighbors. • Backup Dependent Neighbors are used to determine which (Backup) MDR neighbors to become adjacent with, to ensure the backbone of MDRs and Backup MDRs is biconnected. • Phase 4 – Select the MDR Parent and Backup MDR Parent. • (Backup) MDR Parent replaces the (Backup) DR interface variable of OSPF. • If the router itself is an MDR, then the MDR Parent is the router itself, otherwise it is a neighboring MDR. (Similar for Backup MDR.) • The (Backup) MDR Parent is advertised in the (Backup) DR field of each Hello. • If the parameter AdjConnectivity = 2 (biconnected), each MDR Other becomes adjacent with both of its parents, ensuring that the adjacency graph is biconnected. • To maximize stability of adjacencies, the parents are selected persistently, i.e., the existing (Backup) MDR Parent is kept whenever possible.

  10. Example of MDR Selection Algorithm 1 • Node numbers indicate RIDs. • Thin lines indicate bidirectional neighbors. • Red nodes indicate MDRs. • Green nodes indicate Backup MDRs. • Red lines indicate adjacencies associated with MDRs, which form a tree in this case. • Green lines indicate adjacencies added to form a biconnected subgraph. • Each MDR Other becomes adjacent with one MDR and one Backup MDR (or a 2nd MDR). • For example, node 6 does not select itself as MDR, since there is a path from node 8 to each other neighbor via nodes with larger RID. But node 6 selects itself as Backup MDR, 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

  11. Adjacency Maintenance • Adjacencies are formed as follows when biconnected adjacencies are used: • Each (Backup) MDR forms an adjacency with each neighboring (Backup) MDR that is (Backup) Dependent, providing a biconnected backbone. • Each MDR Other forms an adjacency with its (Backup) MDR Parent, creating a biconnected adjacency graph. • For uniconnected adjacencies, omit “Backup” in the above. • An existing adjacency is maintained as long as either the router itself or the neighbor is a (Backup) MDR. Otherwise it is torn down. • To form new adjacencies more quickly in mobile networks, each DD packet includes an MDR TLV, which identifies the MDR Parent and Backup MDR Parent of the sending router. • Database Exchange Optimization: A router (master or slave) performing database exchange does not include an LSA header in its DD packets if it knows the neighbor has the same or newer instance of the LSA. Reduces DD packet overhead by about 50%.

  12. Flooding Procedure • To exploit the broadcast nature of MANETs, an LSA is processed (and possibly forwarded) if it is received from any bidirectional neighbor (not just adjacent neighbors). • A router never forwards an LSA on a MANET interface if either of the following two conditions is satisfied for all bidirectional neighbors on the interface: • The LSA or an ACK for the LSA has been received from the neighbor (over any interface). • The LSA was received on a MANET interface, and the neighbor is “covered” by another neighbor from which the LSA was received. • If an MDR receives a new LSA, it floods the LSA back out the receiving interface if there exists a bidirectional neighbor that does not satisfy condition (a) or (b). • If a Backup MDR receives a new LSA, it waits BackupWaitInterval seconds, and then floods the LSA back out the receiving interface if there exists a bidirectional neighbor that does not satisfy condition (a) or (b). • An MDR Other never floods a received LSA back out the same interface. • An optional step (6) is specified, which avoids redundant forwarding when flooding occurs over multiple MANET interfaces.

  13. Example of MDR Flooding 1 • Node 8 originates and floods a new router-LSA. • If node 7 (MDR) receives the new LSA, it floods the LSA back out the same interface. • If node 6 (BMDR) receives the new LSA, it waits BackupWaitInterval seconds. If during this interval it hears node 7 or 4 forward the LSA, then it does not flood the LSA since all neighbors are covered. Otherwise node 6 floods the LSA unless it has received an ACK for the LSA from nodes 2, 3, and 4. (Nodes 5 and 7 were covered when node 8 flooded the LSA.) • If node 4 (MDR) receives the new LSA from any neighbor, it floods the LSA. • If node 3 (BMDR) receives the new LSA from any neighbor, it waits BackupWaitInterval seconds, and then floods the LSA unless all neighbors are covered. 2 3 4 5 6 7 8

  14. Sending Link State Acknowledgments • All LS ACK packets sent on a MANET interface are multicast using the IP address AllSPFRouters. • The following rules are used for acknowledging a received LSA: • If the LSA is new, send a delayed ACK on each MANET interface, unless the LSA is flooded out the interface. • If the LSA is a duplicate and was received as a multicast, do not send an ACK. • If the LSA is a duplicate and was received as a unicast: • If the router is a (Backup) MDR, send an immediate ACK out the receiving interface. • If the router is an MDR Other, send a delayed ACK out the receiving interface. • Reason for sending an immediate ACK in case (a) is to prevent other adjacent neighbors from retransmitting the LSA.

  15. Receiving Link State Acknowledgments • Each router maintains an Acked LSA List for each adjacent neighbor, to keep track of any LSA instances the neighbor has acknowledged, but which the router itself has not yet received. (Necessary because, unlike RFC 2328, each router acknowledges an LSA only the first time it is received as a multicast.) • An LS ACK packet that is received from an adjacent neighbor is processed as in RFC 2328, with the following additional steps: • If the router receives an LS ACK for an LSA that is newer than the database copy, the LS ACK is added to the Acked LSA List for the sending neighbor. • If a Backup MDR receives an LSA ACK for an LSA for which the BackupWait Timer is set, the sending neighbor is removed from the list of neighbors that have not yet been covered.

  16. Routable Neighbors • A MANET neighbor is defined to be routable if its state is Full, or if the SPF calculation has produced a route to the neighbor and the neighbor satisfies a flexible quality condition. • Only routable MANET neighbors can be used as next hops in the SPF calculation, and can be included in the router-LSA originated by the router. • Note that OSPF already allows a non-adjacent neighbor to be used as a next hop, if both routers are fully adjacent to the DR of a broadcast network. The routability condition is a generalization of this condition to MANETs. • The network-LSA of an OSPF broadcast network implies that a router can use a non-adjacent neighbor as a next hop. But a network-LSA cannot describe the general topology of a MANET, making it necessary to explicitly include non-adjacent neighbors in the router-LSA. • Allowing only adjacent neighbors in LSAs would either result in suboptimal paths or would require a large number of adjacencies.

  17. Link State Advertisements • The choice of which neighbors to include in the router-LSA is flexible, subject to only two requirements: • A router MUST include all Full neighbors in its router-LSA. • A router MUST NOT include any non-routable neighbors in its router-LSA. • Four options for the router-LSA, depending on LSAFullness: • Minimum LSAs: Include only fully adjacent neighbors. • Full LSAs: Include all routable neighbors. • MDR Full LSAs: Only (Backup) MDRs originate Full LSAs, other routers originate Minimum LSAs. • Min-Cost LSAs: Include the minimum set of neighbors to provide a 2-hop path between each pair of neighbors, based on the neighbors’ LSAs. Provides min-hop routing if all link costs are equal. Provides min-cost routing under certain assumptions. • The four LSA options are interoperable with each other, since they all satisfy the above two requirements.

More Related