Subject: RE: Optional Adspec objects

From: "Abes, Andi" <[email-masked]>
Date: Thu, 27 Apr 2000 11:30:35 -0400

see comments....

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Friday, April 14, 2000 5:39 PM
> To: [email-masked]
> Subject: Re: Optional Adspec objects
> 
> 
> > On the other hand, the ambiguity really should not matter.  
> If a Path
> > message is received without an Adspec, the logical thing 
> would seem to
> > be to forward it without an Adspec  (except the RSVP daemon in the
> > sender host might supply a default Adspec when the application does
> > not specify one.)
> 
> This is what I needed to know.
> 
> To me, it seems equally logical to always provide an Adspec, even when
> one os not received.  Of course, if you include GS or CL 
> service blocks
> in it, you will be sending possibly-incorrect information about the

my understanding of the Adspec is that it provides
information about the network usage/capabilities 
not the senders' requirements.
If that is the case, each router can take a snapshot
of itself and send it down in the path, with no
fear of confusing anyone. 

> sender's requirements.  But I don't think it can hurt if an 
> Adspec with
> only default/general characteristics is created.
> 
> But not including one is definitely easier.  If it is legal, that is
> what I'd rather do.
> 
> > "Be liberal in what you receive and conservative in what you send".
> 
> Ah, but this depends on what it means to be conservative in what's
> sent.  Is it conservative to send an optional object when it is not
> required?
> 
> -- David
>

---

From: David Charlap <[email-masked]>
Date: Fri, 28 Apr 2000 10:59:57 -0400

Andi Abes wrote:
> David Charlap wrote:
>>
>> To me, it seems equally logical to always provide an Adspec, even
>> when one os not received.  Of course, if you include GS or CL
>> service blocks in it, you will be sending possibly-incorrect
>> information about the sender's requirements.
> 
> my understanding of the Adspec is that it provides information about
> the network usage/capabilities not the senders' requirements.

WRT the values stored in the Adpec, yes.

But WRT the existance of the various service blocks - no.  Note the
following from RFC 2210:

	3.3. RSVP ADSPEC Object

	An RSVP ADSPEC object is constructed from data fragments
	contributed by each service which might be used by the
	application.  The ADSPEC begins with an overall message header,
	followed by a fragment for the default general parameters,
	followed by fragments for every QoS control service which may be
	selected by application receivers. The size of the ADSPEC varies
	depending on the number and size of per-service data fragments
	present and the presence of non-default general parameters
	(described in Section 3.3.5).

	The complete absence of a data fragment for a particular service
	means that the application sender does not know or care about
	that service, and is a signal to intermediate nodes not to add
	or update information about that service to the ADSPEC. It is
	also a signal to application receivers that they should not
	select that service when making reservations.

In other words, by including an Adspec, a sender is telling the
receiver(s) which kinds of reservations (guaranteed-service, controlled-
load or something proprietary) it can handle.  The recipient may only
choose from those kinds presented.  Seen from the sender's standpoint,
the sender can tell the reciever which kind of reservation to use by not
including Adspec services for any other kinds.

-- David