The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

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? 
> 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? 
>   

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



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls