The MPLS WG Archive

[Roch Guerin <guerin@watson.ibm.com>]

Juha,

Some feedback on the problems you identified with the use of RSVP
as a signalling protocol for MPLS.

> 1. in rsvp the receiver is responsible for requesting a specific qos.
> i want the sender to be able to request the resources and optionally
> also indicate if negotiation down is acceptable.  the network and the
> receiver would then either accept the setup, negotiate the resources
> down within the given limits, or deny the setup.

For most practical intent and purposes, with the Controlled Load Service the
sender TSpec pretty much determines what the reservation will be.  You could
even modify the local call admission, if desired, to have the resources 
reserved at the time of the PATH message (not that I think this would make 
much of a difference).  For Guaranteed Service, this need not be so, but this 
is probably not an issue with MPLS initially.  

> 2. in rsvp the soft state is periodically refreshed.  this causes
> overhead and it is not clear to me what happens during the period when
> the route has changed, but the rsvp state has not been refreshed yet.

A response was already posted for the route change problem.  For the
refresh overhead, there has also been proposals to mitigate the problem,
e.g., increase the frequency initially until the state has been "hardened",
and then lower it to limit the overhead (see "Staged Refresh Timers for RSVP"
by Ping Pan and Henning Schulzrinne, Global Internet'97, Phoenix, AZ, Nov. 1997. 

> 3. rsvp's reservation styles doesn't support merging of reservations,
> where the resources requested by different senders to the same receiver
> are ADDED UP.

Cannot you solve this when you aggregate reservations at an ingress point,
pretty much the way people plan to do it for Diff-Serv?

> 4. the router model of rsvp as shown in figure 9 of rfc2205 is not
> applicable to mpls.  in rsvp a flow arrives from an incoming interface
> and departs through one or more outgoing interfaces, whereas in mpls it
> is the other way arround.

Agree that this is a difference, but you can handle this by terminating
the reservation at the merge point and then restarting an aggregate one.

> because some of the points above seem fundamental in nature, it does not
> make much sense to me to try to hack rsvp into something that it was
> never intended for.

In my mind the question is how much work this entails.  If it is not much
once you have an existing RSVP implementation, and we can use that to gain
some experience, I think it is worth a shot.

Roch