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]