Subject: [Dime] Re: +AFs-Dime+AF0- Diameter QoS Appl.- terminal working mode

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Jul 2007 17:51:35 +0800

Hi Hannes,
(If you are not able to see the picture in good shape, please look at the 
attachment.)
                               financial settlement
                                ...........................+
      Application               V             -------      .
      signaling msg   +--------------+      / QoS AAA \    .
      +-------------->|              |     /  protocol \   .
      |               | Authorizing  +--------------+   \  .
      |               | Entity       |   |          |    | .
      |               +              |<--+----+     |    | .
      |               +--------------+  |QoS  |     |QoS  |.
      |                                install|     |install
      |                                 |rsp. |     |req. |.
      |                                 |     |     |     |.
      |                                  |    |     | .  | .
      |                                   \   |     | . /  .
      |                                     \ |     | /    .
      V                                       |-----V .    .
    +-------------+                  +--------+-----+      .
    |  Entity     |                  | NE           |      .
    |  requesting |                  | performing   |      .
    |  resource   |QoS rsrc granted  | QoS          | <....+
    |             |<-----------------| reservation  |
    +-------------+                  +--------------+

               Figure 5: Authorization Scheme for Push Mode
Push,
Authorizing entity gets access info including access type in the 
P-Access-Network-Info header,
and translates the P-Access-Network-Info header into QIR message. NE so 
knows which QoS control
interface to select between Authorizing entity and NE.

                                        +--------------+
                                        | Entity       |
                                        | authorizing  | <......+
                                        | resource     |        .
                                        | request      |        .
                                        +------------+-+        .
                                        --^----------|--   .    .
                                   /////  |          |  \\\\\   .
                                 //       |          |       \\ .
                                |     QoS | QoS AAA  | QoS     |.
                                |    authz| protocol |authz    |.
                                |     req.|          | res.    |.
                                 \\       |          |       // .
                                   \\\\\  |          |  /////   .
                          QoS           --|----------v--   .    .
       +-------------+    request       +-+------------+        .
       |  Entity     |----------------->| NE           |        .
       |  requesting |                  | performing   |        .
       |  resource   |granted / rejected| QoS          |  <.....+
       |             |<-----------------| reservation  | financial
       +-------------+                  +--------------+ settlement

                       Figure 3: Three Party Scheme
Pull,
Authorizing entity gets Origin-host in the QAR message,
and translates the Origin-host into terminal mode or access type in QAA 
message.
NE so knows which QoS control interface to select between Authorizing entity 
and NE.

B. R.
Tina

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 12, 2007 4:24 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

> 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" 
>>> <[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
>> [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
>>
>>
>>>
>>> ----- 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
>>>
>>>
>>>> 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?
>>> [Tina: this question belongs to another thread "PULL/PUSH/Access network 
>>> related information".]
>>>>
>>>> But how should the AF know anything about the access network 
>>>> characteristics?
>>>> (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.]
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> Hannes Tschofenig wrote:
>>>>> 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 ]                *  [ ]]></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
>>>>
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/dime
> 
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Fri, 13 Jul 2007 17:17:42 -0500

Hi Tina,

Thanks for drawing those beautiful pictures. Looks like you would be
better to be a artist instead of engineer :-).

To be honest, I am a bit confused by the intent of this terminal working
mode. Would it be used for:
- Indication of push or pull mode operated by AE
- Indication of policy profile used by AE
- or both

I support to have a indicator to tell AE which operation model - Push or
Pull should be used, which can be determined by AS (e.g. IMS AF), or
just simply pre-provisoned. However, I am not yet convinced why the
different policy profile should be used according to access
technologies. A good example would be helpful. One example in my mind is
that we may need access network type for correlating charging related
data. However, I don't think this spec should make the charging function
as mandatory requirement and it should be defined separately, such as in
4006. Another example, it would be used for resource based admission
control, but obviously, the terminal working mode is not sufficient to
serve that purpose.

I can see the need to have a parameter to indicate the Push or Pull
mode, which will be sent from AF to PDF or between two AE instances for
inter-domain case, not from AE to NE within the same domain. (BTW, the
current architecture does not perfectly reflect the inter-domain and
intra-domain cases. I don't think the NE as enforcement point can be
controlled by an AE in another administrative domain in reality. We
should add a local AE and remote AE to justify the business model
commonly used in the real network.

See additional comment inline...

Regards,
Dong

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]] 
Sent: Friday, July 13, 2007 5:52 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode

Hi Hannes,
(If you are not able to see the picture in good shape, please look at
the
attachment.)
                               financial settlement

               Figure 5: Authorization Scheme for Push Mode Push,
Authorizing entity gets access info including access type in the
P-Access-Network-Info header, and translates the P-Access-Network-Info
header into QIR message. NE so knows which QoS control interface to
select between Authorizing entity and NE.

[DS] Why NE as policy enforcement point needs to know it is a push or
pull mode, the push or pull is the matter of AE (policy server)'s
operation. I think, we can specify the state machine properly to
indicate the push or pull in NE, for instance, When NE receives QIR for
new session establishment, it goes to Push mode; when the NE receives
the path coupled signaling from end host, it goes to Pull mode and
trigger the QAR to AE. I can draw some detailed state mechanism later.

                                        +--------------+
                                        | Entity       |
                                        | authorizing  | <......+
                                        | resource     |        .
                                        | request      |        .
                                        +------------+-+        .
                                        --^----------|--   .    .
                                   /////  |          |  \\\\\   .
                                 //       |          |       \\ .
                                |     QoS | QoS AAA  | QoS     |.

                       Figure 3: Three Party Scheme Pull, Authorizing
entity gets Origin-host in the QAR message, and translates the
Origin-host into terminal mode or access type in QAA message.
NE so knows which QoS control interface to select between Authorizing
entity and NE.

[DS] when NE receives the path coupled signaling from end host, it
implied a Pull mode by default. Is there any need to send back any thing
from AE to NE in QAA?

B. R.
Tina

----- Original Message -----
From: "Hannes Tschofenig" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 12, 2007 4:24 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

QoS

---

From: Tina TSOU <[email-masked]>
Date: Thu, 19 Jul 2007 00:09:16 +0200

Hi Dong,

I am afraid you have a misunderstanding about the terminal working
mode, in this thread I don't expect it to distinguish the pull/push mode, 
but to
tell the QoS control interface mode like Rw, Gx, etc.

B.R.
Tina

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

Hi Tina,

Regards,
Dong

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: Friday, July 13, 2007 5:52 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: [Dime] Re: [Dime] Diameter QoS Appl.- terminal working mode

Hi Hannes,

                                        +--------------+
                                        | Entity       |
                                        | authorizing  | <......+
                                        | resource     |        .
                                        | request      |        .
                                        +------------+-+        .
                                        --^----------|--   .    .
                                   /////  |          |  \\\\\   .
                                 //       |          |       \\ .
                                |     QoS | QoS AAA  | QoS     |.

B. R.
Tina

----- Original Message -----
From: "Hannes Tschofenig" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 12, 2007 4:24 PM
Subject: Re: [Dime] Diameter QoS Appl.- terminal working mode

QoS

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 19 Jul 2007 09:25:32 +0200

> ...the QoS control interface mode like Rw, Gx, etc.

Like to note that the "QoS control interface mode" at H.248-based policy
control interfaces is addressed by an implicit mechanism:
"Context-created" vs "Context-less" pull modes (see Draft H.248.55;
T05-SG16-070626-TD-WP2-0459!R1).
There's thus then a different pull request, dependent on the "QoS
control interface mode".
There isn't any provisioning/configuration action required, it's just a
local method. The PDP is either receiving the pull request (= H.248
event) on Root or on non-Root termination level. (I.e., this allows the
discrimination between the different "operation models" or "QoS control
interface modes").

-Albrecht   

> Sent: Donnerstag, 19. Juli 2007 00:09
> To: Hannes Tschofenig; SUN D
> Cc: [email-masked]
> Subject: Re: [Dime] Re: [Dime] Diameter QoS Appl.- terminal 
> working mode
> 
> Hi Dong,
> 
> I am afraid you have a misunderstanding about the terminal 
> working mode, in this thread I don't expect it to distinguish 
> the pull/push mode, but to tell the QoS control interface 
> mode like Rw, Gx, etc.
> 
> B.R.
> Tina
> 
> > you work on the document you need to list values and you 
> need to setup
> a
> >>>> charge of assisting whereas the PDF does the final 
> translation. In
> any
> >>>>> interface working mode. First, we can find which mode 
> the terminal
> is
> >>>>>          <t>The QoS-Authorization-Answer message (QAA), 
> indicated
> by
> >>>>> the
> >>>>>
> >>>>>          and performing NEs, terminal-Mode can tell the 
> performing
> NE
> >>>>> how
> >>>>>          field is used by Authorizing entity to install 
> or update
> the
> >>>>> QoS
> >>>>>