[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Another question related to LOM as described in DS-TE-PROTO
Francois:
Now
that we are taking LOM into account when calculating
unreserved bandwidth, do you think we need to do the
same
when
setting out the rules for the Russian Doll model?
The
current text states that:
"All LSPs supporting Traffic Trunks from CTb (with b<=c<7)
use
no more than BCb".
However, this statement does not take the LOM into account.
Take
a look
at the following example:
Assume
two CTs are supported (CT0, CT1) and LOMs are set as
400%
and 200% for CT0 and CT1 respectively. Also assume
that
the
BC0 is set to 100% of the link capacity and BC1 is set to
60%
of the
link capacity. Finally, assume we have the following
TE-classes
defined:
TE-Class CT
P.Priority
0
0 0
1 1
0
On a
100 Mbps link initially we will advertise 400Mbps and
200Mbps
unreserved bandwidth (due to overbooking).
However, if we receive
a setup request for 150Mbps for either CT0 or CT1 we have to reject
it according to the text
above (because 150Mbps > 100Mbps and
150Mbps > 60Mbps). Obviously when we take the LOM
into account
this is not an issue, but to be consistent with the
rest of the text I think
Russian Doll model section of the draft can be
rephrased to include
the LOM.
On a related issue, do we want to allow the user to use
a greater LOM
for CT(i+1) than CT(i)? In the above example can the
user set LOM for
CT0 to 200% and LOM for CT1 to 400%? To me this type of
configuration
does not make sense but do we want to spell this out in
the draft?
Regards,
--Sami
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
>
>
>