Subject: [Fwd: [Ospf-wireless-design] Synchronization requirement for including a neighbor in LSA]

From: Richard Ogier <[email-masked]>
Date: Thu, 14 Jul 2005 12:53:46 -0700

All,

To continue the dicussion of whether non-adjacent neighbors should be
advertised in router-LSAs, as proposed in Section 5 of
http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-03.txt

I will first repost my message of March 31.
In my next email, I will post a preview of the next version
of the draft, in which the term "synchronized" neighbor has been
changed to "routable" neighor (since it is not perfectly
synchonized). This has been implemented in GTNetS for a while.

Richard

-------- Original Message --------
Subject: [Ospf-wireless-design] Synchronization requirement for 
including a neighbor in LSA
Date: Thu, 31 Mar 2005 12:17:37 -0800
From: Richard Ogier <[email-masked]>
To: [email-masked]

All,

I want to discuss the definition of a "synchronized" neighbor
in Section 5 of my draft, and explain why I think this is a
good requirement for a neighbor to be included in the router LSA.
This condition is valid for both full-topology and partial-topology
LSAs, so the discussion below applies to either case.

First, I am assuming that a set of adjacencies has been formed
that spans the entire network, so that there exists a (suboptimal)
path from each router to every other router via adjacent edges
(except temporarily as new adjacencies are formed in response
to topology changes).

Each router will include, at a minimum, each fully adjacent neighbor
in its router LSA. This will provide suboptimal routes to each
reachable router.

The question is, what other neighbors can be included in the router LSA?

Suppose that node i has a non-adjacent, 2-way neighbor j, and that
the SPF calculation has calculated a route to node j via a fully
adjacent neighbor k. Then node i can route data packets to neighbor j
via neighbor k. (Or, neighbor j might not be the final destination,
but might be an intermedate node to another destination.)
So, instead of using neighbor k as the next hop, why not take
a shortcut and forward the data packet directly to neighbor j
as the next hop?  This is quite reasonable, and is exactly what
the synchronized neighbor rule says.

Once neighbor j has been declared to be an acceptable next hop
(to any destination), it can be included in node i's router LSA.

Note that this is a generalization of what is allowed in an OSPF
broadcast network, which allows a non-DR/BDR i to use another
non-DR/BDR j as a next hop as long as both are fully adjacent to
the DR.  In a broadcast network, there is no need for node i
to include node j in its LSA, since the network LSA originated
by the DR already implies this information. But when we
generalize to a multihop network, the only way node i can
inform other routers that it can forward packets to node j,
is to include node j in its router LSA.

A possible concern: What if, after declaring node j to be an
acceptable next hop, there temporarily does not exist a path
of fully adjacent edges to node j, due to topology changes?
The above rule does not detect this and does not remove node j
as an acceptable next hop (unless node j is no longer reachable).

The answer is that the protocol will be robust enough (if designed
properly) to maintain sufficient database synchronization even
when topology changes cause old adjacencies to fail and require
new adjacencies to be formed.

The only case where routers may not be acceptably synchronized
is when the network partitions, i.e., some destinations become
temporarily unreachable.  The above rule will detect this,
since it requires a neighbor to be reachable via a current path
that has already been determined to be acceptable.

I plan to implement the above method in the next few weeks,
so we will see how it peforms.

Richard

_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design