|
Let me address just that
particular NIRA-objective which this mailinglist’s discussion is all about, its
design and yes, also soon, the hereby needed algorithmic technology as to
compute consistently viewed hierarchical topologies. For that computation only a
minor enhancement of the Dijkstra is required, but not the entire All Links Spanning Tree (ALST). But step by
step. Prior contributing this small though important puzzle as to show the HOW,
I think it’s appropriate to show at first WHAT shall be accomplished as well as
WHY this protocol development will get us out of the BGP-trap or better said
aggregation-trap (an imaginary world-wide OSPF would have the same
problems). WHAT:The goal is that each router
aquires a hierarchical network view, where the current router is surrounded by a
network of strict links, which is surrounded by a network of looser … and looser links. For proper understand
WHY so, let me give the following example: Imagine to be at some street
junction in Munich, Germany, and you want to get to
Sausolito. You have available road maps, for
Munich, Bavaria, Germany, Europe and a world map which e.g. contains only 4
US-cities: New York, Chicago, L.A., Miami. But none of your maps shows Sausolito !!!
Here, BGP would give up! But let’s assume, you also know the
geographical coordinates of Sausolito as well as of all nodes of all your nodes
on your maps.( 1 degree precision is enough, no minute or second precision is
required.). Let’s also assume you can by some procedure combine all your maps to
a single map whereby your closer zoomed available map information replaces the respective part in the less
zoomed map. You may find out that L.A. is closest to your destination and use
the L.A. node as the destination node for determining the best next hop – here
to the next street in Munich towards the Munich airport. Later, you may arrive
in NY, and your current country map would also show San Francisco, but still not
Sausolito.So you would make the best next hop being bound to S.F. Whenever you
arrive in California, you may also see Sausolito on your current state map and
determine the best next hop bound to Sausolito. However, as soon as you have reached a
router which has the same geographical coordinates like your destination, this
kind of information cannot help you any further. Yes from now on you need
guidance based on aggregated prefix information as to determine the proper
destination node on your map as we are used to. So prefix propagation can be
limited to a 1-degree-square. Note, how powerful the„<=“ operator was,
when L.A. was selected, compared to
„==“. Mathematical analogy: If you want to find out whether the real
number x is between 0 and 1 you don’t have to compare x with all real numbers in
this interval. Now the big thing is to build the
proper hierarchical network, i.e. the combined topology of the various maps of
different zoom. Each loose link must have the right length (weight)
! There must be a clear understanding
which 1-degree-squares would be contained
within which more upper map. This is subject to „well-known“ standardization
information. Although the borders should be
determined by clean longitude/latitude values and not by political areas like
counties, states, countries, continents, let me, for better understanding, use
such political terms by the following. Example: A state map shall be built
based on all county maps thereof. Each county node router computes the (same
identical) county’s contribution
for this state map, i.e that set of loose links by which it shall be represented
in the next upper topology. Hereby it is sufficient that each node of the county
knows all those county nodes that shall show up in the state map. This information needs to be exchanged
across the borders of neighboring counties of the same state. Not of different
states; that would be required in the next recursion cycle. The process is
similar to forming a PNNI hierarchy. Like there we would have to deal with uplinks (for combining
maps of different zoom) and hierarchical horizontal links, but there are some
important differences. An uplink is not the aggregation of a group of
border-to-border physical links.Instead its upper end is some representative
node of the neighboring county. Instead of the inmature Logical
Group Node Representation with spokes and nucleus etc, we would have well-computed representative
topologies, in the precisely same manner as when we have road maps for cities,
counties, states, countries, continents. If DNS-lookup not only provided the
destination IPv4-address but also the longitude/latitude information, and if we
computed for each visible node the best next hop, which includes each visible
hierarchically upper node, then we could place the best next hop info into a
matrix with 360 x 360 elements, and could retrieve it by means of a single
access (at least in case of hierarchically upper dest.
nodes) Yesterday I received the Internet
Journal with contributions about the IPv4 address
depletion. Maybe IPv4 addresses have only to be
unique 1-degree-square-wide rather than world-wide ?! It may of course be up to the
ID-utilization (besides the LOC-utilization), but eventually this solution may
also avoid this depletion dilemma. LISP-CONS: Look, there is no
political quarrel about the proper allocation of longitudes/latitudes. They are
already properly positioned and do not need any dissemination process. By taking
geographical coordinates also as address info, then it is appropriate to
speak of building some (hierarchical) topology that follows addressing
:-) Routing churn: You will see, a loose
link like Chicago---L.A. would only go down in case of a power black out
throughout the western part of the USA. Hence the looser the link, the less the
churn. Rome was not built in one day. Nor this concept. It may take some time for being developed. But it has immense beneficial objectives, which really can be accomplished. Heiner |