Subject: RE: Bandwidth Allocation of LSP

From: Shahram Davari <[email-masked]>
Date: Tue, 9 May 2000 09:40:10 -0700

Hi Simon,

According to CR-LDP, there are negotiation flags for traffic parameters
(CDR, PDR, ...). In a label request message, if the flag for a specific
traffic parameter is set and the node can't support it, the the node may
replace that parameter with a smaller value. 

In the return path the Label mapping message will have the negotiated
values, for the nodes to reserve.

Regards,
Shahram Davari
Product Research
PMC-Sierra, Inc. (Ottawa) 
555 Legget drive,
Suit 834, Tower B,
Ottawa, ON K2K 2X3, Canada
Phone: +1 (613) 271-4018
Fax  : +1 (613) 271-7007

>-----Original Message-----
>From: Darek Skalecki [mailto:[email-masked]]
>Sent: Monday, May 08, 2000 8:39 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: Bandwidth Allocation of LSP
>
>
>Simon G. M. Koo wrote:
>
>> Hi,
>>
>> I would like to know, if a LSP is requested to setup
>> with QoS requirement of certain bandwidth, will the
>> system assign a fraction of the requirement if the
>> full requirement cannot be satsified?  Or just reject
>> the setup request?   And, if partial requirement can
>> be satisfied, is there any negotiation procedure that
>> the user can accept or reject the assigned amount of
>> bandwidth?  How is it working?
>>
>> Rgds,
>> Simon
>>
>> =====
>> The average Ph.D. thesis is nothing but the transference of 
>bones from one graveyard to another.
>>
>>   --Frank J. Dobie
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Send instant messages & get email alerts with Yahoo! Messenger.
>> http://im.yahoo.com/
>
>I am not aware of either CR-LDP or RSVP-TE allowing for 
>partial reservations. If the full
>reservation cannot be made then a reservation failure  message 
>is generated towards the originator,
>eg: RESV_ERR for RSVP or PATH_ERR for RSVP-TE provided 
>reservations are made on PATH messages
>instead of on RESV messages which I belive is the case for 
>RSVP-TE in order to make
>"make-before-break" work. The originator then can either 
>request less bandwidth, compute a new
>route or go to sleep.
>
>Darek
>