Subject: RE: link bundling in MPLS TE

From: Shahram Davari <[email-masked]>
Date: Fri, 3 Mar 2000 13:27:50 -0800

Hi Kiteeti,

>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Friday, March 03, 2000 4:04 PM
>To: [email-masked]; [email-masked]; [email-masked]
>Subject: RE: link bundling in MPLS TE
>
>
>Hi Shahram,
>
>> The problem is that in both cases you want to route 200M 
>traffic on a single
>> component link. If you do it as 2*100M you will succeed, but 
>if you do it as
>> a single 200M you won't.
>
>I see your problem: the notion of oversubscription.
>
>Oversubscription is taking advantage of stat mux.  Two 100M LSPs
>whose instantaneous traffic never adds up to more than 100M can
>share a 100M link.  A 200M LSP just doesn't fit in a 100M link.
>
>Kireeti.

Could you also please clarify that when you say a 100M LSP, are you talking
about the Peak rate (PIR) or Committed rate (CIR)? 

If in the above example we are talking about CIR then it is impossible to
pass 2*100M LSP or a single 200M LSP through a 100M link. While if we are
talking about PIR then you are right we can't pass a 200M LSP through a 100M
link, but we are most likely unable to pass the 2*100M LSPs either, because
there is no way to guarantee that the instantaneous traffic of the two LSPs
never adds up to more than 100M. Is there any?  

Regards,
-Shahram

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 06 Mar 2000 10:40:33 -0500

In message <[email-masked]
> never adds up to more than 100M. Is there any?  

There is no Committed rate (CIR) in the Tspec for the Controlled-Load
service which most MPLS deployments (all major deployments to my
knowledge) are using.

There is a token rate "r" in bytes per second which is a prediction of
how much might be used and the network accepts this if the traffic has
a sufficient probability of acceptable performance (where the vaules
of sufficient and acceptable are intentionally vague).  Setting an
overbooking of 200% is one way to directly specify how to apply
constraints to meet those vague sufficient and acceptable criteria.

The implementations that I have seen use only "r" and ignore the other
parameters in the Tspec.  This is one of my reasons for suggesting
that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can
depricate use (misuse/abuse?) of the Controlled-Load Tspec for MPLS/RSVP.

Of course, if you did have two 100M flows and had two paths each of
which had 100M available, you'd probably be better off spreading the
load than putting both on the same path and that's exactly what many
algorithms strive to accomplish rather than keep using the shortest
path until it is full to its overbooking capacity.

Curtis

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 6 Mar 2000 18:16:50 +0200 (EET)

> depricate use (misuse/abuse?) of the Controlled-Load Tspec for MPLS/RSVP.

for resource allocation, r alone is fine, but if someone also wants to
do policing of the traffic at the edge, then also the depth of the
bucket should be specified.

-- juha

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 06 Mar 2000 13:34:51 -0500

> bucket should be specified.

I agree.  Then unless policing is also done within the core all that
is needed in the signaling is "r" and the other Tspec parameters serve
no purpose when used in MPLS/RSVP except to confuse people.

Curtis