The MPLS WG Archive

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

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: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/
>>
>>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
>