[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: link capacity and reservable
Hello again,
Specifically, here are the proposed updated formulas for MAM:
MAM Definition when LOM is NOT used (ie LOM[i]=1)
=================================================
o for each value of b in the range 0 <= b <= 7:
Reserved (CTb) <= BCb,
o SUM (Reserved(CTc)) <= Max-Reservable-Bw,
where the SUM is across all values of c in the range 0
<= c <= 7
MAM Definition when LOM is used
===============================
o for each value of b in the range 0 <= b <= 7:
Normalised (CTb) <= BCb,
o SUM (Normalised(CTc)) <= Max-Reservable-Bw,
where the SUM is across all values of c in the range 0
<= c <= 7
"Unreserved TE-Class [i]" when LOM is NOT used (ie LOM[i]=1)
============================================================
MIN [
[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
[ Max_Reservable_Bw - SUM ( Reserved(CTb,q) ) ] for q <= p and 0
<= b <= 7,
]
where:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
"Unreserved TE-Class [i]" when LOM is used
==========================================
LOM(c) x MIN [
[ BCc - SUM ( Normalised(CTb,q) ) ] for q <= p,
[ Max_Reservable_Bw - SUM ( Normalised(CTb,q) ) ] for q <= p and
0 <= b <= 7,
]
where:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
Cheers
Francois
>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch)
>> Sent: 26 May 2003 14:10
>> To: 'Lai, Wai S (Waisum), ALABS'; te-wg@ops.ietf.org
>> Cc: Ash, Gerald R (Jerry), ALABS; Dimitry Haskin; Francois
>> Le Faucheur (flefauch)
>> Subject: RE: link capacity and reservable
>>
>>
>> Hello Waisum,
>>
>> Thanks for your analysis.
>>
>> The point you raise (aka is there a need for vectorisation
>> of aggregate constraints?) was actually one of the key
>> technical points behind the discussion we had at the time of
>> breaking-out "Overbooking" into (i) LSP Size Overbooking,
>> (ii) Link Size Overbooking and (iii) per-CT Local
>> Overbooking Multiplier;
>>
>> I believe there was clear agreement that:
>> - there was a strong need for SPs to be able to apply,
>> on a network wide basis, a different level of overbooking
>> for different CTs (typically high overbooking on
>> best-effort, low/no overbooking on premium/voice)
>> - this was well supported by the "Link Size
>> Overbooking" method (effectively just pretending to have a
>> bigger link than the real one ; and thus effectively
>> applying a single per link overbooking which is COMMON to all CTs)
>> - there was a strong need for SPs to be able to apply a
>> different level of overbooking on differnet links (typically
>> higher overbooking on higher speed links)
>> - this was well supported by the "LSP Size Overbooking"
>> method (which allows different overbooking per CT - it even
>> offers finer granularity of per-LSP overbooking)
>> - there was only a weak potential need for being able
>> to apply different overbooking ratios which need to be
>> different for each CT on different links.
>> - this should be OPTIONAL
>> - this would be well supported by the per-CT Local
>> Overbooking Multiplier.
>>
>> A related conclusion of the above is that the "Link Size
>> Overbooking" method does NOT need to enforce different
>> overbooking ratios for different CTs. If the SP needs
>> different overbooking ratios for different CTs, then, in the
>> context of DS-TE, this can be achieved via the "LSP Size
>> Overbooking" method.
>>
>> Since the "Max Reservable Bandwidth" is involved only in the
>> "LSP Size Overbooking" method, it does NOT need to enforce a
>> different level of overbooking for different CTs; enforcing
>> the same one across all CTs is all what's required. This
>> means that, taking into account the specific environment of
>> DS-TE, the aggregate constraint does not need to be
>> vectorised (although I agree that in a completely generic
>> world it would have to).
>>
>> Now, in the case where the SP wants to enforce different
>> overbooking ratios for different CTs on different links,
>> then this needs to be achieved via the LOMs (and not via the
>> "Link Size Overbooking"). Then the LOMs need to be applied
>> individually to each CT which effectively results in the
>> vectorisation you described. This will be reflected in the
>> CAC formulas when updated to reflect the aggregate
>> constraint (which will be applied to the "Normalised Bw").
>>
>> So to recap in a nutshell, I believe the generic
>> "vectorisation" issue you discussed:
>> - does not apply to Link Size Overbooking in the
>> particular case of DS-TE (since Link Size Overbooking does
>> not need to enforce different overbooking ratios across CT)
>> and thus we only need a single "Max Res Bw" value
>> - does apply to the Local Overbooking Multiplier method
>> and is/will be reflected by applying the "Normalised Bw"
>> when applying the aggregate constraint.
>>
>> Thanks for helping getting to the bottom of this question.
>>
>> Cheers
>>
>> Francois
>>
>> >> -----Original Message-----
>> >> From: Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> >> Sent: 23 May 2003 20:58
>> >> To: te-wg@ops.ietf.org
>> >> Cc: Ash, Gerald R (Jerry), ALABS; Dimitry Haskin; Francois
>> >> Le Faucheur (flefauch)
>> >> Subject: RE: link capacity and reservable
>> >>
>> >>
>> >> Thanks to the responses from Jean-Louis, Dimitry, and Francois
>> >> regarding the issue on the use of max link bw versus max
>> >> reservable bw in my previous mesage (contained here at the end).
>> >>
>> >> The main point underlying the issue that has so far not been
>> >> discussed is this, because of per-CT overbooking, max reservable
>> >> bw should be treated as a vector quantity (as in my previous
>> >> dollar/euro analogy). Let me illustrate by an example.
>> >>
>> >> Max link bw = 100 (assuming some bw unit)
>> >> CT1: bw constraint = 80, LSP bw = 10
>> >> CT2: bw constraint = 70, LSP bw = 7
>> >>
>> >> In this setting (with all the quantities above being normalized
>> >> with respect to link bw), we can accommodate under MAM any one
>> >> of these combinations:
>> >> 8 CT1-LSPs + 2 CT2-LSPs = 94, 7 CT1-LSPs + 4 CT2-LSPs = 98,
>> >> 6 CT1-LSPs + 5 CT2-LSPs = 95, 5 CT1-LSPs + 7 CT2-LSPs = 99,
>> >> 4 CT1-LSPs + 8 CT2-LSPs = 96, 3 CT1-LSPs + 10 CT2-LSPs = 100.
>> >> The aggregate link bw's are all within the max link bw of 100.
>> >>
>> >> Now consider the usage of reservable bw:
>> >> CT1: overbooking = 2, LSP reserved bw = 2 x 10 = 20
>> >> CT2: overbooking = 4, LSP reserved bw = 4 x 7 = 28
>> >>
>> >> The corresponding max reservable bw's would be:
>> >> 8 CT1-LSPs + 2 CT2-LSPs = 216
>> >> 7 CT1-LSPs + 4 CT2-LSPs = 252
>> >> 6 CT1-LSPs + 5 CT2-LSPs = 260
>> >> 5 CT1-LSPs + 7 CT2-LSPs = 296
>> >> 4 CT1-LSPs + 8 CT2-LSPs = 304
>> >> 3 CT1-LSPs + 10 CT2-LSPs = 340
>> >>
>> >> In contrast with max link bw, it's not clear what criterion
>> >> should be used to pick *a single value* from the above list
>> >> and use it as the "aggregate" max reservable bw. While MAM
>> >> is being used here for illustration, this problem is generic
>> >> and affects RDM as well.
>> >>
>> >> As pointed out in my previous message, in current TE for
>> >> aggregate traffic, it is possible to define a single
>> >> "aggregate" max reservable bw value, since an average-overall
>> >> can be assumed. Once different overbooking factors are used
>> >> for different traffic components (e.g., CT's), this is no longer
>> >> the case, and each traffic component has its own max reservable
>> >> bw. That's what I mean by treating max reservable bw as a vector
>> >> quantity with distinct components. This fact is actually also
>> >> independent of the type of overbooking methods used, i.e., LOM
>> >> or not LOM.
>> >>
>> >> Thus, the proper way to do the computation is to first convert
>> >> reservable bw to link bw (or some equivalent normalized quantity),
>> >> and then check against the max link bw (or some equivalent
>> >> normalized quantity). Checking against the "aggregate" max
>> >> reservable bw is problematic since it is a list and not a single
>> >> value, as shown above.
>> >>
>> >> Regarding the limit of bandwidth for a single LSP, that's already
>> >> taken care of by the per-CT bw constraint (since it is assumed
>> >> to be normalized). If folks want to use the max link bw for this
>> >> purpose, it's not precluded by the above consideration either
>> >> (because if the max link bw puts a contraint on the aggregate
>> >> traffic, it certainly puts a contraint on a single LSP).
>> >>
>> >> Thanks, Wai Sum
>> >>
>> >> -----Original Message-----
>> >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
>> >> Sent: Tuesday, May 20, 2003 11:52 AM
>> >> To: Dimitry Haskin; Lai, Wai S (Waisum), ALABS; te-wg@ops.ietf.org
>> >> Cc: Ash, Gerald R (Jerry), ALABS
>> >> Subject: 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
>> >> >> >
>> >> >>
>> >>
>>