Subject: Regarding Traffic Engineering

From: Manish Gupta <[email-masked]>
Date: Thu, 23 Sep 1999 12:10:59 -0400 (EDT)

hi

I am wondering that if the induced mpls graph concept as defined in the
traffic engineering draft is indeed needed to do traffic engineering or it
is an option, because i think that if i have explicitly routed LSPs
based upon CR TLVs (in ATM networks) then is the induced MPLS graphs
concept still needed or its an alternative.

Another question which I have is how do i compute explicit routes ? Is it
based upon some traffic statistics I already have or based upon bandwidth 
requests and avalibility ? How this can be done in a dynamic fashion ?

Thanks
Manish

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Manish Kumar Gupta                                    Phone : 410-455-3063W
Graduate Research Assistant	                              410-737-8367H
Maryland Center for Telecommunications Research       Fax   : 410-455-1048	
University of Maryland Baltimore County          Email:[email-masked]   
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Thu, 23 Sep 1999 13:58:18 -0400

> concept still needed or its an alternative.

  It is needed to do a dynamic computation of the path you want the LSP to
follow. If you only want to statically provision the paths then you don't
need to distribute and store the resource information. Obviously it is 
better to do this stuff dynamically as it reduces the cost of operating
a network. It is however possible to build a centralized server that would
compute routes and give explicit routes to LDP for setup, in which case
you don't need to distribute the resource information. This kind of solution
is not very satisfactory since it does not scale well and dies when the
server dies. A fully distributed approach is far more robust and scalable.

> requests and avalibility ? How this can be done in a dynamic fashion ?

  Normally you would run Dijkstra's algorithm over the topology database.
You would include in that algorithm only links which satisfy the constraints
of the LSP you want to establish. 

  For example, if your graph is G=(V,E) where V is the list of nodes and E
the list of edges. You can think of the path computation as having a sub graphing
operation where you compute G'=(V',E') this subgraph consists of only 
edges E' that have sufficient bandwidth and support the required LSP color
set.

  Once you have G' you can run Dijkstra(G') to get your path. Which will
be the lowest "cost" path that consists of links that satisfy the 
constraints of the LSP.

  The question as to just what the bandwidth is as a constraint, and just
what you reserve is dependent on just how much of a risk you want to
take in squeezing the most out of your bandwidth and will vary from 
network to network. 

  One can position a network on the risk/cost curve by deciding just how
much to overcommit on bandwidth, i.e. you underreserve on the individual
LSPs or perhaps over advertise in the LSAs. This increases your risk but
as long as the statistics work out you save money. Or, one can advertise less
and reserve move for an LSP and lower the risk but also increase the
cost. 

  As far as how you actually compute the numbers this would be based either on
actual measured/sampled data, or on models. In an ideal world you would measure
on the fly and slowly adjust your reservations to reflect the measured values
but you are more likely to do some combination of periodic measurements and
perhaps injection of those measurements into modelling tools and then use 
those outputs to decide what reservations to use and when.

  Sorry to be so vague about it, but every vendor is going to have different
ideas about how to do this and every network is going to have different 
opinions of the degree of risk the want to take to save money. MPLS right now
is in the buisness of providing the knobs, how to adjust them is yet another
debate.

  Peter