[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposal for Simplification of Overbooking
Sandy,
> I'm a little unclear as to your intention in the "integrated
> approach." Is it that the Local Overbooking Multiplier,
> instead of an independent representation of a CT's
> overbooking policy (which is what the new term "OB(CTc)"
> would signify), will now be rather a kind of correction
> factor, configured as needed link by link, to other factors
> which are configured globally?
Yes, the proposed OB(CTc) would be configured by link, by CT, just as in the current proposal for LOM(CTc). However, OB(CTc) is meant to combine, functionally:
LSPOMc = LSP overbooking multiplier for CTc
LSOM = link size overbooking multiplier for a given link
LOMc = local overbooking multiplier, currently proposed per-link, per-CT adjustment factor
In our draft we propose:
OBc = LSPOMc * LSOM * LOMc
> I think in general this wouldn't be a bad way to get
> compatibility with older TE procedures. However, I'm still
> uncomfortable with how even network-wide per-CT policies are
> supported using Link Size Overbooking. And the integrated
> approach appears to build on an understanding of how this is
> done: "For either per-domain per-CT overbooking or per-link
> per-CT overbooking, we have Reserved(CTc) = Tspec(LSPc) /
> OB(CTc)" and "OB(CTc) = LSOM * LSPOM(CTc) * LOM(CTc)."
>
> Specifically, how do you calculate Unreserved (CTc) using
> "LSPOM" when there are per-CT policies and an aggregate
> constraint? I don't see that BCc - Reserved (CTc) / (LSOM *
> LSPOM) yields an effective value to advertise. After all, if
> CT7 has a policy of no overbooking, even though the link
> generally is allowed to be overbooked, if BC7 = 50 and the
> CT's reservation total is 50, then Unreserved (CT7) should
> be 0.
I don't understand your example, I think we need a more detailed example.
Let me try to create an example, and compare today's method of overbooking (Case A) and the proposed method of overbooking (Case B):
Take a link with:
Max link bandwidth = 100
Max reservable bandwidth = 200
(that is, in today's parlance, LSOM = 200/100 = 2, the link bandwidth is overbooked by a factor of 2)
BC0 = 50
BC1 = 150
LSPOB0 = 1
LSPOB1 = 4
(that is, in today's parlance, CT0 is not overbooked, CT1 is overbooked by a factor of 4)
LOM0 = 1
LOM1 = 1
(that is, in today's parlance, no per-link/per-CT overbooking adjustment is made for either CT0 or CT1 using LOM)
Suppose we have 2 LSPs set up over this link:
LSP0 requested bandwidth = 30
LSP1 requested bandwidth = 80
Case A: today's way of applying overbooking factors:
----------------------------------------------------
Tspec(LSP0) = LSP0 requested bandwidth/LSPOB0 = 30/1 = 30
Tspec(LSP1) = LSP1 requested bandwidth/LSPOB1 = 80/4 = 20
Reserved(LSP0) = Tspec(LSP0) = 30
Reserved(LSP1) = Tspec(LSP1) = 20
Then
Unreserved(CT0) = BC0 - Reserved(CT0) = 50 - 30 = 20
Unreserved(CT1) = BC1 - Reserved(CT1) = 150 - 20 = 130
These quantities are advertised.
Case B: the proposed modified way of applying overbooking factors:
------------------------------------------------------------------
First we adjust the BC0 and BC1 by the LSOM for this link:
BC0 = 50/2 = 25
BC1 = 150/2 = 75
(note that the proposed method uses Max link bandwidth as the aggregate constraint)
Then we determine the OB0 and OB1 factors:
OB0 = LSPOB0 * LSOM * LOM0 = 1 * 2 * 1 = 2
OB1 = LSPOB1 * LSOM * LOM1 = 4 * 2 * 1 = 8
Tspec(LSP0) = LSP0 requested bandwidth = 30
Tspec(LSP1) = LSP1 requested bandwidth = 80
Reserved(LSP0) = Tspec(LSP0)/OB0 = 30/2 = 15
Reserved(LSP1) = Tspec(LSP1)/OB1 = 80/8 = 10
Then
Unreserved(CT0) = BC0 - Reserved(CT0) = 25 - 15 = 10
Unreserved(CT1) = BC1 - Reserved(CT1) = 75 - 10 = 65
These quantities are advertised.
I hope this further clarifies the proposal. Perhaps you can ask your question in terms of specifics in the above example.
Thanks,
Jerry