idnits 2.17.1 draft-calhoun-diameter-res-mgmt-02.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 16 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 17 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 4 instances of too long lines in the document, the longest one being 6 characters 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 117: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 121: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 124: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 130: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 132: '...hich does not include this option MUST...' (60 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 754, 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-02.txt Nancy Greene 5 Date: July 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 months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 DIAMETER is a policy protocol used between a client and a server for 32 authentication, authorization and accounting of various services. 33 Examples of such services are for dial-up users (ROAMOPS), RSVP 34 Admission Policies (RAP), FAX Over IP (FAXIP), Voice over IP 35 (SIPTel), Integrated services, etc. 37 This document defines a set of commands which allow DIAMETER servers 38 to maintain session state information. An example of the use of 39 Resource Management would be to limit the number of sessions for a 40 given user. 42 Table of Contents 44 1.0 Introduction 45 1.1 Specification of Requirements 46 1.2 Concept of a session 47 2.0 Command Codes 48 2.1 Session-Free-Request 49 2.2 Session-Free-Answer 50 2.3 Session-Resource-Query 51 2.4 Session-Resource-Reply 52 2.5 Resource-Reclaim-Request 53 2.6 Resource-Reclaim-Answer 54 3.0 DIAMETER AVPs 55 3.1 Query-Index 56 3.2 Resource-Token 57 4.0 Protocol Definition 58 4.1 Feature Advertisement/Discovery 59 4.2 Session Free 60 4.3 Relinquish Session 61 4.4 Interaction with Device-Reboot-Indication 62 4.5 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 The Extension number for this draft is two (2). This value is used in 110 the Extension-Id AVP as defined in [2]. 112 1.1 Specification of Requirements 114 In this document, several words are used to signify the requirements 115 of the specification. These words are often capitalized. 117 MUST This word, or the adjective "required", means that the 118 definition is an absolute requirement of the 119 specification. 121 MUST NOT This phrase means that the definition is an absolute 122 prohibition of the specification. 124 SHOULD This word, or the adjective "recommended", means that 125 there may exist valid reasons in particular circumstances 126 to ignore this item, but the full implications must be 127 understood and carefully weighed before choosing a 128 different course. 130 MAY This word, or the adjective "optional", means that this 131 item is one of an allowed set of alternatives. An 132 implementation which does not include this option MUST 133 be prepared to interoperate with another implementation 134 which does include the option. 136 1.2 Concept of a session 138 A session defines a thread of Diameter messages. All messages related 139 to a particular session MUST include a Session-Id. (Session-Id is 140 described in [1]). A session can be established by either a client or 141 a server. The Session-Id is assigned by the initiator of the session. 142 Resources can be added to, deleted from, or modified in a session. 143 How this is done for a particular service is described in the 144 relevant extensions document. For example, [2] describes session 145 setup and resource allocation for user authentication and 146 authorization. 148 This document describes the more general functions of querying for 149 information on allocated resources, and freeing a session. 151 2.0 Command Codes 153 This document defines the following DIAMETER Commands. All DIAMETER 154 implementations supporting this extension MUST support all of the 155 following commands: 157 Command Name Command Code 158 ----------------------------------- 159 Session-Free-Request 266 160 Session-Free-Answer 267 161 Session-Resource-Query 268 162 Session-Resource-Reply 269 163 Resource-Reclaim-Request 270 164 Resource-Reclaim-Answer 271 166 2.1 Session-Free-Request (SFR) 168 Description 170 The Session-Free-Request message is normally sent by a DIAMETER 171 client to a server, and provides information on specific resources 172 which have been released. 174 The Session-Free-Request message MUST include the Host-IP-Address 175 or the Host-Name as well as the Session-Id AVPs. The Session-Id is 176 used by the server to identify a specific session that was 177 previously authorized. 179 Upon receipt of this message the server MUST free any resources 180 that were previously allocated to the session during the session 181 authorization and respond with the Session-Free-Answer. 183 The Session-Free-Request MAY contain the Result-Code AVP if it is 184 a result of a Session-Reclaim-Request. 186 Message Format 188 ::= 189 190 191 192 193 { || 194 ::= 251 252 253 254 255 { || 256 329 330 [] 331 [] 332 [] 333 334 335 { || 336 399 400 401 [] 402 [] 403 [] 404 405 406 { || 407 459 460 461 462 463 { || 464 510 511 512 513 514 { || 515 723 <-- Reboot-Ack (w/ Res-Mgmt Ext. Id) 724 Session-Resource-Query (Index = 0) --> 725 <-- Session-Resource-Query-Reply (Index = 10) 726 Session-Resource-Query (Index = 10) --> 727 <-- Session-Resource-Query-Reply (Index = 20) 728 Session-Resource-Query (Index = 20) --> 729 <-- Session-Resource-Query-Reply (Index = 0) 731 In the above scenario, the Server issues the initial Session- 732 Resource-Query with a zero Query-Index. The client responds but since 733 it can only fit Resource-Tokens 1 through 9, it sets the Query-Index 734 to 10 in the Session-Resource-Query-Reply. 736 Upon receipt of the response the server processes the message and 737 issues another Session-Resource-Query with the Query-Index value set 738 to 10. The client, upon receipt of the request, knows that it needs 739 to include the Resource-Tokens starting at 10. Again, since the 740 client can only include the Resource-Tokens up to 19, it sets the 741 Query-Index to 20. 743 The Server issues another Session-Resource-Query with the Query-Index 744 set to 20. At this point the client can fit the remaining Resource- 745 Tokens (20 through 26) and therefore sets the Query-Index to zero to 746 indicate that it has sent all of it's active Resource-Tokens. 748 5.0 References 750 [1] Calhoun, Rubens, "DIAMETER", Internet-Draft, 751 draft-calhoun-diameter-03.txt, May 1998. 752 [2] Calhoun, Bulley, "DIAMETER Autentication Extensions", 753 Internet-Draft, draft-calhoun-diameter-auth-03.txt, May 1998. 754 [3] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 755 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 757 6.0 Authors' Addresses 759 Questions about this memo can be directed to: 761 Pat R. Calhoun 762 Technology Development 763 Sun Microsystems, Inc. 764 15 Network Circle 765 Menlo Park, California, 94025 766 USA 768 Phone: 1-650-786-7733 769 Fax: 1-650-786-6445 770 E-mail: pcalhoun@eng.sun.com 772 Nancy Greene 773 Public Data Networks 774 Nortel (Northern Telecom) 775 PO Box 3511 Station C 776 Ottawa, Ontario K1Y 4H7 777 Canada 779 Phone: 1-613-763-9789 780 Fax: 1-613-763-8904 781 E-mail: ngreene@nortel.ca