[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another question related to LOM as described in DS-TE-PROTO
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:Sanjaya.Choudhury@marconi.com]
> Sent: Thursday, March 28, 2002 1:42 PM
> To: 'Francois Le Faucheur'; te-wg@ops.ietf.org
> 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
>
>
>