Subject: RE: E-LSP or L-LSP

From: Shahram Davari <[email-masked]>
Date: Mon, 27 Nov 2000 08:11:45 -0800

Hi Daneil,

With all due respect, I don't think that your mentioned approach will work efficiently. First of all it is not reasonable to expect all routers to have exactly the same BW assignment per PHB. Secondly, it is also not reasonable to expect an E-LSP to carry traffic in proportion to their PHB assignments in the routers.

My understanding of using the E-LSP aggregate BW for admission control is as follows:

During an E-LSP setup, the aggregate BW of all supported PHBs is signaled. If all the routers in the path, have sufficient BW, the E-LSP is admitted. Now at the ingress to this E-LSP, the ingress router could do a separate admission control for each supported BA that is using the mentioned E-LSP (note this is independent of the E-LSP admission control). In other words there are two phases to the admission control, one for the whole E-LSP and another one for the traffic that is going to use that E-LSP. This is very similar to the Aggregate RSVP admission control (check ISSL WG for more information).

Regards,
-Shahram

> For an E-LSP, the aggregate bandwidth is known. This 
> aggregate bandwidth
> corresponds to the sum of bandwidths that are requested for 
> each PHB class
> that are carried inside the E-LSP. In case that the 
> distribution of the
> PHB classes is known, then admission control could be carried out.
> In networks where resources are pre-allocated per PHB class
> and where this is done consistently on all LSR, then the distribution
> of the pre-allocated resources can be used to carry out 
> admission control
> per E-LSP.
> 
> For example, consider the following distribution:
> EF gets 5%, AF1.x gets 10%, AF2.x gets 20%, AF3.x gets 20%, 
> AF4.x gets 20%;
> meaning that on a 100Mbit/s link, EF could reserve up to 5 
> Mbit/s, AF1.x up
> to 10Mbit/s, etc. etc.
> 
> If now an E-LSP requests 7 Mbit/s and this E-LSP carries EF, 
> AF1.x and AF3.x
> traffic, then the 7 Mbit/s could be split up and assigned to 
> the classes
> as follows:
> EF - 1 Mbit/s
> AF1.x - 2 Mbit/s
> AF3.x - 4 Mbit/s
> according to the 'weights' of the resource distribution.
> Then, admission control for each class could be done 
> seperately. The E-LSP
> could be admitted if all of the admission control checks succeed.
> 
> Does this sound reasonable?
> 
> Of course, the whole scheme does not work if the 
> pre-allocated resource distribution
> is not consistent amont all LSR routers.
> 
> Best regards,
> 
> -Daniel
> 
> 
> 
> Marcus Brunner wrote:
> > 
> > Shahram,
> > 
> > In many scenarios, the admission control for a PBH 
> scheduling classes is
> > already fuzzy, which means on a statistical level, you will run into
> > trouble if you want to do admission control for aggregates 
> of different
> > PHB classes.
> > 
> > Marcus
> > 
> > Shahram Davari wrote:
> > >
> > > Hi Daniel,
> > >
> > > You can do admission control for E-LSP too. But the 
> admission control is done for the aggregate of all supported 
> PHBs in that LSP.
> > >
> > > Regards,
> > > -Shahram
>

---

From: "Daniel N. Bauer" <[email-masked]>
Date: Tue, 28 Nov 2000 08:04:05 +0100

> During an E-LSP setup, the aggregate BW of all supported PHBs is signaled. If all the routers in the path, have sufficient BW, the E-LSP is admitted. Now at the ingress to this E-LSP, the ingress r…

Hello Shahram,

maybe my assumptions are a little bit far-fetched. Still, your
solution does not (yet?) convince me, either.
In your proposal, the following points are not quite clear to me:

1.) How does the "admission control for each supported BA" work?
    How does the ingress LSR split up the aggregated BW request into
    a BW request for each BA? What is the rational to do admission
    control for the BAs only at the edge?
    I don't find this very similar to the Aggregate RSVP admission control.
    There, the requirement of each flow is known before the flows are aggregated.
    This is not the case for E-LPSs.

2.) If admission control for E-LSPs is only based on the aggregate bandwidth,
    it becomes difficult to do a reliable admission control for L-LSPs. For L-LSP
    admission control, the LSRs need to know the unreserved bandwidth per OA.
    How is it possible to do book-keeping for unreserved bandwidth, if E-LSPs
    are admitted on the aggregate?

Maybe a solution is to extend the signaling and include optionally the
BW requirements per OA for E-LSPs.

Regards,
-Daniel

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 28 Nov 2000 15:57:49 +0100

All,

>BW requirements per OA for E-LSPs.

For information:
The question of whether it would be worth adding yet another option to the
spec to support per-OA bandwidth signalling (for admission control
purposes), has already been discussed when progressing the draft (see
thread "Re: BANDWIDTH RESERVATION - RE: Announcing").
Below is one message from that thread which should give you some background
as to why we elected to not include such extensions.
Hope that is useful.
Francois

>Delivered-To: [email-masked]
>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Wed, 01 Mar 2000 11:36:43 -0500
>To: [email-masked]
>From: Francois Le Faucheur <[email-masked]>
>Subject: Re: BANDWIDTH RESERVATION - RE: Announcing
>  draft-ietf-mpls-diff-ext-03.txt 
>Cc: Francois Le Faucheur <[email-masked]>,
>        Shahram Davari <[email-masked]>,
>        "'Juha Heinanen'" <[email-masked]>, [email-masked],
>        [email-masked], [email-masked], [email-masked],
>        [email-masked], [email-masked],
>        [email-masked]
>Sender: [email-masked]
>
>Curtis,
>
>At 19:22 25/02/2000 -0500, Curtis Villamizar wrote:
>
>>You have a fine I-D and I do agree that L-LSPs can be used if
>>reservation per BA is desired.  It is just more efficient to use an
>>E-LSP if more than one BA can be accomodated given the limited EXP
>>bits and also given the requirements of the BAs wrt fast-reroute,
>>adaptivity, and resilience match.  In the interest of making that
>>improvement in efficience possible, I would prefer if you would add
>>per BA (or per PHB as the MAPs are now defined) bandwidth as an option
>>to the MAPs for E-LSPs.
>>
>>Please consider making this change to the I-D.
>>
>
>I am considering... but not convinced.
>
>We agree that if one wants to do per-OA Routing and per-OA admission
>Control, then this can be done using L-LSPs + bandwidth reservation as
>currently defined. Call this Mode 1.
>We also agree that if one  wants to do aggregate routing of Multiple-OAs
>and Aggregate Admission Control of Multiple-OAs, then this can be done
>using E-LSPs + bandwidth reservation as currently defined. CAll this Mode 2.
>
>The suggestion above is for extensions allowing aggregate routing/transport
>of multiple-OAs with per-OA admission control. Call this MOde 3. Firstly,
>such an extension would also require defining the procedures and error code
>for handling situations where the admission control for one OA is
>successful while the admission control for another OA is rejected. You
>woudl have to reject the E-LSP explaining which admission control failed.
>Secondly, that would mean that you cannot route one OA onto a Path which
>has capacity for it simply because it happens to travel on an E-LSP along
>another OA which has run out of capacity. In other words, multi-OA Routing
>with per-OA admission control achieves less efficient routing than Mode 2
>would.
>Is this not right?
>
>So, all in all, I still think:
>	- you can do pretty good and label-efficient with Mode 1 
>	- you can do the ideal per-OA thing with Mode 2. 
>	- Mode 3 does not have a strong application in between these 2.
>	- there are already quite a lot of options in our spec...
>
>Do you still see a strong application for Mode 3 which would justify
>extensions in the MAP but also extensions in all the error codes and
>procedures (today we rely on normal RSVP error handling to signal rejection
>because of admission control)?
>
>Opinions from others?
>
>Cheers
>
>Francois
>