The MPLS WG Archive

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

Gopalkrishna Panicker wrote:
> 
> Hello,
> 
> Consider the following topology
> 
>    A-----------B----------C
> 
> Let us say
> 1. we are using make-before-break and therefore using SE style.
> 2. LSP1 with Sender1 has been signalled with a bandwidth of 20
>    units. A is the ingress and C is the egress.
> 
>  Now A decides to reduce the bandwidth to 10 units.  A ceates a new
>  sender template (Sender2) and  Tspec. A then sends the path message
>  towards C.

Correct...

>  After receiving the path message, C computes the bandwidth to be
>  allocated. Since SE style is being used, the merged flowspec sent
>  in the resv message from C to B will  continue to say a bandwidth
>  of 20 units.

What C actually reserves is a matter of local policy, but to assume that
it will choose the least upper bound of the two incoming Path messages
is probably a safe assumption.

>  The only reason the resv makes it back to A is because of the new
>  filterspec (Sender2).

Assuming that the Resv's reservation remains 20, you are correct.

>  I assuming this is correct.
> 
>   Now A issues a path tear for sender1. B will delete the path state
>   associated with sender1.  B will also delete the corresponding
>   filter spec from the resv state.

Correct.

>   Now to my question. How does B know that it has to delete the 10
>   units of bandwidth reservation ?

Two different ways.

When the PathTear arrives at C, C should re-merge the remaining Path
states in the session (which will only be sender2 now), resulting in a
bandwidth of 10 units.  It should then generate a Resv for the new
value, which will propagate back.

Also, each router should clip reservations to the level of the TSpec. 
It is wasteful to reserve more than has been requested.  Once sender1
goes away, the merged resources for the session will be 10 - when the
Resv from C is clipped to the remaining TSpec, 10 will remain.  B should
then change its reservation and send a Resv with the new value.

See section 2.2 of RFC 2205 for the resv merging rules.  In particular
note the three steps at the end of this section.  Inbound Resv FLOWSPECs
are merged into (Re, Resv_Te) - in your example, this is the inbound
FLOWSPEC, since there is only one Resv message arriving.  Inbound Path
TSPECs are merged into the Path_Te variable - in your example, this is
from both Path messages, and later from the one remaining Path message. 
In step 3, the resources actually reserved will be the minimum of
Path_Te and Resv_Te.  In other words, the FLOWSPEC is clipped to the
corresponding TSPEC objects.

Section 2.2 is not easy reading, but it does explain exactly what needs
to happen.

>   If my understanding is correct, the resv message from C had
>   carried a merged flowspec and set of filterspecs (Sender1,
>   Sender2). How does B determine the orginal flowspec associated
>   with the filterspec (in this case Sender1) ?

It determines this by looking at the stored TSPEC object for the
remaining sender(s).

>   Should B on rely on the tspec stored in the PSB ?

Yes.

-- David