idnits 2.17.1 draft-calhoun-diameter-res-mgmt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 118: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 121: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 127: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 129: '...hich does not include this option MUST...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 650, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-03 -- Possible downref: Normative reference to a draft: ref. '1' -- No information found for draft-calhoun-diameter-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-00 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-res-mgmt-01.txt Nancy Greene 5 Date: May 1998 Nortel 7 DIAMETER 8 Resource Management Extensions 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Abstract 33 DIAMETER is a policy protocol used between a client and a server for 34 authentication, authorization and accounting of various services. 35 Examples of such services are for dial-up users (ROAMOPS), RSVP 36 Admission Policies (RAP), FAX Over IP (FAXIP), Voice over IP 37 (SIPTel), Integrated services, etc. 39 This document defines a set of commands which allow DIAMETER servers 40 to maintain session state information. An example of the use of 41 Resource Management would be to limit the number of sessions for a 42 given user. 44 Table of Contents 46 1.0 Introduction 47 1.1 Specification of Requirements 48 1.2 Concept of a session 49 2.0 Command Codes 50 2.1 Session-Free-Request 51 2.2 Session-FreeResponse 52 2.3 Query-Resource-Request 53 2.4 Query-Resource-Response 54 2.5 Resource-Reclaim-Request 55 3.0 DIAMETER AVPs 56 3.1 Query-Index 57 3.2 Resource-Token 58 4.0 Protocol Definition 59 4.1 Session Free 60 4.2 Relinquish Session 61 4.3 Interaction with Device-Reboot-Indication 62 4.4 State Resync 63 5.0 References 64 6.0 Authors' Addresses 66 1.0 Introduction 68 Many services requiring Policy Server Support require the server to 69 maintain session state information. This can only be achieved if the 70 protocol has built-in mechanism to allow both the client and the 71 server to resync its state information. A message set is also 72 required to allow the client to inform the server when a session has 73 terminated. 75 An example of such a requirement is in the dial-up PPP world. With 76 the introduction of flat-rate internet access, there has been a surge 77 in fraud that allows a user to provide his username/password pair to 78 other people. The end result is that a single username can have 79 simultaneous concurrent sessions. 81 It is desirable for the Policy Server to maintain a list of the 82 active sessions so it can detect whether a user is attempting 83 fraudulent activities, and restrict the user to a single login. 85 Internet Service Providers have had to implement this functionality 86 using other less-reliable schemes in the past. Unfortunately, those 87 schemes are known to be problematic and therefore a standard method 88 of maintaining state information is desired. 90 The DIAMETER Resource Management extensions are intended to provide 91 the functionality required to have stateful Policy Servers. This 92 document does not specify what resources can be managed by a server 93 since it is service specific, but it does provide the tools required 94 for the services that require it. 96 When reading this document the reader should keep in mind that the 97 authorization of a session by the server is analogous to the 98 allocation of resources. This document does not deal with the 99 allocation of any resources and is simply a complement to the service 100 extension that requires stateful servers. 102 Message sets and the AVPs used for session setup and resource 103 allocation vary depending on the type of service a session is being 104 created for. The general concept of a session is described in this 105 document, and specific message sets for session setup and resource 106 allocation are found in other extension documents, for example, in 107 [2]. 109 1.1 Specification of Requirements 111 In this document, several words are used to signify the requirements 112 of the specification. These words are often capitalized. 114 MUST This word, or the adjective "required", means that the 115 definition is an absolute requirement of the 116 specification. 118 MUST NOT This phrase means that the definition is an absolute 119 prohibition of the specification. 121 SHOULD This word, or the adjective "recommended", means that 122 there may exist valid reasons in particular circumstances 123 to ignore this item, but the full implications must be 124 understood and carefully weighed before choosing a 125 different course. 127 MAY This word, or the adjective "optional", means that this 128 item is one of an allowed set of alternatives. An 129 implementation which does not include this option MUST 130 be prepared to interoperate with another implementation 131 which does include the option. 133 1.2 Concept of a session 135 A session defines a thread of Diameter messages. All messages related 136 to a particular session MUST include a Session-Id. (Session-Id is 137 described in [1]). A session can be established by either a client or 138 a server. The Session-Id is assigned by the initiator of the session. 139 Resources can be added to, deleted from, or modified in a session. 140 How this is done for a particular service is described in the 141 relevant extensions document. For example, [2] describes session 142 setup and resource allocation for user authentication and 143 authorization. 145 This document describes the more general functions of querying for 146 information on allocated resources, and freeing a session. 148 2.0 Command Codes 150 This document defines the following DIAMETER Commands. All DIAMETER 151 implementations supporting this extension MUST support all of the 152 following commands: 154 Command Name Command Code 155 ----------------------------------- 156 Session-Free-Request 266 157 Session-Free-Response 267 158 Query-Resource-Request 268 159 Query-Resource-Response 269 160 Resource-Reclaim-Request 270 162 2.1 Session-Free-Request 164 Description 166 The Session-Free-Request message is normally sent by a DIAMETER 167 client to a server, and provides information on specific resources 168 which have been released. 170 The Session-Free-Request message MUST include the Host-IP-Address 171 or the Host-Name as well as the Session-Id AVPs. The Session-Id is 172 used by the server to identify a specific session that was 173 previously authorized. 175 Upon receipt of this message the server MUST free any resources 176 that were previously allocated to the session during the session 177 authorization and respond with the Session-Free-Response. 179 The Session-Free-Request MAY contain the Result-Code AVP if it is 180 a result of a Session-Reclaim-Request. 182 A summary of the Session-Free-Request packet format is shown 183 below. The fields are transmitted from left to right. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | AVP Code | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | AVP Length | AVP Flags | Reserved | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Command Code | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 AVP Code 197 256 DIAMETER Command 199 AVP Length 201 The length of this attribute MUST be 12. 203 AVP Flags 205 The flag field MUST have bit one (Mandatory Support) set. 207 Command Code 209 The Command Code field MUST be set to 266 (Session-Free-Request). 211 2.2 Session-Free-Response 213 Description 215 The Session-Free-Response message is sent by the DIAMETER Server 216 to the client to acknowledge the receipt of the Session-Free- 217 Response message. The Result-Code AVP, which MUST be present in 218 the Session-Free-Response, is used in order to identify whether 219 the Server was able to free the resources associated with the 220 Session-Id. The Host-IP-Address or the Host-Name AVP MUST be 221 present in this message. 223 The following Error Codes are defined for the Session-Free- 224 Response message: 226 DIAMETER_ERROR_ALREADY_FREE 1 227 The Session Identifier has already been freed. 229 A summary of the Session-Free-Response packet format is shown 230 below. The fields are transmitted from left to right. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | AVP Code | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | AVP Length | AVP Flags | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Command Code | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 AVP Code 244 256 DIAMETER Command 246 AVP Length 248 The length of this attribute MUST be 12. 250 AVP Flags 252 The flag field MUST have bit one (Mandatory Support) set. 254 Command Code 256 The Command Code field MUST be set to 267 (Session-Free-Response). 258 2.3 Query-Resource-Request 260 Description 262 The Query-Resource-Request message is sent by a DIAMETER Server to 263 a client. This event MAY occur when a Server has lost its state 264 information and wishes to rebuild the information. However, it is 265 valid for a server to send a request periodically to clients to 266 refresh its state information. 268 The presence of one or more Session-Id AVP in the Query- 269 Resource-Request indicates that the server only wants to receive 270 the Resource-Token for the specified session(s). 272 The initial Query-Resource-Request message MUST contain the Host- 273 IP-Address and the Host-Name AVPs and a Query-Index AVP with a 274 value of zero (see section 4.4 for more info). The Query-Index AVP 275 is used by the client as a placeholder in subsequent Query- 276 Resource-Requests in order to identify which Resource-Token to 277 send to the server. 279 When the client receives a non-zero Query-Index AVP, it MUST 280 include Resource-Tokens beginning at the placeholder associated 281 with the value of the Query-Index AVP. 283 A non-zero Query-Index AVP is sent to the DIAMETER Server in the 284 Query-Resource-Response when the client is unable to include all 285 of the Resource-Tokens within a single response. 287 Once a DIAMETER Server has rebooted or lost its state information 288 for any reason, it is recommended that the Server issue a Query- 289 Resource-Request and receive a valid response from a specific 290 client prior to processing any authorization messages from the 291 client. 293 A summary of the Query-Resource-Request packet format is shown 294 below. The fields are transmitted from left to right. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | AVP Code | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | AVP Length | AVP Flags | Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Command Code | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 AVP Code 308 256 DIAMETER Command 310 AVP Length 312 The length of this attribute MUST be 12. 314 AVP Flags 316 The flag field MUST have bit one (Mandatory Support) set. 318 Command Code 320 The Command Code field MUST be set to 268 (Query-Resource- 321 Request). 323 2.4 Query-Resource-Response 324 Description 326 Upon receipt of a Query-Resource-Request, each client is 327 responsible to respond with all of the Resource-Tokens for active 328 sessions that were previously allocated by the requesting server. 329 The message MUST include the Query-Index, a Result-Code AVP, a 330 Host-IP-Address or Host-Name AVPs and one or more Resource-Token 331 AVPs. 333 Since more than one Resource-Token AVP may be returned within a 334 Query-Resource-Response, it is likely that the total packet length 335 would exceed the interface's MTU. It is required to make use of 336 the Query-Index AVP in order to request that the server issue a 337 subsequent Query-Resource-Request. The value of the Query-Index 338 MUST be duplicated in the subsequent Query-Resource-Request by the 339 Server in order for the client to know which Resource-Token to 340 start sending in the following response. 342 If the client was able to fit all of the Resource-Tokens within 343 the Query-Resource-Response it MUST include a Query-Index AVP with 344 a zero value. A zero Query-Index will inform the Server that it 345 SHOULD NOT issue another Query-Resource-Request. 347 A summary of the Query-Resource-Response packet format is shown 348 below. The fields are transmitted from left to right. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | AVP Code | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | AVP Length | AVP Flags | Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Command Code | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 AVP Code 362 256 DIAMETER Command 364 AVP Length 366 The length of this attribute MUST be 12. 368 AVP Flags 370 The flag field MUST have bit one (Mandatory Support) set. 372 Command Code 374 The Command Code field MUST be set to 269 (Query-Resource- 375 Response). 377 2.5 Session-Reclaim-Request 379 Description 381 The Session-Reclaim-Request message is sent by the DIAMETER Server 382 to the client to request that a previously authorized session be 383 freed immediately. This allows the server to free used resources 384 on the client without any manual intervention. 386 The Session-Reclaim-Request message MUST include a Host-IP-Address 387 and the Host-Name AVP and the Session-Id AVP that was used during 388 the session's authorization phase. 390 When a DIAMETER client receives this message it MUST responds with 391 a Session-Free-Request message. 393 A summary of the Resource-Reclaim-Request packet format is shown 394 below. The fields are transmitted from left to right. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | AVP Code | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | AVP Length | AVP Flags | Reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Command Code | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 AVP Code 408 256 DIAMETER Command 410 AVP Length 412 The length of this attribute MUST be 12. 414 AVP Flags 416 The flag field MUST have bit one (Mandatory Support) set. 418 Command Code 419 The Command Code field MUST be set to 270 (Query-Reclaim-Request). 421 3.0 DIAMETER AVPs 423 This section will define the mandatory AVPs which MUST be supported 424 by all DIAMETER implementations supporting this extension. The 425 following AVPs are defined in this document: 427 Attribute Name Attribute Code 428 ----------------------------------- 429 Query-Index 290 430 Resource-Token 291 432 3.1 Query-Index 434 Description 436 This attribute is used in conjunction with the Resource Query 437 mechanism and allows the client to exchange resource information 438 through more than one message exchange. 440 In the initial Query-Resource-Request, this attribute MUST be 441 present with a value of zero. Upon receipt of a Resource Query 442 Response command, the DIAMETER server must check if the attribute 443 is still set to zero. If the value is a non-zero, the DIAMETER 444 server MUST return a Query-Resource-Request with a Query-Index 445 value equal to the value which was set in the response. Upon 446 receipt of a zero, the DIAMETER Server MUST assume that this is 447 the last message exchange. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | AVP Code | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | AVP Length | AVP Flags | Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Integer32 | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 AVP Code 461 290 Query-Index 463 AVP Length 465 The length of this attribute MUST be at least 12. 467 AVP Flags 469 The flag field MUST have bit one (Mandatory Support) set. 471 Integer32 473 The Integer32 field contains a value that has local significance 474 to client in order to identify which Resource-Token to send in the 475 subsequent Query-Resource-Request. 477 3.2 Resource-Token 479 Description 481 The Resource-Token AVP is returned by the DIAMETER Server to the 482 client during authorization (or session setup). The Resource-Token 483 is subsequently used during the Query-Resource-Response in order 484 to hand the Server with enough information to rebuild its state 485 information. 487 The data portion of this AVP includes AVPs and at a minimum MUST 488 include the Session-Id AVP, the Host-IP-Address or Host-Name AVP 489 and the Service-Id. Each service MUST define what AVPs must be 490 included in the Resource-Token in order for the Resource 491 Management extension to work for the specific service. 493 It is likely that more than one of these attributes exist in a 494 Query-Resource-Response. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | AVP Code | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | AVP Length | AVP Flags | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Data ... 504 +-+-+-+-+-+-+-+-+ 506 AVP Code 508 291 Resource-Token 510 AVP Length 512 The length of this attribute MUST be at least 9. 514 AVP Flags 516 The flag field MUST have bit one (Mandatory Support) set. 518 Data 520 The Data field contains the Resource-Token that was returned by 521 the DIAMETER Server during the authorization phase. 523 4.0 Protocol Definition 525 This section will outline how the DIAMETER Resource Management 526 Extension can be used. 528 4.1 Session Free 530 Upon session termination, a Session-Free-Request message is issue by 531 the client to the DIAMETER Server and MUST contain the Session-Id AVP 532 that was used during the authorization phase of the session. 534 The format of the Session-Free-Request message is as follows: 536 ::= 537 538 540 The format of the Session-Free-Response message is as follows: 542 ::= 543 544 546 4.2 Relinquish Session 548 When the server wants the client to relinquish an existing session, 549 the Server issues a Session-Reclaim-Request to the client. The 550 request MUST contain the Session-Id AVP that was used during the 551 authorization phase of the session. 553 The client MUST respond with a Session-Free-Request message. The 554 request MUST contain the Result-Code when it is a response to a 555 Session-Reclaim-Request to indicate whether it was able to free the 556 requested session. The Server MUST respond with the Session-Free- 557 Response. 559 DIAMETER Server DIAMETER Client 560 --------------- --------------- 561 Session-Reclaim-Request --> 562 <-- Session-Free-Request (Result = 0) 563 Session-Free-Response (Result = 0) --> 565 The format of the Session-Reclaim-Request message is as follows: 567 Session-Reclaim-Request ::= 568 569 571 In the roaming scenario the Session-Reclaim-Request message is 572 problematic since it is difficult to identify the target client's 573 proxy chain. This can be achieved by including the Host Name of the 574 client that was found in the authorization request within the Host- 575 Name AVP. 577 4.3 Interaction with Device-Reboot-Indication 579 When a DIAMETER Server receives a Device-Reboot-Indication it MUST 580 assume that all resources currently allocated to the rebooted client 581 MUST be freed. 583 4.4 State Resync 585 The DIAMETER Server requires a flag in the client database in order 586 to identify whether the client has responded to the Query-Resource- 587 Request. Upon receipt of an Authorization message that requires 588 Resource Management, the Server MUST issue a Query-Resource-Request 589 if the client has not previously responded to such requests. 591 A client MUST respond to a Query-Resource-Request with all of the 592 active Resource-Tokens that have previously been allocated by the 593 requesting server. Since the number of active Resource-Tokens MAY be 594 larger than the interface's MTU, it is required to make use of the 595 Query-Index AVP. 597 The following is an example of an exchange between a Server and a 598 Client that has 26 Resource-Tokens which is too many to fit within a 599 single response. 601 DIAMETER Server DIAMETER Client 602 --------------- --------------- 603 Query-Resource-Request (Index = 0) --> 604 <-- Query-Resource-Response (Index = 10) 605 Query-Resource-Request (Index = 10) --> 606 <-- Query-Resource-Response (Index = 20) 607 Query-Resource-Request (Index = 20) --> 608 <-- Query-Resource-Response (Index = 0) 610 In the above scenario, the Server issues the initial Query-Resource- 611 Request with a zero Query-Index. The client responds but since it can 612 only fit Resource-Tokens 1 through 9, it sets the Query-Index to 10 613 in the Query-Resource-Response. 615 Upon receipt of the response the server processes the message and 616 issues another Query-Resource-Request with the Query-Index value set 617 to 10. The client, upon receipt of the request, knows that it needs 618 to include the Resource-Tokens starting at 10. Again, since the 619 client can only include the Resource-Tokens up to 19, it sets the 620 Query-Index to 20. 622 The Server issues another Query-Resource-Request with the Query-Index 623 set to 20. At this point the client can fit the remaining Resource- 624 Tokens (20 through 26) and therefore sets the Query-Index to zero to 625 indicate that it has sent all of it's active Resource-Tokens. 627 The format of the Query-Resource-Request is as follows: 629 ::= 630 631 [] 632 [] 633 [] 635 The format of the Query-Resource-Response message is as follows: 637 ::= 638 639 640 [] 641 [] 642 [] 644 5.0 References 646 [1] Calhoun, Rubens, "DIAMETER", Internet-Draft, 647 draft-calhoun-diameter-03.txt, May 1998. 648 [2] Calhoun, Bulley, "DIAMETER Autentication Extensions", 649 Internet-Draft, draft-calhoun-diameter-auth-03.txt, May 1998. 650 [3] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 651 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 653 6.0 Authors' Addresses 655 Questions about this memo can be directed to: 657 Pat R. Calhoun 658 Technology Development 659 Sun Microsystems, Inc. 660 15 Network Circle 661 Menlo Park, California, 94025 662 USA 664 Phone: 1-650-786-7733 665 Fax: 1-650-786-6445 666 E-mail: pcalhoun@eng.sun.com 668 Nancy Greene 669 Public Data Networks 670 Nortel (Northern Telecom) 671 PO Box 3511 Station C 672 Ottawa, Ontario K1Y 4H7 673 Canada 675 Phone: 1-613-763-9789 676 Fax: 1-613-763-8904 677 E-mail: ngreene@nortel.ca