idnits 2.17.1 draft-calhoun-diameter-accounting-07.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 607, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 610, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-16 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-04 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-09 -- 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-04 -- 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: 11 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-07.txt Pat R. Calhoun 5 Date: July 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 making use of the AVP Tag field (bit 'T' [1]). Each block has a 223 unique tag value, and an optional CMS-Data AVP. If it is known that 224 multiple ADIF-Records are being sent to the same home DIAMETER 225 server, it is possible to have one CMS-Data AVP cover multiple the 226 ADIF-Records. This optimization reduces the crypto computation that 227 would otherwise 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] MUST be present and the CMS-Data AVP [9] MAY be present, and 306 MUST have a tag of the same value as the ADIF-Record AVP. When the 307 Accounting-Request is being submitted to a broker, and includes the 308 CMS-Data AVP [9], the CMS-Data AVP MUST be signed by both the local 309 and home DIAMETER server using the countersignature procedures 310 described in [9]. 312 Message Format 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 field 329 set 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 ] 364 2.3 Accounting-Poll-Ind (ACP) Command 366 The Accounting-Poll-Ind command, indicated by the Command-Code field 367 set to 273, is sent by a DIAMETER Server in order to force the peer 368 to send current accounting data. This data MUST include not yet sent 369 accounting records from completed sessions, as well as INTERIM_RECORD 370 records from all ongoing sessions. 372 The receiver MUST use the Accounting-Request command to send the 373 accounting data. 375 The use of Accounting-Poll-Ind is useful in situations where a 376 DIAMETER server comes up after an unscheduled downtime, and wishes to 377 synchronize with the client(s) sooner than at the end of the next 378 INTERIM_RECORD or at the end of a session. 380 Warning: The use of the Accounting-Poll-Ind message is discouraged in 381 roaming networks, since it is unfeasible for a server to attempt to 382 poll all of it's roaming partner's DIAMETER peers. 384 Message Format 386 ::= 387 388 389 [ 390 391 ] 393 2.4 Accounting-Status-Ind (ASI) Command 395 The Accounting-Status-Ind command, indicated by the Command-Code 396 field set to 279, is sent by a DIAMETER node in order to inform its 397 peer of whether Accounting messages will be sent in the future. A 398 DIAMETER node that is about to be taken out of service SHOULD issue 399 an Accounting-Status-Ind message, with the Accounting-State AVP set 400 to DISABLED. A DIAMETER node that detected that it is able to issue 401 Accounting messages MUST issue an Accounting-Status-Ind message, with 402 the Accounting-State AVP set to ENABLED. 404 Message Format 406 ::= 407 408 [] 409 410 [ 411 412 ] 414 3.0 Mandatory AVPs 416 The following table describes the DIAMETER AVPs defined in the 417 Accounting extension, their AVP Code values, types, possible flag 418 values and whether the AVP MAY be encrypted. 420 +---------------------+ 421 | AVP Flag rules | 422 |----+-----+----+-----|----+ 423 AVP Section Value | | |SHLD| MUST|MAY | 424 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 425 -----------------------------------------|----+-----+----+-----|----| 426 Accounting- 480 3.1 Integer32| M | T,P | | V | Y | 427 Record-Type | | | | | | 428 ADIF-Record 481 3.2 Data | M | T,P | | V | Y | 429 Accounting- 482 3.3 Integer32| M | P | | T,V | Y | 430 Interim-Interval | | | | | | 431 Accounting- 483 3.4 Integer32| M | P | | T,V | Y | 432 Delivery-Max-Batch | | | | | | 433 Accounting- 484 3.5 Integer32| M | P | | T,V | Y | 434 Delivery-Max-Delay | | | | | | 435 Accounting- 485 3.6 Integer32| M | T,P | | V | Y | 436 Record-Number | | | | | | 437 Accounting-State 486 3.7 Integer32| M | P | | T,V | Y | 439 3.1 Accounting-Record-Type AVP 441 The Accounting-Record-Type AVP (AVP Code 480) is of type Integer32 442 and contains the type of accounting record that can be found in the 443 corresponding ADIF-Record AVP. The following values are currently 444 defined for the Accounting-Record-Type AVP: 446 EVENT_RECORD 1 447 An Accounting Event Record is used to indicate that a one-time 448 event has occurred (meaning that the start and end of the event 449 are simultaneous). This record contains all information 450 relevant to the service, and is the only record of the service. 452 START_RECORD 2 453 An Accounting Start, Interim, and Stop Records are used to 454 indicate that a service of a measurable length has been given. 455 An Accounting Start Record is used to initiate an accounting 456 session, and contains accounting information that is relevant 457 to the initiation of the session. 459 INTERIM_RECORD 3 460 An Interim Accounting Record contains cumulative accounting 461 information for an existing accounting session. Interim 462 Accounting Records SHOULD be sent every time a re- 463 authentication or re-authorization occurs. Further, additional 464 interim record triggers MAY be defined by application-specific 465 DIAMETER extensions. The selection of whether to use 466 INTERIM_RECORD records is directed by the Accounting-Interim- 467 Interval AVP. 469 STOP_RECORD 4 470 An Accounting Stop Record is sent to terminate an accounting 471 session and contains cumulative accounting information relevant 472 to the existing session. 474 3.2 ADIF-Record AVP 476 The ADIF-Record AVP (AVP Code 481) is of type Data and contains the 477 ADIF payload, as defined in [10]. 479 3.3 Accounting-Interim-Interval AVP 481 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 482 Integer32 and is sent from the DIAMETER authenticating/authorizing 483 server to the DIAMETER client. The client uses information in this 484 AVP to decide how and when to produce accounting records. With 485 different values in this AVP, service sessions can result in one, 486 two, or two+N accounting records, based on the needs of the home- 487 organization. The following accounting record production behaviour is 488 directed by the inclusion of this AVP: 490 1. The omission of the Accounting-Interim-Interval AVP or its 491 inclusion with Value field set to 0 means that EVENT_RECORD, 492 START_RECORD, and STOP_RECORD are produced, as appropriate for 493 the service. 495 2. The inclusion of the AVP with Value field set to a non-zero 496 value means that INTERIM_RECORD records MUST be produced 497 between the START_RECORD and STOP_RECORD records. The Value 498 field of this AVP is the nominal interval between these records 499 in seconds. The DIAMETER node that originates the accounting 500 information, known as the client, MUST produce the first 501 INTERIM_RECORD record roughly at the time when this nominal 502 interval has elapsed from the START_RECORD, the next one again 503 as the interval has elapsed once more, and so on until the 504 session ends and a STOP_RECORD record is produced. 506 The client MUST ensure that the interim record production times 507 are randomized so that large accounting message storms are not 508 created either among records or around a common service start 509 time. 511 3.4 Accounting-Delivery-Max-Batch AVP 513 The Accounting-Delivery-Max-Batch AVP (AVP Code 483) is of type 514 Integer32 and is included in an Accounting-Answer. This AVP controls 515 how accounting data is transferred to the accounting server. The AVP 516 sets the requirements in terms of number of locally collected records 517 before accounting data transfer SHOULD begin. The DIAMETER node that 518 receives this AVP MAY deliver the data earlier due to satisfying 519 requirements set by Accounting-Delivery-Max-Delay, device reboot, 520 lack of memory, or explicit configuration. The DIAMETER node MUST 521 begin the transfer in the given limits unless prevented from doing so 522 by network partitions, client or server failures, network congestion, 523 or client overload. 525 3.5 Accounting-Delivery-Max-Delay AVP 527 The Accounting-Delivery-Max-Delay AVP (AVP Code 484) is of type 528 Integer32 and is included in an Accounting-Answer. This AVP controls 529 how accounting data is transferred to the authorization request. The 530 AVP sets the requirements in terms of maximum delay before accounting 531 data transfer SHOULD begin. The DIAMETER node that receives this AVP 532 MAY deliver the data earlier due to satisfying requirements set by 533 Accounting-Delivery-Max-Batch, device reboot, lack of memory, or 534 explicit configuration. The DIAMETER node MUST begin the transfer in 535 the given limits unless prevented from doing so by network 536 partitions, client or server failures, network congestion, or client 537 overload. 539 3.6 Accounting-Record-Number AVP 541 The Accounting-Record-Number AVP (AVP Code 485) is of type Integer32 542 and identifies this record within one session. As Session-Id AVPs are 543 globally unique, the combination of Session-Id and Accounting- 544 Record-Number AVPs is also globally unique, and can be used in 545 matching accounting records with confirmations. An easy way to 546 produce unique numbers is to set the value to 0 for records of type 547 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 548 INTERIM_RECORD, 2 for the second, and so on until the value for 549 STOP_RECORD is one more than for the last INTERIM_RECORD. 551 3.7 Accounting-State AVP 553 The Accounting-State AVP (AVP Code 486) is of type Integer32 and is 554 used to communicate to a peer whether Accounting messages will be 555 sent in the future. A node that issues an ASI with the Accounting- 556 State AVP set to DISABLED is informing its peer that it will no 557 longer be transmitting Accounting messages until a subsequent ASI 558 message is sent with the Accounting-State AVP set to ENABLED. 560 The following values have been defined: 561 1 ENABLED 562 2 DISABLED 564 4.0 IANA Considerations 566 The command codes defined in Section 2.0 are values taken from the 567 Command-Code [1] address space and extended in [2], [3] and [9]. 568 IANA should record the values as defined in Section 2.0. 570 The AVPs defined in section 3.0 and 5.0 were alllocated from from the 571 AVP numbering space defined in [1], and extended in [2], [3] and [9]. 572 IANA should record the values as defined in Section 3.0. 574 This document introduces the Accounting-Record-Type AVP, which 575 contains pre-defined values. This document defines the values 1-3. 576 All remaining values are available for assignment via a Designated 577 Expert [8]. 579 5.0 Security Considerations 581 This DIAMETER extension assumes that the accounting data is secured 582 either through a hop-by-hop authentication mechanism, as described in 583 [1], or using a strong authentication mechanism as defined in [9]. 585 6.0 Acknowledgments 587 The authors would like to thank Nenad Trifunovic, Tony Johansson and 588 Pankaj Patel for their participation in the Document Reading Party. 589 Thanks to the various people that have contributed to accounting 590 related requirements at the IETF's AAA Working Group and other 591 related WGs. 593 7.0 References 595 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base 596 Protocol", draft-calhoun-diameter-16.txt, IETF work in progress, 597 July 2000. 599 [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag. "DIAMETER NASREQ 600 Extension", draft-calhoun-diameter-nasreq-04.txt, IETF work in 601 progress, July 2000. 603 [3] P. Calhoun, C. Perkins. "DIAMETER Mobile IP Extension", draft- 604 calhoun-diameter-mobileip-09.txt, IETF work in progress, July 605 2000. 607 [4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 608 cation Dial In User Service (RADIUS)." RFC 2138, April 1997. 610 [5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997. 612 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 613 Levels", BCP 14, RFC 2119, March 1997. 615 [7] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 616 2409, November 1998. 618 [8] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 619 tions Section in RFCs", BCP 26, RFC 2434, October 1998 621 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 622 Extension", draft-calhoun-diameter-strong-crypto-04.txt, IETF 623 work in progress, July 2000. 625 [10] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format 626 (ADIF)", draft-ietf-roamops-actng-07.txt, IETF work in progress, 627 April 2000. 629 [11] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 630 Management", draft-ietf-aaa-acct-06.txt, IETF work in progress, 631 June 2000. 633 [12] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload 634 Compression Protocol (IPComp)", RFC 2393, December 1998. 636 8.0 Authors' Addresses 638 Questions about this memo can be directed to: 640 Jari Arkko 641 Oy LM Ericsson Ab 642 02420 Jorvas 643 Finland 645 Phone: +358 40 5079256 646 E-Mail: Jari.Arkko@ericsson.com 648 Pat R. Calhoun 649 Network and Security Research Center, Sun Labs 650 Sun Microsystems, Inc. 651 15 Network Circle 652 Menlo Park, California, 94025 653 USA 655 Phone: +1 650-786-7733 656 Fax: +1 650-786-6445 657 E-mail: pcalhoun@eng.sun.com 659 Pankaj Patel 660 Convergys Corporation 661 4600 Montgomery Road 662 Cincinnati, OH 45212 663 USA 665 Phone: +1 513-723-2018 666 E-Mail: pankaj.patel@convergys.com 668 Glen Zorn 669 Cisco Systems, Inc. 670 500 108th Avenue N.E., Suite 500 671 Bellevue, WA 98004 672 USA 674 Phone: +1 425 438 8218 675 E-Mail: gwz@cisco.com 677 9.0 Full Copyright Statement 679 Copyright (C) The Internet Society (1999). All Rights Reserved. 681 This document and translations of it may be copied and furnished to 682 others, and derivative works that comment on or otherwise explain it 683 or assist in its implementation may be prepared, copied, published 684 and distributed, in whole or in part, without restriction of any 685 kind, provided that the above copyright notice and this paragraph are 686 included on all such copies and derivative works. However, this docu- 687 ment itself may not be modified in any way, such as by removing the 688 copyright notice or references to the Internet Society or other 689 Internet organizations, except as needed for the purpose of develop- 690 ing Internet standards in which case the procedures for copyrights 691 defined in the Internet Standards process must be followed, or as 692 required to translate it into languages other than English. The lim- 693 ited permissions granted above are perpetual and will not be revoked 694 by the Internet Society or its successors or assigns. This document 695 and the information contained herein is provided on an "AS IS" basis 696 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 697 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 698 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 699 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 700 FITNESS FOR A PARTICULAR PURPOSE.