FW: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Jerry,

A few more questions on the example below:

1) as described below, it looks to me like MAR would cope well with
"overload" situations in situations where all CTs are gradually
increasing their load at the same time so they start "contending" before
one CT has had a chance to hogg a lot of bandwidth. 
But it is not clear how to me MAR would cope with situations where one
CT gets greedy before the other CTs get a chance to contend: for
example, if we assume that CT0 only has reserved 5 and CT1 only has
reserved 5, is there anything that would prevent CT2 from reserving up
to 80?

2) as described below, MAR seemed to target some minimum per-CT
bandwidth apportionment via Bwalloc[i] in case of contention, but does
not seem to be able to enforce a hard "per-CT" maximum reservation in
the absence of contention. 
For example, let's say SP wants to first establish all the Voice TE-LSPs
and want to limit those to 40% of link capacity for some voice
engineering reason (say the Premium Data LSPs and Best-Effort LSPs will
be established after the Voice LSPs).
Could you use MAR to ensure CT2 Voice LSPs would be limited to 40% even
when they are established before any CT1 and CT0 LSPs?
Or are you assuming that load across all CTs is normally increasing
simultaneously?

3) In the case where we want to provide all necessary information to a
Head-end to be able to perform optimisation in case of multiple LSP
establishment, what would be the parameters that would need to be
signaled in IGP (Bwalloc, RBW,...?)?

Thanks

Francois


>> We have 3 CTs: CT0, CT1, CT2, all with 'normal' priority.
>> We have a particular link with capacity = 100. 
>> MAR allocates CT bandwidth for the normal traffic loads, and 
>> in this example the BWalloc values on the given link are as follows:
>> 
>> BWalloc for CT0 = BWalloc0 = 30
>> BWalloc for CT1 = BWalloc1 = 20
>> BWalloc for CT2 = BWalloc2 = 20
>>  
>> This leaves 100 - 70 = 30 units of spare bandwidth on the 
>> link under normal loading.  With MAR, any of the CTs is 
>> allowed to exceed its BWalloc as long a there is at least 
>> RBWk (reserved bandwidth on the link) units of spare 
>> bandwidth remaining.
>> 
>> Let's say RBW = 10.  So under overload, if 
>> 
>> CT0 has taken 50 units of bandwidth (bandwidth-in-progress 
>> for CT0 = BWIP0 = 50),
>> CT1 has taken 30 units of bandwidth (bandwidth-in-progress 
>> for CT1 = BWIP1 = 30),
>> CT2 has taken 10 units of bandwidth (bandwidth-in-progress 
>> for CT2 = BWIP2 = 10),
>> 
>> Therefore, for this loading,
>> Idle link bandwidth (ILBW) = 100 - 50 - 30 - 10 = 10
>> 
>> Let's say a flow arrives for CT0 needing 5 units of 
>> bandwidth (i.e., DBW = 5).  We need to decide based on Table 
>> 2 and Table 1 whether to admit this flow or not.
>> 
>> The link load state is determined from Table 2:
>> 
>> Since ILBW - RBW < DBW (i.e., 10 - 10 < 5), Table 2 says the 
>> link is in the RBW (reserved bandwidth) state.
>> 
>> The allowed load state is determined from Table 1 (the 
>> allowed load state is the minimum level of bandwidth that 
>> must be available on a link to admit the flow):
>> 
>> Since for CT0 (normal priority) BWalloc0 < BWIP0 (30 < 50), 
>> Table 2 says the allowed load state is ABW (available bandwidth).
>> 
>> Hence since the link has less bandwidth (RBW state) than the 
>> allowed load state level of bandwidth required to admit the 
>> flow (ABW), the flow is rejected/blocked.
>> 
>> Now let's say a flow arrives for CT2 needing 5 units of 
>> bandwidth (i.e., DBW = 5).  We need to decide based on Table 
>> 2 and Table 1 whether to admit this flow or not.
>> 
>> The link load state is determined from Table 2:
>> 
>> Since ILBW - RBW < DBW (i.e., 10 - 10 < 5), Table 2 says the 
>> link is in the RBW (reserved bandwidth) state.
>> 
>> The allowed load state is determined from Table 1 (the 
>> allowed load state is the minimum level of bandwidth that 
>> must be available on a link to admit the flow):
>> 
>> Since for CT2 (normal priority) BWIP2 < BWalloc2 (10 < 20), 
>> Table 2 says the allowed load state is RBW (reserved bandwidth).
>> 
>> Hence since the link has sufficient bandwidth (RBW state) 
>> compared to the allowed load state level of bandwidth 
>> required to admit the flow (also RBW), the flow is admitted.
>> 
>> Hence, in the above example, in the current state of the 
>> link and the current CT loading, CT0 and CT1 can no longer 
>> increase their bandwidth on the link, since they are above 
>> their BWalloc values and there is only RBW=10 units of spare 
>> bandwidth left on the link.  
>> 
>> But CT2 can take the additional bandwidth (up to 10 units) 
>> if the demand arrives, since it is below its BWalloc value.
>>