Subject: Re: MPLS and Congestion

From: Fred Baker <[email-masked]>
Date: Tue, 19 Sep 2000 11:02:06 -0700

At 09:46 AM 9/19/00 -0700, Anil Rao wrote:
>         It is possible that in an MPLS enabled network routers face
>congestion ?  If such is the case, is there any standard/recommendation of
>how a router may deal with this?

um, typically, they use queues...

>         How does this problem magnify if the router can provision an optical
>transport path?  Will the router try to avoid the congestion by trying to
>setup another optical transport path or a non-optical LSP using alternate
>router to router paths?

I should expect that if you are shining a beam of light down a fiber, and 
it is being bounced unchanged along other fibers, although the input end 
will need a queue, anything else is just refracting the light beam. The 
light beam is a succession of ones and zeros with no significant variation 
in internal spacing from ingress to egress.

A router would only add congestion to the contents of the light beam if it 
terminated the connection and separately interpreted the packets. That is a 
different problem, no? You are back to originating packets on a light beam, 
not using optical transport.

The last time someone built a switch and believed that it would never 
experience significant congestion was in the early 1980's. They called it a 
Knock-out Switch. When two packets showed up in the same place at the same 
time, one died an untimely death. The death of the Knock-out Switch was 
very timely.

---

From: Anil Rao <[email-masked]>
Date: Tue, 19 Sep 2000 11:56:44 -0700

Fred,

>in internal spacing from ingress to egress.

  This is true in the case of all-optical transport.  But in reality, the
transport will probably be a combination of all-optical switches and
optical-electrical switches.  In such a scheme, it could result in a
congestion even in the transport -- especially with transport switches that
pack different services onto a single lambda and overflow its queues....  

>not using optical transport.

	True.. this could happen as well.. in that case an LSR in an
optically switched end-to-end path can cause the congestion... the
alternatives now available are 

      1.  Use MPLS to either avoid the LSR that is causing congestion 
	2.  Use MPL()S to choose a different interface that can better
handle the bandwidth requests through the same LSR 
      3.  Look at a different optical path to avoid congestion/faults in the
link.

	So, now the question gets to the path choice that can be either pure
MPLS (router to router) or MPL()S (router to optical path).

>time, one died an untimely death. The death of the Knock-out Switch was 

:-)

thanks, anil.

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Sep 2000 14:37:14 -0700

>pack different services onto a single lambda and overflow its queues....

Then you have solved the problem in posing it. If the input rate that 
exactly matches the output rate and there is no aditional traffic, queuing 
is minimal whether it is optical or opto-electric. If yu an opto-electric 
system packs different statistical packet streams into the same lambda 
exceeding its capacity, even momentarily, the designer of that system is on 
his own. Queuing might smooth out the bumps; if not, the designer made a 
bad decision in designing the service. Use the number of lambdas, and the 
number of pipes, you need.