[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Hello,
Here's my analysis of the thread:
There are (at least) three "ways" E-LSPs may potentially be used for DS-TE
and I suggest dealing with them separately:
1) using E-LSPs with traffic from a single OA:
==============================================
This is already explicitely allowed in the recently posted REQTS draft.
As pointed out already, one application for this to allow LSRs to pick
queues based on EXP rather than Label.
I think everyone agrees this is all fine.
2) using E-LSPs with traffic from multiple OAs but using single CSPF
=====================================================================
Jim Boyle provided a convincing example of how this could be used in his 19
Sept message (ie in the case where ratio between voice-sig and
voice-payload is known and stable so both traffic can be treated together
as a whole from CSPF viewpoint).
The important point is that although we have traffic from multiple OAs,
those are really treated as a single "traffic trunk" from the DSTE perspective.
However, this is currently not allowed in the recently posted REQTS draft.
I agree that REQTS draft should be modified to allow this case. This does
not create any significant changes to the current DS-TE model and does not
entail any protocol extensions (ie it comes for free), so it would indeed
be an artificial unnecessary restriction to rule it out.
3) using E-LSPs with traffic from multiple OAs each with their own SPF
======================================================================
In that case, EF and AF1 may be transported on a single E-LSP and would
each have their own CSPF (ie own bandwidth, and being constrained by
different bandwidth constraints, and then presumably with different
restoration requirements, most probably different preemption priorities,...).
To me, Joel perfectly captured the implications of doing this in his
message below. I'll still expand a little.
This would be a departure from the current TE/DS-TE model: so far all
properties are associated with a tunnel (bandwidth, bandwidth pools,
affinity, preemption, restoration) while this new model would require
associating multiple sets of these attributes on every tunnel (eg. one set
per transported OA). It would also require defining/implementing rules for
dynamically mapping multiple OAs on a given LSP (like what do you do when
you have put EF and AF1 on a given E-LSP and now there is a more optimum
path for EF but which is not optimal for AF1: do you clear the existing
E-LSP and try to find existing LSPs which can carry OA and EF on their new
paths, do you resignal the existing LSP with a zero bandwidth for AF1,...).
Some may say this is a small departure, some say it is a significant departure.
This would also require protocol changes (eg. signaling multiple bandwidth
on E-LSP; and I would presume also signal multiple preemption and also
signal multiple affinity requirements...).
Some say these are small changes, some say we already have too many options
and changes in the works.
Regardless of whether one thinks the departure from the model is small or
significant, I think it is a fact that there is a departure which would
need to be explicitely addressed with all its ramification (preemption,
reoptimisation, ...); regardless of whether one thinks the protocol changes
are small or significant, it is a fact that there would be protocol
changes. Interesting engineering work, for sure. But I will repeat myself :
I think we should only commit the TEWG to do such work if SPs require this
in the foreseeable future. So let's hear what SPs say about this.
Otherwise, let's first focus on specifying a simpler solution that
addresses what SPs want to do in the foreseable future so we can get it out
the door fast. Then we can always expand if/when requirements expand.
Cheers
Francois
At 14:17 20/11/2001 -0500, Joel M. Halpern wrote:
>The CAC is not the problem.
>The CSPF, and the source of the information for the CSPF, is the
>problem. Not only do you have to give the requirements to the CSPF
>algorithm (a local process, or a central one, or ... but anyway not what
>we are discussing), but you also must include all N individual bandwidth
>requirements in your request. That is, when you signal the LSP you must
>tell the network how much bandwidth you will use for each class within the
>LSP. This is necessary for two reasons:
>1) The CSPF information may have been out of date, and therefore must be
>checked per link per class
>2) Each link needs to update its per class utilization information, and it
>can only do so if you provide sufficient information.
>
>Therefore, what you have done is NOT signal one TE LSP, but rather to
>signal N LSP with the requirement that they be routed, protected, and
>re-routed together. You got no effective scaling benefit because all the
>bookkeeping has to look at these as separate LSPs.
>
>Hence, the capability you are asking for is the capability to signal an
>LSP bundle that is to be treated together. That is an interesting
>feature, but not a trivial extension to what we have if it is to be done right.
>
>Yours,
>Joel M. Halpern
>
>At 07:45 PM 11/20/01 +0100, Roberto Mameli (ERI) wrote:
>>So, it seems to me that aggregate TE simply means that I choose a single
>>path supporting all BAs, with the same protection/restoration options.
>>This does not automatically preclude that CSPF and CAC require per-PSC
>>bandwidth information as an input. I simply give N bandwidth requirements
>>(one for each of the N classes) to the CSPF algorithm, and it gives me
>>back a SINGLE path capable of carrying all the BAs. If my CSPF would run
>>based only on the E-LSP aggregate bandwidth I would not be able to choose
>>between two different paths with the same total occupancy... see again my
>>previous example, where each link is preconfigured to 50% in all the
>>routers (not reserved, simply preconfigured). In that example I do NOT
>>make aggregate reservation... I have preconfigured BW in every node and
>>simply need some additional information to choose the best way to route
>>the new LSP.
>>
>>However, my point is that I don't want to force the SP to use E-LSP. I
>>just want to say that, since E-LSP exists, a provider could be interested
>>to use it (for whatever reason). If E-LSP cannot be used for nothing more
>>than pure DiffServ, than there is no reason to have E-LSP. Just set up N
>>L-LSP instead of a single one carrying N OAs. But if we think that E-LSP
>>are really useful we cannot bias the standards towards a specific solution.
_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone: +33 4 97 23 26 19
Mobile : +33 6 89 108 159
Fax: +33 4 97 23 26 26
Email: flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410 Biot - Sophia Antipolis
FRANCE
_________________________________________________________