In einer eMail vom 12.07.2008 02:57:44 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
On Fri, Jul 11, 2008 at 7:05 PM, <[EMAIL PROTECTED]> wrote: > My understanding of what you want is this: forwarding from C to B is not > allowed. Hence the packet from D to E must go like > this: D--->C-->G-->F-->E and NOT D-->C-->B-->F-->E. > My saying is: That can be respected. But this is almost normal Dijkstra.Only > the following enhancements are required: Build a graph, which consists of > these nodes A,..H and of directed arrows. Between any two nodes according to > the black lines there are two inversely directed arrows.Except between B > and C. Here there is only one arrow which is from B to C, but not from C to > B. > Node C runs Dijkstra with itself being the root, however modified such that > selecting a predecessor node for any node presumes that there is an arrow > from that predecessor node to that "any"-node. So , while running Dijkstra, > C won't even see that B is a neighbor/candidate.Hence the resulting shortest > path tree will not include "from C to B" but only "from C to G". Okay. I added what I think you just described in red at http://bill.herrin.us/network/geoag-h1.gif. Is that correct? Yes. This means that the forwarding information base at node G looks like: destination {left area}: send to F destination C: send to C destination H: send to H destination D: send to C And the FIB at node C looks like: destination {left area}: send to G destination G: send to G destination D: send to D destination H: send to G Is that correct? Yes. So, D--->C-->G-->F-->E happens for packets from D to E because when the packet is at C, C understands that all of {left area} is available via G and when the packet is at G, G understands that all of {left area} is available via F. Still correct. Thus geographic aggregation cut the FIB almost in half since C and G only have to keep track of {left area} instead of keeping track of A, B. F and E. Still correct? Yes, if you want, but I prefer to say No: I do not pursue to have a FIB of the current classic design. My goal is to fill a table from which by means of a single indexed/offset element lookup the next hop can be retrieved. Heiner
