RE: QoS attributes

["Bari, Farooq" <farooq.bari@attws.com>]

So as I suspected the scenarios can be many and complex. However I feel
that the situation can be simplified if we consider  business models
that are likely to exist. My thinking is that in general we will have
two types of authentication / authorizations and associated QoS values

1) authentication/authorization for accessing the network. QoS
information carried in this part is tightly coupled to user's account /
subscription with his home operator. So this value can be the general
QoS class (e.g. something that indicates the user subscription to real
time services or the user is a gold user etc.). Since the WISP does the
financial settlements for this access by the user with his home network,
the WISP uses this user's QoS profile value provided by his home network
as an upper bound for any other QoS requests made by individual services
later on initiated by the user.

2) authentication/authorization for the service that the user decides to
use after he has been authenticated/authorized to access the network.
This value is provided by the service provider (possibly a 3rd party)
and its value and the way it is negotiated and signaled is independent
of AAA interactions with user's home network for accessing the network.
This QoS value can be more specific e.g. it may identify specific
bandwidth values etc. However the QoS values will be upper bound by the
(1) since the WISP can only charge and therefore provide a QoS that is
within the user's QoS profile provided by the home network at the time
of network access authentication/authorization. 

If the WISP and service provide have direct business (roaming)
agreement, then I would consider it the case where the service provider
is also directly (in a way) paying for the extra QoS to the WISP and
therefore home network's authentication /authorization of subscribed QoS
can be over ruled.


Farooq



-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net] 
Sent: Monday, December 22, 2003 11:53 PM
To: john.loughney@nokia.com
Cc: farooq.bari@attws.com; radiusext@ops.ietf.org
Subject: Re: QoS attributes


john.loughney@nokia.com wrote:
> Farooq,
> 
> 
>>A question for my clarification. What happens if the service
>>that needs a specific QoS is a third party Service i.e. it is not
being
>>delivered/offered by the home network and therefore W/ISP 
>>does not have a AAA relationship as such with the 3rd party.
> 
> 
> If there is no roaming in place, then there probably is no service. 
> The user would then have to pay to the visited network via some 
> mechanism.

I think there are several cases:

1. Service is provided free of charge, QoS set is just used
    to ensure that e.g. those who start the video download can
    also complete and get enough bandwidth while downloading.

    In this case there are no AAA issues. Some QoS signaling
    can take place between the user and the 3rd party service.

2. The 3rd party service has its own authentication and
    billing. The user initiates this authentication in
    addition to the one done at access level. Example:
    SIP layer authentication in addition to WLAN access.

    In this case there is AAA involved, but its local to the
    3rd party service i.e. no roaming to the home network.
    Subscriber pays two bills.

3. The 3rd party service employs authentication with a
    roaming agreement to the home network.

    Here too the service authentication and access
    authentication are separate, but both may use the
    same credentials and be authenticated to the same
    home server. Subscriber pays just one bill.

4. The 3rd party service employs authentication with
    a roaming agreement to the local access network.

    This is like alternative 3, but the roaming path
    goes through the access network.

5. The 3rd party service and the local access network
    can somehow agree to provide QoS services to the
    access network's users. Perhaps based on the block
    of IP addresses allocated to the access network,
    or something like that. Information about the
    provided QoS is exchanged between the networks
    for billing purposes.

--Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>