The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

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

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

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

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


>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:David.Charlap@marconi.com]
>> Sent: Tuesday, June 17, 2003 7:02 AM
>> To: mpls@UU.NET
>> Subject: Re: Merging SE style reservations for make-before-break
>> 
>> 
>> jiri prekow wrote:
>> 
>>>I have a confgiuration as follows-
>>>
>>> 
>>>R1========R2==========R3
>>>\        /
>>> \      /
>>>  \    /
>>>   \R4/
>>>
[...]