The MPLS WG Archive

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

> else's.  but any ipdv and other such performance characteristics are
> not that of the mpls architecture, but of the implementation you're
> testing.  I'm not sure if you agree with me or not, can you please
> confirm that you do or don't?
> 

I agree with you that MPLS architecture does not have aparent difference
from IP when we are talking about forwarding performance. What I care
about
is , how could that affect e2e performance when we measure UDP/TCP. 
We consider such a protocol stack:
  [application protocol/TCP(UDP)/IP/MPLS], and we consider MPLS as a
protocol
adding values to IP networks. So, from the viewpoint of protocol
processing
there may be some different mechanism and implementation. I agree that 
different implementation has different effect on e2e performance. But,
the 
protocol processing  at LER/LSR should have the same logical procedure
which 
is a little different from pure IP networks.

What I care about is how may those changes affect the performance. From
your
word I come to see that our experimental result may only stick to our
implementation
and our experimental policy, but I'm still not clear that how could a
ASIC implemention
of MPLS engine compares to a ASIC implementation IP engine? Is there any
measurement data or paper on this?


> >
> > 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.
> >
> 
> MPLS encap/decap changing delay/jitter characteristics for better or
> worse is a byproduct of the implementation.
> 
> > 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.
> >
> 
> I don't get this.  If you want qos, surely you want to strive for
> low-load paths?
> 

I mean, LSP should be set up along a path which is as low loaded as
possible.
And, also sessions for src-dst pair should chose the least loaded LSP if
there
are multiple LSPs  available. If the LSP is not set up, it should be
computed
to be along the least loaded path.

> >Why shoudn't we make use of those idled resource ?
> 
> I agree.
> 
> What does any of this have to do with policy routing, as you state
> below?  Why do you give the impression that policy routing is only
> necessary for MPLS networks, and not IP?  What, for that matter, is
> policy routing?  I know what I think it is, but that's because we
> happen to implement a feature called "policy-based routing".  I have
> no idea whether this is what you refer to or not.  Also, if you
> continue to insist on confusing architecture with implementation, you
> may want to remember that a policy routing implementation will
> probably have adverse effects on delay/jitter, as there's generally
> more work involved in policy-routing a packet than in normal routing
> or switching or whatever of the same packet.

I agree that both IP and MPLS need policy based routing ( constraint
based
routing), and to our implementation and experiments LER-LER switching
path is more
sensitive to load state. This may be only to our implementation, the
reason
I take it is I find that is changes with protocol stacks which is
definitely 
affect the implementation. I'm not so clear about how those commerical 
implementation different from academic implementation at the fundamental
theoretical level, so is there anyone could do me a favor to give some
explanation or
reference?

Thanks a lot! 

regards



-- 
Jing Shen

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

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