The MPLS WG Archive

["Irfan Lateef" <irfanlateef@hotmail.com>]

Tom,

Thanks for your response. A few comments embedded below.

>If you want to calculate explicit paths and want to check out what
>bandwidth/afinity/etc... is available,

Yes, something similar. In fact what I want to provide to the
management interface user is manual-override capability, like
the aircraft pilot has over auto-pilot. The reason being inspite
of all the sophisticated algorithm, if the route is graphically
mapped on a screen, a human can sometimes make better judgements.

This capability is slightly different than choosing a set of hops
and letting the rest to be filled in by the signalling protocol. Here
the application chooses all the hops and the user changes only the
ones he/she desires for further optimization.

Now this can be done in two ways. One is as you suggested initially
where the NMS gives the source and destination and let the protocol
choose the hops. Here in order to check the hops before setting the
path, I would like to propose a variation, where the NMS instead of
a setup request, should send a "prepare-to-setup" request with src,
dest and the traffic contraints, and the ack message
should return the list of hops. Then the user can send a
"execute-setup" request. If this approach can work,
it would address all the issues typical with offline TE application
as pointed out by you and yet deliver the capability we need.

The second is what I am currently pursuing, namely get all the
formation necessary on the NMS and compute the explicit hops and
perform manual changes and then send a set up request thru the NMS.


>Depending on what configuration you are using, the MPLS link bundling or 
>MPLS-DS-TE MIBs might help you, as they provide specific TE link 
>information.

You are right on the mark. I went through these MIBs and its
looks like they will almost solve my problem. During the course
implementation if I end up squeezing in a few more variables I
will keep the listed posted for consideration in next updates.

>         The management application should not be required to
>compute the explicit hops. There are several reasons why this

I agree in most parts, but would like to make one point.
In the GMPLS paradigm we may need to de-emphasize, the urgency to
update the data and the possibility of its obsolence in shorter time
durations, because the underlying network characteristics are not changing 
as frequently and dynamically as it is in IP layer network.

Here we are talking about lambdas and SONET which may be
considered relatively stable. This is also the reason for manual
override because the paths being setup are of relatively higher bandwidth 
and for longer periods of time having a bigger impact in term of cost for 
the
service provider.

Regards,
Irfan Lateef


>From: "Thomas D. Nadeau" <tnadeau@cisco.com>
>To: "Irfan Lateef" <irfanlateef@hotmail.com>, mpls@UU.NET
>Subject: Re: MIBs for GMPLS
>Date: Wed, 27 Jun 2001 21:12:21 -0400
>
>At 07:53 PM 6/27/2001 -0400, Irfan Lateef wrote:
>>Tom,
>>
>>I may be missing something here but let try to make it
>>more explicit using a hypothetical example.
>>
>>Let us extend the example given in the draft
>>draft-nadeau-mpls-gmpls-te-mib-00.txt section.8 from two hops
>>to N hops and from loosely routed to explicitly routed and assume
>>that this has to be done automatically from a management application.
>>
>>Further assume the application needs to find a list of ERHOPs
>>satisfying a condition like "find unprotected lambdas with OC-48
>>worth of bandwidth and setup an LSP  from A to B".
>
>         Then you go to LSR A and specify the tunnel bandwidth to
>be that of an OC-48 link and specify B as the destination.
>
>>My understanding is, the information gathered by the extensions
>>specified in draft-kompella-ospf-gmpls-extensions-01.txt section.5
>>namely LinkProtectionType,LinkDescriptor (in fact most of the
>>sub-TLVs of TE-link TLV) may be necessary to do this.
>
>         If you feel that the GMPLS-TE-MIB is missing some
>constrains, please let us know. At present, we feel that
>the MIB is nearly adequate for specifying GMPLS te tunnels,
>but we could be wrong and for this reason always welcome
>input from others.
>
>         It is my understanding that the tunnel will be signaled
>as any other MPLS tunnel, just using additional or replacement
>GMPLS-specifics. Therefore, the number of hops in the tunnel
>or the constraints those links fit into are not necessary for
>this to work. That is, the head-end should be able to signal
>the tunnel based on the information specified in the tunnel record.
>If you want to calculate explicit paths and want to check out what
>bandwidth/afinity/etc... is available, there are several
>ways of determining this. Depending on what configuration you
>are using, the MPLS link bundling or MPLS-DS-TE MIBs might
>help you, as they provide specific TE link information. These
>might be more appropriate places to find that information
>anyway.  Please take a look at these and see if they
>meet (or not) your requirements. Second, there are proprietary
>MIBs that various vendors have that show this information
>as well.
>
>>I do not see this data incorporated in any MIB.
>>Now in the absence of such data, how can the management application
>>compute the explicit hops satisfying the criteria mentioned above.
>
>         The management application should not be required to
>compute the explicit hops. There are several reasons why this
>is very difficult, but basically they are the same as any
>off-line TE application would experience, just worse because
>the information needs to be up-to-date all the time. If it
>somehow does, it needs all of the information provided by the
>CSPF in every LSR, perhaps across multiple (G)MPLS domains.
>What is typical in such cases is the use of loose routes.
>These are specified at the head-end LSR, which then does the
>path computation between the points specified. This is much
>easier to do there because it already has this up-to-date
>information. In cases where specific paths are to
>be taken, then entire path (or most of it) is specified, and the
>LSR optionally fills-in the gaps. Some off-line tool may be
>used to assist the operator in this choice, but it is not
>mandatory, and as mentioned, is a difficult process to
>get right especially in a multi-vendor network.
>
>         --Tom
>
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com