OSPF Costs Formula that include delay.

Sat Jan 25 00:31:58 UTC 2014

On Fri, Jan 24, 2014 at 2:58 PM, Jeff Tantsura
<jeff.tantsura at ericsson.com>wrote:

> Eric,
> Issues:
> 1.OSPF (SPF) can only produce a SPT based on cost (metric).
> Anything else would require CSPF rather than SPF.
>

A CSPF based protocol would be a suitable algorithm for adding hard
constraints, instead of preference, such as path delay must be less than X,
 instead of just a weight for each edge of the graph.

However,  if you like:  you can  use a manually set cost for every link
-------   manually figure a weight based on bandwidth or delay at ideal
utilization (but not both  delay and bandwidth simultaneously).

For example,  if you equate cost to delay,  then you might decide that the
greatest delay any path through your AS/routing domain should ever see,
from any pair of routers end-to-end  is 120 milliseconds.

Then you can scribble that down,  and figure out  what fraction of  120ms
 the  delay for every IGP link is, under ideal conditions,  to set your
weight to the corresponding fraction of your chosen maximum weight.

Then decide on a reference scale, for example:     100%  =   cost of  16384
Within that model, a link with 120 milliseconds delay,   traversing that
link costs 16384.
Traversing a link with 10 milliseconds delay should have cost 1366, etc.

Over multiple hops, the costs will then sum together, to give delay under
idealized conditions.

> 2. Delay is not distributed as part of an IGP update

> Typical constrains distributed are: bandwidth, color, some others

 [snip]
>

> RSVP-TE (computation result is an ERO) however theoretically nothing
> precludes one (implementation) to use those  for more comprehensive
> computation, i.e. delay could be taken into consideration as long as the
> path is loop free. So it would look like - compute all loop free paths to
> a destination and then choose one with the smallest cumulative delay.
>

What I would like to see is dynamic computation of Delay and Utilization.

Instead of merely  "choose the one with the smallest cumulative delay" -----
choose the one with the smallest  cumulative delay,   BUT,   offer load
balancing over the N  lowest delay links  in proportion to the available
utilization.

For instance...  if one of the paths has a link somewhere in it is that
 90% congested, load balance unequally, and send a majority of packets over
the  path with the maximum 25%  utilization,  that has less than 10% in
additional delay.

BTW - segment routing will give you this functionality day one :)
>
> Cheers,
> Jeff

--
-JH