Subject: Admission Control error specification

From: [email-masked]
Date: Thu, 8 Feb 96 10:36:55 PST

When an Admission Control failure occurs, RSVP passes an error message
back to the receiver(s) "responsible" for the failure.  The error
reporting message includes a 16-bit "Error Value", which is supposed to
give the application some information about the cause of the failure.

It would seem that the choice of values within the Error Value field is
service-model-dependent, and perhaps service-dependent.  RSVP
faithfully delivers your flowspecs as sealed objects, and similarly it
will faithfully deliver the Error Value back to the application.

Would it be outrageous to suggest that the service specification
documents developed by the int-serv working group should specify any
service-specific Error Value numbers?  At the very least, the RSVP
working group needs input from the int-serv working group on these
issues, which will be important in the real world of integrated service
deployment.

Following a suggestion from John Wroclawski, RSVP specifies that some
high-order bits of the Error Value field are:

	ss = 00: Low order 12 bits contain a globally-defined
		sub-code (values listed below).

	ss = 10: Low order 12 bits contain a organization-specific
		sub-code.  RSVP is not expected to be able to interpret
		this except as a numeric value.

	ss = 11: Low order 12 bits contain a service-specific sub-code.
		RSVP is not expected to be able to interpret this
		except as a numeric value.  Since the traffic control
		mechanism might substitute a different service, this
		encoding may include some representation of the service
		in use.

	and the following global sub-codes are specified:

		Sub-code = 1: Delay bound cannot be met

		Sub-code = 2: Requested bandwidth unavailable

Do these make sense?

Bob Braden

----- End Included Message -----