The MPLS WG Archive

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

AtrJoh@netscape.net wrote:
> 1. Is it possible to reserve less than requested in the flow-info
> without failing? If yes what should be forwarded to the upstream
> node?

Yes, it is theoretically possible.

In RSVP (including RSVP-TE), the egress node decides what should go in 
the FLOWSPEC.  It may choose any amount of resources between zero and 
the least-upper-bound of the TSPEC and ADSPEC.  Larger values are legal, 
but the transit nodes will clip them to the TSPEC value, and they may 
result in admission-control errors if the resources are unavailable 
(which is what the ADSPEC is supposed to inform the egress node.)

In actual practice, with RSVP-TE, the value placed in the FLOWSPEC will 
be directly taken from the TSPEC.  This is because RSVP-TE is a 
router-to-router protocol.  An egress node generally will not be able to 
determine what (if any) smaller-size reservations might be acceptable to 
the application(s) that will ultimately be using the LSP.

(This is different from classical RSVP.  In classical RSVP, the 
signaling goes from application to application, so an egress node may 
have sufficient information to pick a smaller acceptable value.)

In terms of what this reduced-size reservation looks like, it is exactly 
like any other Resv message, but with less resources represented in the 
FLOWSPEC object.

> 2. What should be forwarded to the upstream node in case the peak
> data rate, which was received in flow was "positive inf"?

If your egress node is going to start picking alternate QoS values, it 
will be up to that node to somehow try and figure out what values to use.

A positive-infinity value for a peak data rate effectively means "no 
limit - peak at everything available."  If you choose to reduce it to 
something else, a good first guess might be the available bandwidth 
reported by the ADSPEC object.  But unless your egress node has 
application-specific information, anything you generate has a good 
chance of being wrong.

-- David

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