[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Reflecting new-MAM/SAM definition in diff-te drafts



Hi Francois,

>> I suppose this relationship must hold:
>>
>> Reserved(CTc) = Bandwidth-Requested(CTc)/LSOM
>> 
>> where
>> 
>> Bandwidth-Requested(CTc): For a given Class-Type CTc ( 0 <= 
>> c <= MaxCT ), define "Bandwidth-Requested(CTc)" as the sum 
>> of the bandwidth requested by all established LSPs which 
>> belong to CTc.
>>
>> LSOM: 'LSP/link size overbooking multiplier'
>>
>> Is that correct?  If so, then 'Reserved(CTc)' is also a 
>> 'normalized' quantity, but this time it is normalized by the 
>> LSOM, right?
 
> Yes, I do agree with your statement that "Reserved(CTc)" is also
> normalised in the sense that it reflects the LSP/link size 
> overbooking.
> 
> This is analogous to what happens today with regular TE. The bandwidth
> that is configured as the LSP size may reflect some over/underbooking
> factor. Similarly the Max Reservable bandwidth may reflect some
> over/underbooking ratio.
> The good thing is that from TE's perspective, the only thing we have to
> worry about are these "normalised" bandwidth (reflecting LSP/link size
> Overbooking).
> If an LSP bandwidth is configured/signaled as 100, it is irrelevant (for
> TE) whether the SP expects a peak load of 200 on that LSP and applied an
> LSP overbooking of 2, or whether the SP actually expects a peak load of
> 100 and applied no overbooking.
> Similarly, the relevant constraint is the Max Reservable Bandwidth
> (which can be configured smaller or larger than real link capacity). For
> TE, what matters is that the Max Reservable Bw is set to, say, 1000. It
> doesn't really matter whether the link is actually indeed of 1000 or
> whether it is actually a link of 500 with an link overbooking of 2.
> Basically, TE will establish 10 LSPs of configured bandwidth 100 on that
> link of 1000. That's it.
> This is why, in regular TE, only the LSP bandwidth is the one considered
> (and is indeed a normalised bandwidth factoring LSP Size Overbooking)
> and only Max Reservable is considered (which is also a normalised value
> factoring in the link size overbooking). 
> One interesting point is that TE does not explicitly need the concept
> of LSP size Overbooking *Multiplier" and the Link Size Overbooking
> *Multiplier". They are effectively transparent to TE which works only on
> normalised bandwidth. 
> 
> The DS-TE approach is the same with respect to LSP/link Size Overbooking
> ie the only "bandwidth" we are concerned about is the actual LSP size,
> which factors in the LSP Size Overbooking (ie which is normalised , as
> you stated) and the BCs [+ Max Reservable Bw (as proposed)].
> For DS-TE, like for TE, I think we don't need to explicitly define in
> the drafts the concepts of LSP/Link Size overbooking Multipliers (LSOMs)
> nor formulas using them because we operate directly/exclusively on
> "normalised" values. But I think we  agree in spirit in what those would
> be anyway, based on our discussion.

Thank you for the good and clear explanation.

Then, to clarify further, the following relationship would seem to hold:

LSOM = Max Reservable Bandwidth/Max Link Bandwidth

Is that correct?

If so, then another way to write your proposed formula for the sum of reserved bandwidth would be:

  o SUM (Normalized(CTc)) <= Max Link Bandwidth X LSOM
      for all "c" in the range 0 <= c <= (MaxCT-1)

Is that right?

Thanks,
Jerry