[e2e] EC++N

Shivkumar Kalyanaraman shivkuma at ecse.rpi.edu
Fri Apr 19 14:50:40 PDT 2002


Jon,


> so what i'd do is take Paul Francis FTIF/PIP architecture, and re-use
> it - i'd need a system (the ECN++ idea was part of this) for reporting
> to the routing system what conditions on path-segments are like (not
> BGP:), and a system for end users to discover this, and to specify
> (liek a source route, but not at the "list of IP  addresses" level, at
> the level of granularity of "traffic engineererd region ids) - given


^^^^ We have a recent work in this area -- where we use the tuple
(destination prefix, PathID) as the source route ID, within a broader TE
framework proposal. The pathID is the sum of link weights (for OSPF),
or ASNs for BGP. The key idea is to enable limited TE capabilities
without signaling (i.e. connectionless manner), and enable limited
"source" directed routing.

http://www.ecse.rpi.edu/Homepages/shivkuma/research/te-latest.pdf

The feedback we have gotten on this work is that our BGP assumptions are
too contentious, and the uniqueness probability of the tuple (dest
addr, pathID) has to be better established given the number of paths we
make available in the overall network. But we continue to believe that
this could be an starting point for connectionless TE of OSPF-style protocols
where a full map is available. In OSPF we do not add any new control traffic, and
we can manage the complexity of the multi-path computation algorithms at
the routers we choose to upgrade. Also, our goal is to allow "best-effort
TE", i.e. to be able to upgrade a very few routers in a network, and make
available a reasonable set of multiple paths.

And even though we use the term "source"  routing -- it is not
equivalent to PNNI (or an implication that a source sees the entire
internet) -- sources can only choose multiple paths within the
limits of their visibility into the network topology. But there could be
several "sources" on the path that can attempt to take advantage of the
route diversity within the limits of their visibility into network
topology.


> IPv6, for exampel (only for example) i have TWO 128 bit fields - if we
> too ksomething like the GSE idea, I would have an 64bit EID for each
> end which is immutable, and 8 16 bit ids to play with - the average AS
> path length is 7, so this sounds pretty good....
>

^^^ In our paper above, we also suggest two fields -- one for intra-domain
TE, and another for inter-domain TE.

best
-Shiv





More information about the end2end-interest mailing list