The MPLS WG Archive

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

"Cheng, Dalton" wrote:
> 
> RSVP specifies the receiver based reservation using FLOWSPEC object.
> The Sender initiates the setup with a service blind RSVP
> SENDER_TSPEC object. Knowing that the only differences in format
> between the sender initiated SEND_TSPEC and the Receiver initiated
> FLOWSPEC is the Service Number field, the realization is that the
> SENDER_TSPEC carries a general traffic descriptor while the
> FLOWSPEC is service specific traffic descriptor.
> 
> The question raised here is: can the sender initiated FLOWSPEC
> (service specific SENDER_TSPEC) if the reservation is to be source
> based instead of receiver based?  Also, It appear that although
> this may be achieved with a more sophisticated signaling, that is,
> SENDER_TSPEC+ADSPEC. But if one has no concerns about ctot, dtot,
> csum and dsum carried in ADSPEC, then wouldn't the FLOWSPEC
> initiated by the sender be more efficient? but is it valid?

What you ask is theoretically possible, but it would involve a
fundamental change to the entire architecture of RSVP.  If you're going
to change something that fundamental, why bother using RSVP at all? 
IMO, at that point, you'd be better off inventing something completely
new.  I would object to naming any ingress-driven protocol RSVP.

Now, if you just want routers to make reservations during Path
processing, that's a different story.  There's no reason why it can't
happen - I think Cisco's implementation does just that.  There are good
reasons why you might want to do this, and good reasons against it.

But your suggestion - of including a FLOWSPEC in the Path message -
changes far more than the reservation behavior on a switch.  This is not
something you could casually slip into an existing implementation, and
it is not something that willl easily interoperate with other RSVP
implementations.

I'm not saying that your suggestion is a bad idea, but I don't think it
belongs as an extension to RSVP.  It would create an incompatibility
large enough that it would be better to create a new signaling protocol
based on RSVP plus this change (and many other changes that people would
love to make to RSVP as well.)  The only argument against this is that
there are already three MPLS signaling protocols, and I don't think many
vendors will be keen on having to implement a fourth.

-- David