[e2e] EC++N

[Shivkumar Kalyanaraman]

Oops, the URL should be:
http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-latest.pdf

-Shiv
===

> 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
>
>
>