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