The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

> What type of reservation should an egress router generate when it
> receives an IntServ TSPEC and no ADSPEC?
> 
> If the TSpec is using the deprecated CoS C-Type, it is obvious that
> best-effort is being requested.  It is similarly obvious if the TSpec is
> using the IntServ Null service instead of the Token Bucket TSpec
> parameters.

agreed

> When the TSpec is using the Token Bucket TSpec parameters, the kind of
> reservation (Guaranteed, Controlled-Load or best-effort) is supposed to
> be determined by the presence or absence of service-specific fragments
> in the ADSPEC.  RFC 2210 explicitly states that an egress router should
> not make a reservation using a particular service if that service's
> fragment is missing from the ADSPEC.
> 
> But it appears that some vendors (broken, perhaps) generate ADSPEC
> objects with no service fragments, or they generate Path messages
> without ADSPEC objects altogether.  What kind of service should the
> egress router reserve in this case?
> 
> IMO, this means that the choice of service is "don't care", and the
> egress is free to choose any kind it wants.  I personally think that
> best-effort is the best thing to do in this case, since it imposes the
> least impact on the rest of the network.
> 
> I have been informed, however, that some implementations respond to this
> situation (missing ADSPEC or ADSPEC with no service fragments) by making
> a Controlled Load reservation, and that these implementation actually
> generate missing-ADSPEC Path messages when they want to request
> Controlled Load - meaning they are expecting everybody else to handle
> this ambiguous situation in the same way they do.
> 
> What is this group's opinion here?  I'm especially interested in hearing
> from the RSVP-TE draft authors in this regard.
> 

I think it's best to be pragmatic here and look at implementations
that are deployed and known to interoperate. Current practice is
to use the intserv tspec and the Controlled Load service flowspec.
So when you get an intserv tspec, it's best to respond with a
Controlled Load flowspec unless there is very clear indication that
the sender wants something else (e.g. by sending along an ADSPEC with only
a Guaranteed service fragment).
Also, you can essentially ignore everything in the token bucket spec except
for the bandwidth (token bucket rate). Some implementations make an
effort to handle the max pkt size parameter correctly (for Path
MTU discovery), all other token bucket parameters are not really of interest.

> 
> Finally, is there a way to signal best-effort other than Null service
> and the deprecated CoS object?  I currently understand the IntServ RFCs
> such that a zero parameter means "don't care", therefore a
> Controlled-Load FLOWSPEC with all zeros for parameters should be
> synonymous with best-effort.  Is this correct or should this actually
> imply a Controlled-Load reservation for zero resources (which is
> effectively a black-hole if traffic is policed.)

The latest iterations of the RSVP-TE spec suggest that a CoS object
or the Null service be used to signal best-effort. However, all the
implementations that I'm aware of don't do it that way. Instead,
an intserv tspec with zero bandwidth and a Controlled Load flowspec with
zero bandwidth are used to signal best-effort. I believe this is
actually a violation of the intserv specs but it works just fine. And
if you want to be sure to interoperate, this is the way to go.
I know implementations that will handle CoS objects correctly when
they receive them but I don't think anybody sends a CoS object by
default when requesting best-effort. That would cause interoperabilty
problems. I'm not sure about the support for the Null service in
current implementations.

The changes in the RSVP-TE spec dealing with best-effort signaling
(first the introduction of the CoS object and then it's replacement
with the Null service) were rather unfortunate. It really was just
a change in syntax, not any technical improvement. The good thing
is that the Null service promoted in the latest spec looks like
the aesthetically most pleasant solution, the bad thing is that these
syntax changes are just a waste of time for everybody involved and
an interoperability hazard.

Markus