The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3D123B63.FE89C956@marconi.com>, David Charlap writes:
> Vasanthi Thirumalai wrote:
> > 
> > I responded once before on this issue and my feeling is that it is
> > Peak data rate. But someone on the list disagreed. I guess it also
> > depends to a large extent on the type of the system. For instance
> > on an optical system, you may have a choice of dicrete bandwdths
> > to choose from - say OC-12, OC-48 or OC-192. In such a case the
> > peak data rate seems more appropriate.
> 
> If you're on a network where there is no room for fuzziness in your
> request, then it's not a big deal to generate a TSPEC where r == p.
> 
> As I wrote in response to Julia's message, IntServ objects do not define
> a single "bandwidth" parameter.  Instead, they define 3 (5 for
> guaranteed service) parameters which are used to define a specific
> queueing algorithm.
> 
> If your hardware does not support this queueing model, then the
> parameters must be massaged to fit what your hardware does support. 
> There is no generalized way to do this.  The "right thing" will depend
> on what your hardware's queueing model is.
> 
> -- David


David,

Today's routers use "r" as the value that is credited against
"reservable bandwidth" on an interface and ignore "p" and "b" but it
wouldn't hurt to set "p" to be the same as "r".

It is probably best to set the value for "b" to a very large value
even though it is ignored.  I don't know of anything that does not
ignore "p" and "b" so the discussion of what others put in it and what
is best to put in it hasn't come up in a while.  Maybe someone else
knows of equipment that doesn't ignore "p" and "b" when using RSVP-TE.

Curtis