The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Bandwidth reservation per PSC
Darek, At 12:24 16/06/2000 -0400, Darek Skalecki wrote: >Hi, > >I have a question with regard to bandwidth availability per PSC and TE >extensions to OSPF/ISIS. > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2 >about constraint based routing being >performed separately for each PSC where one of the constraints is >availability of bandwidth from the bandwidth >allocated to the relevant PSC. > >My question is how TE extensions to OSPF/ISIS support advertizing >bandwidth availability per PSC. The only way I can >think this can be achieved is by assigning different colors/resource >classes to different PSCs thus advertizing bandwidth >availability per PSC simply as bandwidth availability per color/resource >class. Is this correct?. > >If it is correct then how serious is the scaling/operational issue at >least within OSPF since N TE LSAs are needed for N >PSCs for every link, implying lots of LSA traffic not to mention >storage within LSDB (which I gather can only store >65536 TE LSAs). > First, of course , in some environments, Constraint Based Routing may be performed "off-line"/"in a Centralised Manner". In these situations, per-PSC bandwidth availability can be determined by the centralised tool without relying on extensions to OSPF/ISIS. Where Constraint Based Routing is performed "on-line"/"in a Distributed Manner", then yes, OSPF/ISIS are required to propagate all necessary bandwidth information. This could be achieved in a number of ways: - one approach would be to advertise bandwidth information for every PSC. As you are pointing out above, this may lead to scaling/operational issues earlier than desired. - another approach would be to advertise bandwidth information only for each "family/class" of PSCs. A family/class of PSC would comprise all the PSCs which share the same bandwidth constraints. It is likely that multiple PSCs can share the same bandwidth constraints (eg "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time PSCs may share the same "max-reservable-bandwidth". In that case, you have traded a little bit of fine-grain control (you can't enforce bandwidth constraints which are different for absolutely every PSC), but you have significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3 available bandwidth information. You will find some text on the second approach in section "6.7 Traffic Engineering in Diffserv Environments" of <draft-ietf-tewg-framework-01.txt>: "Instead of having per-class parameters being configured and propagated on each LSR interface, per-class parameters can be aggregated into per-class-type parameters. The main motivation for grouping a set of classes into a class-type is to improve the scalability of IGP link state advertisements by propagating information on a per-class-type basis instead of on a per-class basis, and also to allow better bandwidth sharing between classes in the same class-type..." Francois >Thanks, > >Darek Skalecki >Nortel Networks > _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________
|
|