[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Microsystems, Inc.
Title: draft-calhoun-diameter-res-mgmt-01.txt               Nancy Greene
Date: May 1998                                                    Nortel



                               DIAMETER
                     Resource Management Extensions
                <draft-calhoun-diameter-res-mgmt-01.txt>



Status of this Memo

   This document is an Internet-Draft. 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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract

   DIAMETER is a policy protocol used between a client and a server for
   authentication, authorization and accounting of various services.
   Examples of such services are for dial-up users (ROAMOPS), RSVP
   Admission Policies (RAP), FAX Over IP (FAXIP), Voice over IP
   (SIPTel), Integrated services, etc.

   This document defines a set of commands which allow DIAMETER servers
   to maintain session state information. An example of the use of
   Resource Management would be to limit the number of sessions for a
   given user.








Calhoun                  expires November 1998                  [Page 1]


INTERNET DRAFT                                                  May 1998


Table of Contents

      1.0  Introduction
      1.1  Specification of Requirements
      1.2  Concept of a session
      2.0  Command Codes
      2.1  Session-Free-Request
      2.2  Session-FreeResponse
      2.3  Query-Resource-Request
      2.4  Query-Resource-Response
      2.5  Resource-Reclaim-Request
      3.0  DIAMETER AVPs
      3.1  Query-Index
      3.2  Resource-Token
      4.0  Protocol Definition
      4.1  Session Free
      4.2  Relinquish Session
      4.3  Interaction with Device-Reboot-Indication
      4.4  State Resync
      5.0  References
      6.0  Authors' Addresses


1.0  Introduction

   Many services requiring Policy Server Support require the server to
   maintain session state information. This can only be achieved if the
   protocol has built-in mechanism to allow both the client and the
   server to resync its state information. A message set is also
   required to allow the client to inform the server when a session has
   terminated.

   An example of such a requirement is in the dial-up PPP world. With
   the introduction of flat-rate internet access, there has been a surge
   in fraud that allows a user to provide his username/password pair to
   other people. The end result is that a single username can have
   simultaneous concurrent sessions.

   It is desirable for the Policy Server to maintain a list of the
   active sessions so it can detect whether a user is attempting
   fraudulent activities, and restrict the user to a single login.

   Internet Service Providers have had to implement this functionality
   using other less-reliable schemes in the past. Unfortunately, those
   schemes are known to be problematic and therefore a standard method
   of maintaining state information is desired.

   The DIAMETER Resource Management extensions are intended to provide



Calhoun                  expires November 1998                  [Page 2]


INTERNET DRAFT                                                  May 1998


   the functionality required to have stateful Policy Servers. This
   document does not specify what resources can be managed by a server
   since it is service specific, but it does provide the tools required
   for the services that require it.

   When reading this document the reader should keep in mind that the
   authorization of a session by the server is analogous to the
   allocation of resources. This document does not deal with the
   allocation of any resources and is simply a complement to the service
   extension that requires stateful servers.

   Message sets and the AVPs used for session setup and resource
   allocation vary depending on the type of service a session is being
   created for. The general concept of a session is described in this
   document, and specific message sets for session setup and resource
   allocation are found in other extension documents, for example, in
   [2].


1.1  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the
             specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that
             there may exist valid reasons in particular circumstances
             to ignore this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST
             be prepared to interoperate with another implementation
             which does include the option.


1.2  Concept of a session

   A session defines a thread of Diameter messages. All messages related
   to a particular session MUST include a Session-Id. (Session-Id is



Calhoun                  expires November 1998                  [Page 3]


INTERNET DRAFT                                                  May 1998


   described in [1]). A session can be established by either a client or
   a server. The Session-Id is assigned by the initiator of the session.
   Resources can be added to, deleted from, or modified in a session.
   How this is done for a particular service is described in the
   relevant extensions document. For example, [2] describes session
   setup and resource allocation for user authentication and
   authorization.

   This document describes the more general functions of querying for
   information on allocated resources, and freeing a session.


2.0  Command Codes

   This document defines the following DIAMETER Commands. All DIAMETER
   implementations supporting this extension MUST support all of the
   following commands:

      Command Name          Command Code
      -----------------------------------
      Session-Free-Request      266
      Session-Free-Response     267
      Query-Resource-Request    268
      Query-Resource-Response   269
      Resource-Reclaim-Request  270


2.1  Session-Free-Request

   Description

      The Session-Free-Request message is normally sent by a DIAMETER
      client to a server, and provides information on specific resources
      which have been released.

      The Session-Free-Request message MUST include the Host-IP-Address
      or the Host-Name as well as the Session-Id AVPs. The Session-Id is
      used by the server to identify a specific session that was
      previously authorized.

      Upon receipt of this message the server MUST free any resources
      that were previously allocated to the session during the session
      authorization and respond with the Session-Free-Response.

      The Session-Free-Request MAY contain the Result-Code AVP if it is
      a result of a Session-Reclaim-Request.

      A summary of the Session-Free-Request packet format is shown



Calhoun                  expires November 1998                  [Page 4]


INTERNET DRAFT                                                  May 1998


      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Command Code

      The Command Code field MUST be set to 266 (Session-Free-Request).


2.2  Session-Free-Response

   Description

      The Session-Free-Response message is sent by the DIAMETER Server
      to the client to acknowledge the receipt of the Session-Free-
      Response message. The Result-Code AVP, which MUST be present in
      the Session-Free-Response, is used in order to identify whether
      the Server was able to free the resources associated with the
      Session-Id. The Host-IP-Address or the Host-Name AVP MUST be
      present in this message.

      The following Error Codes are defined for the Session-Free-
      Response message:

         DIAMETER_ERROR_ALREADY_FREE             1
            The Session Identifier has already been freed.

      A summary of the Session-Free-Response packet format is shown



Calhoun                  expires November 1998                  [Page 5]


INTERNET DRAFT                                                  May 1998


      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Command Code

      The Command Code field MUST be set to 267 (Session-Free-Response).


2.3  Query-Resource-Request

   Description

      The Query-Resource-Request message is sent by a DIAMETER Server to
      a client. This event MAY occur when a Server has lost its state
      information and wishes to rebuild the information. However, it is
      valid for a server to send a request periodically to clients to
      refresh its state information.

      The presence of one or more  Session-Id AVP in the Query-
      Resource-Request indicates that the server only wants to receive
      the Resource-Token for the specified session(s).

      The initial Query-Resource-Request message MUST contain the Host-
      IP-Address and the Host-Name AVPs and a Query-Index AVP with a
      value of zero (see section 4.4 for more info). The Query-Index AVP
      is used by the client as a placeholder in subsequent Query-
      Resource-Requests in order to identify which Resource-Token to



Calhoun                  expires November 1998                  [Page 6]


INTERNET DRAFT                                                  May 1998


      send to the server.

      When the client receives a non-zero Query-Index AVP, it MUST
      include Resource-Tokens beginning at the placeholder associated
      with the value of the Query-Index AVP.

      A non-zero Query-Index AVP is sent to the DIAMETER Server in the
      Query-Resource-Response when the client is unable to include all
      of the Resource-Tokens within a single response.

      Once a DIAMETER Server has rebooted or lost its state information
      for any reason, it is recommended that the Server issue a Query-
      Resource-Request and receive a valid response from a specific
      client prior to processing any authorization messages from the
      client.

      A summary of the Query-Resource-Request packet format is shown
      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Command Code

      The Command Code field MUST be set to 268 (Query-Resource-
      Request).


2.4  Query-Resource-Response



Calhoun                  expires November 1998                  [Page 7]


INTERNET DRAFT                                                  May 1998


   Description

      Upon receipt of a Query-Resource-Request, each client is
      responsible to respond with all of the Resource-Tokens for active
      sessions that were previously allocated by the requesting server.
      The message MUST include the Query-Index, a Result-Code AVP, a
      Host-IP-Address or Host-Name AVPs and one or more Resource-Token
      AVPs.

      Since more than one Resource-Token AVP may be returned within a
      Query-Resource-Response, it is likely that the total packet length
      would exceed the interface's MTU. It is required to make use of
      the Query-Index AVP in order to request that the server issue a
      subsequent Query-Resource-Request. The value of the Query-Index
      MUST be duplicated in the subsequent Query-Resource-Request by the
      Server in order for the client to know which Resource-Token to
      start sending in the following response.

      If the client was able to fit all of the Resource-Tokens within
      the Query-Resource-Response it MUST include a Query-Index AVP with
      a zero value. A zero Query-Index will inform the Server that it
      SHOULD NOT issue another Query-Resource-Request.

      A summary of the Query-Resource-Response packet format is shown
      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.




Calhoun                  expires November 1998                  [Page 8]


INTERNET DRAFT                                                  May 1998


   Command Code

      The Command Code field MUST be set to 269 (Query-Resource-
      Response).


2.5  Session-Reclaim-Request

   Description

      The Session-Reclaim-Request message is sent by the DIAMETER Server
      to the client to request that a previously authorized session be
      freed immediately. This allows the server to free used resources
      on the client without any manual intervention.

      The Session-Reclaim-Request message MUST include a Host-IP-Address
      and the Host-Name AVP and the Session-Id AVP that was used during
      the session's authorization phase.

      When a DIAMETER client receives this message it MUST responds with
      a Session-Free-Request message.

      A summary of the Resource-Reclaim-Request packet format is shown
      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Command Code



Calhoun                  expires November 1998                  [Page 9]


INTERNET DRAFT                                                  May 1998


      The Command Code field MUST be set to 270 (Query-Reclaim-Request).


3.0  DIAMETER AVPs

   This section will define the mandatory AVPs which MUST be supported
   by all DIAMETER implementations supporting this extension. The
   following AVPs are defined in this document:

      Attribute Name       Attribute Code
      -----------------------------------
      Query-Index               290
      Resource-Token            291

3.1  Query-Index

   Description

      This attribute is used in conjunction with the Resource Query
      mechanism and allows the client to exchange resource information
      through more than one message exchange.

      In the initial Query-Resource-Request, this attribute MUST be
      present with a value of zero. Upon receipt of a Resource Query
      Response command, the DIAMETER server must check if the attribute
      is still set to zero. If the value is a non-zero, the DIAMETER
      server MUST return a Query-Resource-Request with a Query-Index
      value equal to the value which was set in the response. Upon
      receipt of a zero, the DIAMETER Server MUST assume that this is
      the last message exchange.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      290     Query-Index

   AVP Length

      The length of this attribute MUST be at least 12.



Calhoun                  expires November 1998                 [Page 10]


INTERNET DRAFT                                                  May 1998


   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains a value that has local significance
      to client in order to identify which Resource-Token to send in the
      subsequent Query-Resource-Request.


3.2  Resource-Token

   Description

      The Resource-Token AVP is returned by the DIAMETER Server to the
      client during authorization (or session setup). The Resource-Token
      is subsequently used during the Query-Resource-Response in order
      to hand the Server with enough information to rebuild its state
      information.

      The data portion of this AVP includes AVPs and at a minimum MUST
      include the Session-Id AVP, the Host-IP-Address or Host-Name AVP
      and the Service-Id.  Each service MUST define what AVPs must be
      included in the Resource-Token in order for the Resource
      Management extension to work for the specific service.

      It is likely that more than one of these attributes exist in a
      Query-Resource-Response.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   AVP Code

      291     Resource-Token

      AVP Length

      The length of this attribute MUST be at least 9.




Calhoun                  expires November 1998                 [Page 11]


INTERNET DRAFT                                                  May 1998


   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Data

      The Data field contains the Resource-Token that was returned by
      the DIAMETER Server during the authorization phase.


4.0  Protocol Definition

   This section will outline how the DIAMETER Resource Management
   Extension can be used.

4.1  Session Free

   Upon session termination, a Session-Free-Request message is issue by
   the client to the DIAMETER Server and MUST contain the Session-Id AVP
   that was used during the authorization phase of the session.

   The format of the Session-Free-Request message is as follows:

   <Session-Free-Request>  ::= <DIAMETER Header>
                               <Session-Free-Request Command AVP>
                               <Session-Id AVP>

   The format of the Session-Free-Response message is as follows:

   <Session-Free-Response>  ::= <DIAMETER Header>
                                <Session-Free-Response Command AVP>
                                <Result-Code AVP>


4.2  Relinquish Session

   When the server wants the client to relinquish an existing session,
   the Server issues a Session-Reclaim-Request to the client. The
   request MUST contain the Session-Id AVP that was used during the
   authorization phase of the session.

   The client MUST respond with a Session-Free-Request message. The
   request MUST contain the Result-Code when it is a response to a
   Session-Reclaim-Request to indicate whether it was able to free the
   requested session. The Server MUST respond with the Session-Free-
   Response.

      DIAMETER Server                                    DIAMETER Client



Calhoun                  expires November 1998                 [Page 12]


INTERNET DRAFT                                                  May 1998


      ---------------                                    ---------------
      Session-Reclaim-Request -->
                                   <-- Session-Free-Request (Result = 0)
      Session-Free-Response (Result = 0) -->

   The format of the Session-Reclaim-Request message is as follows:

   Session-Reclaim-Request ::= <DIAMETER Header>
                               <Session-Reclaim-Request Command AVP>
                               <Session-ID AVP>

   In the roaming scenario the Session-Reclaim-Request message is
   problematic since it is difficult to identify the target client's
   proxy chain. This can be achieved by including the Host Name of the
   client that was found in the authorization request within the Host-
   Name AVP.


4.3  Interaction with Device-Reboot-Indication

   When a DIAMETER Server receives a Device-Reboot-Indication it MUST
   assume that all resources currently allocated to the rebooted client
   MUST be freed.


4.4  State Resync

   The DIAMETER Server requires a flag in the client database in order
   to identify whether the client has responded to the Query-Resource-
   Request.  Upon receipt of an Authorization message that requires
   Resource Management, the Server MUST issue a Query-Resource-Request
   if the client has not previously responded to such requests.

   A client MUST respond to a Query-Resource-Request with all of the
   active Resource-Tokens that have previously been allocated by the
   requesting server. Since the number of active Resource-Tokens MAY be
   larger than the interface's MTU, it is required to make use of the
   Query-Index AVP.

   The following is an example of an exchange between a Server and a
   Client that has 26 Resource-Tokens which is too many to fit within a
   single response.

      DIAMETER Server                                    DIAMETER Client
      ---------------                                    ---------------
      Query-Resource-Request (Index = 0) -->
                                 <-- Query-Resource-Response (Index = 10)
      Query-Resource-Request (Index = 10) -->



Calhoun                  expires November 1998                 [Page 13]


INTERNET DRAFT                                                  May 1998


                                 <-- Query-Resource-Response (Index = 20)
      Query-Resource-Request (Index = 20) -->
                                 <-- Query-Resource-Response (Index = 0)

   In the above scenario, the Server issues the initial Query-Resource-
   Request with a zero Query-Index. The client responds but since it can
   only fit Resource-Tokens 1 through 9, it sets the Query-Index to 10
   in the Query-Resource-Response.

   Upon receipt of the response the server processes the message and
   issues another Query-Resource-Request with the Query-Index value set
   to 10. The client, upon receipt of the request, knows that it needs
   to include the Resource-Tokens starting at 10. Again, since the
   client can only include the Resource-Tokens up to 19, it sets the
   Query-Index to 20.

   The Server issues another Query-Resource-Request with the Query-Index
   set to 20. At this point the client can fit the remaining Resource-
   Tokens (20 through 26) and therefore sets the Query-Index to zero to
   indicate that it has sent all of it's active Resource-Tokens.

   The format of the Query-Resource-Request is as follows:

   <Query-Resource-Request>  ::= <DIAMETER Header>
                                 <Query-Resource-Request Command AVP>
                                 [<Session-Id AVP #1>]
                                 [<Session-Id AVP #2>]
                                 [<Session-Id AVP #n>]


   The format of the Query-Resource-Response message is as follows:

   <Query-Resource-Response>  ::= <DIAMETER Header>
                                  <Query-Resource-Response Command AVP>
                                  <Result-Code AVP>
                                  [<Resource-Token AVP #1>]
                                  [<Resource-Token AVP #2>]
                                  [<Resource-Token AVP #n>]

5.0  References

    [1]   Calhoun, Rubens, "DIAMETER", Internet-Draft,
          draft-calhoun-diameter-03.txt, May 1998.
    [2]   Calhoun, Bulley, "DIAMETER Autentication Extensions",
          Internet-Draft, draft-calhoun-diameter-auth-03.txt, May 1998.
    [3]   Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-
          Draft, draft-calhoun-diameter-framework-00.txt, May 1998




Calhoun                  expires November 1998                 [Page 14]


INTERNET DRAFT                                                  May 1998


6.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com

      Nancy Greene
      Public Data Networks
      Nortel (Northern Telecom)
      PO Box 3511 Station C
      Ottawa, Ontario K1Y 4H7
      Canada

       Phone: 1-613-763-9789
         Fax: 1-613-763-8904
      E-mail: ngreene@nortel.ca


























Calhoun                  expires November 1998                 [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/