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]