Subject: RE: DCLASS Object

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

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

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.

Y

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

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: Ping Pan <[email-masked]>
Date: Tue, 16 Nov 1999 17:51:32 -0500

> requiring definitive knwoledge of the host's capabilities.

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? 

- Ping