![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
The whole idea about micro-loop mitigation and all the multipath topics
including the via-solution that the rtgwg produced lately are based on the state
of art knowledge about Dijkstra.
On my website (www.hummel-research.de) an
example demonstrates how to transform any network into an All Links
Spanning Tree (ALST) rooted at whichever particular destination.
Provided that any node knows the network's topology it may compute for each
destination node such an ALST, and as a result properly esteem ALL links of the
entire network (not just the adjacent links) for the sake of packet forwarding
towards some specific destination node. Dijkstra would yield only an ALL
Nodes Spanning Tree (ANST) rooted at that destination (=the blue subtree in my
example). However by memorizing the sequence by which each node is assigned its
definite predecessor and by transforming - while siffing from node to
node according to this sequence - all those links into arcs,
which Dijkstra didn't transform into its best-hop arcs, you will get an ALL
Links Spanning Tree (ALST) which provides even more loop-free multipath
routes than does ECMP( the red arcs). You may even forward a
packet oppositely directed than is the used arc, by adding an
indication bit in the IP-header to make sure that there after 2 hops will
be enforced which both will get the packet closer towards the desination.1 Hop
to a more remote neighbor node, followed by 2 best hops
without passing the current node would perfectly do.
In the end, any node can find out how to esteem A L
L its adjacent links and can rank them from
1) Dijkstra-best, 2) ECMP, 3) loop-free detouring without getting farer
away, 4) loop-free detouring while getting farer away, 5) detouring while
accepting a loop, e.g. some crankback hops 6) recognizing that there is an
inevitable dead-end so that the packet must be discarded.
As a result any (topology-aware) node gets a 100 % orientation with respect
to forwarding to which ever destination node.Indeed it may properly esteem all
its adjacent links.Also, by properly designed IP-Header bits it may guide the
packets via some unusual and even crankbacking detours, endless-loop-free. This
however also means: The few bits in the IP-Header must not me snatched by
others, e.g. by re-ECN.
Instead based on the ALST each node may also look backwards, and detect a
particular ingress sector subnetwork, i.e. a bunch of nodes which would use it
as transit for packet forwarding towards a particular destination node. It would
be very easy to design an re-ECN-alternative protocol which includes messages,
that are originated by such a congested transit node and are forwarded towards
all nodes which are reached by going inverse to the ALST's arcs (each hereby
notified node would know by itself wether or not to forward the message even
further upstream, and of course towards which nodes further up ).
This I think is the right way to deal with congestion, as opposed to
re-ECN, and again: the few bits in the IP-header should be subject to routing of
THIS packet only !!!.
There are even more routing topics (e.g. multihoming support by the network
rather than to make this an end-user-only topic) which should worry if the few
bits of the IP-header were stolen for other purposes than routing THIS
packet.
Heiner
---------------------------------------------------------------------------------------------
In einer eMail vom 20.10.2009 15:00:37 Westeuropäische Sommerzeit schreibt
Internet-Drafts at ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories. |