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

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Jerry,

See very far below: 

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] 
>> Sent: 21 May 2003 15:24
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; te-wg@ops.ietf.org; Lai, 
>> Wai S (Waisum), ALABS; Dimitry Haskin
>> Subject: 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
>> 

In the "LSP/Link Size Overbooking" method one can apply overbooking by
tweaking the LSP size (lets' call this the "LSP Size Overbooking")
and/or by tweaking the Max Reservable Bw (lets' call this the "Link Size
Overbooking").

Assuming we define LSOM as the "Link Size Overbooking Multiplier" (as
opposed to the "LSP/Link Size Overbooking Multiplier"), then I agree
with the above relationship.

Just to be clear, what I am trying to say is that the above relationship
you stated relates to the overbooking applied on the Link (but that the
overbooking applied on the LSP size is transparent to that because it is
already factored in the LSP size configured/signaled).

>> 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?
>>

Again, assuming we define LSOM as the "Link Size Overbooking Multiplier"
(as opposed to the "LSP/Link Size Overbooking Multiplier"), then I agree
with your relationship.

Thanks for helping get all this clarified.

Francois
 
>> Thanks,
>> Jerry
>>