The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jul> msg00498



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

LSP utilization

  • From: Eric Osborne <eosborne@cisco.com>
  • Date: Sat, 28 Jul 2001 21:00:42 -0400
  • Cc: Eric Osborne <eosborne@cisco.com>, mpls@UU.NET
  • User-Agent: Mutt/1.3.13i
  • X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562

On Sat, Jul 28, 2001 at 07:43:55PM -0400, Raymond Law wrote:
> For example, once an MPLS solution is deployed after a pre-deployment 
> analysis or simulation which found an optimal LSP setup in which all LSPs 
> have 50% utilization. If some LSPs have 80% utilization whereas other LSPs 
> have 30% utilization in deployment.

So first off, I assume you really mean s/MPLS/MPLS-TE/ in this
context.

TE LSPs (or most LDP LSPs) map to FECs.  A FEC is (currently) a
combination of address/mask.  And most traffic is going to be
headed to a FEC that is the BGP next-hop for a particular set of
traffic.  So what you're really asking is (I think) how to balance
traffic to BGP exit points - right?

One thing MPLS-TE can give you is better load-balancing than IP
forwarding, because of the opportunity for unequal-cost forwarding.
Since this is mpls@uu.net, I'll leave the issue of such forwarding
algorithms alone other than to say that they're vendor specific.  But
in the one implementation I'm intimately familiar with, there's a fair 
bit of control as to how you balance between multiple LSPs to the same 
FEC.

> Or, due to the dynamic nature of Internet traffic, some LSPs become 
> congested while other LSPs are underutilized.  Maybe a LSP setup 
> specifically for best effort traffic experience a large amount of traffic 
> during the busy hours and that LSP become overutilized.
> 
> Does any drafts address this problem or has any solution been attempted or 
> proposed in dealing with this issue?

I believe (but have not looked recently) that some of the
operationally-focused TE drafts discuss this.  If I understand what
you're saying (and I may not understand), then this is the same type
of traffic engineering problem one has with ATM VCs and other dynamic, 
bandwidth/QoS-related traffic-trunk stuff.  So since the question
probably reduces to the same whether it's MPLS or ATM, the answer for
ATM (mostly periodic reoptimization) should be the same.




eric 

> 
> Thanks.
> Ray,
> 
> 
> At 06:54 PM 7/28/01 -0400, you wrote:
> >On Sat, Jul 28, 2001 at 04:02:37PM -0400, Raymond Law wrote:
> > > So has anyone looked into increasing the efficiency of LSP usage in a MPLS
> > > domain or is there any solution already out there?
> > >
> >
> >Define "efficient".  Then we can start talking about what the problem
> >may be, whether it needs to be solved, and how to solve it.
> >
> >
> >
> >eric
> >
> > > Thanks.
> > > Ray,
> > >
> > > At 03:58 PM 7/28/01 -0400, you wrote:
> > >
> > > >Of course there is.  It's called 'real world'.
> > > >
> > > >TE is a tool, but not everything in the world (or anywhere near to 
> > that) is
> > > >always TE'ed.
> > > >
> > > >Any notion that MPLS LSP utilization is always efficient is ridiculous.
> > > >
> > > >On Sat, Jul 28, 2001 at 03:51:08PM -0400, Raymond Law wrote:
> > > > > What is the utilization of LSPs in a real MPLS domain?  It seems 
> > that the
> > > > > LSP utilization should be efficient since the LSPs are configured 
> > as such
> > > > > by traffic analysis and administrative means.  Is there a situation in
> > > > > which a LSP is overutilized and another LSP may be underutilized?
> > > > >
> > > > > Thanks.
> > > > > Ray,
> > > > >
> > > >
> > > >--
> > > >Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm
> > > >Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, 
> > U.S.
> > > >"I speak for myself only.""