The MPLS WG Archive

[Jing Shen <jshen@cad.zju.edu.cn>]

We consider this with the following assumption:

1. it's nearly impossible for any user to negotiate a e2e
   bandwidth reservation for his/her accessing to some 
   other site. The most possible solution is to set up
   e2e LSPs which service a group of people( this is to 
   the situation of VPN or DiffServ-aware-TE ). Within 
   the LSP, sessions share bandwidth  reserved in a best-effort
   manner.
2. The network is increasing, and MPLS and IP will be the 
   most possible technology used to carry content.
3. The underlying technology is the same (DWDM  or the like),
   and the available physical bandwidth is the same. 
4. Real-time multimedia application will be the main stream
   application. This means most of applications require 
   high bandwidth.

So, our experiments are set up to find out what's the essential
part of MPLS networks if it's implemented on the same hardware 
platform. ( like that of upgrading IOS version). In order to focus
on switch routing itself, we don't invoke techniques like TE in 
the experiments. And, we do the experiments between IP and MPLS with
the same queueing mechanism, and the same packet classification 
mechanism. 

The experiment results shows, no matter how network is loaded,
if e2e bandwidth reservation is done packets transferring LSP show
 smaller IPDV and a little higher e2e delay. As the testbed is very 
small, we take the reason as: MPLS decap/encap smooth packet's entering 
procedure  into queue of outgoing interface.

On the other hand, if no bandwidth reservation is done: if network
is lightly loaded there is nearly no difference in e2e delay between
IP routing and MPLS switching, while MPLS shows bettter in IPDV; 
if network is heavy loaded MPLS behaves worse in both aspects than
IP does. As we know, the way to control jitter is smoothing packet
transfer 
by controling queueing behavior, and we find the overhead of IP routing
and MPLS switching is nearly the same. This means in our testbed MPLS's 
encap/decap introduces something good to jitter control.

We extend the result to a path consisting multi-hop because middle-LSP
could be considered a tunnel connecting LERs, and also it directly 
applies to LSPs consisting LERs. So, if e2e qos for individual
connection
is considered in MPLS network, it should take the LSP which pass a path
as highly loaded as possible.

>From the discussion above, I come to know that implementation details
do have effect on e2e performance, and commerical implementation
of MPLS may introduce negelectable overhead in encap/decap overhead.
But it exists and accumulated result will come up when network is heavy
loaded.

And, also delay/IPDV is affected by fluctuation in network, we consider 
we extend the instant we observe. 

Some other people says that we could smooth any problem by
overprovisioning.
But, a phenomenon of current network is: sometimes when a part of
network
is heavy loaded the adjacent part idles. Why shoudn't we make use of 
those idled resource ? 

regards




> 
> On Mon, Dec 09, 2002 at 08:41:09PM +0800, Jing Shen wrote:
> > It's main conclusion of our experiments that policy based routing must
> > be used with MPLS if e2e QoS is considered carefully.
> 
> Why?
> 
> eric
> 

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423
Mobile: (0)13516813753
Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************