The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Nov> msg00231



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

RSVP Path without ADSPEC

  • From: David Charlap <David.Charlap@marconi.com>
  • 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