[Dime] [Fwd: Diameter QoS: Feedback]

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

Hi all,

Michael Montemurro reviewed the QoS draft. See message below.
Thank you Mike.

Ciao
Hannes

-------- Original Message --------
Subject: 	Re: Diameter QoS: Feedback Needed
Date: 	Fri, 27 Apr 2007 12:19:59 -0400
From: 	Michael Montemurro <montemurro.michael at gmail.com>
To: 	Tschofenig, Hannes <hannes.tschofenig at nsn.com>
CC: 	Tschofenig, Hannes <hannes.tschofenig at siemens.com>
References: 
<8F6CBC7005099442AECDB784C9E9D7E701A61662 at MCHP7R6A.ww002.siemens.net>



Hannes,

I read through draft-ietf-dime-diameter-qos-00 and evaluated it in the
context of WLAN and here is my analysis. Overall I think it maps well
to what is included for admission control in IEEE 802.11.

- The draft maps well to the IEEE 802.11e admission control
mechansisms, which allows a WLAN device to request a flow via a TSPEC.
I haven't looked at it in detail, but the QSPEC maps to a subset of
the TSPEC specification in IEEE 802.11e.

- QoS-Reserve/Response messages map to ADDTS-Request/Response messages
in 11e. There is an additional DELTS in IEEE 802.11e which could be
send from the AP, if signaled by the QoS Authorization server.

- Internally to the AP or WLAN controller,  the scheduler would have
to be tied into the Diameter Client in the WLAN infrastructure.

- In IEEE 802.11e the ADDTS includes a Traffic Specification which
includes TSPEC IE's. In the response, the Access Point/infrastructure
can suggest a TSPEC that it will admit if it does not like the
request. For example, the device may ask for a G.711 TSPEC, but the AP
with a G.729 TSPEC.

- The server-side can preempt a QoS stream by sending a DELTS as
triggered by a QoS authorization message from the Authrizing entity.

- IEEE 802.11 QoS restricts a device to one QoS flow per user priority
(there are 8 user priorities). A STA can update an existing flow
dependent using another QoS request (ADDTS). The server would have to
interpret this as overwriting its existing QoS flow.

- The WLAN AP also will make a decision to admit a QoS flow depending
on its load (number of other flows, number of clients, medium time
available, etc.). This probably is out of scope of this protocol, but
> from  a system perspective, there could be a case where the flow is
authorized, but the AP cannot admit the flow.

- When a device roams from one AP to another, it re-issues its QoS
requests for any active flows. I believe the protocol is capable of
handling the case where the Authorization Server gets a request from
the device on a new network element. In a standalone AP case, this
could happen. In a case where there is a WLAN controller, I would
expect that this behaviour would be hidden from the QoS Authorization
server.


Cheers,

Mike



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