[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: OSPF Traffic Engineering implementation
From:       Pyda Srisuresh <srisuresh () YAHOO ! COM>
Date:       2001-10-24 12:54:02
[Download RAW message or body]


Hi Chitti,

Your implementation approach seems about right. Native-LSDB, TE-LSDB and
TE-flooding are key to this.

As for configuration and monitoring, I would suggest extending
debug/display facilities to display TE-adjacencies and TE-LSDB.
Extend router configuration to support the following (sec 10).
     1. TE properties for the router.
     2. On a per-Interface basis:
              - Traffic type permitted:  (Native-IP, TE or both)
              - TE properties.

As for TE LSAs, I would suggest the following order of priority for
implementation (assuming, you are using an IP network).
     1. TE-Router LSA (Sec 7.1), and TE-Link-Update LSA (Sec 7.6)
     2. TE-Circuit-paths LSA (Sec 7.5)
     3. TE-Summary LSAs (Sec 7.3) and TE-AS-external LSAs (sec 7.4)

Thanks. Hope this helps. Have a nice day.

regards,
suresh

--- "T. Chitti Babu" <chitti@IT.IITB.AC.IN> wrote:
>
>
> hi
> i have started my implemenation for OSPF traffic engineering extensions.
> i would like to have ur suggestions regarding the procedure
> followed. i have enclosed the implementation details file as an
> attachment.
>
> thanx,
> chitti
>
> --
>
> T.Chitti Babu (H-7, # 133)
> KReSIT , IITBombay
> MUMBAI-400076
>
>
> >              OSPF-TE IMPLEMENTATION
>               -----------------------
>
>  Different Modules at the OSPF-TE router
> -----------------------------------------
>
> There shall be 3 modules at the OSPF-TE enabled  router.
>
> (i) the original old OSPF module which maintains the link state database,
> floods all the LSAs  and maintains the adjacency with neighboring routers
> (ii) traffic engineering module which floods the TE-LSAs periodically with
> different extended link attributes .(TE-LSAs have the structure defined by me
> and has got nothing to do with opaque LSAs)
> (iii) traffic monitoring module which takes care of monitoring the extended
> link attributes like max. bandwidth, available
> bandwidth, delay on that link using SNMP .
>
>
> 1. Usage of TE-LSAs instead of Opaque LSAs & Unreliable flooding
> ----------------------------------------------------------------
>
>  The main content of TE-LSAs (say the "Available Bandwidth") on a specific
> link on a link changes frequently. As this would lead to greater traffic we
> can have unreliable flooding for TE-LSA.
> Even if we loose some TE-LSAs , there wouldn't be much problem except that
> for a short duration, the router might be routing the data using the previous
> available data(assuming a major change will not occur in this short period)
> during that short interval. I think this might not lead to drastic effects.
> (one approach suggested in RFC 2676  for QoS LSAs)
>
> 1.1. Some Optimization
> ---------------------
>        As only some of the 8 options were being used currently, we may use the
> first unused bit as TE-enabled bit to intimate whether the neighboring router
> is TE enabled or not. (as suggested in  draft-srisuresh-ospf-te-01.txt ).
> This would save the network from unnecessary flooding of TE information to
> routers which are not TE enabled.
>
>
>


=====


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

[prev in list] [next in list] [prev in thread] [next in thread]