Subject: Re: RE: router architecture for MPLS

From: "k m a" <[email-masked]>
Date: 12 Oct 2001 03:09:02 -0000

Hi all,
     I am eager to implement LDP STATE MACHINE(MPLS LABEL DISTRIBUTION PROTOCOL,IN FREE BSD) but i am not able to understand the use of implementing LDP.some of the questions within me are  as follows,
1.which is better" doing at kernel level(which involves kernel recompiling) or using existing models like NIST SWITCH environment and including my code for LDP(i told him the second one)".

2.Even if i am implementing ,what is the purpose of implementing.can it that i can compare the characteristics (performance) of LDP  with other existing label distribution protocols like RSVPd and BGP .even when i am doing that implementation work  what  are the parameters i can compare??

3.also,can i not do the comparison of performance with just the simulation itself???

4.the main question is"WHAT IS THE PURPOSE OF IMPLEMENTING LDP,.IN AN ACADEMIC ENVIRONMENT WHERE RESEARCH IS THE MAIN GOAL REALLY PLEASE TELL ME FOR WHAT REASON SHOULD I PROCEED WITH PROCESS OF IMPLEMENTING SINCE CISCO AND JUNIPER IS DOING THAT WORK ALREADY"

5.what features will i use to check the performance??can i use packet sniffers like ethreal or TCPdump????will those s/w sniff my code????or what are the other tools i can use???
       
  Pease also through light what type of research can be done at academic resaerch level in the area of MPLS and TE .
Thanks in advance,

AYYASAMY SENTHILKUMAR         5000,oak street
Masters in Computer networking     #twin oaks apt625  
Dept. of telecommunication            kansas city  
university of missouri                     Missouri-64112
kansas city ,MI-64112                   phone:816-531-2005

---

From: David Charlap <[email-masked]>
Date: Fri, 12 Oct 2001 11:05:46 -0400

k m a wrote:
> 
> 1.which is better" doing at kernel level(which involves kernel
> recompiling) or using existing models like NIST SWITCH environment
> and including my code for LDP(i told him the second one)".

"better" is relative.  It will depend on your OS environment, your
forwarding architecture, and your product requirements.

> 2.Even if i am implementing ,what is the purpose of implementing.
> can it that i can compare the characteristics (performance) of LDP
>  with other existing label distribution protocols like RSVPd and
> BGP .even when i am doing that implementation work  what  are the
> parameters i can compare??

You can't really compare them.  The different protocols are architected
differently and are designed to accomplish different goals.

LDP is a protocol designed for locally assigning labels to routes.  LSPs
don't exist as a fundamental concept - they are an emergent property
that results from multiple switches along a path all assigning labels to
common FEC's.

CR-LDP completely changes the focus of LDP.  It is designed around
creating LSP's.  It eliminates those parts of LDP that are used for
automatically assigning labels and adds new features for traffic
engineering (like QoS and explicit routing.)

RSVP-TE is another LSP-oriented protocol.  It has a fundamentally
different architecture from LDP and CR-LDP, though.

BGP is a wide-area routing protocol.  There are modifications to it to
allow label distribution, but it is still fundamentally a routing
protocol, not an LSP-setup protocol.

> 3.also,can i not do the comparison of performance with just the

Go ahead.  But the results may not match real-world conditions.

Even in a non-simulation environment, real-world performance will vary
grreatly depending on hardware design and protocol implementation. 
There will likely be a trade off between performance and other things
(like stability, conformance to standards, interoperability, support of
optional features, etc.)

> 4.the main question is"WHAT IS THE PURPOSE OF IMPLEMENTING LDP,.IN
> AN ACADEMIC ENVIRONMENT WHERE RESEARCH IS THE MAIN GOAL REALLY
> PLEASE TELL ME FOR WHAT REASON SHOULD I PROCEED WITH PROCESS OF
> IMPLEMENTING SINCE CISCO AND JUNIPER IS DOING THAT WORK ALREADY"

You should ask your advisor about that.  If you are building a router,
then you will need at least one signalling protocol in order to be
commercially viable.  If this is not what you are doing, then you should
ask whoever is funding your work.

> 5.what features will i use to check the performance??can i use
> packet sniffers like ethreal or TCPdump????will those s/w sniff my
> code????or what are the other tools i can use???

Some possibly useful metrics may include:

- Calls-per-second - the rate at which LSPs are established.
- Maximum data-plane throughput - which should be 100% if your line-
  cards are forwarding data in hardware - but will be affected by
  other code in the system if your box does software forwarding.
- Speed of responding to failures - number of LSPs rerouted per
  second, average down-time per LSP, etc.
- Memory consumed per-LSP
- Maximum number of LSPs that can be established and maintained
  without losing stability
- Ability to police/shape/filter data based on signaled QoS and
  DiffServ information

There are plenty more.  If this is a research project, you should be
able to come up with some on your own as well.

-- David

---

From: Irfan Lateef <[email-masked]>
Date: Fri, 12 Oct 2001 11:44:18 -0400

David,

> - Calls-per-second - the rate at which LSPs are established.

I doubt if this is a good metric to investigate. It will only tell you
for a given CPU speed how many PDUs can you process. So what?
There is no algorithm involved. The protocol is developed based on
well defined requirements and there is hardly an chance that you will
try to improve the protocol to enhance the performance based on this
metric.

The second point is, I think MPLS is not "yet" so dynamic in nature
where on a given box you have LSP being setup and torn down as
voice telephone calls in a telecom switch. I think MPLS is largely a
TE and QOS applications deployment tool. Others might think differently.

> - Maximum number of LSPs that can be established and maintained

I am interested in your definition of "losing stability".

Regards,
--
Irfan Lateef
Village Networks Inc,

---

From: David Charlap <[email-masked]>
Date: Fri, 12 Oct 2001 12:15:30 -0400

Irfan Lateef wrote:
> I doubt if this is a good metric to investigate. It will only tell
> you for a given CPU speed how many PDUs can you process. So what?
> well defined requirements and there is hardly an chance that you
> will try to improve the protocol to enhance the performance based
> on this metric.

RFC's are not compilable code.  There are many ways to implement a
standard.  Some ways are better than others.  On equivalent hardware,
this is a useful measurement.

The original poster did say "performance" measurement.  Performance
means speed, and calls per second is a useful measurement.

> voice telephone calls in a telecom switch.

I think this is purely a matter of how customers choose to use a switch.

I see no conceptual reason why one couldn't run MPLS to the desktop and
let applications create and destroy LSPs as they create and destroy
their TCP sessions.  The only real reason this isn't going to happen is
that it would be cost-prohibitive to replace all routers and layer-2
switches in a corporation with LSRs.  But prices always come down, and
this might become attractive in a few years.  (Or maybe not.)

> I am interested in your definition of "losing stability".

For instance, RSVP-TE without RSVP's refresh reduction extensions must
refresh each Path and Resv message individually.  If your refresh
interval is 30 seconds, then a transit router with 100,000 LSPs will
have to send out an average of 3333 Path messages per second.  It will
have to send out an avergage of 3333 Resv messages per second.  It will
have to receive an equal number.  This is a load of over 13,000 messages
per second.  It is likely that a CPU under this kind of load will result
in dropped packets - both to RSVP and to other protocols.  This will
result in route flapping, LSP flapping, and other symptoms, even if the
code is flawless.

Different implementations will start exhibiting this kind of instability
at different load levels, depending on how efficient the code is.

Of course, RSVP's refresh reduction extensions will allow much greater
numbers of LSPs before instability happens, since summery refreshes
impose much less overhead than individual refreshes.

And hard-state protocols like LDP don't have this issue at all, although
they may have other kinds of scalability issues.

-- David

---

From: Irfan Lateef <[email-masked]>
Date: Fri, 12 Oct 2001 13:04:47 -0400

David Charlap wrote:

> switches in a corporation with LSRs.

The other reason is, to bring it to the desktop Microsoft will have to
implement it
in Windwos. And the way they do it is, write a new protocol
Microsoft Personal Label Swapping(MPLS) and ask us all to re-design our
routers
or pay them to use the stack ;-)

BTW, your comment on losing stability was good and has got me thinking if
the
current routers(from the two big boys) are able to handle the numbers you
quoted
in a sizable network and continue to meet other survivability requirements.

Regards,

Irfan Lateef
Village Networks Inc,