Subject: DCLASS Object

From: Chapman Mike <[email-masked]>
Date: Tue, 16 Nov 1999 17:20:07 +0100

Hello,

A possible use of the DCLASS object currently discussed is to carry
upstream packet marking information back to an RSVP sender within
an RSVP RESV message.  However, as discussed in Washington, 
a problem with this is that the Host may not be DiffServ capable.

Alternatively, if a DiffServ capable host were to originate a RSVP PATH
with a DCLASS object included, Hosts that were capable (or prepared) to do
DiffServ 
marking of packets could be identified.  Marking could then be indicated
through 
a DCLASS object present in the RSVP RESV message, as already discussed. 

Where a DCLASS object is not present in the RSVP PATH message, one could
assume 
that the host is either not capable or not prepared to do DiffServ marking
of packets 
associated with that flow.  Where no DCLASS object is present in the PATH
message,
do not return a DCLASS object in the associated RESV message.

The DCLASS object carried in the RSVP PATH message, could also indicate
a Host's initial preference (if it has one) for the DSCP with which packets
associated with that flow 
should be marked.  An agent in the network could then take this initial
preference into account
when deciding upon the Marking information that will be returned within the
DCLASS object present 
in the associated RSVP RESV message.

Do you think this is worth pursuing ??

Regards
Mike

---

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 15:02:17 -0800

> Hi,
> 
> I think this is nice model. Just curious: if DSCP's are mapped to
> network resource at each router, what happens if a router cannot
> accommodate the DSCP from downstream? Does it need to send a 
> RESVERR and
> stop sending DCLASS Object upstream? 
> 

I can think of two options - overwrite with a 'lower' DSCP, or send a
RESV_ERR. Again, many of these issues were dealt with in TCLASS processing.
It will take some careful design to come up with a comprensive set of
guidelines.

Y

---

From: Chapman Mike <[email-masked]>
Date: Wed, 17 Nov 1999 18:21:13 +0100

Hello Yoram,

I appologise in advance if I am discussing items that have already
been covered on the list.

Cheers
Mike 

> -----Ursprüngliche Nachricht-----
> Von:	Yoram Bernet (Exchange) [SMTP:[email-masked]]
> Gesendet am:	Dienstag, 16. November 1999 21:21
> An:	Chapman Mike; [email-masked]'
> Betreff:	RE: DCLASS Object
> 
		>  The current recommended use of the dclass object is to
just send it
		>  upstream, toward the sender. Upstream devices (be they
senders or marking
		> routers/switches) may decide to use it or not to use it. 

	[Chapman Mike]   
	I think the idea of passing marking information from an RSVP-aware
network element 
	to the upstream marking point is a good one, although it is not so
clear to me how you
	know that an upsteam element is able to mark the packets
appropriately (unless through
	some pre-agreement).  So even though the RSVP request has been
admitted, the User is not
	necessarily getting the marking that he wants (ie, downstream may
think upstream is marking,
	while upstream marking may not be supported).

		> You're suggesting,
		> in effect, a negotiation protocol between senders and
downstream dclass
		> aware devices. This is quite a bit more complicated than
the current
		> recommended use. I can envision its merits but also, its
complexities.

	[Chapman Mike]  
	What I was trying to propose was two fold:

	Firstly, a mechanism that could be used to identify that an Upsteam
entity
	exists that is both prepared and able to mark packets according to
the marking
	indication passed back in the RSVP-RESV DCLASS object.

	Now this could be done through the DSCP marking of the packets,
however unless
	a DSCP value is reserved to indicate "Marking element NOT present
upstream, and
	marking required", then there may be confusion as to the
interpretation of the marking
	....does 0 mean "mark me", or does it mean "treat me according to
the Default PHB".

	An alternative to this would be to include a RSVP-PATH DCLASS object
with Length = 4
	(ie, it contains no DSCPs).

	Secondly, as you rightly pointed out, a placeholder for a potential
negotiation 
	protocol through which Hosts could indicate their initial preference
for the DSCP marking
	of packets associated with a particular RSVP request.

		> For now, I would prefer to stick with the one way model,
in which the
		> information is passed upstream for use by those who care.
I can imagine
		> downstream devices implementing somethisn along the
following lines:

		> If a packet arrives with DSCP=0, I need to mark this
packet because nobody
		> upstream was capable of doing so.
		> If a packet arrives with DSCP!=0, then - I don't need to
mark, but - I need
		> to subject to the aggregate policing of this DSCP.

		> I think that this is useful functionality that can be
offered without
		> requiring definitive knwoledge of the host's capabilities.

		> I think that the next interesting problem to address is
how to process
		> DCLASS objects as they are merged and as they flow
upstream. I think that
		> much can be learned from the TCLASS work in the IS802
drafts. I think that
		> negotiation with a host over use of the DCLASS may be the
next item of
		> interest, but that we're not there yet...

		> That's my $.02.

> -----Original Message-----
> From: Chapman Mike [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 8:20 AM
> To: [email-masked]'
> Subject: DCLASS Object
> 
> 
> Hello,
>