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

RE: link capacity and reservable



Jing,
  Many thanks for your example.
  As I stated earlier, current TE extension in IGP deals with
aggregate traffic.  Through a simple average-overall relationship:
max link bw = max reservable bw/overbooking,
it does not matter which quantity is used - in some sense they are
immutable under overbooking.
  But when different per-CT and per-link overbooking factors
are allowed, the use of "max reservable bw" in bw constraint
computation for admission control makes the rules more complex.
I think both your example and mine show that this is the case.
The use of some quantity that is normalized with respect to
the "max link bw" would be much more straightforward.
Thanks, Wai Sum

-----Original Message-----
From: Jing Shen [mailto:jshen_cad@yahoo.com.cn]
Sent: Sunday, May 25, 2003 3:58 AM
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


My question, if parameters in a new LSP setup request are converted as Lai stated, how could we select best path for new traffic flows?

for example, 
       /-----------b \
s----/                \--------t
    a \              /d
        \---------c/


S want to set up LSP of CT1  to T with bandwidth 5Mbps, while at node A there is tow branch ( to B or to C),  if link AC allow more overbooking than AB, but residual BW for CT1 is the same. 

Which path should we take ?  or should OSPF  use which value ( real BW or reservable BW) ? 

thanks 

Jing Shen




"Lai, Wai S (Waisum), ALABS" <wlai@att.com> wrote:
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 as! sumed. Once different overbooking factors are used
for different tr affic 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 b! w 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 ide! ntical results. 

I guess you're right that at the end of the da y 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), A! LABS [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 reserva! ble 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 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)
>> > 
>&! gt; > 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
>> >