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, I am hoping to submit something on extensions to IGPs for support of "Class-types". Let me know if you're interested in working on this. Francois At 17:41 20/06/2000 -0400, Angela Chiu wrote: >Darek, > >I don't think it is currently included in the OSPF and ISIS TE extensions. I >am not aware of anyone who is working on it. But I could be wrong since >there are so many activities around MPLS, hard to keep track of all of them. > >Angela > >-----Original Message----- >From: Darek Skalecki [mailto:dareks@nortelnetworks.com] >Sent: Tuesday, June 20, 2000 4:06 PM >To: alchiu >Cc: mpls; 'Francois Le Faucheur' >Subject: Re: Bandwidth reservation per PSC > > >Thanks Angela, > >Are these extensions currently defined for OSPF and ISIS?. If yes then >please >provide me with a reference, and if not then is anyone working on them ?. I >can >only find extensions related to advertizing bandwidth availability per >priority >not resource class. > >Thanks, > >Darek > > >Angela Chiu wrote: > >> Darek, >> >> These are additional requirements for IGP extensions, as stated in TE >> Framework draft >> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt >> "In order to perform constraint-based routing on a per-class basis for >LSPs, >> the conventional IGPs (e.g., IS-IS and OSPF) should provide extensions to >> propagate per-class resource information." >> Then the draft states that "per-class parameters can be aggregated into >> per-class-type parameters" for scalability improvements. >> >> Regards, >> >> Angela >> >> -----Original Message----- >> From: Darek Skalecki [mailto:dareks@nortelnetworks.com] >> Sent: Tuesday, June 20, 2000 2:51 PM >> To: Francois Le Faucheur >> Cc: mpls@UU.NET; alchiu@att.com >> Subject: Re: Bandwidth reservation per PSC >> >> Thanks Francois, >> >> My question was indeed related to the distributed model. What I am still >not >> sure about is how bandwidth availability within OSPF/ISIS is advertized >per >> PSC or per family of TE related PSCs when the TE extensions only imply >> advertizement per priority. Are colors assigned to different PSCs or >> families of TE related PSCs and bandwidth availability advertized per >> color?. >> >> Thanks, >> >> Darek >> >> Francois Le Faucheur wrote: >> >> > 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 >> > _________________________________________________________________ > _________________________________________________________________ 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 _________________________________________________________________
|
|