The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Backend TE Support
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 |
|