[Dime] [Fwd: Review of QoS approach]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dime] [Fwd: Review of QoS approach]

Hi all,

Avi did a review of the QoS documents and he sent it to me privately. With his permission I forward them to the DIME mailing list.

Ciao
Hannes


-------- Original Message --------
Subject: 	Review of QoS approach
Date: 	Thu, 22 Mar 2007 00:33:59 -0400
From: 	Avi Lior <avi at bridgewatersystems.com>
To: 	Hannes Tschofenig <Hannes.Tschofenig at gmx.net>
References: 	<45EE9907.8030900 at gmx.net>



The approach being taken with respect to QoS in Dime is to define three QoS related documents:

The first document is the an Diameter QoS application.
http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00

It is a Diameter Application which defines 4 Commands and reuses a handfull of base commands.

It defines 6 QoS specific attributes. It uses numerous base attributes and attributes from Credit Control

Of particular interes is ExtendedQoSFilterRule attribute is encoded as an OctetString. It is a combination of the QoSFilterRule and IPFilterRule of the base and some new classifiers: flos-label, ipsec-spi
Quick question about this attribute:
Action as stated comes from DIABASE which is allow/deny. That doesnt make sense for this a qos attribute. IMO if you are going to be using this style of attribute (and there is other ways) then action should be the qos-id that will be used if the classifier matches.
Also the ExtendedQoSFilterRule calls out "options" but doesnt define them: Are they:
TCP flags
IP fragment flag
IP options
ICMP types

The QSPEC is defined by another document: I-D.korhonen-dime-qos-parameters, it is used in the Diameter Application via containment in the QoS-Parameter AVP which binds the qos parameters to a QoS-ID.

In the PARAMETERS draft we define a number of QoS Parameters which have their own format. They dont match RADIUS or DIAMETER AVP encoding and are meant to be opaque to RADIUS and DIAMETER.

The QoS-Parameter attribute is not required to have QOSSPEC as defined in the PARAMETERS document. THis is a good thing because as we have seen many SDO want to define their own SDO specific attributes or QoS blob.

The disadvantage of the PARAMETERS is that they define a new attribute encoding style.

And then there is the draft-korhonen-dime-qos-attributes-00.txt work. Which basically takes the QoS attributes defined in the QoS application and defines that outside that application so that they can be carried inside the EAP message.

I think if we are going to use this approach wouldnt we take the QoS attributes out of the Diameter QoS Application so you only have it documented in one place?

I like the approach of definig attributes outside a diameter applications and then defining the an application and commands as a seperate document. But that is not really necessary as long as we understand that we can use the attributes defined by one diameter application in another diameter application. I think the real advantage is that we can define the QoS Attributes much faster then we can agree on how an application using those attribute would really work. But then again, the excercise of defining the application helps us get the attributes correct. Hmmmmmmmmm..... But on the flip side, people are defining the QoS attributes into their own SDO specific applications. So seperation is a good thing.

As you know I dont like the idea of using "string" type of encoding for the classifier part. It would be good to get rid of that. We can put it in the QoS Attribute. I guess we can allow for both methods. I would like to work on that with you guys if there is support.

WRT to RADIUS work the classifier did change to allow support for filtering on either IP or Layer 2.
"The filtering attributes specified in this document enable
description of layer 2 and layer 3 filters as well as redirection,
and therefore extend the filter language described in [RFC3588].
The attributes defined in this document may be used with RADIUS
dynamic authorization [RFC3576].
"
One thing that maybe omitted by Diameter work is setting up QoS for L2 (Ethernet-CS).



Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183

------------------------------------------------------------------------
*From:* Hannes Tschofenig
*Sent:* Wed 3/7/2007 5:50 AM
*To:* dime at ietf.org
*Subject:* [Dime] Updated QoS Drafts

Hi all,

new versions of the QoS documents are available as you have seen from
the draft
announcements. I would like to clarify the relationship between the
documents:


http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00

  This document describes the Diameter QoS application.


http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt

  This document contains QoS parameters taken from an NSIS working
group document
  and placed into a separate document. We did this to (a) improve
readability, (b) remove
  functionality that is not needed for the Diameter action and to (c)
at the same time
  leverage existing work. Currently we assume that the same registry is
used.
  The final decision depends on the policy for adding new parameters to
the registry.

  These QoS parameters are utilized by
<draft-ietf-dime-diameter-qos-00>, by
  <draft-korhonen-dime-qos-attributes-00.txt> and by corresponding RADIUS
  documents.


http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt

  This document defines the Extended-QoS-Filter-Rule in the spirit of the
  QoS-Filter-Rule.
  Unlike the <draft-ietf-dime-diameter-qos-00> document it addresses
scenarios
  where the updated QoS-Filter-Rule attribute is carried within other
applications.
  It therefore only addresses a limited set of scenarios. One could
compare the
  approach  with the mobility documents.

  This document also assumes that an extended version of the
IPFilterRule attribute
  is available. Currently, the required extensions are described in
  <draft-ietf-dime-diameter-qos-00> and "imported" into this document.
  There is ongoing work in the RADEXT working group to define a more
powerful
  version of the IPFilterRule / NAS-Traffic-Rule, see
  http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt

  We obviously need to align our work with the RADEXT working group with
  regard to this aspect since the newly defined attribute will be made
available as
  described in the Diameter Compatibility section of
  <draft-ietf-radext-filter-rules-02.txt>.


http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requirements-01

 This document takes a different spin and extends the
<draft-ietf-dime-diameter-qos-00>
 document by supporting a "generic push" approach. By "generic push" I
refer to the
 ability of an arbitrary entity, such as an SIP proxy, to signal to
another box.
 Note that this is not the same as the server-initiated communication.


Ciao
Hannes


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.