The MPLS WG Archive

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

Markus Jork wrote:
>>
>> 10: R2 reserves 1M on its outbound interface and on any hardware 
>> components that the two LSPs share.  For those components that are only 
>> used by the second LSP (the one requested in step 6), it is free to clip 
>> the reservation to the request size of 500K.  The Resv that it sends to 
>> R4 will have a FLOWSPEC of 500K.  (See RFC 2209 - note the behavior of 
>> the "UPDATE TRAFFIC CONTROL" section, the Path_Te and Fwd_Flowspec 
>> values.  Also note the TC_AddFlowspec function in RFC 2205).
> 
> According to the spec, R2 could do that but there is nothing in the
> spec that really suggests it should be done. Instead, I would expect
> R2 to also send the 1M Resv to R4.

Look again.

RFC 2205:

	o Make a Reservation

	  Call: TC_AddFlowspec( Interface, TC_Flowspec,
	                        TC_Tspec, TC_Adspec, Police_Flags )
	                        -> RHandle [, Fwd_Flowspec]

	  The TC_Flowspec parameter defines the desired effective QoS
	  to admission control; its value is computed as the maximum
	  over the flowspecs of different next hops (see the
	  Compare_Flowspecs call below).  The TC_Tspec parameter
	  defines the effective sender Tspec Path_Te (see Section
	  2.2).  The TC_Adspec parameter defines the effective Adspec.
	  The Police_Flags parameter carries the three flags
	  E_Police_Flag, M_Police_Flag, and B_Police_Flag; see Section
	  3.8.

	  If this call is successful, it establishes a new reservation
	  channel corresponding to RHandle; otherwise, it returns an
	  error code.  The opaque number RHandle is used by the caller
	  for subsequent references to this reservation.  If the
	  traffic control service updates the flowspec, the call will
	  also return the updated object as Fwd_Flowspec.

Note the last paragraph - if the traffic control service updates the 
flowspec, the call will also return the updated object as Fwd_Flowspec. 
  Since FLOWSPECs are always clipped to TSPECs when they're installed in 
the forwarder by traffic control, Fwd_Flowspec will never be greater 
than TC_Tspec when this function returns.  (It may be less, depending on 
merging/blockading rules, but RSVP-TE doesn't normally implement those 
rules.)

The Fwd_Flowspec returned is the value that is used in the outgoing Resv 
message.  See RFC 2209:

	UPDATE TRAFFIC CONTROL
	...

	6. Compute Path_Te as the sum of the SENDER_TSPEC objects
	   in this set of PSBs.

	...

	o If TCSB is new:

	1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
	   police flags into TCSB.

	2. Turn the Resv_Refresh_Needed flag on and make the
	   traffic control call:

	   TC_AddFlowspec( OI, TC_Flowspec,
	                   Path_Te, police_flags)
	                   ->  Rhandle, Fwd_Flowspec

	3. If this call fails ...

	4. Otherwise (call succeeds), record Rhandle and
	   Fwd_Flowspec in the TCSB. ...

Then, in the RESV REFRESH sequence:

	...

	o Select each sender PSB whose PHOP has address PH.  Set the
	  local flag B_Merge off and execute the following steps.

	  1. Select all TCSB's whose Filter_spec_list's match the
	     SENDER_TEMPLATE object in the PSB and whose OI appears
	     in the OutInterface_list of the PSB.

	...

	  4. Merge the flowspecs from this set of TCSB's, as follows:

	     - If B_Merge flag is off, compute the LUB over the
	       flowspec objects.  From each TCSB, use the
	       Fwd_Flowspec object if present, else use the
	       normal Flowspec object.

	...

Putting all this together, this is what is supposed to happen:

1: For a given outbound interface, you merge all the received
    FLOWSPECs together.

2: Then for each of the corresponding senders, you merge the
    TSPECs together.

3: You submit the merged FLOWSPEC and the merged TSPEC to traffic
    control to add/modify the flowspec.  The actual resources that end
    up being reserved are returned in the Fwd_Flowspec object.  This
    will never be greater than the merged TSPEC.  It might be smaller.

4: When generating an outbound Resv, you merge the Fwd_Flowspec
    parameters from all of the different TCSB objects that have a
    reservation on the interface you're about to send your Resv
    message out on.  (This will be only one TCSB for unicast
    connections.  It could be more if there's a multicast connection.)
    The result of that merge is what's sent to the PHOP.

> R4 can base its admission control decision on the 1M flowspec from R2
> and the 500K tspec from R1. It has both values and can thus figure
> out that the Resv is admissible. The following paragraph in section 2.1
> of RFC2205 hints at this behavior:
> 
>        Sender Tspec
> 
>        A Path message is required to carry a Sender Tspec, which
>        defines the traffic characteristics of the data flow that the
>        sender will generate.  This Tspec is used by traffic control
>        to prevent over-reservation, and perhaps unnecessary
>        Admission Control failures.

This supports what I said - FLOWSPECs are clipped to TSPECs in traffic 
control to prevent wasted reservations.

> An RSVP-TE implementation typically makes admission control decisions
> on receipt of the Path message based on the tspec. I would strongly
> suggest that it then accepts any Resv with a flowspec >= the Path tspec
> to cover this scenario.

First off, the assumption that an RSVP-TE implementation makes its 
reservations during Path processing is unwarranted.  While there are 
some implementations that do, it is wrong to assume that everybody does, 
and it is wrong to assume that implementations are supposed to.

As for accepting a Resv that's too large, that's always been acceptible. 
  No implementation should reject such a message with or without -TE. 
But when it actually installs that reservation, it will get clipped to 
the TSPEC, and the Resv it sends upstream should be the clipped value 
that was installed, not the original value received.

-- David