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

From: "Tina TSOU" <[email-masked]>
Date: Sun, 22 Jul 2007 20:38:39 -0500

Hi Albrecht,
The T05-SG16-070626-TD-WP2-0459!R1 just figures out the H.248
based issue, but diameter-based issue needs a terminal working mode
still. Moreover, the diameter is the trend and direction on the 
QoS control interface.
BTW, it is not good for MG to be involved in such operation in
the draft above. After all, it is the less limiting to the UE
the better.

B. R.
Tina

> ----- Original Message ----- 
> From: "Schwarz Albrecht" <[email-masked]>
> To: "Tina TSOU" <[email-masked]>; "Hannes Tschofenig" 
> <[email-masked]>; "SUN D" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 19, 2007 9:25 AM
> Subject: RE: [Dime] Re: [Dime] Diameter QoS Appl.- terminal 
> working mode
> 
> 
> > ...the QoS control interface mode like Rw, Gx, etc.
> 
> Like to note that the "QoS control interface mode" at H.248-based 
> policycontrol 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 
> controlinterface modes").
> 
> -Albrecht
> 
> > -----Original Message-----
> > From: Tina TSOU [mailto:[email-masked]]
> > 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
> >
> > ----- 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,
> >
> > 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
> >                                 ...........................+
> >       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.
> >
> > [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     |.
> >                                 |    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.
> >
> > [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
> >
> >
> > > 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 ]                                          ]]>
> > >>>>>
> > >>>>>            </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 ]                *  [ ]]>
> > >>>>>
> > >>>>>            </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
> > 
> 
> 

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