[Nsi-wg] Regarding Pathfinding and Topology
Jerry Sobieski
jerry at nordu.net
Sat Dec 10 10:52:22 EST 2011
Regarding Path Finding:
If we go back to [technology agnostic] basics of graphs and path
finding, a "topology" is fundamentally a database of vertices and
edges. A vertex is considered to be "adjacent" to another vertex if
there is an edge directly connecting the two vertices.
Path Finding is the exercise of constructing an ordered list of vertices
beginning with the starting vertex and ending with the terminating
vertex, and consisting of a set of intermediate vertices each of which
is adjacent in the topology to the preceding vertex in the path list.
There are some basic assumptions in the above definition of "path" that
we need to be explicit about.
First, we need to keep in mind that paths do not just magically appear.
We need to analyze the topology to construct a path. We start by
placing the Start point onto our [empty] path list. Then we build up
the path by examining adjacencies. Since the next element in the path
must be adjacent to its predecessor, this forms a constraint on
selecting the next element in the path list: It must be adjacent to the
Start point.
But there may be *several* ( j ) vertices that are adjacent to the start
point. They all represent equal possibilities. So we need to
construct now "j" separate paths - each with the Start, and each with a
different one of the j adjacent elements. So now we have to explore
each of the j possible paths for their adjacencies to add the third
element. And so on. For a large highly connected graph, the possible
number of paths explodes. We need additional constraints to prune
this tree...
So what if adjacency was not the only constraint? What if we added a
constraint called "color" and said find a Blue path. We can check each
adjacent vertex to see if it is Blue and prune all paths who's
adjacencies are not Blue. So now we have a set of partially built
Paths whose elements are adjacent, and Blue. We can continue this
constraint based search of the resources based upon these two
constraints. At each stage if a path has no Blue adjacency (besides the
preceding node) we can prune it. At some stage the last constraint
will be met - the next adjacent element will the Finish point and we
have "found a path".
When we finally analyze all of our potential paths for these
constraints, we may find that we have actually found *multiple*
acceptable Blue paths. Which one shall we choose? Well, we only
needed one, and since all the paths meet the constraints, it does not
matter which we choose. Any will do as far as the initial (user)
constraints are concerned. Note: These paths are not all the
same...the paths may differ significantly in, say, the number of hops.
But since this aspect (number of hops) was not a constraint on the
initial path selection, then it does not matter now and the final
constraint can actually be anything that identifies a single path, e.g.
a random choice. From the PF perspective all of these paths have met
the constraints and are acceptable.
We can continue to discuss possible PF algorithms and issues, but its
important to take stock now, and note some basic observations about this
above example. We need to expose rather subtle assumptions.
---> Another assumption: _/*Each vertex could be traversed in any
direction.*/_ I.e. from any adjacency to any other adjacency. What if
for some reason there were limits on the vertex that would only allow
paths to traverse the vertex in certain ingress/egress pairs? How would
this be expressed to the PF agent(s)? What if every vertex had some
nuance that imposed some random but invariant quirk on the transit
function of the vertex? How would we represent these nuances so that a
PF could evaluate any node in the topology as to its useability in the path?
--->A basic assumption: _/*The topology was static.*/_ It did not
change while we selected the path. Were it to change, other vertices
or edges (adjacencies) might have appeared that would create alternate
paths. Or some vertices or edges might have disappeared that now
invalidate some of our resulting paths. TIme varying availability
causes much problems in large scale PF.
---> Another assumption: _/*Resources were not consumed*/_. We did not
consider if a vertex was "used up" or no longer available. I.e. what
if we said that a vertex can only be traversed once? or a fixed number
of times. Closer to home: What if we had a bandwidth constraint? An
otherwise conforming vertex may not be useable because it ran out of
internal resource...I.e. for some reason and at some point in time, a
vertex is no longer available. How do you know?
---> Another assumption: _/*There is only one path finder operating on
the topology*/_. What if there are two (or more) pathfinders
constructing paths simultaneously.??? This is highly relevant to our
current NSI issues. We need to assume there will be more than one
global pathfinder and these will need to interact cooperatively if we
want to maintain a reliable system. Combined with consumable
resources, we have a *real* big problem. Every time we insert a new
element on one of those k potential paths, the PF needs to make sure
that vertex reflects the use of the resource. What if there were 100
PFs running? 1000 PFs? 10000? What if the each pathfinder was
constructing a k-SPF trees with k=10, or 100, or 1000? How does the
number and complexity of the search algorithm affect scalability?
---> Another assumption: _/*There was one generic well behaved PF. */_
I.e. What if one PF implemented a greedy algorithm - e.g. I will go grab
all the resources I can and then I will release those I deem unnecessary
for this path. If different PF algorithms are implemented, how could
this affect the distributed system? Do we need to specify the
appropriate algorithm?
---> Another assumption. _/*There is one global topology database*/_
that holds all that is known of the topology. And all path finder(s)
have access to this information. Given time varying state, how do we
know if a resources are still available on any node?
Enough for now. Please try to think about the implications of the
issues outlined above. We need to sort through these to arrive at a
workable long term approach to PF and Topology.
tinfo/nsi-wg
Thanks for reading...
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20111210/189f2780/attachment.html
More information about the nsi-wg
mailing list