Subject: RSVP Path without ADSPEC

From: David Charlap <[email-masked]>
Date: Tue, 27 Nov 2001 11:04:04 -0500

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.

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.

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.)

Thanks in advance.

-- David

---

From: Markus Jork <[email-masked]>
Date: Wed, 28 Nov 2001 10:43:02 -0500

> using the IntServ Null service instead of the Token Bucket TSpec

agreed

> 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.

> 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

---

From: David Charlap <[email-masked]>
Date: Wed, 28 Nov 2001 12:42:53 -0500

Markus Jork wrote:
> or the Null service be used to signal best-effort.

What version are you reading?  The CoS FLOWSPEC/TSPEC were explicitly
deleted from the draft as of version -08.  I haven't heard any mention
any anybody putting it back.

> I don't think anybody sends a CoS object by default when requesting
> best-effort.

There are some.

> That would cause interoperabilty problems. I'm not sure about the
> support for the Null service in current implementations.

So far, it appears that Null service is not widely supported.  CoS seems
to be supported by most, but not all, platforms.

> an interoperability hazard.

I know.  And it may be years after the spec becomes an RFC before all
the major players decide to upgrade their code to support Null service.

Which is why I asked my questions in the first place.

-- David

---

From: Markus Jork <[email-masked]>
Date: Wed, 28 Nov 2001 13:05:02 -0500

David,

> any anybody putting it back.

The wording in that sentence wasn't very good. I did not mean to say
the CoS object is still in the very latest spec. It's gone.

Markus