Subject: [Dime] [Fwd: Review of QoS approach]

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Apr 2007 20:58:15 +0200

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 <[email-masked]>
To: 	Hannes Tschofenig <[email-masked]>
References: 	<[email-masked]>

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:* [email-masked]
*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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime