The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

Mark Dewey wrote:
> 
>    I apologize for the wide distribution. I am not sure which mailing
> list this question belongs to.
> 
>    I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of
> an LSP tunnel can be specified in traffic parameter (e.g CDR) TLV.
> 
> How is this value  specified in RSVP if it were used to establish a
> LSP tunnel with qos characteristics?
> 
> If sender TSPEC object is used, should the node implement integrated
> services (CL,GS)?

RSVP-TE defines new CTypes for the TSPEC and FLOWSPEC objects - the
"Class of service" type.  Best-effort is defined here.

For all QoS reservations, the IntServ variations of these objects are
used.

In all cases (best effor or otherwise), TSPEC is mandatory in Path
messages and FLOWSPEC is mandatory in Resv messages.

In terms of actual usage:

- The TSpec will define the level of QoS that the sender wants, as
  decscribed by the 5 generic token-bucket parameters: bucket rate (r),
  bucket size (b), peak data rate (p), minimum packet size (m) and
  maximum packet size (M).

- An ADSPEC object is optional, but strongly recommended in this
  situation.  The ADSPEC contains four generic parameters (hop count,
  bandwidth estimate, minimum latency, and composed MTU).  It also
  contains service-specific fragments - for guaranteed service (which
  includes the delay-factor parameters CTot, CSum, DTot and DSum) and
  controlled-load.

  The ADSPEC defines several things.  First off, its parameters are
  modified by the transit routers as it is passed from PHOP to NHOP, so
  that the parameters that arrive at the egress node contain the LUB of
  the parameters for all switches.  (For instance, the bandwidth
  estimate is reduced by each switch it passes through, resulting in
  the egress router seeing the amount of bandwidth available in the
  most-congested router.)

  Second, the ADSPEC defines which services the sender can handle a
  reservation in.  The presence of a service-specific fragment (GS or
  CL) indicates that the sender can handle that kind of reservation.
  Its absence indicates that it can not handle it.

  One thing I'm unclear on is what it means if an ADSPEC is sent with
  no service-specific fragments.  IMO, this means that neither kind of
  reservation is adequate, and that something akin to best-effort should
  be reserved.  (IOW, an ADSPEC with no service-specific fragments is
  almost illegal, since it would prevent any reservation from being
  established.)  I've heard from others, however, that this means that
  the receiver is free to choose any kind of reservation.

  I'm also not sure what it means if a Path is received with an IntServ
  class of TSPEC but no ADSPEC.  I suppose this means that the receiver
  is free to choose any kind of reservation, and must do so without the
  information that an ADSPEC would have gathered.

- Anyway, once the receiver gets the Path message, it must choose the
  reservation.

  Given that MPLS is router-to-router and not application-to-
  application, the egress router really doesn't have too much choice in
  what it can try to reserve.  It logically must try to reserve what the
  ingress node requested in its TSPEC object.  To do otherwise would
  require knowledge beyond that which is provided by RSVP.  Such meta-
  knowledge could be configured by an operator, or provided as a value-
  added feature, but IMO, it is beyond the scope of the MPLS working
  group.

Getting back to your question about whether integrated services should
be implemented, I would respond with a qualified yes.  A formal IntServ
stack is not necessary for MPLS with RSVP, but the switch must be able
to understand the IntServ objects and be able to make appropriate
reservations.  If it can't do this (which should really only be true if
the switch is incapable of making QoS-type reservations), then it should
probably reject Path and Resv messages that include IntServ-class TSPEC
and FLOWSPEC objects.

-- David