One document matched: draft-calhoun-diameter-res-mgmt-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 06:01:24 |