Subject: Bandwidth Allocation of LSP

From: "Simon G. M. Koo" <[email-masked]>
Date: Sun, 7 May 2000 15:12:55 -0700 (PDT)

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/

---

From: "Darek Skalecki" <[email-masked]>
Date: Mon, 08 May 2000 08:38:52 -0400

> The average Ph.D. thesis is nothing but the transference of bones from one graveyard to another.

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

---

From: David Charlap <[email-masked]>
Date: Mon, 08 May 2000 11:17:06 -0400

Darek Skalecki wrote:
> Simon G. M. Koo wrote:
>> 
>> 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?
> 
> 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.

RSVP-TE does not have to make resevations on Path message processing in
order to implement make before break, although it may make more sense
for some hardware architectures to do so.

As for partial reservations, RSVP (TE or otherwise) will not
automatically grant a partial reservation if full resources are
unavailable, however:

1: Since the actual amount reserved is supposed to be a function of the
   content of the Resv message and not of the Path message (except as an
   upper limit), it is theoreticlaly possible for an RSVP recipient (an
   egress node in MPLS) to request a lower reservation if it can't get
   the full resources.  In non-MPLS implementations, where the
   signalling goes from application to application (and not router to
   router,) this is a real possibility - out of band application data
   may tell clients that it is OK to request reservations less than
   that of the TSPEC in the Path message.

   In MPLS, I don't think this ability will ever actually be used,
   because the applications at the TCP destinations are not where the
   RSVP Paths are terminating.

2: In the case where there are multiple recipients, which are requesting
   diferent amounts of resources (which can only happen in a multicast
   scenario), RSVP's merging rules may cause the amount reserved to be
   less than the total amount requested from all recipients, although
   it will never be less than the least amount requested from a single
   recpient.  When more resources become available, RSVP will re-merge
   the requests and try to increase the amount of the reservation - via
   the "blockade" mechanism.

   This might come into play at some point in the future, where a
   multicast MPLS network is deployed, but for now, it's just an
   interesting footnote.

-- David