Subject: [Dime] Diameter QoS Appl.- terminal working mode

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 12:43:19 +0200

FYI

------

This is without the attachment.

B. R.
Tina

  ----- Original Message ----- 
  From: Tina TSOU 
  To: [email-masked] 
  Sent: Wednesday, July 11, 2007 6:26 PM
  Subject: Diameter QoS Appl.- terminal working mode

  Hi Guys,
  To converge different kind of authorizing entities and performing NEs, terminal-Mode can tell the performing NE how to choose the interface working mode. First, we can find which mode the terminal is by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be multi-mode, and each mode may have different QoS
  profile, so the terminal-mode AVP can help to the operation on match QoS request and QoS control.
  The following changes are proposed. (You can also find the changes in the attachment.)
  section 6.2

        <section title="QoS-Authorization Answer (QAA)">

          <t>The QoS-Authorization-Answer message (QAA), indicated by the

          Command- Code field set to TBD and 'R' bit cleared in the Command

          Flags field is sent in response to the QoS-Authorization-Request

          message (QAR).  To converge different kind of authorizing entities 

          and performing NEs, terminal-Mode can tell the performing NE how 

          to choose the interface working mode. If the QoS authorization request

          is successfully authorized, the response will include the AVPs to 

          allow authorization of the QoS resources as well as accounting and 

          transport plane gating information.</t>

          <t>The message format is defined as follows:</t>

          <t><figure>

              <artwork><![CDATA[

   <QoS-Answer> ::= < Diameter Header: XXX, PXY >                     

                    < Session-Id >                                    

                    { Auth-Application-Id }                           

                    { Auth-Request-Type }                             

                    { Result-Code }                                   

                    { Origin-Host }                                   

                    { Origin-Realm } 

            [ Terminal-Mode ]               

                 *  [ QoS-Resources ]                   

                    [ CC-Time ]                                       

                    [ Acc-Multisession-Id ]                           

                    [ Session-Timeout ]                               

                    [ Authz-Session-Lifetime ]                        

                    [ Authz-Grace-Period ]                            

                 *  [ AVP ]                                           

  ]]></artwork>

            </figure></t>

        </section>

  section 6.3

        <section title="QoS-Install Request (QIR)">

          <t>The QoS-Install Request message (QIR), indicated by the

          Command-Code field set to TDB and 'R' bit set in the Command Flags

          field is used by Authorizing entity to install or update the QoS

          parameters and the flow state of an authorized flow at the transport

          plane element.</t>

          <t>The message MUST carry information for signaling session

          identification or identification of the flow to which the provided QoS

          rules apply, working mode of the terminal, identity of the transport 

          plane element, description of provided QoS parameters, flow state and 

          duration of the provided authorization.</t>

          <t>The message format is defined as follows:</t>

          <t><figure>

              <artwork><![CDATA[

   <QoS-Install-Request> ::= < Diameter Header: XXX, REQ, PXY >       

                             < Session-Id >                           

                             { Auth-Application-Id }                  

                             { Origin-Host }                          

                             { Origin-Realm } 

                 [ Terminal-Mode ] 

                             { Destination-Realm }                    

                             { Auth-Request-Type }                    

                             [ Destination-Host ]                     

                          *  [ QoS-Resources ]          

                             [ Session-Timeout ]                      

                             [ Authz-Session-Lifetime ]               

                             [ Authz-Grace-Period ]                   

                             [ Authz-Session-Volume ]                 

                          *  [ AVP ]                                  

  ]]></artwork>

            </figure></t>

        </section>

  [snipped]

  section 7.1

          <t><figure>

              <artwork><![CDATA[

  Attribute Name                AVP Code     Reference [RFC3588]

  Origin-Host                   264             Section 6.3

  Origin-Realm                  296             Section 6.4

  Terminal-Mode                 TBD

  B. R.

  Tina

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 12:46:08 +0200

Hi Tina,

who translates high-level QoS information used at the application layer 
into information that is appropriate for a QoS model that is used in a 
particular access network. In your model it seems that the AF is in 
charge of assisting whereas the PDF does the final translation. In any 
case, it is not the NE that does it.

Correct?

But how should the AF know anything about the access network 
characteristics?
(unless it is in the access network itself)

What information would you put into the Terminal-Mode AVP?

Ciao
Hannes

Hannes Tschofenig wrote:
>  ----- Original Message -----  From: Tina TSOU  To: [email-masked] 
>  To converge different kind of authorizing entities and performing 
> NEs, terminal-Mode can tell the performing NE how to choose the 
> interface working mode. First, we can find which mode the terminal is 
> by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user 
> terminal may be multi-mode, and each mode may have different QoS

---

From: Tina TSOU <[email-masked]>
Date: Wed, 11 Jul 2007 19:31:31 +0800

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>; "Tina TSOU" <[email-masked]>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

> particular access network. In your model it seems that the AF is in charge 
> of assisting whereas the PDF does the final translation. In any case, it 
> is not the NE that does it.
>
> Correct?
[Tina: this question belongs to another thread "PULL/PUSH/Access network 
related information".]
> (unless it is in the access network itself)
[Tina: this question belongs to another thread "PULL/PUSH/Access network 
related information".]
> What information would you put into the Terminal-Mode AVP?
[Tina: First, we can find which mode the terminal is by Terminal-mode, for 
example
3GPP, WiFi, Wimax, etc.
The user terminal may be multi-mode, and each mode may have different QoS
profile, so the terminal-mode AVP can help to the operation on match QoS
request and QoS control.]
>>  ----- Original Message -----  From: Tina TSOU  To: [email-masked] Sent: 
>> Wednesday, July 11, 2007 6:26 PM
>>  To converge different kind of authorizing entities and performing NEs, 
>> terminal-Mode can tell the performing NE how to choose the interface 
>> working mode. First, we can find which mode the terminal is by 
>> Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may 
>> be multi-mode, and each mode may have different QoS
>>   <QoS-Answer> ::= < Diameter Header: XXX, PXY >                    < 
>> Session-Id >                                   { Auth-Application-Id } 
>> { Auth-Request-Type }                            { Result-Code } 
>> { Origin-Host }                                  { Origin-Realm }
>>            [ Terminal-Mode ]              *  [ QoS-Resources ] 
>> [ CC-Time ]                                      [ Acc-Multisession-Id ] 
>> [ Session-Timeout ]                              [ 
>> Authz-Session-Lifetime ]                       [ Authz-Grace-Period ] 
>> *  [ AVP ]                                          ]]></artwork>
>>
>>            </figure></t>
>>
>>        </section>
>>
>>  section 6.3
>>
>>   <QoS-Install-Request> ::= < Diameter Header: XXX, REQ, PXY >      < 
>> Session-Id >                          { Auth-Application-Id } 
>> { Origin-Host }                         { Origin-Realm }
>>                 [ Terminal-Mode ]
>>                             { Destination-Realm }                   { 
>> Auth-Request-Type }                   [ Destination-Host ] 
>> *  [ QoS-Resources ]         [ Session-Timeout ]                     [ 
>> Authz-Session-Lifetime ]              [ Authz-Grace-Period ] 
>> [ Authz-Session-Volume ]                *  [ 
>>       ]]></artwork>
>>
>>            </figure></t>
>>
>>        </section>
>>
>>
>>
>>  [snipped]
>>
>>
>>
>>  section 7.1
>>
>>          <t><figure>
>>
>>              <artwork><![CDATA[
>>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 11 Jul 2007 19:34:12 +0800

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>; "Tina TSOU" <[email-masked]>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.-  "PULL/PUSH/Access network related 
information"

> is not the NE that does it.
[Tina: Correct.]
> (unless it is in the access network itself)
[Tina: it is configured by the operator/administrator.]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 11 Jul 2007 15:01:12 -0400

Hi Tina,

I have one question/concern about this:
The value of Terminal-Mode would have an implicit (and not defined by
this specification) meaning with it, i.e. each element may interpret it
differently. Maybe an approach, where we have separate AVPs for all
pieces of information which we think could be extracted from
Terminal-Type, could be less ambiguous.

   Thanks,
   Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2007 6:43 AM
> To: [email-masked]; Tina TSOU
> Subject: [Dime] Diameter QoS Appl.- terminal working mode
> 
> FYI
> 
> ------
> 
NEs,
> working mode. First, we can find which mode the terminal is by
Terminal-
> mode, for example 3GPP, WiFi, Wimax, etc. The user terminal may be
multi-
> mode, and each mode may have different QoS
> request and QoS control.
>   The following changes are proposed. (You can also find the changes
in
> the attachment.)
>           to choose the interface working mode. If the QoS
authorization
> request
> 
>           is successfully authorized, the response will include the
AVPs
> to
> 
>           allow authorization of the QoS resources as well as
accounting
> and

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 11 Jul 2007 18:22:09 -0500

Hi Tina,

It seems you intend to make use of this new AVP to indicate the access
network type, or more specific - QoS profile to facilitate the
authorizing entity on the policy decision, is it correct? Then this
proposal is more or less related to the access network related info
issue in another thread, better to consolidate them together. 

As stated in another email, I am not sure if it is good idea to make
authorizing entity specific to each access technologies in the context
of QoS mapping and policy control, especially for inter-domain scenario.
Maybe I misunderstood your point...

Regards,
Dong

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 7:32 AM
To: [email-masked]; Hannes Tschofenig
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

----- Original Message -----
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>; "Tina TSOU" <[email-masked]>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

> particular access network. In your model it seems that the AF is in
charge 

related information".]

related information".]
> What information would you put into the Terminal-Mode AVP?
[Tina: First, we can find which mode the terminal is by Terminal-mode,
for 
example
3GPP, WiFi, Wimax, etc.
The user terminal may be multi-mode, and each mode may have different
QoS
profile, so the terminal-mode AVP can help to the operation on match QoS
request and QoS control.]
NEs, 
in 
authorization 
AVPs 
accounting 

>>          Command-Code field set to TDB and 'R' bit set in the Command

>> Flags

---

From: Tina TSOU <[email-masked]>
Date: Thu, 12 Jul 2007 11:02:52 +0800

Hi Dong,
Yes, kind of, not exactly the access network, but the terminal working
mode. Moreover, it helps the interface between the authorizing entity and
the NEs.

B. R.
Tina

----- Original Message ----- 
From: "Sun, Dong (Dong)" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; <[email-masked]>; "Hannes Tschofenig" 
<[email-masked]>
Sent: Thursday, July 12, 2007 7:22 AM
Subject: RE: [Dime] Diameter QoS Appl.- terminal working mode

Hi Tina,

Regards,
Dong

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: Wednesday, July 11, 2007 7:32 AM
To: [email-masked]; Hannes Tschofenig
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

----- Original Message -----
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>; "Tina TSOU" <[email-masked]>
Sent: Wednesday, July 11, 2007 6:46 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

charge

related information".]

related information".]
NEs,
in
authorization
AVPs
accounting

---

From: Tina TSOU <[email-masked]>
Date: Thu, 12 Jul 2007 11:08:18 +0800

[snipped]
>> What information would you put into the Terminal-Mode AVP?
[Tina: Just a mode value in Terminal-Mode AVP.]

B. R.
Tina

----- Original Message ----- 
From: "Tina TSOU" <[email-masked]>
To: <[email-masked]>; "Hannes Tschofenig" <[email-masked]>
Sent: Wednesday, July 11, 2007 7:31 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

>>> { Auth-Request-Type }                            { Result-Code } { 
>>> Origin-Host }                                  { Origin-Realm }
>>>            [ Terminal-Mode ]              *  [ QoS-Resources ] [ 
>>> CC-Time ]                                      [ Acc-Multisession-Id ] 
>>> [ Session-Timeout ]                              [ 
>>> Authz-Session-Lifetime ]                       [ Authz-Grace-Period ] * 
>>> [ AVP ]                                          ]]></artwork>
>>>
>>>            </figure></t>
>>>
>>>        </section>
>>>
>>>  section 6.3
>>>
>>> Session-Id >                          { Auth-Application-Id } { 
>>> Origin-Host }                         { Origin-Realm }
>>>                 [ Terminal-Mode ]
>>>                             { Destination-Realm }                   { 
>>> Auth-Request-Type }                   [ Destination-Host ] *  [ 
>>> QoS-Resources ]         [ Session-Timeout ]                     [ 
>>> Authz-Session-Lifetime ]              [ Authz-Grace-Period ] [ 
>>> Authz-Session-Volume ]                *  [ ]]></artwork>
>>>
>>>            </figure></t>
>>>
>>>        </section>
>>>
>>>
>>>
>>>  [snipped]
>>>
>>>
>>>
>>>  section 7.1
>>>
>>>          <t><figure>
>>>
>>>              <artwork><![CDATA[
>>>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 12 Jul 2007 11:09:31 +0800

Hi Tolga,
I can use this value to separate the different type NEs, I think, up to now.

B. R.
Tina

----- Original Message ----- 
From: "Asveren, Tolga" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 12, 2007 3:01 AM
Subject: RE: [Dime] Diameter QoS Appl.- terminal working mode

Hi Tina,

   Thanks,
   Tolga

NEs,
Terminal-
multi-
in
authorization
AVPs
accounting

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jul 2007 10:24:05 +0200

Hi Tina,

thanks for the discussion.

I believe that the concrete values in the Terminal-Mode AVP matter. When 
you work on the document you need to list values and you need to setup a 
registry (or refer to an existing registry). You also need to explain 
where the values come from and what type of quality they have when they 
are used as input to some decision making process.

Christian suggested the usage of the P-Access- Network-Info AVP that is 
added by a SIP proxy in the access network.

Do you want to use P-Access- Network-Info?
Could you explain a bit more about the flow of information? Who is 
supposed todo what and when?

Ciao
Hannes

Tina TSOU wrote:
>> ----- Original Message ----- From: "Hannes Tschofenig" 
> ----- Original Message ----- From: "Tina TSOU" <[email-masked]>
>> ----- Original Message ----- From: "Hannes Tschofenig" 
>>> who translates high-level QoS information used at the application 
>>> layer into information that is appropriate for a QoS model that is 
>>> used in a particular access network. In your model it seems that the 
>>> AF is in charge of assisting whereas the PDF does the final 
>>> translation. In any case, it is not the NE that does it.
>>>
>>> Correct?
>> [Tina: this question belongs to another thread "PULL/PUSH/Access 
>> network related information".]
>>>
>> [Tina: this question belongs to another thread "PULL/PUSH/Access 
>> network related information".]
>> [Tina: First, we can find which mode the terminal is by 
>> Terminal-mode, for example
>> 3GPP, WiFi, Wimax, etc.
>>>> interface working mode. First, we can find which mode the terminal 
>>>> is by Terminal-mode, for example 3GPP, WiFi, Wimax, etc. The user 
>>>> in the attachment.)
>>>> authorization request
>>>> AVPs to
>>>> accounting and
>>>> < Session-Id >                                   { 
>>>> Auth-Application-Id } { Auth-Request-Type 
>>>> }                            { Result-Code } { Origin-Host 
>>>> }                                  { Origin-Realm }
>>>> CC-Time ]                                      [ 
>>>> Acc-Multisession-Id ] [ Session-Timeout 
>>>> ]                              [ Authz-Session-Lifetime 
>>>> ]                       [ Authz-Grace-Period ] * [ AVP 
>>>> ]                                          ]]></artwork>
>>>>
>>>>            </figure></t>
>>>>
>>>>        </section>
>>>>
>>>>  section 6.3
>>>>
>>>> < Session-Id >                          { Auth-Application-Id } { 
>>>> { Auth-Request-Type }                   [ Destination-Host ] *  [