The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

David,

see my response at the end...

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

Good. That was really the main point I was trying to make in response
to the original question and what's important for interoperability:
an implementation can receive a flowspec that is larger than the tspec
and needs to be clipped to the tspec for admission control.
So in the scenario of the original question, it's best for R4 to
not make any assumption about whether it's supposed to get a 500K or 1M
reservation but instead look at the 500K tspec for admission control.
This is guaranteed to give interoperability.

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

We just seem to be interpreting one sentence in the spec
differently where it defines the TC_AddFlowspec semantics:

   If the
   traffic control service updates the flowspec, the call will
   also return the updated object as Fwd_Flowspec.

It all depends on what "If" means :-)
My interpretation was that a modified 'Fwd_Flowspec' *may* be computed
and if so, it gets sent upstream. The spec doesn't say you *should*
compute a Fwd_Flowspec and in what way.
But I guess that's outside the realm of the RSVP spec anyway and an
intserv issue. Though even in the intserv specs I don't see anything
authoritative on this.

I also understand your interpretation and you may be completely
right... I don't know.

Markus