Network Working Group                                       G. Zorn, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                               P. McCann
Expires: January 10, May 22, 2008                                      Motorola Labs
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                                 T. Tsou
                                                                  Huawei
                                                                A. Doria
                                          Lulea University of Technology
                                                                  D. Sun
                                                Bell Labs/Alcatel-Lucent
                                                            July 9,
                                                       November 19, 2007

          Protocol for Diameter Quality of Service Application
                  draft-ietf-dime-diameter-qos-01.txt
                  draft-ietf-dime-diameter-qos-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a Diameter application that performs
   Authentication, Authorization, and Accounting for Quality of Service
   (QoS) reservations.  This protocol is used by elements along the path
   of a given application flow to authenticate a reservation request,
   ensure that the reservation is authorized, messages and to account procedures for
   resources consumed during the lifetime of the application flow.
   Clients that implement the Diameter
   QoS application.  The QoS application contact an
   authorizing entity/application server that is located somewhere allows network elements to
   interact with Diameter servers when allocating QoS resources in the network, allowing for a wide variety
   network.  In particular, two modes of flexible deployment
   models. operation - Pull and Push are
   defined.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6  5
   3.  Framework  Diameter QoS Authorization Session Establishment and
       Management . . . . . . . . . . . . . . . . . . . . . . . . . .  8  6
     3.1.  Network element functional model  Parties involved . . . . . . . . . . . . .  9
     3.2.  Implications of endpoint QoS capabilities . . . . . . . . 11
       3.2.1.  Category of endpoint  6
     3.2.  Diameter QoS capabilities  . . . . . . . . 11
       3.2.2.  Interaction modes between authorizing entity and
               network element  . . . . . . . . . . . . . . . . . . . 11
     3.3. Authorization schemes  . . . . . . . . . . . . . Session Establishment . . . . . 13
       3.3.1.  Authorization schemes  6
       3.2.1.  QoS authorization session establishment for pull
               mode . . . . . . . . . 13
       3.3.2.  Authorization schemes for push mode  . . . . . . . . . 16
     3.4.  QoS Authorization Requirements . . . . . . . . . . . . . . 17
   4.  Diameter  6
       3.2.2.  QoS Authorization Session Establishment and
       Management . . . . . . . . authorization session establishment for push
               mode . . . . . . . . . . . . . . . . . . 22
     4.1.  Parties involved . . . . . . . 10
       3.2.3.  Discovery and selection of peer Diameter QoS
               application node . . . . . . . . . . . . . . 22
     4.2.  Diameter QoS Authorization Session Establishment . . . . . 22
     4.3. 13
     3.3.  QoS authorization session re-authorization . . . . . . . . 26
       4.3.1. 13
       3.3.1.  Client-Side Initiated Re-Authorization . . . . . . . . 26
       4.3.2. 14
       3.3.2.  Server-Side Initiated Re-Authorization . . . . . . . . 28
     4.4.  Server-Side Initiated QoS Parameter Provisioning . . . . . 28
     4.5. 16
     3.4.  Session Termination  . . . . . . . . . . . . . . . . . . . 29
       4.5.1. 18
       3.4.1.  Client-Side Initiated Session Termination  . . . . . . 29
       4.5.2. 18
       3.4.2.  Server-Side Initiated Session Termination  . . . . . . 30
   5. 19
   4.  Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   6. 21
   5.  Diameter QoS Authorization Application Messages  . . . . . . . 33
     6.1. 22
     5.1.  QoS-Authorization Request (QAR)  . . . . . . . . . . . . . 34
     6.2. 23
     5.2.  QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 34
     6.3. 23
     5.3.  QoS-Install Request (QIR)  . . . . . . . . . . . . . . . . 35
     6.4. 24
     5.4.  QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 36
     6.5. 25
     5.5.  Re-Auth-Request (RAR)  . . . . . . . . . . . . . . . . . . 25
     5.6.  Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 26
     5.7.  Accounting Request (ACR) . . . . . . . . . . . . . . . . . 36
     6.6. 26
     5.8.  Accounting Answer (ACA)  . . . . . . . . . . . . . . . . . 37
   7. 27
   6.  Diameter QoS Authorization Application AVPs  . . . . . . . . . 38
     7.1. 28
     6.1.  Diameter Base Protocol AVPs  . . . . . . . . . . . . . . . 38
     7.2. 28
     6.2.  Credit Control Application AVPs  . . . . . . . . . . . . . 38
     7.3. 28
     6.3.  Accounting AVPs  . . . . . . . . . . . . . . . . . . . . . 39
     7.4. 29
     6.4.  Diameter QoS Application Defined AVPs  . . . . . . . . . . 39
   8. 29
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   9. 31
     7.1.  Example call flow for pull mode  . . . . . . . . . . . . . 31
     7.2.  Example call flow for push mode  . . . . . . . . . . . . . 33
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 44
   10. 37
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 45
   11. 38
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
   12. 39
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
   13. 40
   12. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 48
   14. 41
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
     14.1. 42
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 49
     14.2. 42
     13.2. Informative References . . . . . . . . . . . . . . . . . . 49 42
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 53 46

1.  Introduction

   To meet

   This document describes the Quality of Service needs of applications such as Voice-
   over-IP in a heavily loaded network, packets belonging to real-time
   application flows must be identified and segregated from other
   traffic to ensure that bandwidth, delay, messages and loss rate requirements
   are met.  In addition, new flows should not be added to procedures for the Diameter
   QoS Application.  The QoS Application allows network elements to
   interact with Diameter servers when it is at or near capacity, which would result allocating QoS resources in degradation of
   quality for all flows carried by the
   network.

   In particular, two modes of operation are defined.  In the first,
   called "Pull Mode", the network element queries the Diameter
   infrastructure for authorization based on some cases, these goals can be achieved with mechanisms such as
   differentiated services and/or end-to-end congestion and admission
   control.  However, when bandwidth is scarce and must be carefully
   managed, such trigger (such as in cellular networks, or when applications and
   transport protocols lack a QoS
   signaling protocol) that arrives along the capability data path to perform end-to-end
   congestion control, explicit reservation techniques are required. be used for
   the session.  In
   these cases, the endpoints will send reservation requests second, called "Push Mode", a Diameter server
   pro-actively sends a command to edge
   and/or interior nodes along the communication path.  In addition network element(s) to
   verifying whether resources are available, the recipient install QoS
   authorization state.  This could be triggered, for instance, by off-
   path signaling such as SIP-based call control.

   A set of a
   reservation request must also authenticate and authorize the request,
   especially in an environment where the endpoints command codes pertinent to this QoS application are not trusted.  In
   addition, these nodes will generate accounting information about the
   resources used and attribute usage
   specified that allows a single Diameter application to support both
   Pull and Push modes based on the requesting endpoints.  This
   will enable the owner requirements of the network element to generate usage-
   sensitive billing records
   technologies, deployment scenarios and to understand how to allocate new
   network capacity.

   A variety of protocols could be used to make a end-host's capabilities.  In
   conjunction with parameters defined in other Diameter QoS request, including
   RSVP [RFC2210], NSIS [I-D.ietf-nsis-qos-nslp], link-specific
   signaling or even SIP/SDP [RFC4566].  This documents,
   this document aims to be
   agnostic depicts basic call flow procedures to the QoS signaling protocol used establish, modify
   and to the terminate a Diameter QoS model to
   which the signaling is directed. application session.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The

   In addition to the terms defined in other relevant Diameter QoS
   documents (e.g., diameter-qos-framework), the following terms are
   used in this document:

   Diameter QoS Application Server

      An

      A Diameter QoS application server is a network entity that exchanges signaling
      messages with an application endpoint.  It may be a source of
      authorization for QoS-enhanced application flows.  For example, a
      SIP server is one kind of application server.

   Application Endpoint

      An application endpoint is an entity in an end user device logical Diameter node that
      exchanges signaling messages with application servers or directly
      with other application endpoints.  Based on the result of this
      signaling,
      supports the endpoint may make a request protocol interaction for QoS from the
      network.  For example, a SIP User Agent is one kind of application
      endpoint.

   Authorizing Entity authorization.  The
      Diameter QoS server resides in the authorizing entity acts as and is able
      to respond to a Diameter server (and may
      collocate with session received from a subscriber database) responsible for authorizing Diameter QoS requests for a particular application flow
      client, or aggregate.  It
      may be initiate a standalone entity or integrated with an application
      server.  This entity corresponds Diameter session to the Policy Decision Point
      (PDP) (see [RFC2753]).

   AAA Cloud

      An infrastructure of AAA entities (clients, agents, servers) based
      on a AAA protocol, which provides trusted secure connections
      between them.  It offers authentication, authorization and
      accounting services to applications in flexible Diameter QoS client
      triggered by application signaling or local and roaming
      scenarios. events.

   Diameter [RFC3588] and RADIUS [RFC2865] are both
      widely deployed AAA protocols.

   Network Element (NE) QoS aware router that acts as Application Client

      A Diameter QoS application client is a logical Diameter node that implements
      supports the protocol interaction for QoS enforcement.  The
      Diameter QoS application client resides in the context of this document.  For
      almost all scenarios this entity triggers the protocol interaction
      described in this document.  This entity corresponds network element and is able to the Policy
      Enforcement Point (PEP) (see [RFC2753]).

   Pull Mode

      In this mode, the
      initiate a Diameter session triggered by a QoS authorization process is invoked signaling or other
      events, or respond to a Diameter session initiated by the a Diameter
      QoS
      reservation request received from the endpoint.  The Network
      Element then requests server.

   Resource Requesting Entity

      A resource requesting entity is a logical entity that supports the
      protocol interaction for QoS authorization decision from the
      Authorizing entity.

   Push Mode

      In this mode, resources.  The resource requesting
      entity resides in the QoS authorization process end-host and is invoked by the
      request from Application Server or local policies able to communicate with
      peer logicial entities in the
      Authorizing Entity.  The Authorizing Entity then installs or Network element to
      trigger the QoS authorization decision to the Network Element initiatively. process.

3.  Framework

   The  Diameter QoS application runs between a network element (acting
   as a Diameter client) Authorization Session Establishment and the resource authorizing Management

3.1.  Parties involved

   Authorization models supported by this application include three
   parties:
   o  Resource requesting entity (acting as
   a Diameter server).  A high-level picture of the resulting
   architecture is shown in Figure 1.

               +-------+---------+
               |
   o  Network Elements (Diameter QoS application (DQA) client)
   o  Authorizing   |
               | Entity      |
               |(Diameter Server)|
               +-------+---------+
                       |
                       |
                /\-----+-----/\
            ////               \\\\
          ||       AAA Cloud       ||
         | (Diameter application)  |
          ||                       ||
            \\\\               ////
                \-------+-----/
                        |
       +---+--+   +-----+----+   +---+--+
       |      |   |    NE    |   |      |    Media
       +  NE  +===+(Diameter +===+  NE  +=============>>
       |      |   |  Client) |   |      |    Flow
       +------+   +----------+   +------+

               Figure 1: An Architecture supporting QoS-AAA

   Figure 1 depicts network elements through which media flows need to
   pass, a cloud of AAA servers, and an authorizing entity. QoS application (DQA) server)

   Note that
   there may be more than one router that needs to interact with the AAA
   cloud along QoS resource requesting entity is only indirectly
   involved in the path of a given application flow, although message exchange.  This entity provides the figure
   only depicts one for clarity.

   In some deployment scenarios, QoS aware network elements may request
   authorization through trigger
   to initiate the AAA cloud based on an incoming Diameter QoS
   reservation request. protocol interaction by transmitting QoS
   signaling messages.  The network element will route Diameter QoS application is only executed
   between the request to a
   designated authorizing entity. Network Element (i.e., DQA client) and the Authorizing
   Entity (i.e., DQA server).

   The authorizing QoS resource requesting entity will return may communicate with the result
   Authorizing Entity using application layer signaling for negotiation
   of the authorization decision.  In other deployment
   scenarios, the authorization will be initiated upon dynamic service parameters.  As part of this application state, so that the request must be authenticated layer protocol
   interaction, for example using SIP, authentication and
   authorized based on information from one or more application servers.

   If defined properly, authorization
   might take place.  This message exchange is, however, outside the interface
   scope of this document.  The protocol communication between the routers QoS
   resource requesting entity and AAA cloud
   would the QoS Network Element might be identical in both cases.  Routers are therefore insulated
   from
   accomplished using the details of particular applications and need not know that
   application servers are involved at all.  Also, the AAA cloud would
   naturally encompass business relationships such as those between
   network operators and third-party application providers, enabling
   flexible intra- NSIS protocol suite, RSVP or inter-domain authorization, accounting, and
   settlement.

3.1.  Network element functional model

   Figure 2 depicts a logical operational model link layer
   signaling protocol.  A description of resource management
   in these protocols is also outside
   the scope of this document and a router.

          +-----------------------------------------------------+
          | DIAMETER Client                                     |
          | Functionality                                       |
          | +---------------++---------------++---------------+ |
          | | User          || tight coupling with these protocols
   is not desirable since this applications aims to be generic.

3.2.  Diameter QoS Authorization || Accounting    | |
          | | Authentication|| Session Establishment

   The Pull and Push modes use a different set of QoS        || command codes for QoS       | |
          | +---------------+| Requests      || Traffic       | |
          |                  +---------------++---------------+ |
          +-----------------------------------------------------+
                                              ^
                                              v
            +--------------+            +----------+
            |QoS Signaling |            | Resource |
            |Msg Processing|<<<<<>>>>>>>|Management|
            +--------------+            +----------+
                 .  ^   |              *      ^
                 |  v   .            *        ^
            +-------------+        *          ^
            |Signaling msg|       *           ^
            | Processing  |       *           V
            +-------------+       *           V
                 |      |         *           V
     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                 .      .         *           V
                 |      |         *     .............................
                 .      .         *     .   Traffic Control         .
                 |      |         *     .                +---------+.
                 .      .         *     .                |Admission|.
                 |      |         *     .                | Control |.
       +----------+    +------------+   .                +---------+.
   <-.-|  Input   |    | Outgoing   |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
       |  Packet  |    | Interface  |   .+----------+    +---------+.
   ===>|Processing|====| Selection  |===.|  Packet  |====| Packet  |.=>
       |          |    |(Forwarding)|   .|Classifier|     Scheduler|.
       +----------+    +------------+   .+----------+    +---------+.
                                        .............................
           <.-.-> = signaling flow
           =====> = data flow (sender --> receiver)
           <<<>>> = control
   session establishment.  For other operations, such as session
   modification and configuration operations
           ****** = routing table manipulation

                Figure 2: Network element functional model

   Processing termination, they use the same set of incoming QoS reservation requests includes three
   actions: admission control, authorization and resource reservation. command codes.

   The admission control function provides information for available
   resources and determines whether there are enough resources to
   fulfill Pull mode or Push mode operation is invoked based on the request. trigger
   of QoS Authorization session.  When a QAR with a new session ID is performed by the Diameter
   client function which involves contacting an authorization entity
   through
   received, the AAA cloud shown Authorizing Entity operates in Section 3.  If both checks are
   successful, the authorized QoS parameters pull mode; when
   other triggers are set received, the Authorizing Entity operates in the packet
   classifier and
   push mode.  Similarly, when a QIR with new session ID is received,
   the packet scheduler.  Note that Network Element operates in the parameters passed
   to push mode; when other triggers
   are recevied, the Traffic Control function may be different from requested QoS
   (depending on Network Element operation in the pull mode.

3.2.1.  QoS authorization decision).  Once session establishment for pull mode

   A request for a QoS reservation or local events received by a Network
   Element can trigger the requested
   resource is granted, initiation of a Diameter QoS authorization
   session.  The Network Element generates a QoS-Authorization-Request
   (QAR) message in which it maps required objects from the Resource Management function provides
   accounting information QoS
   signaling message to Diameter payload objects.

   Figure 2 shows the protocol interaction between a resource requesting
   entity, a Network Element and the Authorizing entity using Entity.

   The Authorizing Entity's identity, information about the Diameter
   client function.

3.2.  Implications application
   session and/or identity and credentials of endpoint the QoS capabilities

3.2.1.  Category of endpoint resource
   requesting entity, requested QoS capabilities

   The parameters, signaling session
   identifier and/or QoS capabilities of endpoints are varied, which can enabled data flows identifiers MAY be
   categorized as follows:
   o  Category 1 endpoint: Has no QoS capability at both application
   encapsulated into respective Diameter AVPs and
      network levels.  This type of endpoint may set up a connection
      through application signaling, but it is unable included into the
   Diameter message sent to specify any
      resource/QoS requirements either through application signaling
      e.g.  SIP or through network signaling e.g.  RSVP or NSIS (or does
      not support network signaling at all).
   o  Category 2 endpoint: Only has QoS capability at the application
      level.  This type of endpoint Authorizing Entity.  The QAR is able sent to set up
   a connection
      through application signaling with certain resource/QoS
      requirements (e.g. application attributes), but it is unable to
      specify any network level resource/QoS requirements (e.g., network
      QoS class) through network signaling e.g., RSVP or NSIS (or does
      not support network layer signaling at all).
   o  Category 3: endpoint: Has QoS capability at Diameter server that can either be the network level.
      This type home server of endpoint may set up a connection through application
      signaling and translate service characteristics into network
      resource/QoS requirements (e.g. network QoS class) locally, and
      request the resources through network signaling e.g.  RSVP or
      NSIS.

3.2.2.  Interaction modes between authorizing entity and network element

   Different QoS mechanisms are employed in packet networks.  Those QoS
   mechanisms can be categorized into two schemes: IntServ and DiffServ.
   In the IntServ scheme, network signaling e.g RSVP, NSIS,
   requesting entity or link
   specific signaling is commonly used to initiate a request from
   endpoint for desired an application server.

   +----------------------------------+-------------------------------+
   | QoS resource of media flow.  In the DiffServ
   scheme, the specific Input Data          | Diameter QoS resources are provisioned AVPs             |
   +----------------------------------+-------------------------------+
   | Authorizing entity ID (e.g.,     | Destination-Host              |
   | taken from authorization token   | Destination-Realm             |
   | or derived based on some predefined
   QoS service classes instead Network      |                               |
   | Access ID (NAI) [RFC2486]        |                               |
   | of endpoint initiated per flow based QoS
   request.

   It is obvious that the eligible QoS scheme is correlated to the
   endpoint's capability in the context requesting entity)    |                               |
   +----------------------------------+-------------------------------+
   | Authorization Token              | QoS-Authz-Data                |
   | Credentials of QoS authorization.  Since
   category 1 and 2 endpoints cannot initiate                   | User-Name                     |
   | the QoS resource requests
   through requesting entity        |                               |
   +----------------------------------+-------------------------------+
   | QoS parameters                   | QoS-Resources                 |
   +----------------------------------+-------------------------------+

   Authorization processing starts at the network signaling, Diameter QoS server when it
   receives the IntServ model is not applicable to
   them in general.  Depending QAR.  Based on network technology and operator's
   demand, a category 3 endpoint may either make use of the network
   signaling for requesting the resource or not perform information in the request.

   The diversity of QoS capabilities of endpoints QoS-
   Authentication-Data, User-Name and QoS schemes of
   network technology leads to QoS-Resources AVPs the distinction on server
   determines the interaction mode
   between authorized QoS authorization system resources and underlying network elements.
   When the IntServ scheme is employed by category 3 endpoint, the
   authorization process is typically initiated by network element when
   a trigger such as the network signaling is received flow state (enabled/
   disabled) from the
   endpoint.  In the DiffServ scheme, since the network element is
   unable to request the resource authorization on its own initiative,
   the authorization process is typically triggered upon either the
   request locally available information (e.g., policy
   information that may be previously established as part of an
   application servers layer signaling exchange, or policies defined by the operator.

   As a consequence, two interaction modes are needed user's subscription
   profile).  The QoS-Resources AVP is defined in support of
   different combinations of QoS schemes and endpoint's QoS
   capabilities.  Push mode and Pull mode.

   o  Push mode:
   [I-D.ietf-dime-qos-attributes].  The QoS authorization process decision is triggered by
      application servers or local network conditions (e.g. time of day
      on resource usage and QoS classes), and the authorization
      decisions are installed by the authorzing entity to then
   reflected in the network
      element on its own initiative without explicit request.  In order response returned to support the push mode, the authorizing entity (i.e.  Diameter
      server) should be able to initiate a Diameter authorization
      session to communicate client with the network element (i.e.  Diameter
      client) without any pre-established connection from the network
      element.
   o  Pull mode: The
   QoS-Authorization-Answer message (QAA).

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS authorization process is triggered by the
      network signaling received from end user equipments or by the
      local event in the network element according to pre-configured
      policies, and authorization decisions are produced upon the
      request of the network element.  In order to support the pull
      mode, the network element (i.e.  Diameter client) will initiate a      ( Diameter authorization session to communicate with authorizing
      entity (i.e.              ( Diameter server).
   For category 1 and 2 endpoints, the Push mode is required, in
   particular, category 1 endpoint requires network initiated push mode
   and category 2 endpoint may use both them.  For category 3 endpoint,
   either push mode or pull mode is doable.

   The Push mode is applicable to certain networks, for example, Cable
   network, DSL, Ethernet, Diffserv enabled IP/MPLS as defined by other
   SDOs e.g.  ETSI TISPAN and ITU-T.  The Pull mode is more appropriate
   to IntServ enabled IP networks or certain wireless networks such as
   GPRS networks as defined by 3GPP/PP2.  Some networks e.g.  WiMAX may
   require both Push and Pull modes.

3.3.  Authorization schemes

3.3.1.  Authorization schemes for pull mode

   Three basic authorization schemes for pull mode exist: one two-party
   and two three-party schemes.  The notation adopted here is in respect
   to the entity that performs the QoS authorization.  The
   authentication of the QoS requesting entity might be done at the
   network element as part of the QoS signaling protocol, or by an off-
   path protocol run (on the application layer or for network access
   authentication) or the authorizing entity might be contacted with
   request for authentication and authorization of the QoS requesting
   entity.  From the Diameter QoS application's point of view these
   schemes differ in type of information that need to be carried.  Here
   we focus on the 'Three party scheme' (Figure 3) and the Token-based
   three party scheme' (Figure 4).  With the 'Two party scheme' the
                        QoS
   resource requesting entity is authenticated by the Network Element
   and the authorization decision is made either locally at the Network
   Element itself or offloaded to a trusted entity (most likely within
   the same administrative domain).  In the former case no Diameter Client)             QoS
   protocol interaction is required.

                                        +--------------+
                                        | Entity       |
                                        | authorizing  | <......+
                                        | resource     |        .
                                        | request      |        .
                                        +------------+-+        .
                                        --^----------|--   .    .
                                   ///// Server)
       |                   |  \\\\\   .
                                 //                         |
       +---QoS-Reserve---->|                         |       \\ .
       |     QoS                   +- - - - - QAR - - - - - >|
       | QoS AAA                   |(QoS-Resources,Cost,     | QoS     |.
       |    authz| protocol |authz    |.                   |     req.|   QoS-Auth-Data,User-ID)|
       | res.    |.
                                 \\                   |                +--------+--------------+
       |       // .
                                   \\\\\                   |                |  /////   .
                          QoS           --|----------v--   .    .
       +-------------+  Authorize request       +-+------------+        .    |  Entity     |----------------->| NE
       |        .                   |  requesting                |  Keep session data    | performing
       |        .                   |  resource   |granted / rejected| QoS                |/Authz-time,Session-Id/|
       |  <.....+                   |             |<-----------------| reservation                +--------+--------------+
       | financial
       +-------------+                  +--------------+ settlement

                       Figure 3: Three Party Scheme

   With the 'Three party scheme' a QoS reservation request that arrives
   at the Network Element is forwarded to the Authorizing Entity (e.g.,
   in the user's home network), where the authorization decision is
   made.  A business relationship, such as a roaming agreement, between
   the visited network and the home network ensures that the visited
   network is compensated for the resources consumed by the user via the
   home network.

                               financial settlement
                                ...........................+
      Authorization             V             -------      .
      Token Request   +--------------+      /                   |< - - - - QAA - - - - - -+
       |                   |(Result-Code,CC-Time,Cost|
       |                   |QoS-Resources,Authz-time)|
       |           +-------+---------+
       |           |Install QoS AAA \    .
      +-------------->| state|
       |     /  protocol \   .           |       +         | Authorizing  +--------------+   \  .
       |           | Entity Authz. session  |
       |           | /Authz-time,    | .                QoS Responder
       |        +------+              |<--+----+           |  CC-Time,Cost/  | .                    Node
       |           +-------+---------+                      |      +--------------+  |QoS
       |     |QoS  |.                   +----------QoS-Reserve---....--->|
       |                   |                        |authz|     |authz|.                                |        |Authorization           |req.+|     |res. |.
       |        |Token                   |Token|                   |<---------QoS-Response--....----|
       |<--QoS-Response----+                                |     |.
       |                   |                                |
       |=====================Data Flow==============....===>|
       |                   | .
       | .                   +- - - - - ACR - - - - - >|
       |                   |(START,QoS-Resources,Cost|
       |                          \                   |CC-Time,Acc-Multisess-id)|
       |                   |                +--------+--------------+
       |                   | . /  .                | Report for successful |                            \
       |                   | /    .                |   QoS reservation     |
       |                   |                |Update of reserved QoS request             |-----V .    .
    +-------------+ + Authz. Token   +--------+-----+      . |  Entity     |----------------->| NE
       |      .                   |  requesting                |      resources        | performing
       |      .                   |  resource   |granted / rejected| QoS                +--------+--------------+
       |                   |< - - - - ACA - - - - - -+
       | <....+                   |             |<-----------------| reservation                         |
    +-------------+                  +--------------+

           Figure 4: Token-based Three Party Scheme

   The 'Token-based Three Party scheme' is applicable to environments
   where a previous protocol interaction is used to request
   authorization tokens to assist the authorization process at the
   Network Element or the Authorizing Entity.

   The 2: Initial QoS resource requesting entity may be involved in an application
   layer protocol interaction, Request Authorization for example using SIP, with the pull

   The Authorizing Entity.  As part of this interaction, authentication and Entity keeps authorization at the application layer might take place.  As a result session state and SHOULD
   save additional information for management of a successful authorization decision, which might involve the
   user's home AAA server, an authorization token is generated by the
   Authorizing Entity session (e.g., Acc-
   Multi-Session-Id, Signaling-Session-Id, authentication data) as part
   of the SIP proxy and an entity trusted by session state information.  A Signaling-session-Id (if
   present) SHOULD be used together with the
   SIP proxy) generated Acc-Multi-
   Session-Id AVP (see Section 6.3) for binding the authorization and returned to
   the accounting session information in case of end host for inclusion into mobility
   (i.e., to correlate the QoS
   signaling protocol.  The authorization token will be used by a
   Network Element Diameter sessions that receives are initiated for the QoS
   same signaling message to authorize
   the QoS request.  Alternatively, the Diameter session from different QoS application will be
   used to forward the authorization token to the user's home network. NE).

   The authorization token allows the authorization decision performed
   at the application layer protocol run to be associated with a
   corresponding QoS signaling session.  Note that the authorization
   token might either refer to established state concerning final result of the authorization decision or request is provided in the token might itself carry
   Result-Code AVP of the authorized
   parameters (protected by a digital signature or a keyed QAA message
   digest to prevent tampering).  In sent by the latter Authorizing Entity.
   In case the authorization
   token may contain several pieces of successful authorization (i.e., Result-Code =
   DIAMETER_LIMITED_SUCCESS, (see Section 6.1)), information pertaining to about the
   authorized application session, but at minimum it should contain:
   o  An identifier of QoS resources and the Authorizing Entity (for example, status of an
      application server) that issued the authorization token,
   o  An identifier referring to a specific application protocol session
      for which the token was issued and
   o  A keyed message digest or digital signature protecting authorized flow
   (enabled/disabled) is provided in the content QoS-Resources AVP of the authorization token.

   A possible structure for QAA
   message.  The QoS information provided via the authorization token and QAA is installed by
   the policy
   element carrying it are proposed in context QoS Traffic Control function of RSVP [RFC3520].

   In the scenario mentioned above, where Network Element.  The value
   DIAMETER_LIMITED_SUCCESS indicates that the QoS resource requesting Authorizing entity is involved in
   expects confirmation via an application layer protocol interaction with accounting message for successful QoS
   resource reservation and for final reserved QoS resources (see
   below).

   One important piece of information returned from the Authorizing entity, it may be worthwhile to consider a token less
   binding mechanism also.  The application layer protocol interaction
   may have indicated
   Entity is the transport port numbers at authorization lifetime (carried inside the QoS resource
   requesting entity where it might receive media streams, for example
   in SIP/SDP signalling these port numbers are advertised. QAA).  The QoS
   resource requesting entity may also use these port numbers in some IP
   filter indications
   authorization lifetime allows the Network Element to determine how
   long the NE performing authorization decision is valid for this particular QoS reservation so that it
   reservation.  A number of factors may properly tunnel the inbound packets.  The NE performing QoS
   reservation will forward influence the QoS resource requesting entity's IP
   address and authorized
   session duration, such as the IP filter indications to user's subscription plan or currently
   available credits at the Authorizing entity user's account (see Section 4).  The
   authorization duration is time-based as specified in [RFC3588].  For
   an extension of the authorization period, a new QoS-Authorization-
   Request/Answer message exchange SHOULD be initiated.  Further aspects
   of QoS authz. request. authorization session maintenance is discussed in Section 3.3,
   Section 3.4 and Section 4.

   The Authorizing entity will use the indication of a successful QoS
   resource requesting entity's IP address reservation and activation of the port numbers in
   data flow is provided by the
   IP filter indication, transmission of an Accounting Request
   (ACR) message, which will match the port numbers advertised in
   the earlier application layer protocol interaction, to identify reports the
   right piece parameters of policy information to be sent to the NE performing the established QoS reservation in
   state: reserved resources, duration of the reservation,
   identification of the QoS authz. response.

3.3.2.  Authorization schemes for push mode

   The push mode can be further divided into two types: endpoint
   initiated enabled flow/QoS signaling session and network initiated.  In
   accounting parameters.  The Diameter QoS server acknowledges the former case,
   reserved QoS resources with the
   authorization process Accounting Answer (ACA) message where
   the Result-Code is triggered by application server upon
   explicit set to 'DIAMETER_SUCCESS'.  Note that the reserved
   QoS request from endpoints through application signaling,
   e.g.  SIP; resources reported in the latter case, ACR message MAY be different than those
   initially authorized with the QAA message, due to the authorization QoS signaling
   specific behavior (e.g., receiver-initiated reservations with One-
   Path-With-Advertisements) or specific process is triggered
   by application server without explicit of QoS request from endpoint.

   In the endpoint initiated scheme, negotiation
   along the data path.

3.2.2.  QoS resource requesting entity
   (i.e. endpoint) determines the required application level authorization session establishment for push mode

   The Diameter QoS and
   sends server in the Authorizing Entity initiates a
   Diameter QoS authorization session upon the request through for QoS
   reservation triggered by application layer signaling message, the
   Application Server will extract application level QoS information or by local
   events, and
   trigger generates a QoS-Install-Request (QIR) message to Diameter
   QoS client in the authorization process NE in which it maps required objects to Authorizing entity.  In Diameter
   payload objects.

   Figure 4 shows the
   network initiated scheme, protocol interaction between the Authorizing entity and/or Application
   sever should derive
   Entity, a Network Element and determine a resource requesting entity.

   The Network Element's identity, information about the QoS requirement according to application attribute, subscription
   session and/or identity and endpoint's capability when
   the endpoint does not explicitly indicate credentials of the QoS attributes.  The
   authorizing entity makes authorization decision based on application
   level QoS information, network policies, end user subscription and
   network resource availability etc., and installs the decision to
   network element directly.

                               financial settlement
                                ...........................+
      Application               V             -------      .
   requesting entity, requested QoS parameters, signaling msg   +--------------+      / session
   identifier and/or QoS AAA \    .
      +-------------->|              |     /  protocol \   .
      |               | enabled data flows identifiers MAY be
   encapsulated into respective Diameter AVPs and included into the
   Diameter message sent from a Diameter QoS server in the Authorizing  +--------------+   \  .
   Entity to a Diameter QoS client in the NE.  This requires that the
   Authorizing Entity has knowledge of specific information for
   allocating and identifying the Network Element that should be
   contacted and the data flow for which the QoS reservation should be
   established.  This information can be statically configured or
   dynamically discovered, see section 3.2.3 for details.

   +----------------------------------+-------------------------------+
   | QoS specific Input Data          | Entity Diameter QoS AVPs             |
   +----------------------------------+-------------------------------+
   | Network Element ID (e.g., from   | Destination-Host              | .
   |               +              |<--+----+ static configuration             | Destination-Realm             | .
   |               +--------------+  |QoS or dynamically discovered, see   |     |QoS  |.                               |                                install|     |install
   |                                 |rsp. section 3.2.3 for details)       |     |req. |.                               |
   +----------------------------------+-------------------------------+
   | Authorization Token              | QoS-Authz-Data                |     |.
   | Credentials of                   | User-Name                     |
   | . the QoS requesting entity        | .                               |                                   \
   +----------------------------------+-------------------------------+
   | QoS parameters                   | . /  . QoS-Resources                 |                                     \
   +----------------------------------+-------------------------------+

   Authorization processing starts at the Diameter QoS server when it
   receives the request from a resource requesting entity through
   application server (e.g.  SIP Invite) or the trigger by local events
   (e.g. pre-configured timer).  Based on the received information the
   server determines the authorized QoS resources and flow state
   (enabled/disabled) from locally available information (e.g., policy
   information that may be previously established as part of an
   application layer signaling exchange, or the user's subscription
   profile).  The authorization decision is then reflected in the QoS-
   Install-Request message (QIR) to the Diameter QoS client.

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)
       |                   | /    .
      V                                       |-----V .    .
    +-------------+                  +--------+-----+      .                          |  Entity
       |                   | NE                          |<-- Trigger --
       |      .                   |  requesting                 +--------+--------------+
       |                   | performing                 |      .  Authorize request    |  resource   |QoS rsrc granted
       | QoS                   | <....+                 |             |<-----------------| reservation  Keep session data    |
    +-------------+                  +--------------+

               Figure 5: Authorization Scheme for Push Mode

3.4.  QoS Authorization Requirements

   A QoS authorization application must meet a number of requirements
   applicable to a diverse set
       |                   |                 |/Authz-time,Session-Id/|
       |                   |                 +--------+--------------+
       |                   |                          |
       |                   |<-- - -- - QIR - - - - - -+
       |                   |(Initial Request,Decision |
       |                   |(QoS-Resources,Authz-time)|
       |           +-------+---------+
       |           |Install QoS state|
       |           |       +         |
       |           | Authz. session  |
       |           | /Authz-time,    |
       |           |  CC-Time,Cost/  |
       |           +-------+---------+
       |                   + - - - - QIA - - - - - ->|
       |                   |    (Result-Code,        |
       |                   |     QoS-Resources)      |
       |                   |                +--------+--------------+
       |                   |                | Report for successful |
       |                   |                |   QoS reservation     |
       |                   |                |Update of networking environments and services.
   It should be compliant with different deployment scenarios with
   specific reserved QoS signaling models and security issues.  Satisfying the
   requirements listed below while interworking with |
       |                   |                |      resources        |
       |                   |                +--------+--------------+
       |                   |                         QoS signaling
   protocols, a Diameter Responder
       |                   |                               Node
       |                   |                                |
       |=====================Data Flow==============....===>|
       |                   |
       |                   +- - - - - ACR - - - - - >|
       |                   |(START,QoS-Resources,Cost|
       |                   |CC-Time,Acc-Multisess-id)|
       |                   |< - - - - ACA - - - - - -+
       |                   |                         |

           Figure 4: Initial QoS application should accommodate Request Authorization for push
   The Authorizing Entity keeps authorization session state and SHOULD
   save additional information for management of the
   capabilities session (e.g., Acc-
   Multi-Session-Id, Signaling-Session-Id, authentication data) as part
   of the QoS signaling protocols rather than introducing
   functional requirements on them. session state information.  A list of requirements Signaling-session-Id (if
   present) SHOULD be used together with the generated Acc-Multi-
   Session-Id AVP (see Section 6.3) for a QoS
   authorization application is provided here:

   Inter-domain support

      In particular, users may roam outside their home network, leading
      to a situation where binding the network element authorization and authorizing entity
      are
   the accounting session information in different administrative domains.

   Identity-based Routing

      The QoS AAA protocol MUST route AAA requests case of end host mobility
   (i.e., to correlate the Authorizing
      Entity, based on Diameter sessions that are initiated for the provided identity
   same signaling session from different QoS NE).

   The final result of the QoS requesting
      entity or authorization decision is provided in the identity
   QoS-Resources AVP of the Authorizing entity encoded in QIR message sent by the
      provided authorization token.

   Flexible Authentication Support Authorizing Entity.
   The QoS AAA protocol MUST support a variety of different
      authentication protocols for verification of authentication information present in QoS signaling messages.  The support for
      these protocols MAY be provided indirectly via the QIR is installed by tying the signaling
      communication for QoS to a previous authentication protocol
      exchange (e.g., using network access authentication).

   Making an Authorization Decision

      The QoS AAA protocol MUST exchange sufficient
   Traffic Control function of the Network Element.  In the case of
   successful enforcement, the Result-Code (= DIAMETER_SUCCESS, (see
   Section 6.1)) information between is provided in the authorizing entity and QIA message.

   One important piece of information from the enforcing entity (and vice versa) Authorizing Entity is the
   authorization lifetime (carried inside the QIR).  The authorization
   lifetime allows the Network Element to compute an determine how long the
   authorization decision and to execute is valid for this decision.

   Triggering an Authorization Process

      The particular QoS AAA protocol MUST allow periodic and event triggered
      execution reservation.
   A number of factors may influence the authorization process, originated at authorized session duration,
   such as the
      enforcing entity user's subscription plan or even currently available credits
   at the authorizing entity.

   Associating QoS Reservations and Application State user's account (see Section 4).  The QoS AAA protocol MUST carry information sufficient for authorization duration is
   time-based as specified in [RFC3588].  For an
      application server to identify extension of the appropriate application session
      and associate it with
   authorization period, a particular QoS reservation.

   Dynamic Authorization

      It MUST be possible for the QoS AAA protocol to push updates
      towards the network element(s) from authorizing entities.

   Bearer Gating

      The new QoS-Install-Request/Answer message or
   QoS-Authorization-Request/Answer message exchange SHOULD be
   initiated.  Further aspects of QoS AAA protocol MUST allow the authorizing entity to gate
      (i.e., enable/disable) authorized application flows based on e.g.,
      application state transitions.

   Accounting Records authorization session maintenance
   is discussed in Section 3.3, Section 3.4 and Section 4.

   The indication of a successful QoS AAA protocol MUST define QoS accounting records containing
      duration, volume (byte count) usage information reservation and description activation of the QoS attributes (e.g., bandwidth, delay, loss rate)
   data flow, is provided by the QoS-Install-Answer message.  Note that were
      supported for
   the flow.

   Sending Accounting Records

      The network element SHOULD send accounting records for a
      particular reserved QoS reservation state resources reported in the QIA message MAY be
   different than those initially authorized with the QIR message, due
   to the authorizing entity, which
      plays QoS signaling specific behavior (e.g., receiver-initiated
   reservations with One-Path-With-Advertisements) or specific process
   of QoS negotiation along the role data path.

   In case of xxx = Acounting_Info in the QIR, it indicates the
   confirmation to an accounting entity.

   Failure Notification

      The server for successful QoS AAA protocol MUST allow resource
   reservation and for final reserved QoS resources (see below).  An ACR
   message reports the network element to report
      failures, such as loss of connectivity due to movement parameters of a mobile
      node or other reasons for packet loss, to the authorizing entity.

   Accounting Correlation

      The established QoS AAA protocol MUST support state: reserved
   resources, duration of the exchange reservation, identification of sufficient
      information to allow for correlation between accounting records
      generated by the network elements QoS
   enabled flow/QoS signaling session and accounting records generated
      by an application parameters to
   accounting server.

   Interaction with other AAA Applications

      Interaction  The accounting server acknowledges the reserved
   QoS resources with other AAA applications such as Diameter Network
      Access (NASREQ) application [RFC4005] the Accounting Answer (ACA) message where the
   Result-Code is required for exchange of
      authorization, authentication set to 'DIAMETER_SUCCESS'.

3.2.3.  Discovery and accounting information.

   In deployment scenarios, where authentication selection of the peer Diameter QoS reservation
   requesting entity (e.g., the user) is done by means outside the application node

   The Diameter QoS application protocol interaction node may obtain the location information
   of its peer nodes (i.e.  FQDN or IP address) through static
   configuration or dynamic discovery as described in [RFC3588].  In
   particular, the Network Element shall perform the relevant operation
   for Pull mode; the Authorizing Entity
   is contacted only with a request shall perform the relevant
   operations for Push mode.

   Upon receipt of a trigger to initiate a new Diameter QoS authorization.
   Authentication might have taken place already via the interaction
   with
   authorization session, the Diameter NASREQ QoS application or as part node selects and
   retrieves the location information of the QoS signaling
   protocol (e.g., Transport Layer Security (TLS) handshake peer node and based on some
   index information provided by the resource requesting entity.  For
   instance, it can be the Authorization Entity's ID stored in the
   General Internet Signaling Transport (GIST) protocol, see
   [I-D.ietf-nsis-ntlp]).

   Authentication of
   authorization token, the end-host's identity (e.g.  NAI [RFC2486]) or
   globally routable IP address.

3.3.  QoS reservation requesting entity to authorization session re-authorization

   Client and server-side initiated re-authorizations are considered in
   the design of the
   Authorizing Entity is necessary if a particular Diameter QoS
   application protocol run cannot be related (or if there is no
   intention to relate it) to a prior authentication.  In this case application.  Whether the
   Authorizing Entity MUST authenticate re-
   authorization events are transparent for the QoS reservation resource requesting
   entity or result in specific actions in order to authorize the QoS request as part signaling protocol is
   outside the scope of the Diameter QoS protocol interaction.

   The document refers to three types application.  It is directly
   dependent on the capabilities of sessions that need to be
   properly correlated.

   QoS signaling session

      The time period during which a the QoS signaling protocol establishes,
      maintains and deletes protocol.

   There are a QoS reservation state at number of options for policy rules according to which the QoS network
      element is referred as QoS signaling session.  Different QoS
      signaling protocols use different ways to identify QoS signaling
      sessions.  The same applies to different usage environments.
      Currently, this document supports three types of QoS session
      identifiers, namely a signaling session id (e.g., the Session
      Identifier used by the NSIS protocol suite), a flow id (e.g.,
      identifier assigned by an application to a certain flow as used in
   NE (AAA client) contacts the 3GPP) and a flow description based Authorizing Entity for re-authorization.
   These rules depend on the IP parameters semantics and contents of the
      flow's end points.  The details can be found in Section 7.4.

   Diameter authorization session

      The time period, for which a Diameter server authorizes a
      requested service (i.e., QoS resource reservation) is referred to
      as a Diameter authorization session.  It is identified QAA message
   sent by a
      Session-Id included in all Diameter messages used for management
      of the authorized service (initial authorization, re-
      authorization, termination), see [RFC3588].

   Application layer session Authorizing Entity:

   a.  The application layer session identifies QAA message contains the duration of an
      application layer service which requires provision authorized parameters of certain QoS.
      An application layer session identifier is provided by the flow
       and its QoS
      requesting entity in and sets their limits (presumably upper).  With these
       parameters the QoS signaling messages, Authorizing Entity specifies the services that the
       NE can provide and will be financially compensated for.
       Therefore, any change or request for example as
      part change of the authorization token.  In general, parameters of
       the application
      session identifier is opaque flow and its QoS that do not conform to the QoS aware network elements.
      It is included in authorized limits
       requires contacting the authorization request Authorizing Entity for authorization.
   b.  The QAA message sent to contains authorized parameters of the
      Authorizing entity flow and helps it to correlate the QoS authorization
      request to the application session state information.

   Correlating these sessions is done at each
       its QoS.  The rules that determine whether parameters' changes
       require re-authorization are agreed out of band, based on a
       Service Level Agreement (SLA) between the three involved
   entities: The QoS requesting entity correlates domains of the application with NE and
       the QoS signaling sessions. Authorizing Entity.
   c.  The QoS network element correlates QAA message contains the
   QoS signaling session with authorized parameters of the flow
       and its QoS.  Any change or request for change of these
       parameters requires contacting the Diameter authorization sessions.  The Authorizing entity SHOULD bind for re-
       authorization.

   d.  In addition to the information about authorized parameters of the three
   sessions together.  Note flow and its QoS,
       the QAA message contains policy rules that determine the NEs
       actions in certain scenarios not all case of the
   sessions change or request for change in authorized
       parameters.

   Provided options are present.  For example, the application session might not
   be visible to QoS signaling protocol directly if there is no binding
   between exhaustive.  Elaborating on any of the application session
   listed approaches is deployment /solution specific and is not
   considered in the QoS requesting entity using current document.

   In addition, the QoS signaling protocol.

4.  Diameter QoS Authorization Session Establishment and Management

4.1.  Parties involved

   Authorization models supported by this application include three
   parties:
   o  Resource requesting entity
   o  Network Elements (Diameter QoS clients)
   o Authorizing Entity (Diameter QoS server)
   Note that may use RAR to perform re-
   authorization with the QoS resource requesting entity is only indirectly
   involved in authorized parameters directly when the message exchange.  This entity re-
   authorization is triggered by service request or local events/policy
   rules.

3.3.1.  Client-Side Initiated Re-Authorization

   The Authorizing Entity provides the trigger
   to initiate duration of the Diameter QoS protocol interaction by transmitting QoS
   signaling messages.  The Diameter QoS application is only executed
   between the Network Element (i.e., Diameter QoS client) and the
   Authorizing Entity (i.e., Diameter QoS server).

   The QoS resource requesting entity may communicate with the
   Authorizing Entity using application layer signaling for negotiation
   of service parameters.  As authorization
   session as part of this application layer protocol
   interaction, for example using SIP, authentication and authorization
   might take place.  This message exchange is, however, outside the
   scope QoS-Authorization-Answer message (QAA).  At
   any time before expiration of this document.  The protocol communication between period, a new QoS-Authorization-
   Request message (QAR) MAY be sent to the Authorizing Entity.  The
   transmission of the
   QoS resource requesting entity and QAR MAY be triggered when the QoS Network Element might be
   accomplished using the NSIS protocol suite, RSVP or
   receives a link layer QoS signaling protocol.  A description message that requires modification of these protocols is also outside the scope
   authorized parameters of this document and a tight coupling with these protocols
   is not desirable since this applications aims to be generic.

4.2.  Diameter an ongoing QoS Authorization Session Establishment

   Figure 7 shows the protocol interaction between a resource requesting
   entity, a Network Element session, when authorization
   lifetime expires or by an accounting event, see Section 4 and the
   Figure 5).

                                               Authorizing Entity.

   A request for a QoS reservation received by a
     End-Host         Network Element
   initiates a             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS authorization session.  The Network Element
   generates a QoS-Authorization-Request (QAR) message in which it maps
   required objects from the Client)             QoS signaling message to Diameter payload
   objects.

   +----------------------------------+-------------------------------+ Server)
       | QoS specific Input Data                   | Diameter QoS AVPs                         |
   +----------------------------------+-------------------------------+
       |=====================Data Flow==========================>
       | Authorizing entity ID (e.g.,                   | Destination-Host              |
   | taken from authorization token   | Destination-Realm             |
   | or from Network Access ID (NAI)  |                               |
   | [RFC2486] of the QoS requesting  |                               |
   | entity)                          |                               |
   +----------------------------------+-------------------------------+                         | Authorization Token              | QoS-Authz-Data                |
   | Credentials of
       | User-Name                     |
   | the QoS requesting entity           +-------+----------+              |
       |
   +----------------------------------+-------------------------------+           |Authz-time/CC-Time|              | QoS parameters
       | QoS-Resources           |
   +----------------------------------+-------------------------------+

   The Authorizing Entity's identity, information about the application
   session and/or identity and credentials of the QoS resource
   requesting entity, requested QoS parameters, signaling session
   identifier and/or QoS enabled data flows identifiers MAY be
   encapsulated into respective Diameter AVPs and included into the
   Diameter message sent to the Authorizing Entity.  The QAR is sent to
   a Diameter server that can either be the home server of the QoS
   requesting entity or an application server.

   Authorization processing starts at the Diameter QoS server when it
   receives the QAR.  Based on the information in the QoS-
   Authentication-Data, User-Name and QoS-Resources AVPs the server
   determines the authorized QoS resources and flow state (enabled/
   disabled) from locally available information (e.g., policy
   information that may be previously established as part of an
   application layer signaling exchange, or the user's subscription
   profile).  The authorization decision is then reflected in the
   response returned to the Diameter client with the QoS-Authorization-
   Answer message (QAA).

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)    expires       |              |
       |
       +---QoS-Reserve---->|           +-------+----------+              |
       |                   +- - - - - QAR - - - - - >|
       |                   |(QoS-Resources,Cost,     |
       |                   |   QoS-Auth-Data,User-ID)|
       | QoS-Authz-Data,User-ID)|
                           |                +--------+--------------+
       |
    NOTE:                  |                |  Authorize request    |
    Re-authorization       |                |                |  Keep Update session data   |
       |
    is transparent to      |                |/Authz-time,Session-Id/|
       |
    the End-Host           |                +--------+--------------+
       |
                           |< - - - - QAA - - - - - -+
       |                   |(Result-Code,CC-Time,Cost|
       |                   |QoS-Resources,Authz-time)|
       |           +-------+---------+               |           |Install
       |           |Update QoS state| state |               |
       |           |       +         |               |
       |           | Authz. session  |               |
       |           | /Authz-time,    |                QoS Responder               |
       |           |  CC-Time,Cost/  |                    Node
       |           +-------+---------+                      |
       |                   +----------QoS-Reserve---....--->|
       |                   |                                |
       |                   |<---------QoS-Response--....----|
       |<--QoS-Response----+               |
       |           +-------+---------+               |
       |
       |=====================Data Flow==============....===>|                   |                         |
       |                   +- - - - - ACR - - - - - >|
       |                   |(START,QoS-Resources,Cost|                   |(INTRM,QoS-Resources,Cost|
       |                   |CC-Time,Acc-Multisess-id)|
       |                   |                +--------+--------------+
       |                   |                | Report for successful |
       |                   |                |   QoS reservation     |
       |                   |                |Update of reserved QoS resources|
       |                   |                   |                |      resources                |/CC-Time,Cost/ used    |
       |                   |                +--------+--------------+
       |                   |< - - - - ACA - - - - - -+
       |                   |                         |
       |=====================Data Flow==========================>
       |                   |

           Figure 7: Initial 5: Client-side initiated QoS Request Authorization re-authorization

3.3.2.  Server-Side Initiated Re-Authorization

   The Authorizing Entity keeps authorization session state and SHOULD
   save additional information for management of the session (e.g., Acc-
   Multi-Session-Id, Signaling-Session-Id, authentication data) MAY initiate a QoS re-authorization by issuing
   a Re-Auth-Request message (RAR) as part
   of the session state information.  A Signaling-session-Id (if
   present) SHOULD be used together with the generated Acc-Multi-
   Session-Id AVP (see Section 7.3) for binding the authorization and
   the accounting session information defined in case of end host mobility
   (i.e., to correlate the Diameter sessions that are initiated for the
   same signaling session from different QoS NE).

   The final result of the authorization request is provided in the
   Result-Code AVP of the QAA message sent by base
   protocol [RFC3588], which may include the Authorizing Entity.
   In case parameters of successful authorization (i.e., Result-Code =
   DIAMETER_LIMITED_SUCCESS, (see Section 7.1)), information about the re-
   authorized QoS resources and the status state: reserved resources, duration of the authorized flow
   (enabled/disabled) is provided in the QoS-Resources AVP
   reservation, identification of the QAA
   message.  The QoS information provided via enabled flow/QoS signaling
   session for re-installation of the QAA is installed resource state by the QoS Traffic
   Control function of the Network Element.

   A Network Element (see
   Figure 2).  The value DIAMETER_LIMITED_SUCCESS indicates that the
   Authorizing entity expects confirmation via an accounting receives such a RAR message for
   successful QoS resource reservation and for final reserved with Session-Id
   matching a currently active QoS
   resources (see bellow).

   One important piece of information returned from the Authorizing
   Entity is the authorization lifetime (carried inside the QAA).  The
   authorization lifetime allows the Network Element to determine how
   long the authorization decision is valid for this particular QoS
   reservation.  A number of factors may influence the authorized
   session duration, such as the user's subscription plan or currently
   available credits at the user's account (see Section 5).  The
   authorization duration is time-based as specified in [RFC3588].  For
   an extension of the authorization period, a new QoS-Authorization-
   Request/Answer message exchange SHOULD be initiated.  Further aspects
   of QoS authorization session maintenance is discussed in Section 4.3,
   Section 4.5 and Section 5.

   The indication of a successful QoS reservation and activation of acknowledges the
   data flow, is provided request by
   sending the transmission of an Accounting Request
   (ACR) message, which reports Re-Auth-Answer (RAA) message towards the Authorizing
   entity.

   If RAR does not include any parameters of the established QoS
   state: reserved resources, duration of the reservation,
   identification of the QoS enabled flow/QoS signaling session and
   accounting parameters.  The Diameter QoS server acknowledges the
   reserved re-authorized QoS resources with the Accounting Answer (ACA) message where
   the Result-Code is set to 'DIAMETER_SUCCESS'.  Note that
   state, the reserved Network Element MUST initiate a QoS resources reported in the ACR re-authorization by
   sending a QoS-Authorization-Request (QAR) message MAY be different than those
   initially authorized with the QAA message, due to towards the
   Authorizing entity.

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS signaling
   specific behavior (e.g., receiver-initiated reservations with One-
   Path-With-Advertisements) or specific process of      ( Diameter              ( Diameter
                        QoS negotiation
   along the data path.

4.3. Client)             QoS authorization session re-authorization

   Client and server-side initiated re-authorizations are considered in
   the design Server)
       |                   |                          |
       |                   |                          |<-- Trigger --
       |                   |                 +--------+--------------+
       |                   |                 |  Authorize request    |
       |                   |                 |  Keep session data    |
       |                   |                 |/Authz-time,Session-Id/|
       |                   |                 +--------+--------------+
       |                   |                          |
       |                   |<-- - -- - RAR - - - - - -+
       |                   |(Request,Decision |
       |                   |(QoS-Resources,Authz-time)|
       |           +-------+---------+
       |           |Install QoS state|
       |           |       +         |
       |           | Authz. session  |
       |           | /Authz-time,    |
       |           |  CC-Time,Cost/  |
       |           +-------+---------+
       |                   + - - - - RAA - - - - - ->|
       |                   |    (Result-Code,        |
       |                   |     QoS-Resources)      |
       |                   |                +--------+--------------+
       |                   |                | Report for successful |
       |                   |                |   QoS reservation     |
       |                   |                |Update of the Diameter reserved QoS application.  Whether the re- |
       |                   |                |      resources        |
       |                   |                +--------+--------------+
       |                   |                         |
       |                   +- - - - - ACR - - - - - >|
       |                   |(INTRM,QoS-Resources,Cost|
       |                   |CC-Time,Acc-Multisess-id)|
       |                   |                +--------+--------------+
       |                   |                |Update of QoS resources|
       |                   |                |/CC-Time,Cost/ used    |
       |                   |                +--------+--------------+
       |                   |< - - - - ACA - - - - - -+
       |                   |                         |

           Figure 6: Server-side Initiated QoS re-authorization

3.4.  Session Termination

3.4.1.  Client-Side Initiated Session Termination

   The authorization events are transparent session for an installed QoS reservation state MAY
   be terminated by the resource requesting
   entity or result in specific actions in Diameter client by sending a Session-
   Termination-Request message (STR) to the QoS signaling Diameter server.  This is a
   Diameter base protocol function and it is
   outside the scope defined in [RFC3588].
   Session termination can be caused by a QoS signaling messaging
   requesting deletion of the Diameter existing QoS application.  It is directly
   dependent on the capabilities of the QoS signaling protocol.

   In addition, there are reservation state or it can
   be caused as a number of options for policy rules according
   to which the NE (AAA client) contacts the Authorizing Entity for re-
   authorization.  These rules depend on the semantics and contents result of
   the QAA message sent by the Authorizing Entity:

   a.  The QAA message contains the authorized parameters a soft-state expiration of the flow
       and its QoS and sets their limits (presumably upper).  With these
       parameters the Authorizing Entity specifies the services that the
       NE can provide and will be financially compensated for.
       Therefore, any change or request for change of the parameters
   reservation state.  After a successful termination of the flow and its QoS
   authorization session, final accounting messages MUST be exchanged
   (see Figure 7).  It should be noted that do not conform to the authorized limits
       requires contacting two sessions
   (authorization and accounting) have independent management by the Authorizing Entity
   Diameter base protocol, which allows for authorization.
   b.  The QAA message contains authorized parameters of finalizing the flow and
       its QoS.  The rules that determine whether parameters' changes
       require re-authorization are agreed out of band, based on a
       Service Level Agreement (SLA) between accounting
   session after the domains end of the NE and
       the authorization session.

                                               Authorizing Entity.
   c.  The QAA message contains the authorized parameters of the flow
       and its QoS.  Any change or request for change
     End-Host         Network Element             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       |==Data Flow==>X /Stop of these
       parameters requires contacting the Authorizing entity for re-
       authorization.
   d.  In addition to the authorized parameters of the flow and its QoS,
       the QAA message contains policy rules that determine the NEs
       actions in case of change or request for change in authorized
       parameters.

   Provided options are not exhaustive.  Elaborating on any of the
   listed approaches is deployment /solution specific and is not
   considered in the current document.

4.3.1.  Client-Side Initiated Re-Authorization

   The Authorizing Entity provides the duration of the authorization
   session as part of the QoS-Authorization-Answer message (QAA).  At
   any time before expiration of this period, a new QoS-Authorization-
   Request message (QAR) MAY be sent to the Authorizing Entity.  The
   transmission of the QAR MAY be triggered when the Network Element
   receives a QoS signaling message that requires modification of the
   authorized parameters of an ongoing QoS session, when authorization
   lifetime expires or by an accounting event, see Section 5 and
   Figure 8).

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       |=====================Data Flow==========================>
       |                   |                         |
       |           +-------+----------+              |
       |           |Authz-time/CC-Time|              |
       | data flow/      |    expires
       |                   |                         |           +-------+----------+
       +---QoS-Reserve---->|                         |
       |  (Delete QoS      +- - - - - QAR STR - - - - - >|
       |                   |(QoS-Resources,Cost,     |
       |                   | QoS-Authz-Data,User-ID)|   reservation)    |                +--------+--------------+
    NOTE:
       |                   |  Authorize request                |
    Re-authorization Remove authorization  |
       |<--QoS-Response----+                | Update session data state         |
    is transparent to
       |                |/Authz-time,Session-Id/|
    the End-Host                   |                +--------+--------------+
                           |< - - - - QAA STA - - - - - -+
                   +-------+--------+                |                   |(Result-Code,CC-Time,Cost|
       |                   |QoS-Resources,Authz-time)|
       |           +-------+---------+               |
       |           |Update
                   |Delete QoS state |               |
       |           |       +         |               |
       |           | Authz. session  |               |
       |           | /Authz-time,    |               |
       |           |  CC-Time,Cost/  | state|
                   |  Report final  |           +-------+---------+
                   | accounting data|                   QoS Responder
                   +-------+--------+                       Node
                           +----------QoS-Reserve-----....--->|
                           |         (Delete QoS              |
                           |          reservation)
                           |
                           +- - - - - ACR - - - - - >|
       |                   |(INTRM,QoS-Resources,Cost|
       |
                           |(FINAL,QoS-Resources,Cost|
                           |CC-Time,Acc-Multisess-id)|
                           |                   |                +--------+--------------+
                           |                |                |Update of QoS resources| Report for successful |
                           |                |/CC-Time,Cost/ used                |  end of QoS session   |
                           |                +--------+--------------+
       |
                           |< - - - - ACA - - - - - -+
                           |
                           |                            QoS Responder
                           |
       |=====================Data Flow==========================>                                Node
                           |<---------QoS-Response----....----+
                           |                                  |

            Figure 8: QoS request re-authorization

4.3.2. 7: Client-Side Initiated Session Termination

3.4.2.  Server-Side Initiated Re-Authorization

   The Session Termination

   At anytime during a session the Authorizing Entity MAY optionally initiate a QoS re-authorization
   by issuing a Re-Auth-Request send an Abort-
   Session-Request message (RAR) as defined in (ASR) to the Network Element.  This is a
   Diameter base protocol function and it is defined in [RFC3588].  A
   Possible reasons for initiating the ASR message to the Network
   Element client that receives such
   a RAR message with Session-Id matching a currently active QoS are insufficient credits or session
   acknowledges the request by sending termination at the Re-Auth-Answer (RAA) message
   and MUST initiate a QoS reservation re-authorization by sending a
   QoS-Authorization-Request (QAR)
   application layer.  The ASR message towards the Authorizing
   entity.

4.4.  Server-Side Initiated QoS Parameter Provisioning

   In certain deployment scenarios (mostly applicable for local QoS
   provision) an active control over the QoS resource and QoS enabled
   data flows from results in termination of the network side is required.  Therefore,
   authorized session, release of the
   Authorizing Entity is enabled to update installed QoS parameters and
   flow state reserved resources at the Network
   Element by sending a QoS-Install Request
   message (QIR).  Network Elements MUST apply the updates and respond
   with an QoS-Install Answer message (QIA).  This functionality, for
   example, allows the update of already authorized flow status transmission of an
   established appropriate QoS reservation due to signaling message
   indicating a change at notification to other Network Elements aware of the application layer
   session
   signaling session.  A final accounting message exchange MUST be
   triggered as a result of this ASR message exchange (see Figure 9). 8).

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       +===================+=Data
       |=====================Data Flow==========================>
       |                   |                +--------+--------------+
       |                   |                |Data flow preemption   |
       |                   |                +--------+--------------+
       |                   |< - - - - QIR ASR - - - - - -+
       |                   |(QoS-Resources[QoS-Flow-                   |                         |
       |====Data Flow=====>X                         | -State=CLOSE])  QoS Responder
       |                   |           +-------+---------+                         |      Node
       |<--QoS-Notify------+----------QoS-Reserve-----....--->|
       |           |Update QoS state                   |         (Delete QoS     |        |
                           |       +          reservation)   |
                   +-------+--------+                |
                   |Delete QoS state|                |
                   | Authz. session  Report final  |                |
                   |           |/QoS-Flow-State= accounting data|                |
                   +-------+--------+                |
                           +- - - - - ASA - - - - - >|
                           |                +--------+--------------+
                           |     CLOSE/                | Remove authorization  |
                           |           +-------+---------+                |
       +====Data Flow=====>X     session state     |
                           |                +--------+--------------+
                           +- - - - - QIA ACR - - - - - >|
                           |(FINAL,QoS-Resources,Cost|
                           |CC-Time,Acc-Multisess-id)|
                           |                +--------+--------------+
                           |                | Report for successful |
                           |                |  end of QoS session   |
                           |                +--------+--------------+
                           |< - - - - ACA - - - - - -+
                           |                            QoS Responder
                           |                                Node
                           |<---------QoS-Response----....----+
                           |     (Result-Code)                                  |

            Figure 9: 8: Server-Side Initiated QoS Parameter Provisioning Session Termination

4.  Accounting

   The Authorizing Entity MAY initiate a Diameter QoS authorization session
   establishment and application provides accounting for usage of
   reserved QoS reservation state installation (prior to a
   request from a Network Element).  This function requires that the
   Authorizing Entity resources.  Diameter QoS accounting has knowledge of specific information identifying built-in support
   for online, duration based accounting.  This accounting is based on
   the Network Element notion that should be contacted and the data flow for
   which the Diameter QoS reservation should be established.(mostly applicable
   for local scenarios)

4.5.  Session Termination

4.5.1.  Client-Side Initiated Session Termination

   The authorization session for an installed QoS reservation state MAY
   be terminated by clients are in the Diameter client by sending a Session-
   Termination-Request message (STR) best position to
   determine the cost of those resources.

   In the Diameter server.  This is QoS application, the router MAY send a
   Diameter base protocol function and it is defined Cost-
   Information AVP (see [RFC4006]) in [RFC3588].
   Session termination can be caused by the QAR.  If the Cost-Information
   AVP includes a QoS signaling messaging
   requesting deletion of Cost-Unit AVP (see [RFC4006]) then the existing QoS reservation state or it can Cost-Unit
   SHOULD be caused as "minute".  The Cost-Information AVPs represent the cost to
   allocate the resources requested in the QoS-Resources AVP included in
   the same QAR message.  The QAR MAY optionally contain a result of Tariff-Time-
   Change AVP (see [RFC4006]) which is the time at which the cost will
   change, a soft-state expiration second Cost-Information AVP, which is the cost of the QoS
   reservation state.  After
   reserved resources after the tariff time change, and a successful termination of second Tariff-
   Time-Change, which is the
   authorization session, final accounting messages time at which the tariff would change
   again.  Either all three or none of these AVPs MUST be exchanged
   (see Figure 10).  It should be noted that present in the two sessions
   (authorization and accounting) have independent management by
   QAR.

   The Resource Authorizing Entity returns a CC-Time AVP (see [RFC4006])
   in the
   Diameter base protocol, QAA message which allows is the total authorized gate-on time for finalizing the accounting
   session after
   service.  If the end of QAR included two Tariff-Time-Change AVPs, the authorization session.
   current time plus the CC-Time AVP returned in the QAA MUST NOT exceed
   the second Tariff-Time-Change AVP from the QAR.  Based on information
   in the Cost-Information AVPs, the Resource Authorizing
     End-Host         Network Element Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       |==Data Flow==>X /Stop can use
   the CC-Time AVP to guarantee that the total cost of the data flow/      |
       |                   |                         |
       +---QoS-Reserve---->|                         |
       |  (Delete QoS      +- - - - - STR - - - - - >|
       |   reservation)    |                +--------+--------------+
       |                   |                | Remove authorization  |
       |<--QoS-Response----+                | session state         |
       |                   |                +--------+--------------+
                           |< - - - - STA - - - - - -+
                   +-------+--------+                |
                   |Delete QoS state|
                   |  Report final  |
                   | accounting data|                   QoS Responder
                   +-------+--------+                       Node
                           +----------QoS-Reserve-----....--->|
                           |         (Delete QoS              |
                           |          reservation)
                           |
                           +- - - - - ACR - - - - - >|
                           |(FINAL,QoS-Resources,Cost|
                           |CC-Time,Acc-Multisess-id)|
                           |                +--------+--------------+
                           |                | Report will
   not exceed a certain threshold, which allows, for successful |
                           |                |  end example, support of QoS session   |
                           |                +--------+--------------+
                           |< - - - - ACA - - - - - -+
                           |
                           |                            QoS Responder
                           |                                Node
                           |<---------QoS-Response----....----+
                           |                                  |

           Figure 10: Client-Side Initiated Session Termination

4.5.2.  Server-Side Initiated Session Termination

   At anytime during
   prepaid users.

   Each ACR message contains a session triplet of QoS-Resources AVP, Cost-
   Information AVP, and CC-Time AVP.  This represents the Authorizing Entity MAY send total time
   consumed at the given cost for the given resources.  Note that an Abort-
   Session-Request ACR
   message (ASR) to MUST be sent separately for each interval defined by the Network Element.  This is a
   Diameter base protocol function
   Tariff-Time-Change AVPs and it is defined in [RFC3588].
   Possible reasons for initiating the ASR message to expiration of the CC-Time returned in
   the QAA (see Figure 5).

   The Network Element are insufficient credits or starts an accounting session termination at the
   application layer.  The ASR by sending an
   Accounting-Request message results in termination of the
   authorized session, release (ACR) after successful QoS reservation and
   activation of the reserved resources at data flow (see Figure 2).  After every successful
   re-authorization procedure the Network
   Element and transmission of element MUST initiate an appropriate QoS signaling message
   indicating a notification to other Network Elements aware of the
   signaling session.  A final accounting message exchange MUST be
   triggered as a result of this ASR
   interim accounting message exchange (see Figure 11).

                                               Authorizing
     End-Host 5).  After successful
   session termination the Network Element             Entity
   requesting QoS      ( Diameter              ( Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       |=====================Data Flow==========================>
       |                   |
       |                   |< - - - - ASR - - - - - -+
       |                   |                         |
       |====Data Flow=====>X                         |  QoS Responder
       |                   |                         |      Node
       |<--QoS-Notify------+----------QoS-Reserve-----....--->|
       |                   |         (Delete QoS     |        |
                           |          reservation)   |
                   +-------+--------+                |
                   |Delete QoS state|                |
                   |  Report element MUST initiate a final  |                |
                   |
   exchange of accounting data|                |
                   +-------+--------+                |
                           +- - - - - ASA - - - - - >|
                           |                +--------+--------------+
                           |                | Remove authorization  |
                           |                |     session state     |
                           |                +--------+--------------+
                           +- - - - - ACR - - - - - >|
                           |(FINAL,QoS-Resources,Cost|
                           |CC-Time,Acc-Multisess-id)|
                           |                +--------+--------------+
                           |                | Report messages for successful |
                           |                |  end terminating of QoS session   |
                           |                +--------+--------------+
                           |< - - - - ACA - - - - - -+
                           |                            QoS Responder
                           |                                Node
                           |<---------QoS-Response----....----+
                           |                                  |

           Figure 11: Server-Side Initiated Session Termination

5.  Accounting

   The Diameter QoS application provides the accounting
   session and reporting final records for the usage of
   reserved the QoS resources.
   resources reserved (see Figure 7).

5.  Diameter QoS accounting has built-in support
   for online, duration based accounting.  This accounting is based on
   the notion that the Authorization Application Messages

   The Diameter QoS clients are in the best position to
   determine Application requires the cost definition of those resources.

   In the new mandatory
   AVPs and Command-codes (see Section 3 of [RFC3588]).  Four new
   Diameter QoS application, the router MAY send a Cost-
   Information AVP (see [RFC4006]) in the QAR.  If the Cost-Information
   AVP includes a Cost-Unit AVP (see [RFC4006]) then the Cost-Unit
   SHOULD messages are defined along with Command-Codes whose values
   MUST be "minute".  The Cost-Information AVPs represent the cost supported by all Diameter implementations that conform to
   allocate the resources requested in
   this specification.

   Command-Name                  Abbrev.        Code      Reference
   QoS-Authz-Request              QAR           [TBD]     Section 5.1
   QoS-Authz-Answer               QAA           [TBD]     Section 5.2
   QoS-Install-Request            QIR           [TBD]     Section 5.3
   QoS-Install-Answer             QIA           [TBD]     Section 5.4

   In addition, the QoS-Resources AVP included following Diameter Base protocol messages are used
   in the same QAR message.  The QAR Diameter QoS application:

   Command-Name                  Abbrev.        Code      Reference
   Accounting-Request             ACR            271       RFC 3588
   Accounting-Request             ACR            271       RFC 3588
   Accounting-Answer              ACA            271       RFC 3588
   Re-Auth-Request                RAR            258       RFC 3588
   Re-Auth-Answer                 RAA            258       RFC 3588
   Abort-Session-Request          ASR            274       RFC 3588
   Abort-Session-Answer           ASA            274       RFC 3588
   Session-Term-Request           STR            275       RFC 3588
   Session-Term-Answer            STA            275       RFC 3588

   Diameter nodes conforming to this specification MAY optionally contain a Tariff-Time-
   Change AVP (see [RFC4006]) which is advertise support
   by including the time at which value of TBD in the cost will
   change, a second Cost-Information AVP, which is Auth-Application-Id or the cost Acct-
   Application-Id AVP of the
   reserved resources after the tariff time change, Capabilities-Exchange-Request and a second Tariff-
   Time-Change, which is the time at which
   Capabilities-Exchange-Answer commands, see [RFC3588].

   The value of TBD MUST be used as the tariff would change
   again.  Either Application-Id in all three or none QAR/QAA
   and QIR/QIA commands.

   The value of these AVPs TBD MUST be present in used as the
   QAR.

   The Resource Authorizing Entity returns a CC-Time AVP (see [RFC4006]) Application-Id in the QAA message which is the total authorized gate-on time all ACR/ACA
   commands, because this application defines new, mandatory AVPs for
   accounting.

   The value of zero (0) SHOULD be used as the
   service.  If the QAR included two Tariff-Time-Change AVPs, the
   current time plus the CC-Time AVP returned Application-Id in the QAA MUST NOT exceed
   the second Tariff-Time-Change AVP from the QAR.  Based on information all
   STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are
   defined in the Cost-Information AVPs, the Resource Authorizing Entity can use
   the CC-Time AVP to guarantee that the total cost of the session will
   not exceed a certain threshold, which allows, Diameter base protocol and no additional mandatory
   AVPs for example, support of
   prepaid users.

   Each ACR those commands are defined in this document.

5.1.  QoS-Authorization Request (QAR)

   The QoS-Authorization-Request message contains a triplet (QAR) indicated by the Command-
   Code field (see Section 3 of QoS-Resources AVP, Cost-
   Information AVP, [RFC3588]) set to TBD and CC-Time AVP.  This represents the total time
   consumed at 'R' bit set in
   the given cost Command Flags field is used by Network elements to request
   quality of service related resource authorization for the a given resources.  Note that an ACR flow.

   The QAR message MUST be sent separately carry information for each interval defined by signaling session
   identification, Authorizing Entity identification, information about
   the
   Tariff-Time-Change AVPs requested QoS, and the expiration identity of the CC-Time returned in QoS requesting entity.  In
   addition, depending on the QAA (see Figure 8).

   The Network Element starts an accounting session by sending deployment scenario, an
   Accounting-Request message (ACR) after successful QoS reservation authorization
   token and
   activation credentials of the data flow (see Figure 7).  After every successful
   re-authorization procedure QoS requesting entity SHOULD be
   included.

   The message format, presented in ABNF form [RFC2234], is defined as
   follows:

    <QoS-Request> ::= < Diameter Header: XXX, REQ, PXY >
                         < Session-Id >
                         { Auth-Application-Id }
                         { Origin-Host }
                         { Origin-Realm }
                         { Destination-Realm }
                         { Auth-Request-Type }
                         [ Destination-Host ]
                         [ User-Name ]
                      *  [ QoS-Resources ]
                         [ QoS-Authz-Data ]
                         [ Cost-Information ]
                         [ Acc-Multisession-Id ]
                         [ Bound-Auth-Session-Id ]
                      *  [ AVP ]

5.2.  QoS-Authorization Answer (QAA)

   The QoS-Authorization-Answer message (QAA), indicated by the Network element MUST initiate an
   interim accounting 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 exchange (see Figure 8).  After successful
   session termination (QAR).
   If the Network element MUST initiate a final
   exchange of accounting messages for terminating of QoS authorization request is successfully authorized, the accounting
   session and reporting final records for
   response will include the usage AVPs to allow authorization of the QoS
   resources reserved (see Figure 10).

6.  Diameter QoS Authorization Application Messages as well as accounting and transport plane gating
   information.

   The message format is defined as follows:

    <QoS-Answer> ::= < Diameter QoS Application requires Header: XXX, PXY >
                     < Session-Id >
                     { Auth-Application-Id }
                     { Auth-Request-Type }
                     { Result-Code }
                     { Origin-Host }
                     { Origin-Realm }
                  *  [ QoS-Resources ]
                     [ CC-Time ]
                     [ Acc-Multisession-Id ]
                     [ Session-Timeout ]
                     [ Authz-Session-Lifetime ]
                     [ Authz-Grace-Period ]
                  *  [ AVP ]

5.3.  QoS-Install Request (QIR)

   The QoS-Install Request message (QIR), indicated by the definition of new mandatory
   AVPs Command-Code
   field set to TDB and Command-codes (see Section 3 of [RFC3588]).  Four new
   Diameter messages are defined along with Command-Codes whose values
   MUST be supported by all Diameter implementations that conform to
   this specification.

   Command-Name                  Abbrev.        Code      Reference
   QoS-Authz-Request              QAR           [TBD]     Section 6.1
   QoS-Authz-Answer               QAA           [TBD]     Section 6.2
   QoS-Install-Request            QIR           [TBD]     Section 6.3
   QoS-Install-Answer             QIA           [TBD]     Section 6.4

   In addition, 'R' bit set in the following Diameter Base protocol messages are Command Flags field is used
   in
   by Authorizing entity to install or update the Diameter QoS application:

   Command-Name                  Abbrev.        Code      Reference
   Accounting-Request             ACR            271       RFC 3588
   Accounting-Request             ACR            271       RFC 3588
   Accounting-Answer              ACA            271       RFC 3588
   Re-Auth-Request                RAR            258       RFC 3588
   Re-Auth-Answer                 RAA            258       RFC 3588
   Abort-Session-Request          ASR            274       RFC 3588
   Abort-Session-Answer           ASA            274       RFC 3588
   Session-Term-Request           STR            275       RFC 3588
   Session-Term-Answer            STA            275       RFC 3588

   Diameter nodes conforming to this specification MAY advertise support
   by including parameters and the value
   flow state of TBD in an authorized flow at the Auth-Application-Id transport plane element.

   The message MUST carry information for signaling session
   identification or the Acct-
   Application-Id AVP identification of the Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer commands, see [RFC3588].

   The value flow to which the provided
   QoS rules apply, identity of TBD MUST be used as the Application-Id in all QAR/QAA transport plane element, description
   of provided QoS parameters, flow state and QIR/QIA commands.

   The value duration of TBD MUST be used as the Application-Id in all ACR/ACA
   commands, because this application defines new, mandatory AVPs for
   accounting. provided
   authorization.

   The value of zero (0) SHOULD be used as the Application-Id in all
   STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are message format is defined in the Diameter base protocol and no additional mandatory
   AVPs for those commands are defined in this document.

6.1.  QoS-Authorization Request (QAR)

   The QoS-Authorization-Request message (QAR) indicated by the Command-
   Code field (see Section 3 of [RFC3588]) set to TBD and 'R' bit set in
   the Command Flags field is used by Network elements to request
   quality of service related resource authorization for a given flow.

   The QAR message MUST carry information for signaling session
   identification, Authorizing Entity identification, information about
   the requested QoS, and the identity of the QoS requesting entity.  In
   addition, depending on the deployment scenario, an authorization
   token and credentials of the QoS requesting entity SHOULD be
   included.

   The message format, presented in ABNF form [RFC2234], is defined as
   follows:

    <QoS-Request> ::= < as follows:

    <QoS-Install-Request> ::= < Diameter Header: XXX, REQ, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Origin-Host }
                              { Origin-Realm }
                              { Destination-Realm }
                              { Auth-Request-Type }
                              [ Destination-Host ]
                         [ User-Name ]
                           *  [ QoS-Resources ]
                              [ QoS-Authz-Data Session-Timeout ]
                              [ Cost-Information Authz-Session-Lifetime ]
                              [ Acc-Multisession-Id Authz-Grace-Period ]
                              [ Bound-Auth-Session-Id Authz-Session-Volume ]
                           *  [ AVP ]

6.2.  QoS-Authorization

5.4.  QoS-Install Answer (QAA) (QIA)

   The QoS-Authorization-Answer QoS-Install Answer message (QAA), (QIA), indicated by the Command-
   Code Command-Code
   field set to TBD and 'R' bit cleared in the Command Flags field is
   sent in response to the QoS-Authorization-Request QoS-Install Request message (QAR).
   If the QoS authorization request is successfully authorized, (QIR) for
   confirmation of the
   response will include result of the AVPs to allow authorization installation of the provided QoS
   resources as well as accounting and transport plane gating
   information.
   reservation instructions.

   The message format is defined as follows:

    <QoS-Answer>

     <QoS-Install-Answer> ::= < Diameter Header: XXX, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Auth-Request-Type }
                     { Result-Code }
                     { Origin-Host }
                              { Origin-Realm }
                              { Result-Code }
                           *  [ QoS-Resources ]
                     [ CC-Time ]
                     [ Acc-Multisession-Id ]
                     [ Session-Timeout ]
                     [ Authz-Session-Lifetime ]
                     [ Authz-Grace-Period ]
                           *  [ AVP ]

6.3.  QoS-Install Request (QIR)

5.5.  Re-Auth-Request (RAR)

   The QoS-Install Request Re-Auth-Request message (QIR), (RAR), indicated by the Command-Code
   field set to TDB 258 and the 'R' bit set in the Command Flags field field, is used
   sent by the Authorizing entity Entity to install or update the Network Element in order to
   initiate the QoS parameters and re-authorization from DQA server side.

   If the
   flow state of an authorized flow at RAR command is received by the transport plane element.

   The message MUST carry information for signaling session
   identification or identification Network Element without any
   parameters of the flow to which the provided re-authorized QoS rules apply, identity of state, the transport plane element, description
   of provided Network Element MUST
   initiate a QoS parameters, flow state and duration of re-authorization by sending a QoS-Authorization-
   Request (QAR) message towards the provided
   authorization. Authorizing entity.

   The message format is defined as follows:

    <QoS-Install-Request>

    <Re-Auth-Request> ::= < Diameter Header: XXX, 258, REQ, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Origin-Host }
                              { Origin-Realm }
                              { Destination-Realm }
                              { Auth-Request-Type }
                              [ Destination-Host ]
                           *  [ QoS-Resources ]
                              [ Session-Timeout ]
                              [ Authz-Session-Lifetime ]
                              [ Authz-Grace-Period ]
                              [ Authz-Session-Volume ]
                           *  [ AVP ]

6.4.  QoS-Install Answer (QIA)

5.6.  Re-Auth-Answer (RAA)

   The QoS-Install Answer Re-Auth-Answer message (QIA), (RAA), indicated by the Command-Code field
   set to TBD 258 and the 'R' bit cleared in the Command Flags field field, is
   sent by the Network Element to the Authorizing Entity in response to
   the QoS-Install Request message (QIR) for
   confirmation of the result of the installation of the provided QoS
   reservation instructions. RAR command..

   The message format is defined as follows:

     <QoS-Install-Answer>

     <Re-Auth-Answer> ::= < Diameter Header: XXX, 258, PXY >
                              < Session-Id >
                              { Auth-Application-Id }
                              { Origin-Host }
                              { Origin-Realm }
                              { Result-Code }
                           *  [ QoS-Resources ]
                           *  [ AVP ]

6.5.

5.7.  Accounting Request (ACR)

   The Accounting Request message (ACR), indicated by the Command-Code
   field set to 271 and 'R' bit set in the Command Flags field is used
   by Network Element to report parameters of the authorized and
   established QoS reservation.

   The message MUST carry accounting information authorized QoS
   resources and its usage, e.g., QoS-Resources, CC-Time, CC-Cost, Acc-
   Multi-Session-Id.

   The message format is defined as follows:

     <Accounting-Request> ::= < Diameter Header: XXX, REQ, PXY >
                              < Session-Id >
                              { Acct-Application-Id }
                              { Destination-Realm }
                              [ Destination-Host ]
                              [ Accounting-Record-Type ]
                              [ Accounting-Record-Number ]
                            * [ QoS-Resources ]
                              [ Cost-Information ]
                              [ CC-Time ]
                              [ Acc-Multi-Session-Id ]
                            * [ AVP ]

6.6.

5.8.  Accounting Answer (ACA)

   The Accounting Answer message (ACA), indicated by the Command-Code
   field set to 271 and 'R' bit cleared in the Command Flags field is
   sent in response to the Accounting Request message (ACR) as an
   acknowledgment of the ACR message and MAY carry additional management
   information for the accounting session, e.g.  Acc-Interim-Interval
   AVP.

   The message format is defined as follows:

      <Accounting-Answer> ::= < Diameter Header: XXX, PXY >
                              < Session-Id >
                              { Acct-Application-Id }
                              [ Result-Code ]
                              [ Accounting-Record-Type ]
                              [ Accounting-Record-Number ]
                              [ Acc-Multi-Session-Id ]
                            * [ AVP ]

7.

6.  Diameter QoS Authorization Application AVPs

   Each of the AVPs identified in the QoS-Authorization-Request/Answer
   and QoS-Install-Request/Answer messages and the assignment of their
   value(s) is given in this section.

7.1.

6.1.  Diameter Base Protocol AVPs

   The Diameter QoS application uses a number of session management
   AVPs, defined in the Base Protocol ([RFC3588]).

   Attribute Name                AVP Code     Reference [RFC3588]
   Origin-Host                   264             Section 6.3
   Origin-Realm                  296             Section 6.4
   Destination-Host              293             Section 6.5
   Destination-Realm             283             Section 6.6
   Auth-Application-Id           258             Section 6.8
   Result-Code                   268             Section 7.1
   Auth-Request-Type             274             Section 8.7
   Session-Id                    263             Section 8.8
   Authz-Lifetime                291             Section 8.9
   Authz-Grace-Period            276             Section 8.10
   Session-Timeout                27             Section 8.13
   User-Name                       1             Section 8.14

   The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to
   Diameter applications.  The value of the Auth-Application-Id for the
   Diameter QoS application is TBD.

7.2.

6.2.  Credit Control Application AVPs

   The Diameter QoS application provides accounting for usage of
   reserved QoS resources.  Diameter QoS accounting has built-in support
   for online, duration based accounting.  For this purpose it re-uses a
   number of AVPs defined in Diameter Credit Control application.
   [RFC4006].

   Attribute Name                AVP Code     Reference [RFC4006]
   Cost-Information AVP          423             Section 8.7
   Unit-Value AVP                445             Section 8.8
   Currency-Code AVP             425             Section 8.11
   Cost-Unit AVP                 424             Section 8.12
   CC-Time AVP                   420             Section 8.21
   Tariff-Time-Change AVP        451             Section 6.20

   Usage of the listed AVPs is described in Section 5 4
   Diameter QoS application is designed to independently provide credit
   control over the controlled QoS resources.  However, deployment
   scenarios, where Diameter QoS application is collocated with Diameter
   Credit Control application, are not excluded.  In such scenarios the
   credit control over the QoS resources might be managed by the Credit
   control application.  Possible interworking approach might be a usage
   of Credit-Control AVP (AVP Code 426) with a newly defined value.  It
   will indicate to the Diameter QoS entities that the credit control
   over the QoS resources would be handled in separate session by Credit
   Control application.  An active cooperation of both applications
   would be required but it is not elaborated further in this document.

7.3.

6.3.  Accounting AVPs

   The Diameter QoS application uses Diameter Accounting and accounting
   AVPs as defined in Section 9 of [RFC3588].  Additional description of
   the usage of some usage of some of them in the QoS authorization context is
   provided:

   Attribute Name                AVP Code     Reference [RFC3588]
   Acct-Application-Id           259             Section 6.9
   Accounting-Record-Type        480             Section 9.8.1
   Accounting-Interim-Interval    85             Section 9.8.2
   Accounting-Record-Number      485             Section 9.8.3
   Accounting-Realtime-Required  483             Section 9.8.7
   Acc-Multi-Session-ID           50             Section 9.8.5

   The following AVPs need further explanation:

   Acct-Application-Id AVP

      The Acct-Application-Id AVP (AVP Code 259)is assigned by IANA to
      Diameter applications.  The value of the Acct-Application-Id for
      the Diameter QoS application is TBD (TBD).

   Acc-Multisession-ID

      Acc-Multi-Session-ID AVP (AVP Code 50) SHOULD be used to link
      multiple accounting sessions together, allowing the correlation of
      accounting information.  This AVP MAY be returned by the Diameter
      server in a QoS-Authorization-Answer message (QAA), and MUST be
      used in all accounting messages for the given session.

6.4.  Diameter QoS Application Defined AVPs

   This document reuses the AVPs defined in Section 4 of
   [I-D.ietf-dime-qos-attributes].

   This section lists the AVPs that are introduced specifically for the
   Diameter QoS application.  The followig new AVPs are defined: Bound-
   Auth-Session-Id and the QoS-Authz-Data AVP.

   The following table describes the Diameter AVPs newly defined in this
   document for usage with the QoS Application, their AVP code values,
   types, possible flag values, and whether the AVP may be encrypted.

                                                  +-------------------+
                                                  |    AVP Flag rules |
   +----------------------------------------------|----+---+----+-----+
   |                       AVP  Section           |    |   |SHLD| MUST|
   | Attribute Name        Code Defined Data Type |MUST|MAY| NOT|  NOT|
   +----------------------------------------------+----+---+----+-----+
   |QoS-Authz-Data         TBD    6.4  Grouped    | M  | P |    |  V  |
   |Bound-Auth-Session-Id  TBD    6.4  UTF8String | M  | P |    |  V  |
   +----------------------------------------------+----+---+----+-----+
   |M - Mandatory bit. An AVP with "M" bit set and its value MUST be  |
   |    supported and recognized by a Diameter entity in order the    |
   |    message, which carries this AVP, to be accepted.              |
   |P - Indicates the need for encryption for end-to-end security.    |
   |V - Vendor specific bit that indicates whether the AVP belongs to |
   |    a address space.                                              |
   +------------------------------------------------------------------+

   QoS-Authz-Data

      The QoS-Authz-Data AVP (AVP Code TBD) is of type OctetString.  It
      is a container that carries application session or user specific
      data that has to be supplied to the Authorizing entity as input to
      the computation of the authorization decision.

   Bound-Authentication-Session-Id

      The Bound-Authentication-Session AVP (AVP Code TBD) is of type
      UTF8String.  It carries the id of the Diameter authentication
      session that is used for the network access authentication (NASREQ
      authentication session).  It is used to tie the QoS authorization
      request to a prior authentication of the end host done by a co-
      located application for network access authentication (Diameter
      NASREQ) at the QoS NE.

7.  Examples

7.1.  Example call flow for pull mode

   This section presents an example of the interaction between the end
   host and Diameter QoS application entities using Pull mode.  The
   application layer signaling is, in this example, provided using SIP.
   Signaling for a QoS resource reservation is done using the QoS NSLP.
   The authorization of the QoS reservation request is done by the
   Diameter QoS application (DQA).

     End-Host                                 SIP Server  Correspondent
   requesting QoS                            (DQA Server)        Node

         |                                          |              |
       ..|....Application layer SIP signaling.......|..............|..
       . |  Invite (SDP)                            |              | .
       . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->              | .
       . |  100 Trying                              |              | .
       . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+  Invite (SDP)| .
       . |                                          +-.-.-.....-.-.> .
       . |                                          |  180 SDP'    | .
       . |                                          <-.-.-.....-.-.+ .
       . |                                 +--------+--------+     | .
       . |                                 |Authorize session|     | .
       . |                                 |   parameters    |     | .
       . | 180 (Session parameters)        +--------+--------+     | .
       . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+              | .
       ..|..........................................|... ..........|..
         |                                          |              |
         |           +------------+                 |              |
         |           |     NE     |                 |              |
         |           |(DQA Client)|                 |              |
         |           +------+-----+                 |              |
         |                  |                       |              |
         |QoS NSLP Reserve  |                       |              |
         +------------------> QAR                   |              |
         | (POLICY_DATA>v   +- - - - -<<AAA>>- - - ->              |
         |  QSPEC)  v   >===>(Destination-Host,     |              |
         |      v   >=======>QoS-Authz-Data        ++------------+ |
         |      >===========>QoS-Resources,        |Authorize    | |
         |                  |Cost-Info)            |QoS resources| |
         |                  |                      ++------------+ |
         |                  | QAA                   |              |
         |                  <- - - - -<<AAA>>- - - -+              |
         |                  |(Result-Code,          |              |
         |                  |QoS-Resources,         |              |
         |                  |CC-Time,               |              |
         |                  |Authz-Lifetime)        |              |
         |        +---------+--------+              |              |
         |        |Install QoS state1|              |              |
         |        |+ Authz. session  |              |              |
         |        +---------+--------+              |              |
         |                  |QoS NSLP Reserve                      |
         |                  +---------------..............--------->
         |                  |                                      |
         |                  |                     QoS NSLP Response|
         |QoS NSLP Response <---------------..............---------+
         <------------------+                                      |
         |                  |                        QoS NSLP Query|
         |QoS NSLP Query    <---------------..............---------+
         <------------------+                                      |
         |QoS NSLP Reserve  |                                      |
         +------------------> QAR                   |              |
         |                  +- - - - -<<AAA>>- - - ->              |
         |                  |                   +---+---------+    |
         |                  |                   |Authorize    |    |
         |                  |                   |QoS resources|    |
         |                  | QAA               +---+---------+    |
         |                  <- - - - -<<AAA>>- - - -+              |
         |        +---------+--------+              |              |
         |        |Install QoS state2|                             |
         |        |+ Authz. session  |                             |
         |        +---------+--------+                             |
         |                  |  QoS NSLP Reserve                    |
         |                  +---------------..............--------->
         |                  |                     QoS NSLP Response|
         |QoS NSLP Response <---------------..............---------+
         <------------------+                                      |
         |                  |                                      |
         /------------------+--Data Flow---------------------------\
         \------------------+--------------------------------------/
         |                  |                                      |

         .-.-.-.-.  SIP signaling
         ---------  QoS NSLP signaling
         - - - - -  Diameter QoS Application messages
         =========  Mapping of objects between QoS and AAA protocol

             Figure 23: QoS Authorization Example - Pull Mode

   The communication starts with SIP signaling between the two end
   points and the SIP server for negotiation and authorization of them in the QoS authorization context is
   provided:

   Attribute Name                AVP Code     Reference [RFC3588]
   Acct-Application-Id           259             Section 6.9
   Accounting-Record-Type        480             Section 9.8.1
   Accounting-Interim-Interval    85             Section 9.8.2
   Accounting-Record-Number      485             Section 9.8.3
   Accounting-Realtime-Required  483             Section 9.8.7
   Acc-Multi-Session-ID           50             Section 9.8.5

   The following AVPs need further explanation:

   Acct-Application-Id AVP

      The Acct-Application-Id AVP (AVP Code 259)is assigned by IANA to
      Diameter applications.  The value
   requested service and its parameters (see Figure 23).  As a part of
   the Acct-Application-Id for process, the Diameter QoS application SIP server verifies whether the user at Host A is TBD (TBD).

   Acc-Multisession-ID

      Acc-Multi-Session-ID AVP (AVP Code 50) SHOULD be used
   authorized to link
      multiple accounting sessions together, allowing use the correlation of
      accounting information.  This AVP MAY requested service (and potentially the ability
   to be returned by charged for the Diameter
      server in service usage).  Negotiated session parameters
   are provided to the end host.

   Subsequently, Host A initiates a QoS-Authorization-Answer QoS signaling message (QAA), and MUST be
      used towards Host
   B. It sends a QoS NSLP Reserve message, in all accounting messages for which it includes
   description of the given session.

7.4.  Diameter required QoS Application Defined AVPs

   This document reuses (QSPEC object) and authorization data
   for negotiated service session (part of the AVPs defined in Section 4 POLICY_DATA object).
   Authorization data includes, as a minimum, the identity of
   [I-D.ietf-dime-qos-attributes].

   This section lists the AVPs that are used by this specifispecific to
   authorizing entity (e.g., the Diameter QoS application.

   Additionally, SIP server) and an identifier of the followig new AVPs
   application service session for which QoS resources are defined:
   Bound-Auth-Session-Id requested.

   A QoS NSLP Reserve message is intercepted and processed by the QoS-Authz-Data AVP first
   QoS aware Network Element.  The following table describes NE uses the Diameter AVPs newly defined in this
   document QoS application
   to request authorization for usage with the received QoS Application, their AVP code values,
   types, possible flag values, and whether reservation request.
   The identity of the AVP may be encrypted.

                                                  +-------------------+
                                                  |    AVP Flag rules |
   +----------------------------------------------|----+---+----+-----+
   |                       AVP  Section           |    |   |SHLD| MUST|
   | Attribute Name        Code Defined Data Type |MUST|MAY| NOT|  NOT|
   +----------------------------------------------+----+---+----+-----+
   |QoS-Authz-Data         TBD    7.4  Grouped    | M  | P |    |  V  |
   |Bound-Auth-Session-Id  TBD    7.4  UTF8String | M  | P |    |  V  |
   +----------------------------------------------+----+---+----+-----+
   |M - Mandatory bit. An AVP Authorizing Entity (in this case the SIP server
   that is co-located with "M" bit set and its value MUST be  |
   |    supported and recognized by a Diameter entity in order server) is put into the    |
   |    message, which carries this
   Destination-Host AVP, to be accepted.              |
   |P - Indicates the need for encryption for end-to-end security.    |
   |V - Vendor specific bit that indicates whether any additional session authorization data is
   encapsulated into the AVP belongs to |
   |    a address space.                                              |
   +------------------------------------------------------------------+

   QoS-Authz-Data

      The QoS-Authz-Data AVP (AVP Code TBD) is and the description of type OctetString.  It the
   QoS resources is included into QoS-Resources AVP.  In addition, the
   NE rates the requested QoS resources and announces the charging rate
   into the Cost-Information AVP.  These AVPs are included into a container that carries application session or user specific
      data that has QoS
   Authorization Request message, which is sent to the Authorizing
   entity.

   A Diameter QAR message will be supplied to routed through the Authorizing entity as input AAA network to the computation of the authorization decision.

   Bound-Authentication-Session-Id
   Authorizing Entity.  The Bound-Authentication-Session AVP (AVP Code TBD) is of type
      UTF8String.  It carries Authorizing Entity verifies the id of requested
   QoS against the Diameter authentication
      session that is used QoS resources negotiated for the network access authentication (NASREQ
      authentication session). service session and
   replies with QoS-Authorization answer (QAA) message.  It is used to tie carries the
   authorization result (Result-Code AVP) and the description of the
   authorized QoS parameters (QoS-Resources AVP), as well as duration of
   the authorization
      request to a prior authentication session (Authorization-Lifetime AVP) and duration
   of the end host done by a co-
      located application time (CC-Time) for network access authentication (Diameter
      NASREQ) at which the end-user should be charged with
   the rate announced in the QAR message.  The NE interacts with the
   traffic control function and installs the authorized QoS NE.

8.  Examples resources
   and forwards the QoS NSLP Reserve message further along the data
   path.

7.2.  Example call flow for push mode

   This section presents an example of the interaction between the
   application layer signaling end-
   host and the Diameter QoS signaling along the data
   path. application entities using Push Mode.  The
   application layer signaling is, in this example, provided using SIP.
   Signaling for a QoS resource reservation is done using the QoS NSLP.
   The authorization of the QoS reservation request is done by the
   Diameter QoS application (DQA).

    End-Host              NE                  SIP Server  Correspondent
  requesting QoS      (DQA Client)           (DQA Server)        Node

        |                  |                          |              |
      ..|....Application layer SIP signaling.......|..............|.. signaling..........|..............|..
      . |  Invite (SDP) Invite(SDP offer)|                          |              | .
      . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>              | .
      . |  100 Trying      |                          | .
       . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+  Invite (SDP)| .
       . |                                          +-.-.-.....-.-.> .
       . |                                          |  180 SDP'    | .
       . |                                          <-.-.-.....-.-.+ .
       . |                                 +--------+--------+              | .
      . |                                 |Authorize session| <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+              | .
      . |                                 |   parameters    |     | . |.............................................|..............| .
        | 180 (Session parameters)        +--------+--------+                  | .
       . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+                +---------+-------------+|
        | .
       ..|..........................................|... ..........|..                  |                |  Authorize request    ||
        |                  |           +------------+                |  Keep session data    ||
        |                  |                |/Authz-time,Session-Id/||
        |     NE                  |                +---------+-------------+|
        |                  |                          |           |(DQA Client)|              |
        |                  |<-- - -- - QIR - -- - -- -+              |           +------+-----+
        |                  |(Initial Request,Decision |              |
        |                  |(QoS-Resources,Authz-time)|              |
        |
         |QoS NSLP Reserve          +-------+---------+                |              |
        |
         +------------------> QAR          |Install QoS state|                |              |
        | (POLICY_DATA>v   +- - - - -<<AAA>>- - - ->          |       +         |  QSPEC)  v   >===>(Destination-Host,                |              |
        |      v   >=======>QoS-Authz-Data        ++------------+          | Authz. session  |      >===========>QoS-Resources,        |Authorize                |              |
        |                  |Cost-Info)            |QoS resources|          | /Authz-time,    |                |                      ++------------+              |
        |          | QAA  CC-Time,Cost/  |                |              |                  <-
        |          +-------+---------+                |              |
        |                  + - - -- - -<<AAA>>- QIA - - -+ - - - ->|              |
        |                  |(Result-Code,                  |     (Result-Code,        |              |                  |QoS-Resources,
        |                  |      QoS-Resources)      |                  |CC-Time,              |
        |                  |                  |Authz-Lifetime)               +----------+------------+ |
        |                  |        +---------+--------+               | Report for successful | |
        |                  |               |        |Install   QoS state1| reservation     | |
        |        |+ Authz. session                  |               |Update of reserved QoS | |
        |        +---------+--------+                  |               |      resources        |                  |QoS NSLP Reserve |
        |                  +---------------..............--------->                  |               +----------+------------+ |
      . |                  |                          |                     QoS NSLP Response|
         |QoS NSLP Response <---------------..............---------+
         <------------------+ Invite (SDP) | .
      . |                  |                        QoS NSLP Query|
         |QoS NSLP Query    <---------------..............---------+
         <------------------+                          +-.-.-.....-.-.> .
      . |
         |QoS NSLP Reserve 180 (Ringing)                               |              |
         +------------------> QAR .
      . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.<.-.-.-.-.-.-.-+ .
      . |                  |                          |                  +- - - - -<<AAA>>- - - ->  200 OK (SDP)| .
      . |                  |                          <-.-.-.....-.-.+ .
        |                   +---+---------+                  |                 +--------+-----------+  |
        |                   |Authorize                  |                 |re-Authorize session|  |
        |                  |                   |QoS resources|                 |   parameters       |  |
        | QAA               +---+---------+                  |                 +--------+-----------+  |
        |                  <- - - - -<<AAA>>- - - -+ RAR - - - - - +              |
        |        +---------+--------+                 |              |
        |        |Install        |Activate QoS state2|                             |
         |        |+ Authz. session state|                 |              |
        |        +---------+--------+                 |              |
        |  QoS NSLP Reserve                  +- - - - - - RAA - - - - - >              |
      . |                  +---------------..............---------> 200 (SDP answer) |                          |                     QoS NSLP Response|
         |QoS NSLP Response <---------------..............---------+
         <------------------+              | .
      . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+              | .
        |                  |                                         |
         /------------------+--Data
        /------------------+-----Data Flow---------------------------\
         \------------------+--------------------------------------/
        \------------------+-----------------------------------------/
        |                  |                                         |

        .-.-.-.-.  SIP signaling
         ---------  QoS NSLP signaling
        - - - - -  Diameter QoS Application messages
         =========  Mapping of objects between QoS and AAA protocol

             Figure 24: Token-based QoS Authorization Example - Push Mode

   The communication starts with SIP signaling between the two end
   points and the SIP server for negotiation and authorization of the
   requested service and its parameters (see Figure 24).  As a part of
   the process, the SIP server verifies whether the user at Host A is
   authorized to use the requested service (and potentially the ability
   to be charged for the service usage).  Negotiated session parameters
   are provided to the end host.

   Subsequently, Host A initiates a QoS signaling message towards Host
   B. It sends a QoS NSLP Reserve message, in which it includes
   description of the required QoS (QSPEC object) and authorization data
   for negotiated service session (part of the POLICY_DATA object).
   Authorization data includes, as a minimum, the identity of the
   authorizing entity (e.g., the SIP server) and an identifier of be charged for the
   application service session for which QoS resources are requested.

   A QoS NSLP Reserve message usage).  The DQA server is intercepted and processed by triggered to
   authorize the first QoS aware Network Element.  The NE uses the request based on session parameters (i.e.  SDP
   offer), initiate a Diameter QoS application
   to request authorization for the received session and install
   authorized QoS reservation request. state to the Network Element via QIR message.

   The identity DQA server may obtain the info of peer DQA client from pre-
   configured information or query the Authorizing Entity (in DNS based on Host A's identity or
   IP address (In this case the a DQA server is co-located with a SIP server
   that
   and a DQA client is co-located with a Diameter server) Network element).  The identity
   of Network Element is put into the Destination-Host AVP, any additional session authorization data is
   encapsulated into the QoS-Authz-Data AVP and the
   description of the QoS resources is included into QoS-Resources AVP.  In addition, the
   NE rates the requested QoS resources and announces the charging rate
   into the Cost-Information AVP.  These AVPs are included into a QoS
   Authorization Request message, which is sent to the Authorizing
   entity.

   A Diameter QAR message will be routed through the AAA network to the
   Authorizing Entity.  The Authorizing Entity verifies the requested
   QoS against the QoS resources negotiated for the service session and
   replies with QoS-Authorization answer (QAA) message.  It carries the
   authorization result (Result-Code AVP) and the description of the
   authorized QoS parameters (QoS-Resources AVP), AVP,
   as well as duration of the authorization session (Authorization-Lifetime (Authorization-
   Lifetime AVP) and duration of the time (CC-Time) for which the end-user end-
   user should be charged with the rate announced in the QAR QIR message.
   The NE interacts with the
   traffic control function and installs traffic control function and reserves the
   authorized QoS resources accordingly.

   With successful QoS authorization, the SDP offer in SIP Invite is
   forwared to Host B. Host B sends back a 18x (ringing) message towards
   Host A and processes the SDP.  Once Host B accepts the call, it sends
   back a 200 OK, in which it includes description of the accepted
   session parameters (i.e.  SDP answer).

   The DQA server may verifies the accepted QoS against the pre-
   authorized QoS resources resources, and forwards sends a Diameter RAR message to the DQA
   client in the network element for activating the installed policies
   and commit the resource allocation.  With successful QoS NSLP Reserve message further along enforcement,
   the data
   path. 200 OK is forwarded towards Host A.

   Note that the example examples above shows show a sender-initiated reservation from
   the End-Host towards the corresponding node and a receiver-initiated
   reservation from the correspondent node towards the End-Host.

9.

8.  IANA Considerations

   TBD

10.

9.  Security Considerations

   This document describes a mechanism for performing authorization of a
   QoS reservation at a third party entity.  Therefore, it is necessary
   that the QoS signaling application to carry sufficient information
   that should be forwarded to the backend AAA server.  This
   functionality is particularly useful in roaming environments where
   the authorization decision is most likely provided at an entity where
   the user can be authorized, such as in the home realm.

   QoS signaling application MAY re-use the authenticated identities
   used for the establishment of the secured transport channel for the
   signaling messages, e.g., TLS or IPsec between the end host and the
   policy aware QoS NE.  In addition, a collocation of the QoS NE with,
   for example, the Diameter NASREQ application (see [RFC4005]) may
   allow the QoS authorization to be based on the authenticated identity
   used during the network access authentication protocol run.  If a co-
   located deployment is not desired then special security protection is
   required to ensure that arbitrary nodes cannot reuse a previous
   authentication exchange to perform an authorization decision.

   Additionally, QoS authorization might be based on the usage of
   authorization tokens that are generated by the Authorizing Entity and
   provided to the end host via application layer signaling.

   The impact of the existence of different authorization models is
   (with respect to this Diameter QoS application) the ability to carry
   different authentication and authorization information.

11.

   TBD

10.  Acknowledgements

   The authors would like to thank John Loughney and Allison Mankin for
   their input to this document.  In September 2005 Robert Hancock,
   Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and
   Elwyn Davies provided a detailed review.  Robert also provided us
   with good feedback earlier in 2005.  Jerry Ash provided us review
   comments late 2005/early 2006.  Rajith R provided some inputs to the
   document early 2007

   [Editor's Note: Acknowledgements need to be updated.]

12.

11.  Contributors

   The authors would like to thank Tseno Tsenov (tseno.tsenov@gmail.com)
   and Frank Alfano (falfano@lucent.com) for starting the Diameter
   Quality of Service work within the IETF, for your significant draft
   contributions and for being the driving force for the first few draft
   versions.

   [Editor's Note: A bit of history needs to be included here.]

13.

12.  Open Issues

   Open issues related to this draft are listed at the issue tracker
   available at: http://www.tschofenig.com:8080/diameter-qos/

14.

13.  References

14.1.

13.1.  Normative References

   [I-D.ietf-dime-qos-attributes]
              Korhonen, J., Tschofenig, H., Arumaithurai, M., and M.
              Jones, "Quality of Service Attributes for Diameter
              and RADIUS", draft-ietf-dime-qos-attributes-00 Diameter",
              draft-ietf-dime-qos-attributes-03 (work in progress), July
              November 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

14.2.

13.2.  Informative References

   [I-D.ietf-nsis-ntlp]
              Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signalling Transport", draft-ietf-nsis-ntlp-13 draft-ietf-nsis-ntlp-14 (work in
              progress), April July 2007.

   [I-D.ietf-nsis-qos-nslp]
              Manner, J., "NSLP for Quality-of-Service Signaling",
              draft-ietf-nsis-qos-nslp-14
              draft-ietf-nsis-qos-nslp-15 (work in progress), June July 2007.

   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, September 1997.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC2749]  Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.,
              and A. Sastry, "COPS usage for RSVP", RFC 2749,
              January 2000.

   [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
              for Policy-based Admission Control", RFC 2753,
              January 2000.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3313]  Marshall, W., "Private Session Initiation Protocol (SIP)
              Extensions for Media Authorization", RFC 3313,
              January 2003.

   [RFC3520]  Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
              "Session Authorization Policy Element", RFC 3520,
              April 2003.

   [RFC3521]  Hamer, L-N., Gage, B., and H. Shieh, "Framework for
              Session Set-up with Media Authorization", RFC 3521,
              April 2003.

   [RFC4027]  Josefsson, S., "Domain Name System Media Types", RFC 4027,
              April 2005.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

Authors' Addresses

   Glen Zorn (editor)
   Cisco Systems
   2901 Third Avenue, Suite 600
   SEA1/5/
   Seattle, WA  98121
   USA

   Phone: +1 (425) 344 8113
   Email: gwz@cisco.com glenzorn@comcast.net

   Peter J. McCann
   Motorola Labs
   1301 E. Algonquin Rd
   Schaumburg, IL  60196
   USA

   Phone: +1 847 576 3440
   Email: pete.mccann@motorola.com

   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com

   Tina Tsou
   Huawei
   Shenzhen,
   P.R.C

   Email: tena@huawei.com

   Avri Doria
   Lulea University of Technology
   Arbetsvetenskap
   Lulea,   SE-97187
   Sweden

   Email: avri@ltu.se
   Dong Sun
   Bell Labs/Alcatel-Lucent
   101 Crawfords Corner Rd
   Holmdel, NJ  07733
   USA

   Email: dongsun@alcatel-lucent.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).