tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5866

 
 
 

Diameter Quality-of-Service Application

Part 2 of 3, p. 17 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
4.  QoS Application 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 application (DQA) client)

   o  Authorizing Entity (Diameter QoS application (DQA) server)

   Note that the QoS RRE is only indirectly involved in the message
   exchange.  This entity provides the trigger to initiate the Diameter
   QoS protocol interaction by transmitting QoS signaling messages.  The
   Diameter QoS application is only executed between the Network Element
   (i.e., DQA client) and the Authorizing Entity (i.e., DQA server).

Top      Up      ToC       Page 18 
   The QoS RRE may communicate with the AE using application-layer
   signaling for the negotiation of service parameters.  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 of this document.  The
   protocol communication between the QoS resource requesting entity and
   the QoS NE might be accomplished using the NSIS protocol suite, RSVP,
   or a link-layer signaling protocol.  A description of these protocols
   is also outside the scope of this document.

4.2.  Session Establishment

   Pull and Push modes use a different set of command codes for session
   establishment.  For other operations, such as session modification
   and termination, they use the same set of command codes.

   The selection of Pull mode or Push mode operation is based on the
   trigger of the QoS authorization session.  When a QoS-Authorization-
   Request (QAR, see Section 5.1) message with a new Session-Id is
   received, the AE operates in Pull mode; when other triggers are
   received, the AE operates in Push mode.  Similarly, when a QoS-
   Install-Request (QIR, see Section 5.3} with a new Session-Id is
   received, the NE operates in Push mode; when other triggers are
   received, the NE operates in Pull mode.

   The QoS authorization session is typically established per subscriber
   base (i.e., all requests with the same User-ID), but it is also
   possible to be established on a per node or per request base.  The
   concurrent sessions between an NE and an AE are identified by
   different Session-Ids.

4.2.1.  Session Establishment for Pull Mode

   A request for a QoS reservation or local events received by an NE can
   trigger the initiation of a Diameter QoS authorization session.  The
   NE converts the required objects from the QoS signaling message to
   Diameter AVPs and generates a QAR message.

   Figure 6 shows the protocol interaction between a Resource Requesting
   Entity, a Network Element, and the Authorizing Entity.

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

Top      Up      ToC       Page 19 
   +------------------------------------------+------------------------+
   | QoS-Specific Input Data                  | Diameter AVPs          |
   +------------------------------------------+------------------------+
   | Authorizing Entity ID (e.g.,             | Destination-Host       |
   | Destination-Host taken from              | Destination-Realm      |
   | authorization token, Destination-Realm,  |                        |
   | or derived from the Network Access       |                        |
   | Identifier (NAI) of the QoS requesting   |                        |
   | entity)                                  |                        |
   | Authorization Token Credentials of the   | QoS-Authorization-Data |
   | QoS requesting entity                    | User-Name              |
   | QoS-Resources (including QoS parameters) |                        |
   +------------------------------------------+------------------------+

           Table 1: Mapping Input Data to QoS AVPs -- Pull Mode

   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 QoS-Resources AVP is defined in [RFC5777].  The
   authorization decision is then reflected in the response returned to
   the Diameter client with the QoS-Authorization-Answer (QAA) message.

Top      Up      ToC       Page 20 
                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS       (Diameter               (Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       +---QoS-Reserve---->|                         |
       |                   +- - - - - QAR - - - - - >|
       |                   |(QoS-Resources,          |
       |                   |   QoS-Auth-Data,User-ID)|
       |                   |                +--------+--------------+
       |                   |                |  Authorize request    |
       |                   |                |  Keep session data    |
       |                   |                |/Authz-time,Session-Id/|
       |                   |                +--------+--------------+
       |                   |< - - - - QAA - - - - - -+
       |                   |(Result-Code,            |
       |                   |QoS-Resources,Authz-time)|
       |           +-------+---------+
       |           |Install QoS state|
       |           |       +         |
       |           | Authz  session  |
       |           | /Authz-time/    |                QoS Responder
       |           |                 |                    Node
       |           +-------+---------+                      |
       |                   +----------QoS-Reserve---....--->|
       |                   |                                |
       |                   |<---------QoS-Response--....----|
       |<--QoS-Response----+                                |
       |                   |                                |
       |=====================Data Flow==============....===>|

         Figure 6: Initial QoS Request Authorization for Pull Mode

   The Authorizing Entity keeps authorization session state and SHOULD
   save additional information for management of the session (e.g.,
   Signaling-Session-Id, authentication data) as part of the session
   state information.

   The final result of the authorization request is provided in the
   Result-Code AVP of the QAA message sent by the Authorizing Entity.
   In the case of successful authorization (i.e., Result-Code =
   DIAMETER_LIMITED_SUCCESS (see Section 7.1)), information about the
   authorized QoS resources and the status of the authorized flow
   (enabled/disabled) is provided in the QoS-Resources AVP of the QAA
   message.  The QoS information provided via the QAA is installed by
   the QoS Traffic Control function of the NE.  The value

Top      Up      ToC       Page 21 
   DIAMETER_LIMITED_SUCCESS indicates that the AE expects confirmation
   via another QAR message for successful QoS resource reservation and
   for final reserved QoS resources (see below).

   One important piece of information returned from the Authorizing
   Entity is the authorization lifetime (carried inside the QAA).  The
   authorization lifetime allows the NE 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 the currently available
   credits at the user's account (see Section 8).  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 are discussed in Sections 4.3, 4.4,
   and 8.

   The indication of a successful QoS reservation and activation of the
   data flow is provided by the transmission of a QAR message, which
   reports the parameters of the established QoS state: reserved
   resources, duration of the reservation, and identification of the QoS
   enabled flow/QoS signaling session.  The Diameter QoS server
   acknowledges the reserved QoS resources with the QA Answer (QAA)
   message where the Result-Code is set to 'DIAMETER_SUCCESS'.  Note
   that the reserved QoS resources reported in this QAR message MAY be
   different than those authorized with the initial QAA message, due to
   the QoS-signaling-specific behavior (e.g., receiver-initiated
   reservations with One-Path-With-Advertisements) or specific process
   of QoS negotiation along the data path.

4.2.2.  Session Establishment for Push Mode

   The Diameter QoS server in the AE initiates a Diameter QoS
   authorization session upon the request for a QoS reservation
   triggered by application-layer signaling or by local events, and
   generates a QoS-Install-Request (QIR) message to the Diameter QoS
   client in the NE in which it maps required objects to Diameter
   payload objects.

   Figure 7 shows the protocol interaction between the AE, a Network
   Element, and an RRE.

   The NE's identity, information about the application session and/or
   identity and credentials of the QoS resource requesting entity,
   requested QoS parameters, and signaling session identifier and/or QoS
   enabled data flows identifiers MAY be encapsulated into respective
   Diameter AVPs and included in the Diameter message sent from a
   Diameter QoS server in the Authorizing Entity to a Diameter QoS

Top      Up      ToC       Page 22 
   client in the NE.  This requires that the AE has knowledge of
   specific information for allocating and identifying the NE 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 4.2.3 for details.

   +-----------------------------------------+-------------------------+
   | QoS-Specific Input Data                 | Diameter AVPs           |
   +-----------------------------------------+-------------------------+
   | Network Element ID                      | Destination-Host        |
   |                                         | Destination-Realm       |
   | Authorization Token Credentials of the  | QoS-Authorization-Data  |
   | QoS requesting entity                   | User-Name               |
   | QoS-Resources (including QoS            |                         |
   | parameters)                             |                         |
   +-----------------------------------------+-------------------------+

           Table 2: Mapping Input Data to QoS AVPs -- Push Mode

   Authorization processing starts at the Diameter QoS server when it
   receives a request from an RRE through an AppS (e.g., SIP Invite) or
   is triggered by a local event (e.g., a 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 (QIR) message to the Diameter
   QoS client.

Top      Up      ToC       Page 23 
                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS       (Diameter               (Diameter
                        QoS Client)             QoS Server)
       |                   |                          |
       |                   |                          |<-- Trigger --
       |                   |                 +--------+--------------+
       |                   |                 |  Authorize request    |
       |                   |                 |  Keep session data    |
       |                   |                 |/Authz-time,Session-Id/|
       |                   |                 +--------+--------------+
       |                   |                          |
       |                   |<-- - -- - QIR - - - - - -+
       |                   |(Initial Request,Decision |
       |                   |(QoS-Resources,Authz-time)|
       |           +-------+---------+
       |           |Install QoS state|
       |           |       +         |
       |           | Authz  session  |
       |           | /Authz-time/    |
       |           |                 |
       |           +-------+---------+
       |                   + - - - - QIA - - - - - ->|
       |                   |    (Result-Code,        |
       |                   |     QoS-Resources)      |
       |                   |                +--------+--------------+
       |                   |                | Report for successful |
       |                   |                |   QoS reservation     |
       |                   |                |Update of reserved QoS |
       |                   |                |      resources        |
       |                   |                +--------+--------------+
       |                   |                         QoS Responder
       |                   |                               Node
       |                   |                                |
       |=====================Data Flow==============....===>|

         Figure 7: Initial QoS Request Authorization for Push Mode

   The AE keeps authorization session state and SHOULD save additional
   information for management of the session (e.g.,
   Signaling-Session-Id, authentication data) as part of the session
   state information.

   The final result of the authorization decision is provided in the
   QoS-Resources AVP of the QIR message sent by the AE.  The QoS
   information provided via the QIR is installed by the QoS Traffic
   Control function of the NE.

Top      Up      ToC       Page 24 
   One important piece of information from the AE is the authorization
   lifetime (carried inside the QIR).  The authorization lifetime allows
   the NE 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 the currently available credits at the user's account (see
   Section 8).  The authorization duration is time-based as specified in
   [RFC3588].  For an extension of the authorization period, a new QoS-
   Install-Request/Answer message or QoS-Authorization-Request/Answer
   message exchange SHOULD be initiated.  Further aspects of QoS
   authorization session maintenance are discussed in Sections 4.3, 4.4,
   and 8.

   The indication of QoS reservation and activation of the data flow can
   be provided by the QoS-Install-Answer message immediately.  In the
   case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS,
   (see Section 7.1)) information is provided in the QIA message.  Note
   that the reserved QoS resources reported in the QIA message may be
   different than those initially authorized with the QIR message, due
   to the QoS signaling-specific behavior (e.g., receiver-initiated
   reservations with One-Path-With-Advertisements) or specific process
   of QoS negotiation along the data path.  In the case that Multiple
   AEs control the same NE, the NE should make the selection on the
   authorization decision to be enforced based on the priority of the
   request.

4.2.3.  Discovery and Selection of Peer Diameter QoS Application Node

   The Diameter QoS application node may obtain information of its peer
   nodes (e.g., Fully-Qualified Domain Name (FQDN), IP address) through
   static configuration or dynamic discovery as described in Section 5.2
   of [RFC3588].  In particular, the NE shall perform the relevant
   operation for Pull mode; the AE shall perform the relevant operations
   for Push mode.

   Upon receipt of a trigger to initiate a new Diameter QoS
   authorization session, the Diameter QoS application node selects and
   retrieves the location information of the peer node that is
   associated with the affected user based on some index information
   provided by the RRE.  For instance, it can be the Authorization
   Entity's ID stored in the authorization token, the end-user identity
   (e.g., NAI [RFC4282]), or a globally routable IP address.

4.3.  Session Re-Authorization

   Client- and server-side initiated re-authorizations are considered in
   the design of the Diameter QoS application.  Whether the
   re-authorization events are transparent for the resource requesting

Top      Up      ToC       Page 25 
   entity or result in specific actions in the QoS signaling protocol is
   outside the scope of the Diameter QoS application.  It is directly
   dependent on the capabilities of the QoS signaling protocol.

   There are a number of options for policy rules according to which the
   NE (AAA client) contacts the AE for re-authorization.  These rules
   depend on the semantics and contents of the QAA message sent by the
   AE:

   a.  The QAA message contains the authorized parameters of the flow
       and its QoS and sets their limits (presumably upper).  With these
       parameters, the AE specifies the services that the NE can provide
       and for which it will be financially compensated.  Therefore, any
       change or request for change of the parameters of the flow and
       its QoS that do not conform to the authorized limits requires
       contacting the AE for authorization.

   b.  The QAA message contains authorized parameters of 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 the domains of the NE and
       the AE.

   c.  The QAA message contains the authorized parameters of the flow
       and its QoS.  Any change or request for change of these
       parameters requires contacting the AE 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 a change or a 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.

   In addition, the AE may use an RAR (Re-Authorization-Request) to
   perform re-authorization with the authorized parameters directly when
   the re-authorization is triggered by service request or local events/
   policy rules.

4.3.1.  Client-Side Initiated Re-Authorization

   The AE provides the duration of the authorization session as part of
   the QoS-Authorization-Answer (QAA) message.  At any time before the
   expiration of this period, a new QoS-Authorization-Request (QAR)
   message MAY be sent to the AE.  The transmission of the QAR MAY be
   triggered when the NE receives a QoS signaling message that requires

Top      Up      ToC       Page 26 
   modification of the authorized parameters of an ongoing QoS session,
   or authorization lifetime expires.

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS       (Diameter               (Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       |=====================Data Flow==========================>
       |                   |                         |
       |           +-------+----------+              |
       |           |Authz-time/CC-Time|              |
       |           |    expires       |              |
       |           +-------+----------+              |
       |                   +- - - - - QAR - - - - - >|
       |                   |(QoS-Resources,          |
       |                   | QoS-Authorization-Data,User-ID) |
                           |                +--------+--------------+
    NOTE:                  |                |  Authorize request    |
    Re-authorization       |                | Update session data   |
    is transparent to      |                |/Authz-time,Session-Id/|
    the End-Host           |                +--------+--------------+
                           |< - - - - QAA - - - - - -+
       |                   |(Result-Code,            |
       |                   |QoS-Resources,Authz-time)|
       |           +-------+---------+               |
       |           |Update QoS state |               |
       |           |       +         |               |
       |           | Authz  session  |               |
       |           | /Authz-time/    |               |
       |           |                 |               |
       |           +-------+---------+               |
       |                   |                         |
       |=====================Data Flow==========================>
       |                   |

           Figure 8: Client-side Initiated QoS Re-Authorization

4.3.2.  Server-Side Initiated Re-Authorization

   The AE MAY initiate a QoS re-authorization by issuing a
   Re-Authorization-Request (RAR) message as defined in the Diameter
   base protocol [RFC3588], which may include the parameters of the
   re-authorized QoS state: reserved resources, duration of the
   reservation, identification of the QoS-enabled flow/QoS signaling
   session for re-installation of the resource state by the QoS Traffic
   Control function of the NE.

Top      Up      ToC       Page 27 
   An NE that receives such an RAR message with Session-Id matching a
   currently active QoS session acknowledges the request by sending the
   Re-Auth-Answer (RAA) message towards the AE.

   If the RAR does not include any parameters of the re-authorized QoS
   state, the NE MUST initiate a QoS re-authorization by sending a
   QoS-Authorization-Request (QAR) message towards the AE.

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS       (Diameter               (Diameter
                        QoS Client)             QoS 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/    |
       |           |                 |
       |           +-------+---------+
       |                   + - - - - RAA - - - - - ->|
       |                   |    (Result-Code,        |
       |                   |     QoS-Resources)      |
       |                   |                +--------+--------------+
       |                   |                | Report for successful |
       |                   |                |   QoS reservation     |
       |                   |                |Update of reserved QoS |
       |                   |                |      resources        |
       |                   |                +--------+--------------+
       |                   |                         |

           Figure 9: Server-Side Initiated QoS Re-Authorization

Top      Up      ToC       Page 28 
4.4.  Session Termination

4.4.1.  Client-Side Initiated Session Termination

   The authorization session for an installed QoS reservation state MAY
   be terminated by the Diameter client by sending a Session-
   Termination-Request (STR) message to the Diameter server with a
   response Session-Termination-Acknowledgement (STA) message.  This is
   a Diameter base protocol function and it is defined in [RFC3588].
   Session termination can be caused by a QoS signaling message
   requesting deletion of the existing QoS reservation state, or it can
   be caused as a result of a soft-state expiration of the QoS
   reservation state.

                                               Authorizing
     End-Host         Network Element             Entity
   requesting QoS       (Diameter               (Diameter
                        QoS Client)             QoS Server)
       |                   |                         |
       |==Data Flow==>X /Stop of the data flow/      |
       |                   |                         |
       +---QoS-Reserve---->|                         |
       |  (Delete QoS      +- - - - - STR - - - - - >|
       |   reservation)    |                +--------+--------------+
       |                   |                | Remove authorization  |
       |                   |                | session state         |
       |                   |                +--------+--------------+
       |                   |< - - - - STA - - - - - -+
       |           +-------+--------+                |
       |           |Delete QoS state|
       |           +-------+--------+                   QoS Responder
       |                   |                                Node
       |                   +----------QoS-Reserve-----....--->|
       |                   |         (Delete QoS              |
       |                   |          reservation)            |
       |                   |<---------QoS-Response----....----+
       |<--QoS-Response----+                                  |

           Figure 10: Client-Side Initiated Session Termination

4.4.2.  Server-Side Initiated Session Termination

   At any time during a session, the AE MAY send an Abort-Session-
   Request (ASR) message to the NE.  This is a Diameter base protocol
   function and it is defined in [RFC3588].  Possible reasons for
   initiating the ASR message to the NE are insufficient credits or
   session termination at the application layer.  The ASR message
   results in termination of the authorized session, release of the

Top      Up      ToC       Page 29 
   reserved resources at the NE, and transmission of an appropriate QoS
   signaling message indicating a notification to other Network Elements
   aware of the signaling session.

                                               Authorizing
     End-Host         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|                |
                   +-------+--------+                |
                           +- - - - - ASA - - - - - >|
                           |                +--------+--------------+
                           |                | Remove authorization  |
                           |                |     session state     |
                           |                +--------+--------------+
                           |                            QoS Responder
                           |                                Node
                           |<---------QoS-Response----....----+
                           |                                  |

           Figure 11: Server-Side Initiated Session Termination

5.  QoS Application Messages

   The Diameter QoS application requires the definition of new mandatory
   AVPs 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.

Top      Up      ToC       Page 30 
       +---------------------------+---------+------+-------------+
       | Command Name              | Abbrev. | Code | Reference   |
       +---------------------------+---------+------+-------------+
       | QoS-Authorization-Request |   QAR   |  326 | Section 5.1 |
       | QoS-Authorization-Answer  |   QAA   |  326 | Section 5.2 |
       | QoS-Install-Request       |   QIR   |  327 | Section 5.3 |
       | QoS-Install-Answer        |   QIA   |  327 | Section 5.4 |
       +---------------------------+---------+------+-------------+

                      Table 3: Diameter QoS Commands

   In addition, the following Diameter base protocol messages are used
   in the Diameter QoS application:

          +-----------------------+---------+------+-----------+
          | Command-Name          | Abbrev. | Code | Reference |
          +-----------------------+---------+------+-----------+
          | Re-Auth-Request       |   RAR   |  258 | [RFC3588] |
          | Re-Auth-Answer        |   RAA   |  258 | [RFC3588] |
          | Abort-Session-Request |   ASR   |  274 | [RFC3588] |
          | Abort-Session-Answer  |   ASA   |  274 | [RFC3588] |
          | Session-Term-Request  |   STR   |  275 | [RFC3588] |
          | Session-Term-Answer   |   STA   |  275 | [RFC3588] |
          +-----------------------+---------+------+-----------+

                      Table 4: Diameter Base Commands

   Diameter nodes conforming to this specification MAY advertise support
   for the Diameter QoS application by including the value of 9 in the
   Auth-Application-Id or the Acct-Application-Id AVP of the
   Capabilities-Exchange-Request and Capabilities-Exchange-Answer
   commands, see [RFC3588].

   The value of 9 MUST be used as the Application-Id in all QAR/QAA and
   QIR/QIA commands.

   The value of zero (0) SHOULD be used as the Application-Id in all
   STR/STA, ASR/ASA, and RAR/RAA commands.

5.1.  QoS-Authorization Request (QAR)

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

Top      Up      ToC       Page 31 
   The QAR message MUST carry information for signaling session
   identification, AE 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 is defined as follows:

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

5.2.  QoS-Authorization-Answer (QAA)

   The QoS-Authorization-Answer (QAA) message, indicated by the Command-
   Code field being set to 326 and the 'R' bit being cleared in the
   Command Flags field, is sent in response to the QoS-Authorization-
   Request (QAR) message.  If the QoS authorization request is
   successfully authorized, the response will include the AVPs to allow
   authorization of the QoS resources and transport plane gating
   information.

   The message format is defined as follows:

    <QoS-Authorization-Answer> ::= < Diameter Header: 326, PXY >
                                   < Session-Id >
                                   { Auth-Application-Id }
                                   { Auth-Request-Type }
                                   { Result-Code }
                                   { Origin-Host }
                                   { Origin-Realm }
                                *  [ QoS-Resources ]
                                   [ Acct-Multisession-Id ]
                                   [ Session-Timeout ]
                                   [ Authorization-Session-Lifetime ]
                                   [ Authorization-Grace-Period ]
                                *  [ AVP ]

Top      Up      ToC       Page 32 
5.3.  QoS-Install Request (QIR)

   The QoS-Install Request (QIR) message, indicated by the Command-Code
   field being set to 327 and the 'R' bit being set in the Command Flags
   field, is used by the AE to install or update the QoS parameters and
   the flow state of an authorized flow at the transport plane element.

   The message MUST carry information for signaling-session
   identification or identification of the flow to which the provided
   QoS rules apply, identity of the transport plane element, description
   of provided QoS parameters, flow state, and duration of the provided
   authorization.

   The message format is defined as follows:

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

5.4.  QoS-Install Answer (QIA)

   The QoS-Install Answer (QIA) message, indicated by the Command-Code
   field being set to 327 and the 'R' bit being cleared in the Command
   Flags, field is sent in response to the QoS-Install Request (QIR)
   message for confirmation of the result of the installation of the
   provided QoS reservation instructions.

   The message format is defined as follows:

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

Top      Up      ToC       Page 33 
5.5.  Re-Auth-Request (RAR)

   The Re-Auth-Request (RAR) message, indicated by the Command-Code
   field being set to 258 and the 'R' bit being set in the Command Flags
   field, is sent by the AE to the NE in order to initiate the QoS
   re-authorization from the DQA server side.

   If the RAR command is received by the NE without any parameters of
   the re-authorized QoS state, the NE MUST initiate a QoS
   re-authorization by sending a QoS-Authorization-Request (QAR) message
   towards the AE.

   The message format is defined as follows:

         <RAR>  ::= < Diameter Header: 258, REQ, PXY >
                    < Session-Id >
                    { Origin-Host }
                    { Origin-Realm }
                    { Destination-Realm }
                    { Destination-Host }
                    { Auth-Application-Id }
                    { Re-Auth-Request-Type }
                    [ User-Name ]
                    [ Origin-State-Id ]
                  * [ Proxy-Info ]
                  * [ Route-Record ]
                  * [ QoS-Resources ]
                    [ Session-Timeout ]
                    [ Authorization-Session-Lifetime ]
                    [ Authorization-Grace-Period ]
                    [ Authorization-Session-Volume ]
                  * [ AVP ]

Top      Up      ToC       Page 34 
5.6.  Re-Auth-Answer (RAA)

   The Re-Auth-Answer (RAA) message, indicated by the Command-Code field
   being set to 258 and the 'R' bit being cleared in the Command Flags
   field, is sent by the NE to the AE in response to the RAR command.

   The message format is defined as follows:

         <RAA>  ::= < Diameter Header: 258, PXY >
                    < Session-Id >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ User-Name ]
                    [ Origin-State-Id ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                  * [ Failed-AVP ]
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Host-Max-Cache-Time ]
                  * [ Proxy-Info ]
                  * [ QoS-Resources ]
                  * [ AVP ]



(page 34 continued on part 3)

Next RFC Part