The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Jun> msg00396



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Bandwidth reservation per PSC

  • From: Francois Le Faucheur <flefauch@cisco.com>
  • Date: Mon, 19 Jun 2000 11:31:03 +0200
  • Cc: mpls@UU.NET, alchiu@att.com

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
_________________________________________________________________