The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Apr> msg00186



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

Backend TE Support

  • From: "Ash, Gerald R (Jerry), ALARC" <gash@att.com>
  • Date: Mon, 24 Apr 2000 09:50:15 -0400
  • Cc: "Ash, Gerald R (Jerry), ALARC" <gash@att.com>, mpls@UU.NET

The I-D located at
http://www.research.att.com/~jrex/jerry/
reports simulation results for various LSP computation alternatives (under
overload/failure scenarios on a large multiservice voice/data network):
- off-node (centralized) vs. on-node (distributed) computation
- available-bandwidth flooding vs. no available-bandwidth flooding
- effect of frequency of available-bandwidth flooding
- etc.
In the "Main" (summary) section of the draft, Table 1.2 summarizes the
comparison results:
- on-node LSP computation can outperform off-node computation
- LSP computation without available-bandwidth flooding can outperform
methods with available-bandwidth flooding
- etc.
A viewgraph summary of the draft (presented at the IETF-47 TEWG) is
available on request.
----------------------
Jerry Ash
AT&T Labs
Middletown, NJ, USA
gash@att.com
----------------------


>-----Original Message-----
>From: Dave Cooper [mailto:dcooper@globalcenter.net]
>Sent: Thursday, April 20, 2000 12:05 PM
>To: mpls@UU.NET
>Subject: Backend TE Support
>
>We've been running MPLS in the core for TE purposes
>for quite some time now. However, one of the largest hurdles we
>have faced is not just the stability of the protocol
>but the actual management of protocol. More specifically,
>the TE bandwidth statements used to make "optimal" path 
>decisions. (Keeping TE bandwidth consistent with 
>actual peak flows).
>
>In a large backbone, flows can fluctuate by large
>variations (usually due to egress traffic shifts,
>down customers, or other external factors) and its
>obvious that TE bandwidth can become "outdated" fairly
>quickly.
>
>I was inquiring to see if other providers or vendors
>have been working on developing software to help 
>manage this critical component of MPLS.  The old adage
>is correct in "Garbage in, Garbage out" and if TE
>bandwidth is not accurate, LSPs will never be
>routed over optimal paths.  We have been doing some 
>in-house development, but we're always interested in 
>outside input or even code that can be co-developed.
>
>-dave