The MPLS WG Archive

[Lan Wang <lanw@CS.UCLA.EDU>]

Hi Roch and Juha,

I'm a student at UCLA.  I've been following this discussion from the very
beginning and I found that my understanding of some basic concepts of
RSVP such as merging and heterogeneous reservation is different from
yours. I would appreciate it very much if you could clarify them.

On Thu, 17 Sep 1998, Roch Guerin wrote: 

> Juha,
> 
> Was just curious about one aspect.  Do you mean to imply that there is no need
> for heterogeneous reservations *at all* in MPLS, e.g., the scenario were
> multiple senders (to the same egress) want to reserve different amounts would
> never arise?

If the scenario is multiple senders and one receiver, how can there be
heterogeneous reservations?  Heterogeneous reservations that cause killer
reservation problems are those from two or more receivers requesting
different amount of resources for the same sender or same set of senders
*in the same RSVP session*. 

If my understanding is correct, there will not be heterogeneous
reservations if the session is unicast since there's only one
receiver in a unicast session.  

> On a related point, if you want to "merge" reservations from multiple senders
> to the same egress, what is your definition of merging:  Is it the sum of the
> reservations or the max of the reservations?  Note that either way you will 
> have to deal with some form of the "killer reservation" problem. 
> 
> If it is the sum, you may reach a link (close to the egress) that cannot 
> accommodate the total reservation but could accommodate a subset.  The
> question is then to figure what to blockade.  Note that without individual
> state, that's going to be difficult, and btw there is no heterogeneity in 
> reservation here.
  
If there's no heterogeneity, I don't think there's killer reservation
problem. 

> 
> Alternatively, if your merging is a max operation, you can run into a similar 
> problem although blockading the culprit is now easier even without individual 
> state (as in RSVP, you can backtrack till you find the culprit).

I don't quite understand this max operation.  Do you mean that each sender
has a different Tspec and the receiver is making a shared style
reservation?  If we are talking about unicast sessions, there's no
merging even if the reservation style is shared.

Regards,

Lan


~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
  Lan Wang                     Internet Research Lab
lanw@cs.ucla.edu         UCLA Computer Science Department