Subject: Re: Merging SE style reservations for make-before-break

From: David Charlap <[email-masked]>
Date: Mon, 23 Jun 2003 15:22:51 -0400

I wasn't 100% correct in my message.

R4 won't reserve 1M.  It will receive a reservation for 500K, and that 
is what it will reserve.  R1 and R2 will reserve 1M on all shared 
components, but R4 will only reserve 500K.

This is what should happen:

1: R1 sends a Path message with a TSPEC of 1M to R2
2: R2 records this and sends a Path message with a TSPEC of 1M to R3
3: R3 reserves 1M and sends a Resv with a FLOWSPEC of 1M to R2
4: R2 reserves 1M and sends a Resv with a FLOWSPEC of 1M to R1
5: R1 reserves 1M

At this point, the first LSP is established.

6: R1 sends a Path in the same session to R4 with a TSPEC of 500K
7: R4 sends a Path to R2 with a TSPEC of 500K
8: R2 sends a Path to R3 with a TSPEC of 500K

9: R3 applies merging rules and sends a Resv with a FLOWSPEC of 1M (for 
both senders) to R2.  It leaves the existing 1M reservation in place 
(but adds a new sender to it.)

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

11: R4 reserves 500K and sends a Resv with a FLOWSPEC of 500K to R1.

12: R1 will apply the merging rules (yielding 1M) for the two FLOWSPECs 
received.  For those components that are shared between the two LSPs, 1M 
will be reserved.  For those components that are only used by the 
R1-R4-R2-R3 LSP, it is free to only reserve 500K.

At this point, the second LSP is established - the "make" part of make 
before break.  Now the first LSP will be torn down:

13: R1 tears the connection for the first LSP.  The reservation is freed 
for those components that only service the first LSP (for example, the 
reservation on the interface that connects to R2).  For those components 
that are shared between the two LSPs, the reservation is modified to 
500K.  R1 sends a PathTear to R2.

14: R2 receives the PathTear.  As with R1, it frees the reservation for 
those components that only service the first LSP (for example, the 
reservation on the interface that connects to R1).  For those components 
that are shared between the two LSPs, the reservation is modified to 
500K.  R2 sends a PathTear to R3.

15: R3 receives a PathTear.  Since all components are shared in this 
router, it modifies all reservations in the session to 500K.

16: R3 sends out a Resv message with a FLOWSPEC of 500K (and the only 
remaining sender on the FILTERSPEC list) to R2.

17: R2 needs to do nothing, because the reservation matches what's 
already in place.  Since the Resv that would be sent to R4 is that same 
as the Resv that's already being refreshed, it doesn't have to do 
anything more at this point.

I hope this helps out a bit.  Pay close attention to the reservation 
merging rules as defined in RFC 2205.  They are a bit tricky to understand.

RFC 2209 will also help explain it - just keep in mind that RFC 2209 is 
an informational RFC, not a standard - it's meant to clearly illustrate 
the concepts using a hypothetical router architecture.  You don't have 
to build your internal implementation to match it if your architecture 
doesn't match.

-- David

Sundara Murugan wrote:
> If R4 doesn't have 1M then the MBB lsp will fail. That doesn't sound correct.
> 
> -sundara
> 
> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2003 7:02 AM
> To: [email-masked]
> Subject: Re: Merging SE style reservations for make-before-break
> 
> 
> jiri prekow wrote:
> 
>>I have a confgiuration as follows-
>>
>> 
>>R1========R2==========R3
>>\        /
>> \      /
>>  \    /
>>   \R4/
>>
>>lsp1 takes the path R1-R2-R3 with a reservation of 1M
>>At this time you do a make-before-break for lsp1 with
>>a lower bandwidth of say 500K, and it takes the path
>>R1-R4-R2-R3. When you get the resv at R2 it will have a  
>>flow descriptor of 1M followed by 2 filter specs. When
>>R2 sends out a resv to R4 for the new
>>make-before-break lsp should the flow descriptor
>>contain a value of 500K or should it be 1M.
> 
> 
> 1M.
> 
> The RSVP merging rules are pretty explicit.  For classical RSVP, where 
> all reservations are made on the egress interface, you take the least 
> upper bound of the incoming reservations (with is 1M in this case), 
> reserve that and transmit that upstream towards your PHOP.
> 
> With MPLS, it's functionally the same.  You're not reserving only on the 
> egress interface, so your internal reservations (ingress bandwidth, 
> fabric bandwidth, egress bandwidth, connection, etc.) will be on a 
> per-LSP basis with appropriate sharing where possible, but the Resv you 
> send out will still be the least upper bound of its compponents.
> 
> After the original LSP is torn down (the "break" step of "make before 
> break") then router R2 will re-sent its Resv message with a bandwidth of 
> 500K, since there is now only one LSP to merge.  R3 will see this and 
> will change its reservation for the group at that time.
> 
> -- David
>

---

From: "Sundara Murugan" <[email-masked]>
Date: Mon, 23 Jun 2003 11:46:49 -0700

-sundara

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Tuesday, June 17, 2003 7:02 AM
To: [email-masked]
Subject: Re: Merging SE style reservations for make-before-break

1M.

-- David

---

From: Markus Jork <[email-masked]>
Date: Tue, 24 Jun 2003 17:53:37 -0400

David,
 
> components, but R4 will only reserve 500K.

I believe this is a valid implementation but based on reading RFC2205,
I'd expect a somewhat different behavior. See below...

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

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.

Markus

>>>I have a confgiuration as follows-
[...]

---

From: David Charlap <[email-masked]>
Date: Tue, 24 Jun 2003 19:59:36 -0400

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

>        Admission Control failures.

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

> suggest that it then accepts any Resv with a flowspec >= the Path tspec

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

---

From: Markus Jork <[email-masked]>
Date: Wed, 25 Jun 2003 14:58:59 -0400

David,

see my response at the end...

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

> 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

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

---

From: David Charlap <[email-masked]>
Date: Thu, 26 Jun 2003 13:36:14 -0400

> compute a Fwd_Flowspec and in what way.

If traffic control updates the FLOWSPEC is the important condition.  I 
think section 2.2 (the merging rules) of RFC 2205 explains when this 
happens:

	...
	3. (Re, Resv_Te) and Path_Te are passed to traffic control.
	   Traffic control will compute the effective flowspec as the
	   "minimum" of Path_Te and Resv_Te, in a service-dependent
	   manner.

I would assume that traffic control will update the flowspec if the 
minimum computed in step 3 is different from the requested flowspec.

But you're right that we're probably splitting hairs here.  If an 
implementation chooses not to do this, and forwards the full-size 
FLOWSPEC, I don't think it will break anything - the PHOP should clip 
his reservation anyway.

But it may lead to inefficient behavior in a multicast scenario.  My 
effective TSPEC (Path_Te) may be different from my upstream neighbor's 
(due to having different senders on different PHOP interfaces.)  If my 
upstream neighbor has a larger effective TSPEC than I do, he will clip 
my outbound FLOWSPEC to a larger value than I have installed in my 
hardware - which may result in lost packets.

If I always send out a FLOWSPEC that corresponds to what I have 
installed in my hardware (the clipped value), then this won't happen, 
because the upstream node won't install a reservation larger than requested.

In a unicast scenario, I don't think this can happen, but I'm not 100% 
sure of that.

-- David