INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-res-mgmt-03.txt Nancy Greene
Date: February 1999 Nortel
DIAMETER
Resource Management Extensions
Status of this Memo
This document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@ipass.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
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 (IP
Tel), Integrated services, etc.
Calhoun expires August 1999 [Page 1]
INTERNET DRAFT February 1999
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 August 1999 [Page 2]
INTERNET DRAFT February 1999
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 August 1999 [Page 3]
INTERNET DRAFT February 1999
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 August 1999 [Page 4]
INTERNET DRAFT February 1999
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 August 1999 [Page 5]
INTERNET DRAFT February 1999
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>
<Nonce 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 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 266 (Session-Free-
Request).
Calhoun expires August 1999 [Page 6]
INTERNET DRAFT February 1999
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>
[<Error-Code AVP>]
<Timestamp AVP>
<Nonce 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
Calhoun expires August 1999 [Page 7]
INTERNET DRAFT February 1999
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 'P' 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
Calhoun expires August 1999 [Page 8]
INTERNET DRAFT February 1999
specific client prior to processing any authorization messages
from the client.
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>
<Nonce 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 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 268 (Session-Resource-
Query).
Calhoun expires August 1999 [Page 9]
INTERNET DRAFT February 1999
2.4 Session-Resource-Query-Reply (SRQR)
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>
[<Error-Code AVP>]
[<Resource-Token AVP #1>]
[<Resource-Token AVP #2>]
[<Resource-Token AVP #n>]
<Timestamp AVP>
<Nonce 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.
Calhoun expires August 1999 [Page 10]
INTERNET DRAFT February 1999
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 'P' 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
Calhoun expires August 1999 [Page 11]
INTERNET DRAFT February 1999
Session-Reclaim-Request ::= <DIAMETER Header>
<Session-Reclaim-Request Command AVP>
<Session-ID AVP>
<Timestamp AVP>
<Nonce AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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 'P' 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
Calhoun expires August 1999 [Page 12]
INTERNET DRAFT February 1999
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>
[<Error-Code AVP>]
<Timestamp AVP>
<Nonce AVP>
{<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 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 271 (Session-Reclaim-
Answer).
Calhoun expires August 1999 [Page 13]
INTERNET DRAFT February 1999
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 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.
Calhoun expires August 1999 [Page 14]
INTERNET DRAFT February 1999
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 'P' 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.
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 should be considered as opaque data
to all systems other than the creator of the token. One could
easily imagine that the token would include AVPs, such as the
Session Id, Host-IP-Address or Host-Name AVP and the Extension-Id
AVP. Each service SHOULD define the set of AVPs that are necessary
for the creation of session state information, however given that
this is only used by the creator, it will remain largely
implementation specific.
NOTE: The above may not be true in cases where a DIAMETER server
farm exists and these servers must exchange session state
information. Therefore, it may be desirable to simply require that
the token consists of DIAMETER AVPs.
It is likely that more than one of these attributes exist in a
Session-Resource-Reponse.
AVP Format
Calhoun expires August 1999 [Page 15]
INTERNET DRAFT February 1999
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 'P' bits
MUST NOT be 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 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 two (2).
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
Calhoun expires August 1999 [Page 16]
INTERNET DRAFT February 1999
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.
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.
Calhoun expires August 1999 [Page 17]
INTERNET DRAFT February 1999
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
[1] Calhoun, Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-08.txt, Work in Progress,
February 1999.
[2] Calhoun, Bulley, "DIAMETER Autentication Extensions",
draft-calhoun-diameter-auth-04.txt, Work in Progress,
July 1998.
[3] Calhoun, Zorn, Pan, "DIAMETER Framework",
draft-calhoun-diameter-framework-02.txt, Work in Progress,
December 1998.
6.0 Authors' Addresses
Questions about this memo can be directed to:
Calhoun expires August 1999 [Page 18]
INTERNET DRAFT February 1999
Pat R. Calhoun
Network and Security Research Center, Sun Labs
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 August 1999 [Page 19]