[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-02.txt               Nancy Greene
Date: July 1998                                                   Nortel



                               DIAMETER
                     Resource Management Extensions
                <draft-calhoun-diameter-res-mgmt-02.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
   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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (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 January 1999                  [Page 1]


INTERNET DRAFT                                                 July 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-Free-Answer
      2.3  Session-Resource-Query
      2.4  Session-Resource-Reply
      2.5  Resource-Reclaim-Request
      2.6  Resource-Reclaim-Answer
      3.0  DIAMETER AVPs
      3.1  Query-Index
      3.2  Resource-Token
      4.0  Protocol Definition
      4.1  Feature Advertisement/Discovery
      4.2  Session Free
      4.3  Relinquish Session
      4.4  Interaction with Device-Reboot-Indication
      4.5  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.



Calhoun                   expires January 1999                  [Page 2]


INTERNET DRAFT                                                 July 1998


   The DIAMETER Resource Management extensions are intended to provide
   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].

   The Extension number for this draft is two (2). This value is used in
   the Extension-Id AVP as defined 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.





Calhoun                   expires January 1999                  [Page 3]


INTERNET DRAFT                                                 July 1998


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
   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-Answer       267
      Session-Resource-Query    268
      Session-Resource-Reply    269
      Resource-Reclaim-Request  270
      Resource-Reclaim-Answer   271


2.1  Session-Free-Request (SFR)

   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-Answer.



Calhoun                   expires January 1999                  [Page 4]


INTERNET DRAFT                                                 July 1998


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

   Message Format

      <Session-Free-Request>  ::= <DIAMETER Header>
                                  <Session-Free-Request Command AVP>
                                  <Session-Id AVP>
                                  <Timestamp AVP>
                                  <Initialization-Vector AVP>
                                  {<Integrity-Check-Vector AVP> ||
                                   <Digital-Signature AVP }

   AVP Format

      A summary of the Session-Free-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           |     Reserved      |U|T|V|E|H|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Command Code

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





Calhoun                   expires January 1999                  [Page 5]


INTERNET DRAFT                                                 July 1998


2.2  Session-Free-Answer (SFA)

   Description

      The Session-Free-Answer message is sent by the DIAMETER Server to
      the client to acknowledge the receipt of the Session-Free-Request
      message. The Result-Code AVP, which MUST be present in the
      Session-Free-Answer, 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-Answer
      message:

         DIAMETER_ERROR_ALREADY_FREE             1
            The Session Identifier has already been freed.

   Message Format

      <Session-Free-Answer>  ::= <DIAMETER Header>
                                 <Session-Free-Answer Command AVP>
                                 <Result-Code AVP>
                                 <Timestamp AVP>
                                 <Initialization-Vector AVP>
                                 {<Integrity-Check-Vector AVP> ||
                                  <Digital-Signature AVP }

   AVP Format

      A summary of the Session-Free-Answer 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           |     Reserved      |U|T|V|E|H|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER Command

      AVP Length



Calhoun                   expires January 1999                  [Page 6]


INTERNET DRAFT                                                 July 1998


         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Command Code

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


2.3  Session-Resource-Query (SRQ)

   Description

      The Session-Resource-Query 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 Session-
      Resource-Query indicates that the server only wants to receive the
      Resource-Token for the specified session(s).

      The initial Session-Resource-Query 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
      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
      Session-Resource-Query-Reply 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
      Session-Resource-Query and receive a valid response from a
      specific client prior to processing any authorization messages
      from the client.



Calhoun                   expires January 1999                  [Page 7]


INTERNET DRAFT                                                 July 1998


   Message Format

      Session-Resource-Query  ::= <DIAMETER Header>
                                  <Session-Resource-Query Command AVP>
                                  [<Session-Id AVP #1>]
                                  [<Session-Id AVP #2>]
                                  [<Session-Id AVP #n>]
                                  <Timestamp AVP>
                                  <Initialization-Vector AVP>
                                  {<Integrity-Check-Vector AVP> ||
                                   <Digital-Signature AVP }

   AVP Format

      A summary of the Session-Resource-Query 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           |     Reserved      |U|T|V|E|H|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Command Code

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


2.4  Session-Resource-Query-Reply (SRQR)



Calhoun                   expires January 1999                  [Page 8]


INTERNET DRAFT                                                 July 1998


   Description

      Upon receipt of a Session-Resource-Query, 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
      Session-Resource-Query-Reply, 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 Session-Resource-Query. The value of the
      Query-Index MUST be duplicated in the subsequent Session-
      Resource-Query 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 Session-Resource-Query-Reply 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 Session-Resource-Query.

   Message Format

      Session-Resource-Query-Reply  ::= <DIAMETER Header>
                                     <Session-Res-Qry-Reply Command AVP>
                                     <Result-Code AVP>
                                     [<Resource-Token AVP #1>]
                                     [<Resource-Token AVP #2>]
                                     [<Resource-Token AVP #n>]
                                     <Timestamp AVP>
                                     <Initialization-Vector AVP>
                                     {<Integrity-Check-Vector AVP> ||
                                      <Digital-Signature AVP }

   AVP Format

      A summary of the Session-Resource-Query-Reply 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           |     Reserved      |U|T|V|E|H|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                   expires January 1999                  [Page 9]


INTERNET DRAFT                                                 July 1998


       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Command Code

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


2.5  Session-Reclaim-Request (SRR)

   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.

   Message Format

      Session-Reclaim-Request ::= <DIAMETER Header>
                                  <Session-Reclaim-Request Command AVP>
                                  <Session-ID AVP>
                                  <Timestamp AVP>
                                  <Initialization-Vector AVP>
                                  {<Integrity-Check-Vector AVP> ||
                                   <Digital-Signature AVP }

   AVP Format




Calhoun                   expires January 1999                 [Page 10]


INTERNET DRAFT                                                 July 1998


      A summary of the Session-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           |     Reserved      |U|T|V|E|H|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Command Code

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


2.6  Session-Reclaim-Answer (SRA)

   Description

      The Session-Reclaim-Answer message is sent by the DIAMETER client
      to acknowledge the Session-Reclaim-Request. The Result-Code AVP
      indicates wether the request was successfully completed or not.

   Message Format

      Session-Reclaim-Answer ::= <DIAMETER Header>
                                 <Session-Reclaim-Answer Command AVP>
                                 <Result-Code AVP>
                                 <Timestamp AVP>
                                 <Initialization-Vector AVP>



Calhoun                   expires January 1999                 [Page 11]


INTERNET DRAFT                                                 July 1998


                                 {<Integrity-Check-Vector AVP> ||
                                  <Digital-Signature AVP }

   AVP Format

      A summary of the Session-Reclaim-Answer 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           |     Reserved      |U|T|V|E|H|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Command Code

         The Command Code field MUST be set to 271 (Session-Reclaim-
         Answer).


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



Calhoun                   expires January 1999                 [Page 12]


INTERNET DRAFT                                                 July 1998


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 Session-Resource-Query, this attribute MUST be
      present with a value of zero. Upon receipt of a Session-Resource-
      Query-Reply 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 Session-Resource-Query 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.

   AVP Format

      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           |     Reserved      |U|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         290     Query-Index

      AVP Length

         The length of this attribute MUST be at least 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be 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 Session-Resource-Query.



Calhoun                   expires January 1999                 [Page 13]


INTERNET DRAFT                                                 July 1998


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 Session-Resource-Query-Reply 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 Extension-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
      Session-Resource-Reponse.

   AVP Format

      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           |     Reserved      |U|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Code

         291     Resource-Token

      AVP Length

         The length of this attribute MUST be at least 9.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'U' bits
         MUST NOT be set.

      Data

         The Data field contains the Resource-Token that was returned by



Calhoun                   expires January 1999                 [Page 14]


INTERNET DRAFT                                                 July 1998


         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  Feature Advertisement/Discovery

   As defined in [2], the Reboot-Ind and Device-Feature-Query messages
   can be used to inform a peer about locally supported DIAMETER
   Extensions. In order to advertise support of this extension, the
   Extension-Id AVP must be transmitted with a value of one (1).


4.2  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.


4.3  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-Reclaim-Answer message. The
   response indicates whether the request was successfully processed
   through the Result-Code 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.4  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 peer
   MUST be freed.




Calhoun                   expires January 1999                 [Page 15]


INTERNET DRAFT                                                 July 1998


4.5  State Resync

   Upon receipt of a Reboot-Ack message from a client that contains an
   Extension-Id AVP with the value set to 1 (Resource-Management), a
   DIAMETER entity SHOULD issue a Session-Resource-Query to the peer.
   All requests from the peer MUST be ignored until the peer has
   successfully responded to the Session-Resource-Query message.

   Upon receipt of a Session-Resource-Query a response MUST be returned
   which contains all of the active Resource-Tokens that have previously
   been allocated by the requesting node. 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
      ---------------                                    ---------------
      Reboot-Ind                         -->
                                         <-- Reboot-Ack (w/ Res-Mgmt Ext. Id)
      Session-Resource-Query (Index = 0) -->
                                 <-- Session-Resource-Query-Reply (Index = 10)
      Session-Resource-Query (Index = 10) -->
                                 <-- Session-Resource-Query-Reply (Index = 20)
      Session-Resource-Query (Index = 20) -->
                                 <-- Session-Resource-Query-Reply (Index = 0)

   In the above scenario, the Server issues the initial Session-
   Resource-Query 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 Session-Resource-Query-Reply.

   Upon receipt of the response the server processes the message and
   issues another Session-Resource-Query 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 Session-Resource-Query 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.


5.0  References



Calhoun                   expires January 1999                 [Page 16]


INTERNET DRAFT                                                 July 1998


    [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


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 January 1999                 [Page 17]


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