Subject: [mpls] basic query about RSVP

From: shilpa goel <[email-masked]>
Date: Fri, 22 Dec 2006 15:51:42 +0530

Hi,

  I have few basic doubts regarding the functioning of RSVP-TE:

In RSVP as I understand "Link Admission Control" is used within the PATH
message and the bandwidth value is included in the sender's Tspec field.
This bandwidth is moved to a waiting pool untill a RESV mesage is received.
Otherwise, a path error  message will be sent upon reception of RESV.  With
respect to this understanding, I have the following doubts:

1)What actual benefits do we achieve by "Receiver Initiated Reservation
Style"? Why cannot we perform Admission Control and Policy control during
the flow of Path messages only?

2)When the path message is moving downstream and the required bandwidth is
available
then it is moved to the waiting pool, but what if the required bandwidth is
not
available why the error message has to wait for the RESV message from the
downstream?
In this way we are unnecessarily blocking the network with the control
packets if we
know that required reservation could not be made in the first place?

thanks,
Shilpa
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: David Charlap <[email-masked]>
Date: Fri, 22 Dec 2006 10:52:42 -0500

shilpa goel wrote:
> In RSVP as I understand "Link Admission Control" is used within the 
> PATH message and the bandwidth value is included in the sender's Tspec 
> field. This bandwidth is moved to a waiting pool untill a RESV mesage 
> is received. Otherwise, a path error  message will be sent upon 
> reception of RESV.  With respect to this understanding, I have the 
> following doubts:

What you describe (reserve bandwidth during Path processing, validate 
reservation during Resv processing) is one possible way.

RFC 2205 and 3209 only mandate that your reservations (including label 
allocation) be completely in-place before you complete Resv processing 
(usually just before sending a Resv upstream or notifying application 
software.)

Making reservations during Path processing is an optimization that is 
sometimes used to reduce Resv processing latency.  But this approach is 
not without its problems - for instance, the resources requested in the 
Resv's FLOWSPEC object might not match the Path message's TSPEC object.  
Dealing with these kinds of mismatches is more complicated if you've 
pre-reserved bandwidth.

You can also end up with temporary bandwidth leaks if the Resv message 
is delayed or is not received (which may happen if you are close to the 
originating node of an LSP with a lot of hops.)

> 1)What actual benefits do we achieve by "Receiver Initiated 
> Reservation Style"? Why cannot we perform Admission Control and Policy 
> control during the flow of Path messages only?

RSVP (classical RSVP, RFC 2205, pre-MPLS) was designed for many-to-many 
multicast situations.  A given session may have multiple senders, each 
requesting different amounts of bandwidth.  The receiver (or receivers 
if the destination is a multicast group) apply application-specific 
merge-rules to determine the amount of resources that will be reserved.  
As these Resv messages propagate upstream (merging with Resv messages 
from other receivers, in the case of multicast), the amounts reserved 
may be quite different from what was in the original TSPEC objects.

In the MPLS world, LSPs tend to run from router-to-router instead of 
application-to-application, and most LSPs have a single sender and a 
single receiver (not counting ongoing work on p2mp LSPs), so 
Resv-initiated reservations is not as critical as it is in the classical 
RSVP scenario.

> 2)When the path message is moving downstream and the required 
> bandwidth is available
> then it is moved to the waiting pool, but what if the required 
> bandwidth is not
> available why the error message has to wait for the RESV message from 
> the downstream?

As I mentioned above, allocating bandwidth during Path processing is not 
a mandatory behavior.  If your application chooses to implement this, 
then it will obviously have to deal with the problems that arise from 
such a choice.

-- David