Subject: Comments on policy QoS IM

From: Ponnappan Appan <[email-masked]>
Date: Thu, 10 Aug 2000 16:37:11 +0800 (SGT)

Here are some comments/questions on the QoS info. model draft 01
version:

1. Is there an updated version of this document since draft 01
has expired in April?

2. There is nothing specific to QoS in the qosPolicySimpleCondition
class, can this be moved to the core info. model?

3. The qosPolicyPRAction class has a valid reference(qpMeter attribute)
to the qosPolicyMeter class if metering is required as part of the PR
action.
Since the traffic profile to be metered against is part of the
qosPolicyPRAction,
(which is qpTrfcProf attribute), there are no attributes in the
qosPolicyMeter
class. Can these empty class instances be avoided by defining qpMeter
attribute
as a flag which indicates whether metering is required or not?

4. From the description of the attributes qpRSVPMessageType, qpRSVPStyle

and qpRSVPServiceType attributes of the qosPolicyRSVPAction, these
attribute values are used as "conditions" for the RSVP flows for which
the
qosPolicySignalCtrlAction and/or the qoPolicyRSVPInstallAction are to be

applied.

Can these be explicitly defined as part of a condition instead of being
"hidden"
in the policy action?

Thank you,
Appan

---

From: "Yoram Snir" <[email-masked]>
Date: Thu, 10 Aug 2000 15:47:46 +0200

Thanks for your valuable remarks.
Please see comments inline (between <yoram>).

------------------------------------------
Yoram Snir - Manager, Business Development
Cisco Systems
Tel.     +972-9-9700085
Mobile   +972-54-970085
------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ponnappan Appan
Sent: Thursday, August 10, 2000 10:37 AM
To: [email-masked]
Subject: Comments on policy QoS IM

Will soon be available in the IETF repository.

<yoram>
This was discussed in the last 2 IETF meetings and because of the advanced
status of the core IM, will remain in the QPIM.
<yoram>

<yoram>
The meter is actually an aggregating meter, to be shared by more than one
policy rule, this is why it has to be a separate class.
Example:
rule 1: if ftp mark with DSCP=3 and police ftp+http traffic to 64K
rule 2: if http mark with DSCP=4 and police ftp+http traffic to 64K

Notice, both rules classify traffic to be policed together, i.e., share the
same policer (and traffic profile, in this example).
<yoram>

applied.

<yoram>
No since the rule conditions are to be applied to the flow, not the RSVP
signaling of this flow.
Example, rule: if flow is http allow RSVP reservation (PATH and RESV) of
type SE of 64k... The condition is the http classifier and the action is the
admission of specific RSVP reservation by the designated PDP.
<yoram>

Thank you,
Appan