[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: link capacity and reservable
Dimitry,
>> -----Original Message-----
>> From: Dimitry Haskin [mailto:dhaskin@axiowave.com]
>> Sent: 20 May 2003 16:45
>> To: 'Lai, Wai S (Waisum), ALABS'; te-wg@ops.ietf.org
>> Cc: Dimitry Haskin; Francois Le Faucheur (flefauch); Ash,
>> Gerald R (Jerry), ALABS
>> Subject: RE: link capacity and reservable
>>
>>
>> Waisum, Jerry,
>>
>> IMO, both yours and Francois' formulas for the aggregate reservation
>> constrain would achieve identical results.
I guess you're right that at the end of the day it would be pretty much
the same thing functionnally.
>>Note that max
>> reservable b/w
>> constraint is simply applied to the sum of reservations at
>> each CT which
>> already account for individual overbooking factors at each
>> CT. However with
>> the formula that you are proposing we would completely shut
>> the door for
>> other uses of the max link b/w TLV, for instance as a
>> constraint on the max
>> LSP b/w. Since we have already a parameter that was
>> explicitly defined as
>> the aggregate reservation constrain, there is no need to
>> close door for a
>> different use of the max link b/w parameter at this point.
>>
Agreed.
Thanks
FRancois
>> Regards,
>> Dimitry
>>
>> > -----Original Message-----
>> > From: Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> > Sent: Monday, May 19, 2003 4:47 PM
>> > To: te-wg@ops.ietf.org
>> > Cc: Dimitry Haskin; Francois Le Faucheur (flefauch); Ash, Gerald R
>> > (Jerry), ALABS
>> > Subject: link capacity and reservable
>> >
>> >
>> > This is in response to the discussion of maximum reservable
>> > bandwidth in
>> > http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00264.html
>> > http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00265.html
>> > As the issue is not restricted solely to MAM, and has impact on
>> > RDM and in fact all BC models, I am talking about it in a more
>> > general context.
>> >
>> > Current TE extension in IGP deals with aggregate traffic.
>> > There is thus a simple average-overall relationship:
>> > max link bandwidth = max reservable bandwidth/overbooking.
>> > As a result, whether "max link bandwidth" is supported or
>> > commonly used or not is immaterial.
>> >
>> > In DS-TE, there is per-CT bandwidth contstraint and per-CT
>> > overbooking. Max reservable bandwidth should accordingly be
>> > treated as a vector quantity. Reflecting this view, the
>> > following definition for MAM in <tewg-diff-te-reqts> is
>> > adequate:
>> > for each value of b in the range 0 <= b <= 7:
>> > Reserved (CTb) <= BCb
>> > (with some clarification in MAM spec regarding overbooking)
>> >
>> > Also, the following additional condition for MAM definition as
>> > proposed in the second message quoted above is both unneccsary
>> > and incorrect:
>> > SUM (Reserved (CTc)) <= Max Reservable Bandwidth
>> > for all "c" in the range 0 <= c <= (MaxCT-1)
>> >
>> > This is like when I have 15 dollars and 10 euros in my pocket,
>> > then my max reserve is 25 (of what unit).
>> >
>> > The "max link bandwidth," being a normalized quantity, is more
>> > meaningful. For admission control under MAM, in addition to
>> > the observing the bandwidth constraints as specified in the
>> > above deinition, something like the following may be used:
>> > SUM (Reserved (CTc)/overbooking(CTc)) <= Max Link Bandwidth
>> > for all "c" in the range 0 <= c <= (MaxCT-1)
>> > (with some tweaks to account for priorities)
>> >
>> > Thanks, Wai Sum
>> >
>>