idnits 2.17.1 draft-calhoun-diameter-accounting-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: '4' is defined on line 609, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 612, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-05 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-11 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2138 (ref. '4') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '5') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-05 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-07 -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Informational draft: draft-ietf-aaa-acct (ref. '11') ** Obsolete normative reference: RFC 2393 (ref. '12') (Obsoleted by RFC 3173) Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Jari Arkko 3 Category: Standards Track Oy LM Ericsson Ab 4 Title: draft-calhoun-diameter-accounting-08.txt Pat R. Calhoun 5 Date: September 2000 Sun Microsystems, Inc. 6 Pankaj Patel 7 Convergys Corporation 8 Glen Zorn 9 Cisco Systems, Inc. 11 DIAMETER Accounting Extension 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 This document is an individual contribution for consideration by the 35 AAA Working Group of the Internet Engineering Task Force. Comments 36 should be submitted to the diameter@diameter.org mailing list. 38 Distribution of this memo is unlimited. 40 Copyright (C) The Internet Society 1999. All Rights Reserved. 42 Abstract 44 The DIAMETER protocol provides Authentication and Authorization for 45 network access technologies, such as NASREQ, ROAMOPS and Mobile IP. 46 The ROAMOPS WG has been working on an accounting data format, called 47 Accounting Data Interchange Format (ADIF), as a method to transfer 48 accounting information over a wide variety of transports. 50 This extension describes how accounting records can be securely 51 transmitted over the DIAMETER protocol. When combined with the 52 Strong Security extension, accounting records MAY traverse 53 intermediate proxies in a secure fashion and is compatible with 54 the referral broker model. This extension allows for both 55 real-time and batched accounting transfers. 57 Table of Contents 59 1.0 Introduction 60 1.1 Requirements language 61 1.2 Authorization-Server Directed Model 62 1.3 Protocol Messages 63 1.4 Fault Resilience 64 1.5 Session Records 65 1.6 Accounting in brokering environments 66 2.0 Command-Codes Values 67 2.1 Accounting-Request (ACR) Command 68 2.2 Accounting-Answer (ACA) Command 69 2.3 Accounting-Poll-Ind (ACP) Command 70 2.4 Accounting-Status-Ind (ASI) Command 71 3.0 Mandatory AVPs 72 3.1 Accounting-Record-Type AVP 73 3.2 ADIF-Record AVP 74 3.3 Accounting-Interim-Interval AVP 75 3.4 Accounting-Delivery-Max-Batch AVP 76 3.5 Accounting-Delivery-Max-Delay AVP 77 3.6 Accounting-Record-Number AVP 78 3.7 Accounting-State AVP 79 4.0 IANA Considerations 80 5.0 Security Considerations 81 6.0 Acknowledgments 82 7.0 References 83 8.0 Authors' Addresses 84 9.0 Full Copyright Statement 86 1.0 Introduction 88 This accounting protocol is based on an authorization-server directed 89 model with capabilities for both efficient batch and fast real-time 90 delivery of accounting information. Several fault resilience methods 91 [11] have been built in to the protocol in order minimize loss of 92 accounting data in various fault situations and under different 93 assumptions about the capabilities of the used devices. 95 1.1 Requirements language 97 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 98 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 99 described in [6]. 101 1.2 Authorization-Server Directed Model 103 The authorization-server directed model means that at authorization 104 time, the device generating the accounting data gets information from 105 the authorization server regarding the way accounting data shall be 106 forwarded. This information includes accounting record timeliness 107 requirements. 109 As discussed in [11], batch transfer of accounting data is more CPU- 110 and bandwidth efficient than real-time transfer. However, there are 111 many applications where real-time transfer is a requirement for at 112 least some of the accounting records. These applications include 113 roaming, where most (local) accounting records can be transferred in 114 batch mode, but roaming (visiting) accounting records should be 115 transferred fast due to the needs of credit limit checks and fraud 116 detection. For these reasons this accounting protocol defines both 117 batch and real-time transfer modes, and allows their use 118 simultaneously. The authorization server (chain) directs the 119 selection of proper transfer strategy, based on its knowledge of the 120 user and relationships of roaming partnerships. The server (or 121 proxies in between) use the Accounting-Delivery-Max-Batch, 122 Accounting-Delivery-Max-Delay, and Accounting-Interim-Interval AVPs 123 to control the operation of the DIAMETER peer operating as a client. 124 The first two AVPs set the requirements in terms of number of records 125 and maximum delay before accounting data transfer for this session 126 SHOULD begin. The DIAMETER peer acting as a client MAY deliver the 127 data earlier due to a full batch of records, device reboot, lack of 128 memory, or explicit configuration. The DIAMETER client MUST begin the 129 transfer in the given limits unless prevented from doing so by 130 network partitions, failures of peers, network congestion, or client 131 overload. 133 The Accounting-Interim-Interval AVP, when present, instructs the 134 DIAMETER node acting as a client to produce accounting records 135 continuously even during a session. 137 Typically, the authorization server uses a few batching/real-time 138 classes, such as the local users whose data might be transferred once 139 in an hour and the roaming users whose data would be transferred 140 immediately. Each Accounting-Delivery-Max-Batch / Accounting- 141 Delivery-Max-Delay AVP pair with different values forms one pool of 142 accounting data in the DIAMETER node acting as a client. That is, a 143 new record is placed to same pool as the previous one if the 144 authorization server returned same values for both AVPs and the pool 145 has not been emptied in between. 147 The Extension number for this draft is five (5). This value is used 148 in the Extension-Id Attribute value Pair (AVP) as defined in [1]. 150 1.3 Protocol Messages 152 The DIAMETER peer, acting as a client, generating the accounting data 153 will use the Accounting-Request message to send one or more 154 accounting records to its peer. The receiver (server) MUST reply with 155 the Accounting-Answer message with appropriate confirmations. 157 It is possible that a DIAMETER Proxy breaks up a batch of accounting 158 records and sends them towards different DIAMETER Home servers. In 159 this case, it is possible that a separate Accounting-Answer message 160 contain the response for each block. Therefore, a DIAMETER node MUST 161 be prepared to handle this scenario. 163 Upon receipt of an Accounting-Request, a home DIAMETER server MUST 164 generate a response. A home server is the node that "owns" the realm 165 portion of the user's NAI. The response includes the Result-Code, 166 which MAY contain an error if the ADIF-Record, or some other AVP, is 167 not acceptable. 169 Each DIAMETER Accounting protocol message MAY be compressed using 170 IPComp [12] in order to reduce the used network bandwidth. DIAMETER 171 peers MUST use a negotiation mechanisms such as IKE [7] in order to 172 ensure that both peers are able to handle IPComp. 174 1.4 Fault Resilience 176 DIAMETER Base protocol [11] mechanisms are used to overcome small 177 message loss and network faults of temporary nature. 179 DIAMETER peers acting as clients MUST implement the use of alternate 180 servers to guard against server failures and certain network 181 failures. DIAMETER peers acting as servers or related off-line 182 processing systems MUST detect duplicate accounting records caused by 183 the sending of same record to several servers and duplication of 184 messages in transit. This detection MUST be based on the inspection 185 of the Session-Id [1] and Accounting-Record-Number AVP pairs. 187 DIAMETER clients MAY have non-volatile memory for the safe storage of 188 accounting records over reboots or extended network failures, network 189 partitions, and server failures. If such memory is available the 190 client SHOULD store new accounting records there as soon as the 191 records are created and until a positive acknowledgement of their 192 reception from the DIAMETER Server has been received. Upon a reboot, 193 the client MUST starting sending the records in the non-volatile 194 memory to the accounting server with appropriate modifications in 195 termination cause, session length, and other relevant information in 196 the records. 198 A further extension of this protocol may include AVPs to control how 199 many accounting records may at most be stored in the DIAMETER client 200 without committing them to the non-volatile memory or transferring 201 them to the DIAMETER server. 203 The client SHOULD NOT remove the accounting data from any of its 204 memory areas before the correct Accounting-Answer has been received. 205 The client MAY remove oldest, undelivered or yet unacknowledged 206 accounting data if it runs out of resources such as memory. It is an 207 implementation dependent matter for the client to accept new sessions 208 under this condition. 210 1.5 Session Records 212 In all accounting records the Session-Id AVP, ADIF-Record AVP, and 213 User-Name AVPs MUST be present. If strong authentication is required, 214 as described in [9], the CMS-Data AVP may be used to authenticate the 215 ADIF-Record AVP. It is not typically necessary, nor recommended, that 216 the strong authentication cover any additional AVPs since the ADIF- 217 Record, and associated CMS-Data, MAY need to be submitted to a third 218 party (see section 1.6 below). 220 However, if the accounting records are being in sent in batch mode, 221 the sender can create several "blocks" of accounting records by 222 encapsulating each "block" within a separate Grouped-AVP AVP, each 223 with an optional CMS-Data AVP [9]. If it is known that multiple 224 ADIF-Records are being sent to the same home DIAMETER server, it is 225 possible to have one CMS-Data AVP cover multiple the ADIF-Records. 226 This optimization reduces the crypto computation that would otherwise 227 be necessary. 229 Different types of session records are sent depending on the actual 230 type of accounted service and the authorization server's directions 231 for interim accounting. If the accounted service is a one-time event, 232 meaning that the start and stop of the event are simultaneous, then 233 the Accounting-Record-Type AVP MUST be present and set to the value 234 EVENT_RECORD. 236 If the accounted service is of a measurable length, then the AVP MUST 237 use the values START_RECORD, STOP_RECORD, and possibly, 238 INTERIM_RECORD. If the authorization server has directed interim 239 accounting to be enabled for the session, but no interim interval was 240 specified, two accounting records MUST be generated for each service 241 of type session. When the initial Accounting-Request is sent for a 242 given session is sent, the Accounting-Record-Type AVP MUST be set to 243 the value START_RECORD. When the last Accounting-Request is sent, the 244 value MUST be STOP_RECORD. 246 If a specified interim interval exists, the DIAMETER client MUST 247 produce additional records between the START_RECORD and STOP_RECORD, 248 marked INTERIM_RECORD. The production of these records is directed 249 both by Accounting-Interim-Interval as well as any re-authentication 250 or re-authorization of the session. If a batch size of greater than 251 1 has been specified by the authorization server, then the DIAMETER 252 client MUST ensure that new interim records overwrite previous 253 interim records for the same session and batch as this reduces the 254 amount of memory required to store the records. In effect, this means 255 that interim records are delivered at least as often as dictated by 256 Accounting-Delivery-Max-Delay. 258 1.6 Accounting in brokering environments 260 The DIAMETER base protocol [1] describes brokers that provide 261 redirect services, by allowing AAA servers within a roaming 262 consortium to directly communicate. Referral services can be secured 263 using the strong security extension defined in [9]. Since brokers can 264 also provide settlement services, they typically need to be aware of 265 the accounting information exchange, and since they are no longer 266 part of the message exchange, the DIAMETER protocol MUST allow the 267 broker to receive the accounting record. The strong security [9] 268 provides the broker with the assurances it needs that both parties 269 agreed with the accounting information submitted. 271 When the local AAA server issues an Accounting-Request to the home 272 AAA server, it includes an ADIF-Record AVP as well as a CMS-Data AVP 273 [9], which contains the signature of the local AAA server. The home 274 server MUST add it's own signature to the CMS-Data AVP, that covers 275 both the ADIF-Record and the local AAA's signature. The whole is 276 submitted to the local AAA server in the Accounting-Answer. The local 277 AAA server MUST submit the ADIF-Record, and associated CMS-Data AVP 278 to the broker. The broker can verify that both parties participated 279 and accepted the accounting record, by validating the signatures. 281 2.0 Command-Codes Values 283 This section defines new Command-Code [1] values that MUST be 284 supported by all DIAMETER implementations that conform to this 285 specification. The following Command Codes are currently defined in 286 this document: 288 Command-Name Abbrev. Code Reference 289 -------------------------------------------------------- 290 Accounting-Request ACR 271 2.1 291 Accounting-Answer ACA 272 2.2 292 Accounting-Poll-Ind ACP 273 2.3 293 Accounting-Status-Ind ASI 279 2.4 295 2.1 Accounting-Request (ACR) Command 297 The Accounting-Request command, indicated by the Command-Code field 298 set to 271, is sent by a DIAMETER node, acting as a client, in order 299 to exchange accounting information with a peer. The Accounting 300 information is contained within an ADIF record, as described in [10]. 302 The Accounting-Request command MAY contain accounting information for 303 more than a single session, which allows it to send batched 304 accounting information. When the batch mode is used, the session-Id 305 AVP [1], the ADIF-Record AVP and the optional CMS-Data AVP [9] MUST 306 be encapsulated within a Grouped-AVP AVP [1]. When the Accounting- 307 Request is being submitted to a broker, and includes the CMS-Data AVP 308 [9], the CMS-Data AVP MUST be signed by both the local and home 309 DIAMETER server using the countersignature procedures described in 310 [9]. 312 Message Format 314 ::= 315 316 && 318 && 319 && 320 && 321 && 322 323 } 324 [ 325 326 ] 328 2.2 Accounting-Answer (ACA) Command 330 The Accounting-Answer command, indicated by the Command-Code field 331 set to 272, is used to acknowledge an Accounting-Request command. The 332 Accounting-Answer command contains the same Session-Id and ADIF- 333 Record AVPs that were sent in the Accounting-Request command. If the 334 CMS-Data AVP was present in the Accounting-Request, the corresponding 335 ACA message MUST include the CMS-Data AVP signed by the responder to 336 provide strong AVP authentication, which MAY be used for the purposes 337 of repudiation. 339 Only the target DIAMETER Server, known as the home DIAMETER Server, 340 SHOULD respond with the Accounting-Answer command. However, if a 341 DIAMETER node in the proxy chain stores the accounting records for 342 submission to the home network in batched mode, it MUST respond to 343 the request. 345 If the Accounting-Request command contained more than one ADIF-Record 346 AVP, the Accounting-Answer SHOULD contain the same number of ADIF- 347 Record AVPs. However, it is possible for the DIAMETER Server to 348 acknowledge each ADIF-Record in a separate response. This allows the 349 sender of the ADIF-Records to send a batch of records, whose final 350 destination are different. 352 Message Format 354 ::= 355 356 357 358 && 360 && 361 && 362 363 } 364 [ 365 366 ] 368 2.3 Accounting-Poll-Ind (ACP) Command 370 The Accounting-Poll-Ind command, indicated by the Command-Code field 371 set to 273, is sent by a DIAMETER Server in order to force the peer 372 to send current accounting data. This data MUST include not yet sent 373 accounting records from completed sessions, as well as INTERIM_RECORD 374 records from all ongoing sessions. 376 The receiver MUST use the Accounting-Request command to send the 377 accounting data. 379 The use of Accounting-Poll-Ind is useful in situations where a 380 DIAMETER server comes up after an unscheduled downtime, and wishes to 381 synchronize with the client(s) sooner than at the end of the next 382 INTERIM_RECORD or at the end of a session. 384 Warning: The use of the Accounting-Poll-Ind message is discouraged in 385 roaming networks, since it is unfeasible for a server to attempt to 386 poll all of it's roaming partner's DIAMETER peers. 388 Message Format 390 ::= 391 392 393 [ 394 395 ] 397 2.4 Accounting-Status-Ind (ASI) Command 398 The Accounting-Status-Ind command, indicated by the Command-Code 399 field set to 279, is sent by a DIAMETER node in order to inform its 400 peer of whether Accounting messages will be sent in the future. A 401 DIAMETER node that is about to be taken out of service SHOULD issue 402 an Accounting-Status-Ind message, with the Accounting-State AVP set 403 to DISABLED. A DIAMETER node that detected that it is able to issue 404 Accounting messages MUST issue an Accounting-Status-Ind message, with 405 the Accounting-State AVP set to ENABLED. 407 Message Format 409 ::= 410 411 [] 412 413 [ 414 415 ] 417 3.0 Mandatory AVPs 419 The following table describes the DIAMETER AVPs defined in the 420 Accounting extension, their AVP Code values, types, possible flag 421 values and whether the AVP MAY be encrypted. 423 +---------------------+ 424 | AVP Flag rules | 425 |----+-----+----+-----|----+ 426 AVP Section Value | | |SHLD| MUST|MAY | 427 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 428 -----------------------------------------|----+-----+----+-----|----| 429 Accounting- 480 3.1 Integer32| M | P | | V | Y | 430 Record-Type | | | | | | 431 ADIF-Record 481 3.2 Data | M | P | | V | Y | 432 Accounting- 482 3.3 Integer32| M | P | | V | Y | 433 Interim-Interval | | | | | | 434 Accounting- 483 3.4 Integer32| M | P | | V | Y | 435 Delivery-Max-Batch | | | | | | 436 Accounting- 484 3.5 Integer32| M | P | | V | Y | 437 Delivery-Max-Delay | | | | | | 438 Accounting- 485 3.6 Integer32| M | P | | V | Y | 439 Record-Number | | | | | | 440 Accounting-State 486 3.7 Integer32| M | P | | V | Y | 442 3.1 Accounting-Record-Type AVP 443 The Accounting-Record-Type AVP (AVP Code 480) is of type Integer32 444 and contains the type of accounting record that can be found in the 445 corresponding ADIF-Record AVP. The following values are currently 446 defined for the Accounting-Record-Type AVP: 448 EVENT_RECORD 1 449 An Accounting Event Record is used to indicate that a one-time 450 event has occurred (meaning that the start and end of the event 451 are simultaneous). This record contains all information 452 relevant to the service, and is the only record of the service. 454 START_RECORD 2 455 An Accounting Start, Interim, and Stop Records are used to 456 indicate that a service of a measurable length has been given. 457 An Accounting Start Record is used to initiate an accounting 458 session, and contains accounting information that is relevant 459 to the initiation of the session. 461 INTERIM_RECORD 3 462 An Interim Accounting Record contains cumulative accounting 463 information for an existing accounting session. Interim 464 Accounting Records SHOULD be sent every time a re- 465 authentication or re-authorization occurs. Further, additional 466 interim record triggers MAY be defined by application-specific 467 DIAMETER extensions. The selection of whether to use 468 INTERIM_RECORD records is directed by the Accounting-Interim- 469 Interval AVP. 471 STOP_RECORD 4 472 An Accounting Stop Record is sent to terminate an accounting 473 session and contains cumulative accounting information relevant 474 to the existing session. 476 3.2 ADIF-Record AVP 478 The ADIF-Record AVP (AVP Code 481) is of type Data and contains the 479 ADIF payload, as defined in [10]. 481 3.3 Accounting-Interim-Interval AVP 483 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 484 Integer32 and is sent from the DIAMETER authenticating/authorizing 485 server to the DIAMETER client. The client uses information in this 486 AVP to decide how and when to produce accounting records. With 487 different values in this AVP, service sessions can result in one, 488 two, or two+N accounting records, based on the needs of the home- 489 organization. The following accounting record production behaviour is 490 directed by the inclusion of this AVP: 492 1. The omission of the Accounting-Interim-Interval AVP or its 493 inclusion with Value field set to 0 means that EVENT_RECORD, 494 START_RECORD, and STOP_RECORD are produced, as appropriate for 495 the service. 497 2. The inclusion of the AVP with Value field set to a non-zero 498 value means that INTERIM_RECORD records MUST be produced 499 between the START_RECORD and STOP_RECORD records. The Value 500 field of this AVP is the nominal interval between these records 501 in seconds. The DIAMETER node that originates the accounting 502 information, known as the client, MUST produce the first 503 INTERIM_RECORD record roughly at the time when this nominal 504 interval has elapsed from the START_RECORD, the next one again 505 as the interval has elapsed once more, and so on until the 506 session ends and a STOP_RECORD record is produced. 508 The client MUST ensure that the interim record production times 509 are randomized so that large accounting message storms are not 510 created either among records or around a common service start 511 time. 513 3.4 Accounting-Delivery-Max-Batch AVP 515 The Accounting-Delivery-Max-Batch AVP (AVP Code 483) is of type 516 Integer32 and is included in an Accounting-Answer. This AVP controls 517 how accounting data is transferred to the accounting server. The AVP 518 sets the requirements in terms of number of locally collected records 519 before accounting data transfer SHOULD begin. The DIAMETER node that 520 receives this AVP MAY deliver the data earlier due to satisfying 521 requirements set by Accounting-Delivery-Max-Delay, device reboot, 522 lack of memory, or explicit configuration. The DIAMETER node MUST 523 begin the transfer in the given limits unless prevented from doing so 524 by network partitions, client or server failures, network congestion, 525 or client overload. 527 3.5 Accounting-Delivery-Max-Delay AVP 529 The Accounting-Delivery-Max-Delay AVP (AVP Code 484) is of type 530 Integer32 and is included in an Accounting-Answer. This AVP controls 531 how accounting data is transferred to the authorization request. The 532 AVP sets the requirements in terms of maximum delay before accounting 533 data transfer SHOULD begin. The DIAMETER node that receives this AVP 534 MAY deliver the data earlier due to satisfying requirements set by 535 Accounting-Delivery-Max-Batch, device reboot, lack of memory, or 536 explicit configuration. The DIAMETER node MUST begin the transfer in 537 the given limits unless prevented from doing so by network 538 partitions, client or server failures, network congestion, or client 539 overload. 541 3.6 Accounting-Record-Number AVP 543 The Accounting-Record-Number AVP (AVP Code 485) is of type Integer32 544 and identifies this record within one session. As Session-Id AVPs are 545 globally unique, the combination of Session-Id and Accounting- 546 Record-Number AVPs is also globally unique, and can be used in 547 matching accounting records with confirmations. An easy way to 548 produce unique numbers is to set the value to 0 for records of type 549 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 550 INTERIM_RECORD, 2 for the second, and so on until the value for 551 STOP_RECORD is one more than for the last INTERIM_RECORD. 553 3.7 Accounting-State AVP 555 The Accounting-State AVP (AVP Code 486) is of type Integer32 and is 556 used to communicate to a peer whether Accounting messages will be 557 sent in the future. A node that issues an ASI with the Accounting- 558 State AVP set to DISABLED is informing its peer that it will no 559 longer be transmitting Accounting messages until a subsequent ASI 560 message is sent with the Accounting-State AVP set to ENABLED. 562 The following values have been defined: 563 1 ENABLED 564 2 DISABLED 566 4.0 IANA Considerations 568 The command codes defined in Section 2.0 are values taken from the 569 Command-Code [1] address space and extended in [2], [3] and [9]. 570 IANA should record the values as defined in Section 2.0. 572 The AVPs defined in section 3.0 and 5.0 were alllocated from from the 573 AVP numbering space defined in [1], and extended in [2], [3] and [9]. 574 IANA should record the values as defined in Section 3.0. 576 This document introduces the Accounting-Record-Type AVP, which 577 contains pre-defined values. This document defines the values 1-3. 578 All remaining values are available for assignment via a Designated 579 Expert [8]. 581 5.0 Security Considerations 583 This DIAMETER extension assumes that the accounting data is secured 584 either through a hop-by-hop authentication mechanism, as described in 585 [1], or using a strong authentication mechanism as defined in [9]. 587 6.0 Acknowledgments 589 The authors would like to thank Nenad Trifunovic, Tony Johansson and 590 Pankaj Patel for their participation in the Document Reading Party. 591 Thanks to the various people that have contributed to accounting 592 related requirements at the IETF's AAA Working Group and other 593 related WGs. 595 7.0 References 597 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base 598 Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, 599 September 2000. 601 [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag. "DIAMETER NASREQ 602 Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in 603 progress, September 2000. 605 [3] P. Calhoun, C. Perkins. "DIAMETER Mobile IP Extension", draft- 606 calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- 607 tember 2000. 609 [4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 610 cation Dial In User Service (RADIUS)." RFC 2138, April 1997. 612 [5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997. 614 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 615 Levels", BCP 14, RFC 2119, March 1997. 617 [7] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 618 2409, November 1998. 620 [8] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 621 tions Section in RFCs", BCP 26, RFC 2434, October 1998 623 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 624 Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF 625 work in progress, September 2000. 627 [10] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format 628 (ADIF)", draft-ietf-roamops-actng-07.txt, IETF work in progress, 629 April 2000. 631 [11] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 632 Management", draft-ietf-aaa-acct-06.txt, IETF work in progress, 633 June 2000. 635 [12] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload 636 Compression Protocol (IPComp)", RFC 2393, December 1998. 638 8.0 Authors' Addresses 640 Questions about this memo can be directed to: 642 Jari Arkko 643 Oy LM Ericsson Ab 644 02420 Jorvas 645 Finland 647 Phone: +358 40 5079256 648 E-Mail: Jari.Arkko@ericsson.com 650 Pat R. Calhoun 651 Network and Security Research Center, Sun Labs 652 Sun Microsystems, Inc. 653 15 Network Circle 654 Menlo Park, California, 94025 655 USA 657 Phone: +1 650-786-7733 658 Fax: +1 650-786-6445 659 E-mail: pcalhoun@eng.sun.com 661 Pankaj Patel 662 Convergys Corporation 663 4600 Montgomery Road 664 Cincinnati, OH 45212 665 USA 667 Phone: +1 513-723-2018 668 E-Mail: pankaj.patel@convergys.com 670 Glen Zorn 671 Cisco Systems, Inc. 672 500 108th Avenue N.E., Suite 500 673 Bellevue, WA 98004 674 USA 676 Phone: +1 425 438 8218 677 E-Mail: gwz@cisco.com 679 9.0 Full Copyright Statement 681 Copyright (C) The Internet Society (1999). All Rights Reserved. 683 This document and translations of it may be copied and furnished to 684 others, and derivative works that comment on or otherwise explain it 685 or assist in its implementation may be prepared, copied, published 686 and distributed, in whole or in part, without restriction of any 687 kind, provided that the above copyright notice and this paragraph are 688 included on all such copies and derivative works. However, this docu- 689 ment itself may not be modified in any way, such as by removing the 690 copyright notice or references to the Internet Society or other 691 Internet organizations, except as needed for the purpose of develop- 692 ing Internet standards in which case the procedures for copyrights 693 defined in the Internet Standards process must be followed, or as 694 required to translate it into languages other than English. The lim- 695 ited permissions granted above are perpetual and will not be revoked 696 by the Internet Society or its successors or assigns. This document 697 and the information contained herein is provided on an "AS IS" basis 698 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 699 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 700 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 701 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 702 FITNESS FOR A PARTICULAR PURPOSE.