[Docs] [txt|pdf] [Tracker] [Email] [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-00.txt
Date: March 1998



                                       DIAMETER
                            Resource Management Extensions
                       <draft-calhoun-diameter-res-mgmt-00.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 learn the current status of any Internet-Draft,  please  check  the
   1id-abstracts.txt  listing  contained  in  the  Internet-Drafts Shadow
   Directories on ds.internic.net,  nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.

Abstract

   DIAMETER is a management 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),
   etc.

   DIAMETER is an extensible protocol which defines a base protocol which
   can be used by any services to suit their needs. 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.

Table of Contents

      1.0  Introduction
      1.1  Specification of Requirements
      2.0  Command Name and Command Code
      3.0  Command Meanings


Calhoun                  expires September 1998                  [Page 1]


INTERNET DRAFT                                                 March 1998


      3.1  Resource-Free-Request
      3.2  Resource-Free-Response
      3.3  Query-Resource-Request
      3.4  Query-Resource-Response
      3.5  Resource-Reclaim-Request
      4.0  Attribute Name and Attribute Code
      5.0  Attribute Meanings
      5.1  Packet-Index
      5.2  Resource-Attached
      6.0  Motivation
      5.0  References
      7.0  Description (or Implementation Rules)
      8.0  References
      9.0  Authors' Addresses


1.0 Introduction

   The DIAMETER Resource Management extensions are intended  to  allow  a
   DIAMETER  server  to manage a set of resources. This document does not
   specify which resources may be management by a server  since  this  is
   implementation  and  service  specific.  The  protocol  extensions are
   designed to allow maximum flexibility and provider customers to define
   a local policy of resources which must be managed.

   Examples of resources which a DIAMETER server may wish to  manage  are
   the  number  of  active sessions per user/domain, the number of active
   flows for a specific host, etc.

   When reading this  document  the  reader  should  keep  in  mind  that
   authorization by a server is similar to the allocation of resource.


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.


Calhoun                  expires September 1998                  [Page 2]


INTERNET DRAFT                                                 March 1998


   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.


2.0 Command Name and Command Code

    Command Name: Resource-Free-Request
    Command Code: 11

    Command Name: Resource-Free-Response
    Command Code: 12

    Command Name: Query-Resource-Request
    Command Code: 13

    Command Name: Query-Resource-Response
    Command Code: 14

    Command Name: Resource-Reclaim-Request
    Command Code: 15


3.0 Command Meanings

3.1 Resource-Free-Request

   Description

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

      Since a DIAMETER client  cannot  predict  what  resources  will  be
      managed  by  the server, it is desirable that the client return ALL
      of the  attributes  which  were  sent  to  it  during  the  session
      authorization  (note  that the attributes sent in the authorization
      is similar to the  allocation  of  resources  by  a  server).  This
      flexibility  will  allow  the  DIAMETER server to manage any set of
      widgets, which is  service  specific  and  should  be  specifically
      stated  in  the  document  which  describes  the  DIAMETER  service
      extensions.

      Upon receipt of an Resource-Free-Request, A  DIAMETER  Server  MUST
      reply with a response. This response MAY be either a Resource-Free-
      Response  if  resource  management  is  supported  or  a   Command-
      Unrecognized packet if it does not.



Calhoun                  expires September 1998                  [Page 3]


INTERNET DRAFT                                                 March 1998


      If the DIAMETER Server does support Resource  Management,  it  MUST
      then release any resources at this point.

      A summary of  the  Resource-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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 11 (Resource-Free-Request).


3.2 Resource-Free-Response

   Description

      Resource-Free-Response packets are sent by the DIAMETER server to a
      client  to acknowledge that a specific resource has been freed. The
      DIAMETER server is responsible for releasing  any  resources  which
      are attached via the attributes.

      The Resource-Free-Response packets SHOULD NOT include  any  of  the
      attributes which were included in the request packet.

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

       0                   1                   2                   3


Calhoun                  expires September 1998                  [Page 4]


INTERNET DRAFT                                                 March 1998


       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 12 (Resource-Free-Response).


3.3 Query-Resource-Request

   Description

      Query-Resource-Request packets are sent by the DIAMETER server to a
      client.   Although   this   procedure   SHOULD   only  be  done  at
      initialization time, it is legal  for  an  implementation  to  send
      Query-Resource-Requests   regularly  to  ensure  that  local  state
      information is valid.

      Upon receipt of a Query-Resource-Request,  the  client  MUST  reply
      with  a  response.  This  response  MAY be either a Query-Resource-
      Response  if  resource  management  is  supported  or  a   Command-
      Unrecognized packet if it is not.

      The initial  Resource-Query-Request  MUST  contain  a  Packet-Index
      attribute  with  a  value of zero (See the attribute definition for
      more  information).  However,  if  a   Query-Resource-Response   is
      received  with  a Packet-Index attribute with a non-zero value, the
      Server MUST send another Query-Resource-Request  with  the  Packet-
      Index  attribute  value  set to the value which was received in the
      response. A response with the Packet-Index attribute value  set  to
      zero indicates that the transaction is complete.


Calhoun                  expires September 1998                  [Page 5]


INTERNET DRAFT                                                 March 1998


      If the DIAMETER Server times out before receiving any responses, it
      MAY assume that there are no clients on the network, at which point
      it may retry periodically or give up  and  expect  regular  service
      specific messages (this is implementation specific).

      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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 13 (Query-Resource-Request).


3.4 Query-Resource-Response

   Description

      Upon receipt of a request, each client is  responsible  to  respond
      with all resources for all sessions which were previously allocated
      for sessions which are still  active.  Each  Authorization  message
      must  be  encapsulated  within  a  Resource-Attached attribute (see
      below).

      Since many  Authorization  messages  may  be  returned  within  one
      Resource-Query-Response,  it is likely that the total packet length
      exceed the interface's MTU. Although it is entirely possible to use
      IP  fragmentation,  it  is  possible that clients or servers do not


Calhoun                  expires September 1998                  [Page 6]


INTERNET DRAFT                                                 March 1998


      have sufficiently large enough buffers to hold a very large packet.
      Therefore,  clients  MUST  not  send  packets which exceed the MTU,
      therefore once the maximum packet  length  has  been  reached,  the
      Packet-Index  attribute's  value  MUST  be set to a value which the
      client could use on a further request to return  the  rest  of  the
      information.

      When the DIAMETER Server receives a response with the  Packet-Index
      set  to  a  non-zero  value,  it  must sent another Query-Resource-
      Request with the Packet-Index set to the value which was set in the
      response.

      When the DIAMETER Server receives  a  Query-Resource-Response  from
      the  client  with a Packet-Index attribute with a value of zero, it
      MUST assume that the client has no data left and  should  NOT  send
      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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 14 (Query-Resource-Response).


3.5 Resource-Reclaim-Request



Calhoun                  expires September 1998                  [Page 7]


INTERNET DRAFT                                                 March 1998


   Description

      Resource-Reclaim-Request packets are sent by the DIAMETER server to
      the client to request that a previously allocated resource be freed
      immediately. This allows an administrator to  free  used  resources
      from  the  DIAMETER  server  without any manual intervention on the
      client.

      The Resource-Reclaim-Request message should include all  previously
      allocated  resources  which  where  included  in  the authorization
      packet. It is assumed that if all of the attributes which  were  in
      the  authorization  message  are  present  in this packet, then the
      DIAMETER Server  is  requesting  that  the  client  disconnect  the
      session.

      When a DIAMETER client receives this message it responds  with  the
      Resource-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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 15 (Query-Reclaim-Request).


4.0 Attribute Name and Attribute Code


Calhoun                  expires September 1998                  [Page 8]


INTERNET DRAFT                                                 March 1998


    Attribute Name: Packet-Index
    Attribute Code: 267

    Attribute Name: Resource-Attached
    Attribute Code: 268


5.0 Attribute Meanings

5.1 Packet-Index

   Description

      This attribute is used  in  conjunction  with  the  Resource  Query
      mechanism  and  allows  for  data greater than the MTU size. In the
      original Resource-Query-Request, this attribute should  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 Resource Query Request with a Packet-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 packet.

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                Packet Index                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Packet Index  |
       +-+-+-+-+-+-+-+-+

    Code

      267     Packet Index


    Length

      The length of this attribute MUST be 9.


    Flags

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


    Packet Index



Calhoun                  expires September 1998                  [Page 9]


INTERNET DRAFT                                                 March 1998


      The Packet Index field contains the packet sequence number.


5.2 Resource-Attached

   Description

      This attribute contains all attributes which were  received  in  an
      authorization  message.  This  attribute is used with the Resource-
      Query-Response in order for  the  DIAMETER  client  to  return  the
      previously allocated resources.

      It is likely that more than one of  these  attributes  exist  in  a
      Resource-Query-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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |  Resource...  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      268     Resource-Attached


    Length

      The length of this attribute MUST be at least 7.


    Flags

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


    Resource Attached

      The value of this attribute is the a specific Resource.


6.0 Motivation

   With the large demand for the leasing of dial-up ports and  access  to
   corporate backbone networks, it is necessary for a central registry to
   maintain an address pool. In the past, this was  mostly  done  by  the
   client,  but  with the above scenarios there are now multiple pools to
   deal with.


Calhoun                 expires September 1998                  [Page 10]


INTERNET DRAFT                                                 March 1998


   One possibility is to pre-configure all address pools in every clients
   within  the  network. However, this is not only very wasteful but is a
   deployment nightmare for service providers.

   Since the protocol can manage any resource, another possible  resource
   would  be the number simultaneous session for a given user. This would
   allow service providers the ability to limit the number of  concurrent
   logins  based  of  the  user's  service profile (i.e. more than one if
   Multi-Link is enabled for the user). This also  resolves  the  problem
   with  service  providers  who  charge  a flat fee for unlimited usage,
   where a user can distribute his/her username and password and  end  up
   tying up dial-up ports.

   The method which is most commonly  used  today  is  for  the  DIAMETER
   server to make use of the STOP accounting record in order to determine
   when the user has been disconnected. This  solution  is  unfortunately
   not  suitable  in  installations  where  the accounting and operations
   departments are physically separate and  so  are  the  accounting  and
   authentication  DIAMETER  servers.  This  solution  will allow for the
   authentication server to determine when a session has been released.

   Since it is quite likely that  a  DIAMETER  server  would  loose  it's
   internal  database  of  allocated  resources  should a crash occur (or
   power outage), a mechanism should exist which would allow the DIAMETER
   server  to  rebuild  the  information.  The  Resource  Query mechanism
   described in this document will allow the DIAMETER server to poll  all
   of it's clients in order to determine what has already been allocated.

   Note that for large networks with resilient DIAMETER  Servers,  it  is
   required  that  a  distributed  database  be used as a back-end to the
   DIAMETER Server.


7.0 Description (or Implementation Rules)

   Upon a call termination, a Resource-Free Message is generated  by  the
   client to the DIAMETER Server which MUST contain all of the attributes
   which were attached in the authorization message.

   In order to support the fact that a client may reboot, if  a  DIAMETER
   Server  receives  a  Device-Reboot  message  it  MUST  assume that all
   resources currently allocated to that client MUST be freed.

   The DIAMETER Server now requires a special  state  for  each  of  it's
   configured  clients.  This  state will indicate whether the client has
   responded to the Resource-Query-Request which was sent  out  when  the
   DIAMETER   Server   rebooted.  If  the  DIAMETER  Server  receives  an
   Authentication or Authorization request from a client  which  did  NOT
   respond  the  the  Query  message,  the  DIAMETER  server  MAY  send a
   Resource-Query-Request  to  the  client  in  order  to  retrieve   any


Calhoun                 expires September 1998                  [Page 11]


INTERNET DRAFT                                                 March 1998


   resources that may have been already allocated. If  it  is  determined
   that   the  client  supports  DIAMETER  and  the  resource  management
   extension,  then  the  DIAMETER  server   should   only   respond   to
   Authentication/Authorization  requests  if it has received a Resource-
   Query-Response from the requesting client.

   A client MUST respond to a  Resource-Query-Request  with  all  of  the
   resources which were allocated to it via the DIAMETER Server. In order
   to do this, the client SHOULD return all authorization messages in the
   response.  Since  response  packets  may  be greater than the MTU, the
   Packet-Index attribute allow the protocol  to  send  multiple  request
   response pairs.

   This will allow a DIAMETER Server, which may have crashed, to  recover
   and to be able to identify what resources have been allocated.


8.0 References

    [1]   Calhoun, Rubens, "DIAMETER", Internet-Draft,
          draft-calhoun-diameter-00.txt, January 1998.
    [2]   Calhoun, "DIAMETER Autentication Extensions", Internet-Draft,
          draft-calhoun-diameter-auth-00.txt, January 1998.

9.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-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net














Calhoun                 expires September 1998                  [Page 12]


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