Subject: Re: Another question related to LOM as described in DS-TE-PROTO

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 18 Jun 2002 12:40:01 +0200

At 12:37 05/04/2002 -0500, Choudhury, Sanjaya wrote:

>Hi Francois! I have one more question related to
>usage of LOM as described in the DS-TE-PROTO.

Sanjaya and all,

I did more thinking on LOM.

My conclusion is that the LOM should be reflected in the Unreserved Bw 
values advertised in IGP. The LOM should be reflected as if the BCs had 
been inflated by their respective local LOM.

Back to your example:
Assume (simple admission control scheme, single preemption level):
CT              LOM    BC
-----------------------------
CT0             400%    200M
CT1             200%    100M
Initially, IGP advertises:
         Unreserved CT0xLOM(0)=800
         Unreserved CT1xLOM(1)=200
After establishment of an LSP with CT=CT1 and BW=100, IGP advertises:
         Unreserved CT0xLOM(0)=800-100=700
         Unreserved CT1xLOM(1)=200-100=100

The example formulas for computing Unreserved Bw would simply become:
"Unreserved TE-Class [i]" =
         MIN  [
         [ (BCc-LOM(c)) - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
      . . .
         [ (BC0-LOM(0)) -  SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b 
<= 7,
           ]

My rationale is that:

         - I think the LOM needs to be factored in by the local LSR on 
which they are configured because only this LSR can accurately factor their 
impact across the other Class-Types. This relates to the discussion we had 
with Dimitry and the point that a Head-end just cannot always guess exactly 
the distribution of bandwidth across the various CTs, only the local LSR 
can know it. So only the local LSR can accurately factor in the LOM of each 
CT and then advertises Unreserved Bw values which reflect this.

         - I think the LOM needs to be factored as an "inflation" of the 
bandwidth pool (as opposed to a "deflation" of the LSP size) because we 
should make this work even if the Head-end is not aware that Local 
Overbooking is used somewhere remotely in the network (or even does not 
support optional Local Overbooking) and thus Head-end need to always 
operate on "raw/unmodified" tunnel bandwidth.

Properties of this approach are:
         - the Local Overbooking method can be deployed without having to 
advertise the optional LOMs in the IGP (as long as the local optimisation 
on HE is not required). ie I just configure LOMs locally on LSRs and this 
only changes existing advertisement without necessitating additional 
advertisement.
         - The LOcal Overbooking methods can be used even if the head-end 
does support the "LOM" option itself. Basically if an LSR support the 
optional LOM on one of its link, all the Head-end will efectively benefit 
from the LOM on that link, without even knowing that their is Local 
Overbookinmg on that particular link.

Note that, when BC sub-TLV is used, the BCs need not be affected by LOM. 
They are advertised just as configured. Only the "unreserved Bw" values are 
affected by LOM. Note that this can result in "Unreserved Bw" values being 
larger than the BC values when LOM is used, but I don't think this is an 
issue because:
         - either Head-end does not do local optimisation and thus will 
ignore the BC values (and just use the "Unreserved Bw" values)
         - or Head-end does local optimisation and thus it needs to be 
LOM-capable and it needs to receive the optionnal LOM sub-TLV. It woudl 
then understand that , when LOM is used, the Unreserved Bw values are based 
on BC x LOM.

Could you think through the above approach and give me feed-back?

Thanks

Francois

>Assume (simple admission control scheme):
>CT              LOM    BC
>-----------------------------
>CT1             200%   100M
>CT0(CT1+CT2)    400%    200M
>
>1) create lsp1 BW 20M ct=ct1 then
>    CT1_AVAIL_BW=100-20/2=90M
>    CT0_AVAIL_BW=200-20/2=190M (and *not* 200-20/4=195m)
>Am I correct?
>
>Thanks,
>sanjay
>
>
> > -----Original Message-----
> > From: Choudhury, Sanjaya [mailto:[email-masked]]
> > Sent: Thursday, March 28, 2002 1:42 PM
> > To: 'Francois Le Faucheur'; [email-masked]
> > Subject: question related to DS-TE-PROTO: Does advertised
> > unreserved bw
> > ta ke LOM into account ?
> >
> >
> >
> >  Hi! Here is a question related to DS-TE-PROTO-3 draft.
> >
> >    Is the following assumption correct ?
> >
> >    The  per-TE-Class unreserved bandwidth advertised by IGPs, are
> >    the actual bandwidth available for the TE-Class [i.e
> > _without_ taking
> >    the LOM into account.]
> >
> >    The PCM of the a LSR may use the advertised unreserved BW and
> >    value from the LOM TLV, to decide (/predict), whether it should use
> >    a specific link.
> >
> >    A simplistic example:
> >       (i)   Assume the actual link bw 100M
> >       (ii)   Only CT0 is supported (and only 1 preemption priority
> > supported)
> >      (iii)  LOM[0] = 200%
> >
> >      Case-1: No LSPs have been established
> >
> >                  Assumption:
> >                  -------------
> >             In this case the Adv bw is   100M  (and not 200M)
> >                   [Although 200M worth of CT0 connections can be
> >                    established]
> >
> >       Case-2: 1 LSP with 50M bandwidth has been established
> >
> >                   Assumption:
> >                   --------------
> >                   In this case the Adv bw is  = 100 -50/2 =
> > 75M (and not 200
> > -50 = 150M)
> >
> > Thanks,
> > sanjay
> >
> >
> >

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 24 Jun 2002 18:44:10 +0200

Sanjaya and all,

At 12:40 18/06/2002 +0200, Francois Le Faucheur wrote:
>         [ (BCcxLOM(c)) - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b 
> <= 7,
>      . . .
>         [ (BC0xLOM(0)) -  SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b 
> <= 7,
>           ]

As I got into teh nitty-gritty of this, I realised the formulas should 
actually read:
"Unreserved TE-Class [i]" =
           LOM (c)  x  MIN  [
         [ BCc - SUM ( Reserved(CTb,q)/LOM(b) ) ]   for q <= p and c <= b <= 7,
      . . .
         [ BC0 -  SUM ( Reserved(CTb,q)/LOM(b) ) ]    for q <= p and 0 <= b 
<= 7,
           ]

To illustrate this, let's consider again the example above with two CTs and 
single preemption.
CT              LOM    BC
-----------------------------
CT0             400%    200M
CT1             200%    100M

Above Formulas become:
Unreserved CT0 = LOM(0) x  [ BC0 - Reserved (CT0)/LOM(0) - Reserved 
(CT1)/LOM(1) ]
Unreserved CT1 = LOM(1) x
                 MIN  [
                 [ BC0 - Reserved (CT0)/LOM(0) - Reserved (CT1)/LOM(1) ]
                 [ BC1 - Reserved (CT1)/LOM(1) ]
                 ]

If there is no established LSP, IGP advertises:
         Unreserved CT0 = 4 x (200 - 0/4 - 0/2 )= 800
         Unreserved CT1 = 2 x (100- 0/2) = 200

If there is only a single LSP established with CT=CT0 and BW=100, IGP 
advertises:
         Unreserved CT0 = 4 x (200 - 100/4 - 0/2 )=700
         Unreserved CT1 = 2 x (100- 0/2) = 200

If there is only a single LSP established with CT=CT1 and BW=100, IGP 
advertises:
         Unreserved CT0 = 4 x (200 - 0/4 - 100/2 )= 600
         Unreserved CT1 = 2 x (100- 100/2) = 100
That's the interesting bit (and where the previous formulas got it wrong). 
Basically, the effect of a tunnel on the available bandwidth of a CT, 
depends on the LOM for the CT of that tunnel. In other words, you can see 
above that a tunnel of BW=100 affects Unreserved CT0 twice more if it is a 
CT1 tunnel than a CT0 tunnel [ because LOM(1) is twice less than LOM(0) ]

If there are two LSPs established, one with CT=CT1 and BW=100 and one with 
CT=CT0 and BW=100, IGP advertises:
         Unreserved CT0 = 4 x (200 - 100/4 - 100/2) = 500
         Unreserved CT1 = 2 x (100 - 100/2) = 100

I think I got it right this time.

Francois

> which they are configured because only this LSR can accurately factor 
> their impact across the other Class-Types. This relates to the discussion 
> we had with Dimitry and the point that a Head-end just cannot always 
> guess exactly the distribution of bandwidth across the various CTs, only 
> the local LSR can know it. So only the local LSR can accurately factor in 
> the LOM of each CT and then advertises Unreserved Bw values which reflect this.
>
>They are advertised just as configured. Only the "unreserved Bw" values 
>are affected by LOM. Note that this can result in "Unreserved Bw" values 
>being larger than the BC values when LOM is used, but I don't think this 
>is an issue because:
> then understand that , when LOM is used, the Unreserved Bw values are 
> based on BC x LOM.
>
>