[ippm] [e2e] Mathematical analysis of e2e lable switching path

Kavé Salamatian salamat at rp.lip6.Fr
Thu Oct 3 12:23:02 PDT 2002


>> -----Original Message-----
>> From: Kav?Salamatian [mailto:salamat at rp.lip6.fr]
>> Sent: Thursday, October 03, 2002 2:57 AM
>> To: Shen Jing; end2end-interest at postel.org
>> Cc: ippm at advanced.org
>> Subject: RE: [ippm] [e2e] Mathematical analysis of e2e lable
>> switching path [...]
>> The difference may come from a simpler  traffic
>> engineering in
>> MPLS. Meaning that we should evaluate the effect of traffic
>> engineeringon
>> performance, not the particuliar behaviour of MPLS network.

>  My thought is, even for traffic engineering MPLS is not
>necessary. The benefits you get from constrained routing
>can easily be achived by means of some OMP in OSPF. Researchers
>have achived the same Traffic engineering objective by optimizing
>OSPF weights in  backbone network. AT&T's netscope is a standing
>example. Some of the traffic-aware routing schemes will also help
>in achieving the MPLS promises.
> But, MPLS is still relevant for some of the VPN based and access
>based solutions.
> As for as TE by OSPF weight optimization, all the present works
>consider link weight assignment as a static problem. One have to
>account various network dynamic (i.e..link failures) while
>optimizing OSPF weights. Also, I dont know how well the optimization
>techniques  like local search heuristics/tabu search help
>load balance a practical network.

I was not meaning that MPLS is necessary. I only say that it may simplify
traffic engineering, for example it simplify load balancing with unequal
weight. I fully agree about the fact that traffic engineering can be done in
other that will not need the introduction of MPLS and its cumbersome (at
least from my point of view) label distribution mechanism.

I will also add that VPN can be done by Layer 3 mechanism.

Kv




More information about the end2end-interest mailing list