idnits 2.17.1 draft-hakala-diameter-credit-control-06.txt: -(1591): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 31) being 71 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 230: '...is specification MAY advertise support...' RFC 2119 keyword, line 249: '... on the service event information, MAY...' RFC 2119 keyword, line 267: '... this SHOULD be considered when unit...' RFC 2119 keyword, line 269: '... There MAY be multiple credit contro...' RFC 2119 keyword, line 270: '...balancing. The system MAY also contain...' (127 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 856 has weird spacing: '...control use...' == Line 892 has weird spacing: '...elapses acc...' == Line 932 has weird spacing: '...g equal end ...' == Line 990 has weird spacing: '...quested to en...' == Line 995 has weird spacing: '..., or Tx to e...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since the credit control application is based on real-time bi-directional communication between the credit control client and the credit control server alternative destinations and buffering of messages are not sufficient in the event of communication failures. Since the credit control server has to maintain a session state the credit control message stream MUST not be moved to a backup credit control server during an ongoing credit control session. However, Diameter agents MAY perform failover to an alternative agent when they detect a transport failure. As a consequence the credit control server MAY receive duplicate messages. These duplicates or out of sequence messages can be detected in the credit control server based on the credit control server session state machine (section 3.3), Session-Id AVP and Accounting-Record-Number AVP. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 6 AVP Occurrence Table The following table presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- 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.) -- The document date (February 2003) is 7731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWORDS' is mentioned on line 1807, but not defined == Missing Reference: 'E121' is mentioned on line 1490, but not defined == Missing Reference: 'CE121' is mentioned on line 1491, but not defined == Missing Reference: 'ACCMGMT' is mentioned on line 1810, but not defined == Unused Reference: 'E212' is defined on line 1793, but no explicit reference was found in the text == Unused Reference: 'CE212' is defined on line 1797, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter is -16, but you're referring to -17. -- Possible downref: Non-RFC (?) normative reference: ref. '3GPPCHARG' ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE164' -- Possible downref: Non-RFC (?) normative reference: ref. 'E212' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE212' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 18 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Harri Hakala, 3 Leena Mattila 4 INTERNET-DRAFT Ericsson, 5 Draft: Juha-Pekka 6 Expires: August 2003 Koskinen, 7 Marco Stura, 8 John Loughney, 9 Nokia 11 February 2003 13 Diameter Credit Control Application 15 Status of this memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is an individual submission to the IETF. Comments 37 should be directed to the authors. 39 Abstract 41 This document specifies a Diameter application that is used for real- 42 time cost and credit control between a service element and a credit 43 control server in service environment. 45 Diameter accounting messages with additional AVPs are used to 46 transfer service and credit control information between the service 47 element and the credit control server. 49 TABLE OF CONTENTS 51 1 Introduction 52 1.1 Requirements language 53 1.2 Terminology 54 1.3 Advertising application support 56 2 Architecture Model 58 3 Service Credit Control 59 3.1 Session Based Credit Control 60 3.1.1 First Interrogation 61 3.1.2 Interim Interrogation 62 3.1.3 Final Interrogation 63 3.1.4 Failure Procedures 64 3.2 One Time Event 65 3.2.1 Service Price Enquiry 66 3.2.2 Balance Check 67 3.2.3 Direct Debiting 68 3.2.4 Refund 69 3.2.5 Failure Procedures 70 3.3 Credit Control Session State Machine 72 4 Accounting AVPs 73 4.1 Abnormal-Termination-Reason AVP 74 4.2 Accounting-Correlation-Id AVP 75 4.3 Check-Balance-Result AVP 76 4.4 Cost-Information AVP 77 4.5 Credit-Control-Failure-Handling AVP 78 4.6 Currency-Code AVP 79 4.7 Direct-Debiting-Failure-Handling AVP 80 4.8 Exponent AVP 81 4.9 Final-Unit-Indication AVP 82 4.10 Granted-Service-Unit AVP 83 4.11 Requested-Action AVP 84 4.12 Requested-Service-Unit AVP 85 4.13 Service-Parameter-Info AVP 86 4.14 Service-Parameter-type AVP 87 4.15 Service-Parameter-Value AVP 88 4.16 Subscription-Id AVP 89 4.17 Subscription-Id-Data AVP 90 4.18 Subscription-Id-Type AVP 91 4.19 Unit-Type AVP 92 4.20 Unit-Value AVP 93 4.21 Used-Service-Unit AVP 94 4.22 Value-Digits AVP 96 5 Result-Code AVP Values 97 5.1 Transient Failures 98 5.2 Permanent Failures 100 6 AVP Occurrence Table 101 6.1 Accounting AVP Table 103 7 IANA Considerations 104 7.1 Application Identifier 105 7.2 Command Codes 106 7.3 AVP Codes 107 7.4 Result-Code AVP Values 108 7.5 Abnormal-Termination-Reason AVP 109 7.6 Check-Balance-Result AVP 110 7.7 Credit-Control-Failure-Handling AVP 111 7.8 Direct-Debiting-Failure-Handling AVP 112 7.9 Requested-Service-Unit AVP 113 7.10 Subscription-Id-Type AVP 114 7.11 Unit-Type AVP 116 8 Credit Control Application related configurable parameter 118 9 Security Considerations 120 10 References 121 10.1 Normative 122 10.2 Non-Normative 124 11 Acknowledgements 126 12 Authors addresses 128 13 Full Copyright Statement 130 14 Expiration Date 132 1 Introduction 134 This Diameter application, combined with the Diameter base protocol 135 [DIAMBASE], describes the accounting protocol that can be used for 136 real time cost and credit control in the service environment. 138 The next generation wireless networks specify (e.g. 3G Charging and 139 Billing requirements [3GPPCHARG]) more critical requirements for the 140 accounting applications. The accounting application must be able to 141 rate accounting information in real-time. For example, for the 142 service environment it is vital to be able to rate service event 143 information instantly. 145 There also exists a demand for the end user credit control. The 146 accounting application must be able to check the end user's account 147 for coverage for the requested service event charge prior to 148 execution of that service event. All the chargeable events related to 149 a specific account must be prevented from the end user when the 150 credit of that account is exhausted or expired. 152 Also a mechanism should be provided to indicate to the end user of 153 the charges to be levied for a chargeable event. 155 There are as well services such as gaming or advertising that in some 156 situations rather refund than deduct the end user's account. 158 To fulfill all these needs a new type of accounting application is 159 needed, the credit control application. This application is used for 160 real-time delivery of service event information in the service 161 environment from the service element to the credit control server to 162 minimize the financial risk. 164 1.1. Requirements language 166 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 167 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 168 described in [KEYWORDS]. 170 1.2 Terminology 172 AAA 173 Authentication, Authorization and Accounting 175 Accounting 176 The act of collection of information on resource usage for the 177 purposes of trend analysis, auditing, billing or cost allocation. 179 Accounting Server 180 The accounting server receives accounting data from the service 181 elements and other devices and translates it into session records. 182 It acts as an interface to back-end rating, billing, and operations 183 support systems. 185 Charging 186 In the telecom world charging is synonym to accounting. A function 187 whereby information related to a chargeable event is transferred in 188 order to make it possible to determine usage for which the charged 189 party may be billed. 191 Credit Control 192 Credit control is a mechanism, which directly interacts in real- 193 time with an account and controls or monitors the charges, related 194 to the service usage. Credit control is a process of checking if 195 credit is available, credit-reservation, reduction of credit from 196 the end user account when service is completed and refunding of 197 reserved credit not used. 199 Credit Control Server 200 It is located in the home environment and is accessed by service 201 elements in real-time for purpose of price determination and credit 202 control before the service event is delivered to the end-user. It 203 may also interact with business support systems. 205 Diameter Credit Control Client 206 A Diameter credit control client is an entity that interacts with a 207 credit control server. 209 Diameter Credit Control Server 210 A Diameter credit control server is an entity that handles credit 211 control request. 213 Rating 214 The act of determining the cost of the service event. 216 Service 217 A type of task that is performed by a service element for an end 218 user. 220 Service Element 221 A network element that provides a service to end user. A service 222 element itself can include the application service providers or 223 application service providers can be located in an other domain. 225 Service Event 226 Any event which creates value for the end-user. 228 1.3 Advertising application support 230 Diameter nodes conforming to this specification MAY advertise support 231 by including the value of TBD (X) in the Acct-Application-Id AVP of 232 the Capabilities-Exchange-Request and Capabilities-Exchange-Answer 233 command [DIAMBASE]. 235 2 Architecture Model 237 A service element provides services to end-users. When accounting is 238 used a service element collects service event information and reports 239 it while and/or after services are provided to an accounting server 240 by using an accounting protocol. Alternatively the accounting server 241 may query the service element for service event information. 243 The accounting protocol can for example be RADIUS accounting protocol 244 or the Diameter base protocol with a Diameter application. 246 If real-time credit control is required, the service element (credit 247 control client) contacts the credit control server with service event 248 information included before the service is provided. The credit 249 control server, depending on the service event information, MAY 250 perform the rating of the service event, pricing of the service 251 event, credit check and credit-reservation from the account. The 252 service element monitors the service execution according to the 253 instructions returned by the credit control server. After the service 254 completion the credit control server deducts the money from the 255 account. 257 If direct debiting/refunding is requested, the credit control server 258 deducts/increases the end user's account, respectively. The service 259 element can also enquire the price of the service or the account 260 balance status from the credit control server. 262 In a multi-service environment it might happen that an end user with 263 already ongoing service (e.g. voice call) issues a new service 264 request (e.g. data service) towards same account or during an active 265 multimedia session an additional media type is added to the session 266 causing a new simultaneous request towards same account. Consequently 267 this SHOULD be considered when units are granted to the services. 269 There MAY be multiple credit control servers in the system for 270 reasons of redundancy and load balancing. The system MAY also contain 271 separate rating server(s) and accounts MAY locate in a centralized 272 database. System internal interfaces can exist to relay messages 273 between servers and an account manager. However the detailed 274 architecture of credit control system and its interfaces are 275 implementation specific and are out of scope of this specification. 277 The credit control protocol is the Diameter base protocol with the 278 Diameter credit control application. 280 accounting 281 +------------+ +-----------+ protocol +--------------+ 282 | End |<----->| Service |<------------>| Accounting | 283 | User | +-->| Element |<-----+ | Server | 284 +------------+ | +-----------+ | +--------------+ 285 | | 286 +------------+ | | 287 | End |<--+ | +--------------+ 288 | User | +------>|Credit Control| 289 +------------+ credit control | Server | 290 protocol +--------------+ 292 The credit control server and accounting server in this architecture 293 model are logical entities. The real configuration MAY combine them 294 into a single host. 296 There MAY exist protocol transparent Diameter relays and redirect 297 agents between credit control client and credit control server. These 298 agents transparently support the Diameter credit control application. 300 If Diameter credit control proxies exist between the credit control 301 client and the credit control server, they MUST advertise the 302 Diameter credit control application support. 304 3 Service Control 306 When an end user requests a service the request is forwarded to a 307 service element in the home domain, that is the same administrative 308 domain, in which the end user's credit control server is located. In 309 some cases it might be possible that the service element in the 310 visited domain can offer service event to the end user, but in that 311 case a commercial agreement must exist between the service element in 312 the visited domain and in the home domain. 314 The service element SHOULD authenticate and authorize the end user 315 before any request is sent to the credit control server. The way how 316 the authentication and/or authorization are performed in the service 317 element and the authentication and/or authorization messages that are 318 used are not defined in this application. The methods defined in 319 other Diameter applications or other legacy authentication and 320 authorization methods can be used. 322 Each credit control session MUST have globally unique Session-Id as 323 defined in [DIAMBASE] and it MUST NOT be changed during the life time 324 of a credit control session. 326 The Diameter credit control client in the service element MAY get 327 information from the authorization server regarding the way 328 accounting data shall be forwarded (accounting protocol, credit 329 control protocol or both) based on its knowledge of the end user. 330 This means that the accounting information is forwarded to the 331 accounting server as defined in [DIAMBASE], or the credit control 332 server SHOULD be contacted before the service event is offered to the 333 end user or both the accounting protocol and the credit control 334 protocol MAY be used in parallel. 336 The authorization server MAY include the Accounting-Realtime-Required 337 AVP to determine what to do if the sending of accounting records to 338 the accounting server has been temporarily prevented as defined in 339 [DIAMBASE]. The Accounting-Realtime-Required AVP is not used by this 340 application. Instead of or in addition to the Accounting-Realtime- 341 Required AVP the authorization server MAY include the Credit-Control- 342 Failure-Handling AVP and Direct-Debiting-Failure-Handling AVP to 343 determine what to do if the sending of credit control messages to the 344 credit control server has been temporarily prevented. The usage of 345 Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure- 346 Handling AVP gives flexibility to have different failure handling for 347 credit control session and one time event direct debiting. The credit 348 control server MAY override the failure handling for credit control 349 session by including the Credit-Control-Failure-Handling AVP in the 350 Accounting-Answer. 352 The usage of separate AVPs makes it possible to have different 353 failure handling towards accounting servers and credit control 354 servers, in case both should be used parallel. It is recommended that 355 the client complements the credit control failure procedures with 356 backup accounting flow towards an accounting server. With different 357 combinations of above AVPs different safety levels can be built. 358 For example by choosing the Credit-Control-Failure-Handling AVP equal 359 to CONTINUE and Accounting-Realtime-Required AVP equal to 360 DELIVER_AND_GRANT the service can be granted to the end user even if 361 the connection to the credit control server is down but the 362 accounting server is able to collect the accounting information, 363 provided that there is information exchange taking place between the 364 accounting server and credit control server. 366 If authentication and authorization is done based on Diameter 367 application the authorization server MAY include the Acct-Interim- 368 Interval AVP to control the operation of the device in the service 369 element operating as a client as defined in [DIAMBASE]. If the Acct- 370 Interim-Interval AVP is included then the interim interval MAY be 371 present in the request message sent to the credit control server. 373 The Diameter credit control server MAY override the interim interval. 374 It is up to the credit control server to determine, even 375 independently from the requested value, the allowed interim interval 376 to be used for consumption of the granted service units. The credit 377 control server MAY return the interim interval in the Answer message 378 to the credit control client. It can be included in the Answer 379 message even in case it is not present in the Request message. 380 Alternatively the accounting interim interval can be omitted from the 381 Answer message. However, since interim records are also produced at 382 the expiry of granted service units and/or for mid-session service 383 events the omission of Acct-Interim-Interval does not mean that 384 interim records are not produced. 386 During authorization, the authorization server MAY return the 387 Accounting-Multi-Session-Id, which the Diameter credit control client 388 MAY include in all subsequent accounting messages. The Accounting- 389 Multi-Session-Id AVP MAY include the value of the original Session- 390 Id. It's contents are implementation specific, but MUST be globally 391 unique across other Accounting-Multi-Session-Id, and MUST NOT be 392 changed during the life time of a credit control session. 393 There are certain applications that require multiple accounting sub- 394 sessions. Such applications would send messages with a constant 395 Session-Id AVP, but a different Accounting Sub-Session-Id AVP. 396 If several credit sub-sessions will be used, all sub-sessions MUST be 397 closed separately before the closing the main session. The absence of 398 this AVP implies no sub-sessions are in use. 400 If the credit control client wants to perform credit-reservation 401 before granting service to the end user it MUST use several 402 interrogations towards the credit control server. In this case the 403 credit control server MUST maintain the accounting session state. 405 A one time event MAY be used when there is no need to maintain any 406 state in the Diameter credit control server, for example enquiring 407 the price of the service. 409 3.1 Session Based Credit Control 411 For a session based credit control several interrogations are needed: 412 the first, intermediate (optional) and the final interrogation. 414 3.1.1 First Interrogation 415 The first interrogation MUST be sent before the Diameter credit 416 control client in a service element allows any service event to the 417 end user. The Accounting-Record-Type is set to the value START_RECORD 418 in the first request message. The Subscription-Id-Data AVP SHOULD be 419 included to identify the end-user in the credit control server. 421 If the Diameter credit control client knows the cost of the service 422 event the monetary amount to be charged is included in the Requested- 423 Service-Unit AVP. If the Diameter credit control client does not know 424 the cost of the service event, the Requested-Service-Unit AVP MAY 425 contain the number of requested service events and the Service- 426 Parameter-Info AVP SHOULD contain the service event information to be 427 rated by the credit control server. The Service-Parameter-Info AVP 428 always refers to the requested service units. 430 The Event-Timestamp AVP contains the time when the service event is 431 requested in the service element. 433 The credit control server SHOULD rate the service event and make a 434 credit-reservation from the end user's account that covers the cost 435 of the service event. If the type of the Requested-Service-Unit AVP 436 is money, no rating is needed but the corresponding monetary amount 437 is reserved from end user's account. 439 The credit control server returns the Granted-Service-Unit AVP in the 440 Answer message to the Diameter credit control client. The Granted- 441 Service-Unit AVP contains the amount of service units that the 442 Diameter credit control client can provide to the end user until a 443 new Accounting-Request MUST be sent to the credit control server. If 444 several unit types are sent in the Answer message the credit control 445 client MUST handle each unit type separately. However there MUST be 446 maximum one instance of the same unit type in one Answer message. 447 When the granted service units for one unit type have been spent a 448 new Accounting-Request MUST be sent to the credit control server even 449 though there would be service units left for other units types. The 450 type of the Granted-Service-Unit AVP can be time, volume, service 451 specific or money depending on the type of service event. It is not 452 allowed to change the unit type(s) within the session. 454 If the credit control server determines that no further control is 455 needed for the service it MAY include the result code indicating that 456 the credit control is not applicable (e.g. service is free of charge) 457 and terminate the credit control session. 459 The Accounting-Answer message can MAY include the Final-Unit- 460 Indication AVP to indicate that the Answer message contains the final 461 units for the service session. After the end user has used these 462 units, the Diameter credit control client is responsible for 463 terminating the service session and the credit control session by 464 sending the final interrogation to the credit control server. 466 3.1.2 Intermediate Interrogation 467 When all the granted service units for one unit type are spent by the 468 end user or the interim interval is expired the Diameter credit 469 control client MUST send a new Accounting-Request to the credit 470 control server. In case the Acct-Interim-Interval is used it is 471 always up to the Diameter credit control client to send a new request 472 well in advance before the expiration of the previous request in 473 order to avoiding interruption in the service element. Even if the 474 granted service units reserved by the credit control server have not 475 been spent upon expiration of the accounting interim interval, the 476 Diameter credit control client MUST send a new Accounting-Request to 477 the credit control server. 479 There can be also mid-session service events, which might affect the 480 rating of the current service events. In this case a spontaneous 481 updating (a new Accounting-Request) SHOULD be sent including 482 information related to the service event even if all the granted 483 service units have not been spent or the accounting interim interval 484 has not expired. 486 When the used units are reported to the credit control server the 487 credit control client will not have any units in its possession 488 before new granted units are received from the credit control server. 489 When the new granted units are received from the credit control 490 server these units apply from the point where the measurement of the 491 reported used units stopped. 493 The Accounting-Record-Type AVP is set to the value INTERIM_RECORD in 494 the intermediate request message. The Subscription-Id-Data AVP SHOULD 495 also be included in the intermediate message to identify the end user 496 in the credit control server. 498 The Requested-Service-Unit AVP contains the new amount of requested 499 service units. The Used-Service-Unit AVP contains the amount of used 500 service units measured from the point when the service became active 501 or, in case of interim interrogations are used during the session, 502 from the point when the previous measurement ended. The same unit 503 types that are used in the previous message MUST be used. If several 504 unit types were included in the previous Answer message the used 505 service units for each unit type MUST be reported. 507 The Event-Timestamp AVP contains the time of the event that triggered 508 the sending of the new Accounting-Request. 510 The credit control server MUST deduct the used monetary amount from 511 the end user's account. It MAY rate the new request and make a new 512 credit-reservation from the end user's account that covers the cost 513 of the requested service event. 515 The Accounting-Answer message with the Accounting-Record-Type AVP set 516 to the value INTERIM_RECORD MAY include the Cost-Information AVP 517 containing the accumulated cost estimation for the session without 518 taking any credit-reservation into account. 520 There MAY be several intermediate interrogations within a session. 522 3.1.3 Final Interrogation 524 When the end user terminates the service session or when all the 525 granted units are used after a Final-Unit-Indication AVP has been 526 received from the credit control server, the Diameter credit control 527 client MUST send a final Accounting-Request message to the credit 528 control server. The Accounting-Record-Type AVP is set to the value 529 STOP_RECORD. 531 The Event-Timestamp AVP MAY contain the time of the session was 532 terminated. 534 The Used-Service-Unit AVP contains the amount of used service units 535 measured from the point when the service became active or, in case of 536 interim interrogations are used during the session, from the point 537 when the previous measurement ended. If several unit types were 538 included in the previous answer message the used service units for 539 each unit type MUST be reported. 541 After final interrogation the credit control server MUST refund the 542 reserved credit amount not used to the end user's account and deduct 543 the used monetary amount from the end user's account. 545 The Accounting-Answer message with the Accounting-Record-Type set to 546 the value STOP_RECORD SHOULD include the Cost-Information AVP 547 containing the estimated total cost for the session in question. 549 3.1.4 Failure Procedures 551 Since the credit control application is based on real-time bi- 552 directional communication between the credit control client and the 553 credit control server alternative destinations and buffering of 554 messages are not sufficient in the event of communication failures. 555 Since the credit control server has to maintain a session state the 556 credit control message stream MUST not be moved to a backup credit 557 control server during an ongoing credit control session. However, 558 Diameter agents MAY perform failover to an alternative agent when 559 they detect a transport failure. As a consequence the credit control 560 server MAY receive duplicate messages. These duplicates or out of 561 sequence messages can be detected in the credit control server based 562 on the credit control server session state machine (section 3.3), 563 Session-Id AVP and Accounting-Record-Number AVP. 565 If a communication failure occurs during an ongoing credit control 566 session the credit control client will terminate or continue the 567 service depending on the value set in the Credit-Control-Failure- 568 Handling AVP. The Credit-Control-Failure-Handling AVP MAY be sent 569 from the authorization server and in the Accounting-Answer from the 570 credit control server. For new credit control sessions failover to 571 alternative credit control server SHOULD be performed, if possible. 573 The timer Tx (as defined in section 8) is used in the credit control 574 client to supervise the communication with the credit control server. 576 If the credit control server detects a failure during an ongoing 577 credit control session it will terminate the credit control session 578 and return the reserved units back to the end user's account. 580 The supervision session timer Ts as defined in [DIAMBASE] is used in 581 the credit control server. 583 3.2 One Time Event 585 The one time event is used when there is no need to maintain 586 accounting session state in the credit control server. 588 The one time event can be used when the service element wants to know 589 the cost of the service event without any credit-reservation or to 590 check the account balance without any credit-reservation. It can be 591 used also for refunding service units on the user's account or direct 592 debiting without any credit-reservation. 594 3.2.1 Service Price Enquiry 596 Sometimes the service element needs to know the price of the service 597 event. There might exist services offered by application service 598 providers, whose prices are not known in the service element. End 599 user might also want to get an estimation of the price of a service 600 event before requesting it. 602 A Diameter credit control client requesting the cost information MUST 603 set the Accounting-Record-Type AVP equal to EVENT_RECORD, include the 604 Requested-Action AVP set to PRICE_ENQUIRY and set the requested 605 service event information into the Service-Parameter-Info AVP in the 606 Accounting-Request message. 608 The credit control server calculates the cost of the requested 609 service event, but it does not perform any account balance check or 610 credit-reservation from the account. 612 The estimated price of the requested service event is returned to the 613 credit control client in the Cost-Information AVP in the Accounting- 614 Answer message. 616 3.2.2 Balance Check 618 Sometimes Diameter credit control client needs only to verify that 619 the end user's account balance covers the cost for a certain service 620 without reserving any units from the account at the time of the 621 enquiry. This method does not guarantee that there would be credit 622 left when the Diameter credit control client requests the debiting of 623 the account with a separate request. 625 A Diameter credit control client requesting the balance check MUST 626 set the Accounting-Record-Type AVP equal to EVENT_RECORD, include 627 Requested-Action AVP set to CHECK_BALANCE and include the 628 Subscription-Id-Data to identify the End-User in the credit control 629 server. 631 The credit control server makes the balance check, but it does not do 632 any credit-reservation from the account. 634 The result of balance check (Credit/No Credit) is returned to the 635 credit control client in the Check-Balance-Result AVP in the 636 Accounting-Answer message. 638 3.2.3 Direct Debiting 640 There are certain one time events for which service execution is 641 always successful in the service environment. Sometimes the delay 642 between the service invocation and the actual service delivery to the 643 end user can be so long that the use of the session based credit 644 control would lead to unreasonable long credit control sessions. 645 In these cases the Diameter credit control client can use the one 646 time event scenario for direct debiting. The Diameter credit control 647 client SHOULD be sure that the requested service event execution will 648 be successful, when this scenario is used. 650 The Accounting-Record-Type is set to the value EVENT_RECORD and the 651 Requested-Action AVP set to DIRECT_DEBITING in the Accounting-Request 652 message. The Subscription-Id-Data AVP SHOULD be included to identify 653 the End-User in the credit control server. The Event-Timestamp AVP 654 contains the time when the service event is requested in the service 655 element. 657 The Diameter credit control client MAY include the monetary amount to 658 be charged in the Request-Service-Unit AVP, if it knows the cost of 659 the service event. If the Diameter credit control client does not 660 know the cost of the service event, then the Service-Parameter-Info 661 AVP SHOULD contain the service event information to be rated by the 662 credit control server. The Service-Parameter-Info AVP always refers 663 to the requested service unit. 665 The credit control server SHOULD rate the service event and deduct 666 the corresponding monetary amount from end user's account. If the 667 type of the Requested-Service-Unit AVP is money, no rating is needed 668 but the corresponding monetary amount is deducted from the End User's 669 account. 671 The credit control server returns the Granted-Service-Unit AVP in the 672 Answer message to the Diameter credit control client. The Granted- 673 Service-Unit AVP contains the amount of service units that the 674 Diameter credit control client can provide to the end user. The type 675 of the Granted-Service-Unit can be time, volume, service specific or 676 money depending on the type of service event. 678 If the credit control server determines that no credit control is 679 needed for the service it MAY include the result code indicating that 680 the credit control is not applicable (e.g. service is free of 681 charge). 683 For informative purposes, the Accounting-Answer message SHOULD also 684 include the Cost-Information AVP containing the estimated total cost 685 of the requested service. 687 3.2.4 Refund 689 There MAY be a need to refund service units on the end user's 690 account, for example gaming services. 692 The credit control client MUST set Accounting-Record-Type AVP to the 693 value EVENT_RECORD and the Requested-Action AVP to REFUND in the 694 Accounting-Request message. The Subscription-Id-Data AVP SHOULD be 695 included to identify the End-User in the credit control server. 697 The Diameter credit control client MAY include the monetary amount to 698 be refunded in the Request-Service-Unit AVP, if it knows the cost of 699 the service event. If the Diameter credit control client does not 700 know the cost of the service event, then the Service-Parameter-Info 701 AVP SHOULD contain the service event information to be rated by the 702 credit control server. The Service-Parameter-Info AVP always refers 703 to the requested service unit. 705 For informative purposes, the Accounting-Answer message MAY also 706 include the Cost-Information AVP containing the estimated monetary 707 amount of refunded unit. 709 3.2.5 Failure Procedure 711 There MAY exist protocol transparent Diameter relays and redirect 712 agents or Diameter credit control proxies between credit control 713 client and credit control server. These agents MAY perform failover 714 procedures if they detect transport failure as described in 715 [DIAMBASE]. 717 When the credit control client detects a communication failure to the 718 credit control server its behavior depends on the requested action. 719 The timer Tx (as defined in section 8) is used in the credit control 720 client to supervise the communication with the credit control server. 722 In case the requested action is Service Price Enquiry or Balance 723 Check and communication failure is detected the credit control client 724 MAY forward the request messages to an alternative credit control 725 server, if possible. 727 If the requested action is DIRECT_DEBITING and the Direct-Debiting- 728 Failure-Handling AVP is set to TERMINATE_OR_BUFFER the credit control 729 client SHOULD terminate the service if it can determine from the 730 result code or error code in the answer message that units have not 731 been debited. Otherwise the credit control client SHOULD grant the 732 service to the end user and store the record in the credit control 733 application level non-volatile storage. The credit control client 734 MUST mark these request messages as possible duplicate by setting the 735 T-flag in the command header as described in [DIAMBASE] section 3. If 736 the Direct-Debiting-Failure-Handling AVP is set to CONTINUE the 737 service SHOULD be granted even if credit control messages can't be 738 delivered. If the timer Tx expires the credit control client MUST 739 continue the service and eventually buffer the request according to 740 the value of the Direct-Debiting-Failure-Handling AVP. 742 The Accounting-Request with requested action REFUND should always be 743 stored in the credit control application level non-volatile storage 744 in case of temporary failure. The credit control client MUST mark the 745 re-transmitted request message as possible duplicate by setting the 746 T-flag in the command header as described in [DIAMBASE] section 3. 748 The implementation MAY choose to limit the number of re-transmission 749 attempts and define a re-transmission interval. 751 Because there can appear duplicate request for various reason the 752 credit control server is therefore responsible for the real time 753 duplicate detection. Implementation issues for duplicate detection 754 are discussed in [DIAMBASE] Appendix C. When the credit control 755 client re-sends messages from its application level non-volatile 756 storage it MUST mark these request messages as possible duplicate by 757 setting the T-flag in the command headers as described in [DIAMBASE] 758 section 3. 760 Only one place in the credit control system SHOULD be responsible for 761 duplicate detection. If there is only one credit control server 762 within the given realm the credit control server MAY perform 763 duplicate detection. In case when more than one credit control server 764 are supporting the credit control application the accounting manager 765 controlling the account database MAY be responsible for duplicate 766 detection. 768 3.3 Credit Control Session State Machine 770 The following state machines MUST be supported for credit control 771 applications. 773 The first two state machines are to be observed by credit control 774 clients. The first one describes the session based credit control and 775 the second one event based credit control. The third state machine 776 describes the credit control session from a credit control server 777 perspective. 779 Any event not listed in the state machines MUST be considered as an 780 error condition, and a corresponding answer, if applicable, MUST be 781 returned to the originator of the message. 783 In the state table, the event 'Failure to send' means that the 784 Diameter credit control client is unable to communicate with the 785 desired destination (i.e. the answer message is not received within 786 the validity time of the request). This could be due to the peer 787 being down, or due to a physical link failure in the path to/from the 788 credit control server. 790 The event 'Temporary error' means that the Diameter credit control 791 client received a transient failure notification in the Accounting 792 Answer command (i.e. the peer sending back a transient failure or 793 temporary protocol error notification DIAMETER_TOO_BUSY, or 794 DIAMETER_LOOP_DETECTED in the Result-Code AVP). 796 The event 'Failed answer' means that the Diameter credit control 797 client received non-transient failure (permanent failure) 798 notification in the Accounting Answer command. 800 The action 'store record' means that a record is stored in the credit 801 control application level non-volatile storage. 803 The event 'Not successfully processed' means that the credit control 804 server could not process the message, e.g. due to unknown end user, 805 account being empty or due to errors defined in [DIAMBASE]. 807 The states PendingS, PendingI, PendingL PendingE and PendingB stand 808 for pending states to wait for an answer to an accounting request 809 related to a Start, Interim, Stop, Event or Buffered record 810 respectively. 812 CLIENT, SESSION BASED 813 State Event Action New State 814 --------------------------------------------------------------- 815 Idle Client or device requests Send PendingS 816 access accounting 817 start req., 818 start Tx. 820 PendingS Successful accounting Stop Tx Open 821 start answer received 823 PendingS Failure to send, or Grant Idle 824 temporary error and service to 825 credit control fault end user 826 handling equal to CONTINUE 828 PendingS Failure to send, or Disconnect Idle 829 temporary error and user/dev 830 credit control fault 831 handling equal to TERMINATE 833 PendingS Tx expired and credit Disconnect Idle 834 Control fault handling user/dev 835 equal to TERMINATE 837 PendingS Tx expired and credit control Grant 838 fault handling equal to service to Idle 839 CONTINUE end user 841 PendingS Accounting start answer Disconnect Idle 842 received with result code user/dev 843 SERVICE_ DENIED or 844 USER_NOT_FOUND 846 PendingS Accounting start answer Grant Idle 847 received with result code service 848 equal to credit control N/A to end user 850 PendingS Failed accounting start answer Grant Idle 851 received and credit control Service to 852 fault handling end user 853 equal to CONTINUE 855 PendingS Failed accounting start answer Disconnect Idle 856 received and credit control user/dev 857 failure handling equal to 858 TERMINATE 860 PendingS User service terminated Queue PendingS 861 termination 862 event 864 PendingS Change in rating condition Queue PendingS 865 changed 866 rating 867 condition 868 event 870 Open Granted unit elapses Send PendingI 871 and no final unit accounting 872 indication received interim req., 873 start Tx. 875 Open Granted unit elapses Disconnect PendingL 876 and final unit indication send 877 received accounting 878 stop req., 879 start Tx. 881 Open Change in rating condition Send PendingI 882 in queue accounting 883 interim req., 884 Start Tx. 886 Open Service terminated in queue Send PendingL 887 accounting 888 stop req., 889 start Tx 891 Open Change in rating condition Send PendingI 892 or interim interval elapses accounting 893 interim req., 894 Start Tx. 896 Open User service terminated Send PendingL 897 accounting 898 stop req., 899 start Tx 901 PendingI Successful accounting interim Stop Tx Open 902 answer received 904 PendingI Failure to send, or Grant Idle 905 temporary error and service to 906 credit control fault end user 907 handling equal to CONTINUE 909 PendingI Failure to send, or Disconnect Idle 910 temporary error and user/dev 911 credit control fault 912 handling equal to TERMINATE 914 PendingI Tx expired and credit control Disconnect Idle 915 fault handling equal to user/dev 916 TERMINATE 918 PendingI Tx expired and credit control Grant 919 fault handling equal to service to Idle 920 CONTINUE end user. 922 PendingI Accounting interim answer Disconnect Idle 923 received with result code user/dev 924 SERVICE_DENIED 926 PendingI Accounting interim answer Grant Idle 927 received with result code service 928 equal to credit control N/A to end user 930 PendingI Failed accounting interim Grant Idle 931 answer received and credit service to 932 control fault handling equal end user. 933 to CONTINUE 935 PendingI Failed accounting interim Disconnect Idle 936 answer received and credit user/dev 937 control fault handling 938 equal to TERMINATE 940 PendingI User service terminated Queue PendingI 941 termination 942 event 944 PendingI Change in rating Queue PendingI 945 condition changed 946 rating 947 condition 948 event 950 PendingL Successful accounting stop Idle 951 answer received 953 PendingL Tx expired Idle 955 PendingL Failure to send, or temporary Idle 956 error or failed answer 958 PendingL Change in rating condition PendingL 960 CLIENT, EVENT BASED 961 State Event Action New State 962 ---------------------------------------------------------------- 964 Idle Client or device requests Send PendingE 965 a one-time service accounting 966 event req., 967 Start Tx. 969 Idle Records in storage Send PendingB 970 stored 971 records 973 PendingE Successful accounting Idle 974 event answer received 976 PendingE Failure to send, temporary Indicate Idle 977 error or failed accounting service 978 event answer received, or error 979 Tx expired, requested 980 action GET_BALANCE or 981 PRICE_ENQUIRY 983 PendingE Accounting event answer Disconnect Idle 984 received with result code user/dev 985 SERVICE_ DENIED or 986 USER_NOT_FOUND 988 PendingE Accounting event answer Grant Idle 989 received with result code service 990 credit control N/A, requested to end 991 action DIRECT_DEBITING user 993 PendingE Failure to send, temporary Grant Idle 994 error or failed accounting service 995 event answer received, or Tx to end 996 expired, requested user 997 action DIRECT_DEBITING and 998 fault handling equal to 999 CONTINUE 1001 PendingE Failed accounting event Disconnect Idle 1002 answer received, requested user/dev 1003 action DIRECT_DEBITING and 1004 fault handling equal to 1005 TERMINATE_OR_BUFFER 1007 PendingE Failure to send or Tx Grant Idle 1008 expired, requested service 1009 action DIRECT_DEBITING and to end user 1010 fault handling equal to and store 1011 TERMINATE_OR_BUFFER record with 1012 T-flag 1014 PendingE Temporary error, requested Disconnect Idle 1015 action DIRECT_DEBITING and user/dev 1016 fault handling equal to 1017 TERMINATE_OR_BUFFER 1019 PendingE Failed accounting event Indicate Idle 1020 answer received, requested service 1021 action REFUND error and 1022 delete record 1024 PendingE Failure to send or Store record Idle 1025 Tx expired, requested with T-flag 1026 action REFUND 1028 PendingE Temporary error Store record Idle 1029 and requested action 1030 REFUND 1032 PendingB Successful accounting answer Delete Idle 1033 received record 1035 PendingB Failed accounting answer Delete Idle 1036 received record 1038 PendingB Failure to send or Idle 1039 temporary error 1041 SERVER, SESSION AND EVENT BASED 1042 State Event Action New State 1043 ---------------------------------------------------------------- 1045 Idle Accounting start request Send Open 1046 received and successfully accounting 1047 processed. start 1048 answer, 1049 reserve units, 1050 start Ts 1052 Idle Accounting start request Send Idle 1053 received, but not accounting 1054 successfully processed. start 1055 Answer with 1056 Result-Code 1057 != SUCCESS 1059 Idle Accounting event request Send Idle 1060 received and successfully accounting 1061 processed. event 1062 answer, 1063 debit units 1065 Idle Accounting event request Send Idle 1066 received, but not accounting 1067 successfully processed. event 1068 Answer with 1069 Result-Code 1070 != SUCCESS 1072 Open Accounting Interim request Send Open 1073 received and successfully accounting 1074 processed answer, 1075 debit used 1076 units and 1077 reserve 1078 new units, 1079 Restart Ts 1081 Open Accounting interim request Send Idle 1082 received, but not accounting 1083 successfully processed. interim 1084 Answer with 1085 Result-Code 1086 != SUCCESS, 1087 debit used 1088 units 1090 Open Accounting stop request Send Idle 1091 received, and successfully accounting 1092 processed stop answer, 1093 Stop Ts, 1094 debit used 1095 units 1097 Open Accounting stop request Send Idle 1098 received, but not accounting 1099 successfully processed. stop 1100 Answer with 1101 Result-Code 1102 != SUCCESS, 1103 debit used 1104 units 1106 Open Session supervision timer Ts Stop Ts, Idle 1107 expired release 1108 reserved 1109 units 1111 4 Accounting AVPs 1113 This section defines the accounting AVPs that are specific to 1114 Diameter Credit Control Application and MAY be included in the 1115 Diameter accounting messages [DIAMBASE]. 1117 Accounting-Request command MAY include the following additional AVPS: 1118 [ Subscription-Id ] 1119 [ Requested-Action ] 1120 *[ Requested-Service Unit ] 1121 *[ Used-Service-Unit ] 1122 *[ Service-Parameter-Info ] 1123 [ Abnormal-Termination-Reason] 1124 *[ Accounting-Correlation-Id ] 1125 [ Credit-Control-Failure-Handling ] 1127 Accounting-Answer command MAY include a following additional AVPS: 1128 [ Subscription-Id ] 1129 *[ Granted-Service-Unit ] 1130 [ Cost-Information] 1131 [ Final-Unit-Indication ] 1132 [ Check-Balance-Result ] 1133 [ Credit-Control-Failure-Handling ] 1135 The following table describes the Diameter AVPs defined in Credit 1136 Control application, their AVP Code values, types, possible flag 1137 values and whether the AVP MAY be encrypted. 1139 +---------------------+ 1140 | AVP Flag rules | 1141 |----+-----+----+-----|----+ 1142 AVP Section | | |SHLD| MUST|MAY | 1143 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 1144 -----------------------------------------|----+-----+----+-----|----| 1145 Abnormal- XXX 4.1 Enumerated | - | P | | V | Y | 1146 Termination-Reason | | | | | | 1148 Accounting- XXX 4.2 OctetString| - | P | | V | Y | 1149 Correlation-Id | | | | | | 1150 Check-Balance- XXX 4.3 Enumerated | M | P | | V | Y | 1151 Result | | | | | | 1152 Cost-Information XXX 4.5 Grouped | - | P | | V | Y | 1153 Credit-Control- XXX 4.6 Enumerated | M | P | | V | Y | 1154 Failure-Handling | | | | | | 1155 Direct-Debiting XXX 4.8 Enumerated | M | P | | V | Y | 1156 Failure-Handling | | | | | | 1157 Final-Unit- XXX 4.9 Unsigned32 | M | P | | V | Y | 1158 Indicator | | | | | | 1159 Granted-Service- XXX 4.10 Grouped | M | P | | V | Y | 1160 Unit | | | | | | 1161 Requested-Action XXX 4.11 Enumerated | M | P | | V | Y | 1162 Requested-Service XXX 4.12 Grouped | M | P | | V | Y | 1163 Unit | | | | | | 1164 Service-Parameter XXX 4.14 Grouped | M | P | | V | Y | 1165 Info | | | | | | 1166 Subscription-Id XXX 4.17 Grouped | M | P | | V | Y | 1167 Used-Service-Unit XXX 4.22 Grouped | M | P | | V | Y | 1168 -----------------------------------------+----+-----+----+-----+----+ 1170 4.1 Abnormal-Termination-Reason AVP 1172 The Abnormal-Termination-Reason AVP (AVP Code TBD) is of type 1173 Enumerated and contains information about the reason for an abnormal 1174 service termination in a service element. 1176 The following reasons are defined: 1178 SERVICE_ELEMENT_TERMINATION 0 1179 An error occurred in the service element. 1181 CONNECTION_TO_END-USER_BROKEN 1 1182 The connection to the end-user is broken. 1184 4.2 Accounting-Correlation-Id AVP 1186 The Accounting-Correlation-Id AVP (AVP Code TBD) is type of 1187 OctetString and contains information to correlate accounting data 1188 generated for different components of the service, e.g. transport and 1189 service level. 1191 4.3 Check-Balance-Result AVP 1193 The Check Balance Result AVP (AVP code TBD) is of type Enumerated and 1194 contains the result of the balance check. This AVP is applicable only 1195 when the Requested-Action AVP indicates CHECK_BALANCE in the 1196 Accounting-Request command. 1198 The following values are defined for the Check-Balance-Result AVP. 1200 ENOUGH_CREDIT 0 1201 There is enough credit in the account to cover the requested 1202 service. 1204 NO_CREDIT 1 1205 There isn�t enough credit in the account to cover the 1206 requested service. 1208 4.4 Cost-Information AVP 1210 The Cost-Information AVP (AVP Code TBD) is of type Grouped and is 1211 used to return the cost information of a service in the Accounting- 1212 Answer command. The included Unit-Value AVP contains the cost 1213 estimate (always type of money) of the service in case of price 1214 enquiry or the accumulated cost estimation in the case of credit 1215 control session. 1216 The Currency-Code specifies in which currency the cost was given. 1218 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 1219 the Accounting-Request command the Cost-Information AVP sent in the 1220 succeeding Accounting-Answer command contains the cost estimation of 1221 the requested service, without any reservation being made. 1223 The Cost-Information AVP included in the Accounting-Answer command 1224 with the Accounting-Record-Type set to INTERIM_RECORD contains the 1225 accumulated cost estimation for the session without taking any 1226 credit-reservation into account. 1228 The Cost-Information AVP included in the Accounting-Answer command 1229 with the Accounting-Record-Type set to EVENT_RECORD or STOP_RECORD 1230 contains the estimated total cost for the requested service. 1232 It has the following ABNF grammar: 1234 ::=< AVP Header: TBD > 1235 { Unit-Value } 1236 { Currency-Code } 1238 4.5 Credit-Control-Failure-Handling AVP 1240 The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type 1241 Enumerated. The credit control client uses information in this AVP to 1242 decide what to do if the sending of credit control messages to the 1243 credit control server has been for instance temporarily prevented due 1244 to a network problem. 1246 TERMINATE 0 1247 When the Credit-Control-Failure-Handling AVP is set to TERMINATE 1248 the service MUST only be granted as long as there is a 1249 connection to the credit control server. If the credit control 1250 client does not receive any Accounting-Answer message within the 1251 Tx timer (as defined in section 8) the credit control request 1252 is regarded failed. The moving of already started credit control 1253 session to alternative server is not allowed. 1255 This is the default behaviour if the AVP isn't included in the 1256 reply from the authorization or credit control server. 1258 CONTINUE 1 1259 When the Credit-Control-Failure-Handling AVP is set to CONTINUE 1260 the service SHOULD be granted even if credit control messages 1261 can't be delivered. 1263 4.6 Currency-Code AVP 1265 The Currency-Code AVP (AVP Code TBD) is of type Unsigned32 and 1266 contains a currency code that specifies in which currency the values 1267 of AVPs containing monetary units were given. It is specified using 1268 the numeric values defined in the ISO 4217 standard. 1270 4.7 Direct-Debiting-Failure-Handling AVP 1272 The Direct-Debiting-Failure-Handling AVP (AVP Code TBD) is of type 1273 Enumerated. The credit control client uses information in this AVP to 1274 decide what to do if the sending of credit control messages 1275 (Requested-Action AVP set to Direct Debiting) to the credit control 1276 server has been for instance temporarily prevented due to a network 1277 problem. 1279 TERMINATE_OR_BUFFER 0 1280 When the Direct-Debiting-Failure-Handling AVP is set to 1281 TERMINATE_OR_BUFFER the service MUST be granted as long as there 1282 is a connection to the credit control server. If the credit 1283 control client does not receive any Accounting-Answer message 1284 within the Tx timer (as defined in section 8) the credit control 1285 request is regarded failed. The client SHOULD terminate the 1286 service if it can determine from the failed answer that units 1287 have not been debited. Otherwise the credit control client 1288 SHOULD grant the service, store the request to application level 1289 non-volatile storage and try to re-send the request. These 1290 requests MUST be marked as possible duplicate by setting the T- 1291 flag in the command header as described in [DIAMBASE] section 3. 1293 This is the default behaviour if the AVP isn't included in the 1294 reply from the authorization server. 1296 CONTINUE 1 1297 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE 1298 the service SHOULD be granted even if credit control messages 1299 can't be delivered. 1301 4.8 Exponent AVP 1303 Exponent AVP is of type Integer32 (AVP code TBD) and contains the 1304 exponent value to be applied for the Value-Digit AVP within the Unit- 1305 Value AVP. 1307 4.9 Final-Unit-Indication AVP 1309 The Final-Unit-Indication AVP (AVP Code TBD) is of type Unsigned32 1310 and indicates that the Granted-Service-Unit AVP in the accounting 1311 command contains the final units for the service. After these units 1312 have expired, the Diameter credit control client in a service element 1313 is responsible for terminating the service and sending the 1314 STOP_RECORD to the credit control server. 1315 If more than one unit types are received in the Accounting-Answer, 1316 the Unit type which first expired SHOULD cause the termination. 1317 If included in a command, the value of this AVP is always 1. 1319 4.10 Granted-Service-Unit AVP 1321 Granted-Service-Unit AVP (AVP Code TBD) is of type Grouped and 1322 contains the amount of units that the Diameter credit control client 1323 can provide to the end user until the service must be released or the 1324 new Accounting-Request must be sent. The Unit-Value AVP contains the 1325 granted units and the Unit-Type AVP defines the type of the unit. 1327 If the Unit-Type AVP is set to time in the Accounting-Answer command, 1328 the Unit Value AVP specifies the granted time in seconds. 1330 If the Unit-Type AVP is set to volume in the Accounting-Answer 1331 command, the Unit-Value AVP specifies the granted volume in bytes. 1333 If the Unit-Type AVP is set to service specific in the Accounting- 1334 Answer command, the Unit-Value AVP specifies the granted number of 1335 service specific units (e.g. number of events, points) given in a 1336 selected service. 1338 If the Unit-Type AVP is set to money in the Accounting-Answer 1339 command, the Unit-Value AVP specifies the granted monetary amount in 1340 the given currency. If the unit type is money, a Currency-Code AVP 1341 SHOULD be included. 1343 It has the following ABNF grammar: 1345 ::=< AVP Header: TBD > 1346 { Unit-Type } 1347 { Unit-Value } 1348 [ Currency-Code ] 1349 4.11 Requested-Action AVP 1351 The Requested-Action AVP (AVP Code TBD) is type of Enumerated and 1352 contains the requested action being sent by Accounting-Request 1353 command where the Accounting-Record-Type is set to EVENT_RECORD. 1354 The following values are defined for the Requested-Action AVP: 1356 DIRECT DEBITING 0 1357 Direct debiting indicates that the request is to decrease the 1358 end user's account according to information specified in the 1359 Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 1360 The Granted-Service Unit AVP in the Accounting-Answer command 1361 contains the debited units. 1363 REFUND ACCOUNT 1 1364 Refund account indicates that the request is to increase the end 1365 user's account according to information specified in the 1366 Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 1367 The Granted-Service Unit AVP in the Accounting-Answer command 1368 contains the refunded units. 1370 CHECK_BALANCE 2 1371 Check balance indicates that the request is a balance check 1372 request. In this case the checking of the account balance is 1373 done without any credit reservation from the account. The Check- 1374 Balance-Result AVP in the Accounting-Answer command contains the 1375 result of the Balance Check. 1377 PRICE_ENQUIRY 3 1378 Price Enquiry indicates that the request is a price enquiry 1379 request. In this case neither checking of the account balance 1380 nor reservation from the account will be done, only the price of 1381 the service will be returned in the Cost-Information AVP in the 1382 Accounting-Answer Command. 1384 4.12 Requested-Service-Unit AVP 1386 The Requested-Service-Unit AVP (AVP Code TBD) is of type Grouped and 1387 contains the amount of requested units specified by the Diameter 1388 credit control client. The included Unit-Value AVP contains the 1389 requested Unit-Value and the Unit-Type AVP defines the type of the 1390 unit. A server is not required to implement all of the unit types, 1391 and must treat unknown or unsupported unit types as invalid AVP 1392 values. 1394 If the Unit Type AVP is set to time in the Accounting-Request 1395 command, the Unit-Value AVP specifies the requested time in seconds. 1397 If the Unit-type AVP is set to volume in the Accounting-Request 1398 command, the Unit-Value AVP specifies the requested volume in bytes. 1400 If the Unit-type AVP is set to service specific in the Accounting- 1401 Request command, the Unit-Value AVP specifies the requested 1402 number of service specific units (e.g. number of events) given in a 1403 selected service. 1405 If the Unit-Type AVP is set to money in the Accounting-Request 1406 command, the Unit-Value AVP specifies the monetary amount in the 1407 given currency. If the unit type is money, a Currency-Code AVP SHOULD 1408 be included. 1410 It has the following ABNF grammar: 1412 ::=< AVP Header: TBD > 1413 { Unit-Type } 1414 { Unit-Value } 1415 [ Currency-Code ] 1417 4.13 Service-Parameter-Info AVP 1419 The Service-Parameter-Info AVP (AVP Code TBD) is of type Grouped and 1420 contains a service specific information used for price calculation 1421 or rating. The Service-Parameter-Type AVP defines the service 1422 parameter type and the Service-Parameter-Value AVP contains the 1423 parameter value. The actual contents of these AVPs are not within 1424 the scope of this document and SHOULD be defined in another Diameter 1425 application, standards written by other standardization bodies, or 1426 service specific documentation. 1428 In case of unknown service request (e.g. unknown Service-Parameter- 1429 Type), the corresponding answer message MUST contain the error code 1430 DIAMETER_RATING_FAILED. An Accounting Answer message with this error 1431 MUST contain one or more Failed-AVP AVPs containing the Service- 1432 Parameter-Info AVPs that caused the failure. 1434 It has the following ABNF grammar: 1436 ::=< AVP Header: TBD > 1437 [ Service-Parameter-Type ] 1438 [ Service-Parameter-Value ] 1440 4.14 Service-Parameter-Type AVP 1442 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code TBD) 1443 and defines the type of the service event specific parameter (e.g. it 1444 can be end-user location, service name). The different parameters and 1445 their types are service specific and the meanings of these parameters 1446 are not defined in this document. The Service-Parameter-Value AVP 1447 contains the service parameter type. 1449 4.15 Service-Parameter-Value AVP 1451 The Service-Parameter-Value AVP is of type UTF8String (AVP Code TBD) 1452 and contains the value of the service parameter type. 1454 4.16 Subscription-Id AVP 1456 The Subscription-Id AVP (AVP Code TBD) is used to identify the end 1457 user's subscription and is of type Grouped. The Subscription-Id AVP 1458 includes a Subscription-Id-Data AVP that hold the identifier and a 1459 Subscription-Id-Type AVP that defines the identifier type. 1461 It has the following ABNF grammar: 1463 ::=< AVP Header: TBD > 1464 { Subscription-Id-Data } 1465 { Subscription-Id-Type } 1467 4.17 Subscription-Id-Data AVP 1469 The Subscription-Id-Data AVP (AVP Code TBD) is used to identify the 1470 end-user and is of type UTF8String. The Subscription-Id-Type AVP 1471 defines which type of identifier is used. 1473 4.18 Subscription-Id-Type AVP 1475 The Subscription-Id-Type AVP (AVP Code TBD) is of type Enumerated and 1476 it is used to determine which type of identifier that is carried by 1477 the Subscription-Id AVP. A server is not required to implement all 1478 of the Subscription-Id-Types, and MUST treat unknown or unsupported 1479 Subscription-Id-Types as invalid AVP values. 1481 The identifier can be one of the following: 1483 END_USER_MSISDN 0 1484 The identifier is in international MSISDN format, according 1485 to the ITU-T E.164 numbering plan as defined in [E164] and 1486 [CE164]. 1488 END_USER_IMSI 1 1489 The identifier is in international IMSI format, according to 1490 the ITU-T E.212 numbering plan as defined in [E121] and 1491 [CE121]. 1493 END_USER_SIP_URL 2 1494 The identifier is in the form of a SIP URL as defined in 1495 [SIP]. 1497 END_USER_NAI 3 1498 The identifier is in the form of a Network Access Identifier 1499 as defined in [NAI]. 1501 END_USER_PRIVATE 4 1502 The Identifier is a credit control server private identifier. 1504 4.19 Unit-Type AVP 1506 The Unit-Type AVP is of type Enumerated (AVP Code TBD) and contains 1507 the type of the unit. 1508 The unit type can be one of the following: 1510 CREDIT_TYPE_TIME 0 1511 The unit is of type time, given in seconds. 1513 CREDIT_TYPE_VOLUME 1 1514 The unit is of type volume, given in bytes. 1516 CREDIT_TYPE_SERVICE_SPECIFIC 2 1517 The unit is service specific (e.g. number of events, 1518 points, chips, services etc), given in a selected service. 1520 CREDIT_TYPE_MONEY 3 1521 The unit is of type money, given as a monetary value, whose 1522 currency SHOULD be specified by the Currency-Code AVP. 1524 4.20 Unit-Value AVP 1526 Unit-Value AVP is of type Grouped (AVP Code TBD). The value can be 1527 time in seconds, volume in bytes, number of service specific units or 1528 monetary amount depending on the given unit type. The Unit-Value is a 1529 value together with an exponent, i.e. Unit-Value = Value-Digits AVP * 1530 10^Exponent. This representation avoids unwanted rounding off. For 1531 example the value of 2,3 is represented as Value-Digits = 23 and 1532 Exponent = -1. The absence of exponent part MUST be interpreted as 1533 exponent being equal to zero. 1535 It has the following ABNF grammar: 1537 ::=< AVP Header: TBD > 1538 { Value-Digits } 1539 [ Exponent ] 1541 4.21 Used-Service-Unit AVP 1543 The Used-Service-Unit AVP is of type Grouped AVP (AVP Code TBD) and 1544 contains the amount of used units measured from the point when the 1545 service became active or, in case of interim interrogations are used 1546 during the session, from the point when the previous measurement 1547 ended. The included Unit-Type AVP defines the type of the unit and 1548 the Unit-Value AVP contains the used amount. 1550 If the Unit Type AVP is set to time in the Accounting-Request 1551 command, the Unit-Value AVP specifies the used time in seconds. 1553 If the Unit-Type AVP is set to volume in the Accounting-Request 1554 command, the Unit-Value AVP specifies the used volume in bytes. 1556 If the Unit-type AVP is set to service specific in the Accounting- 1557 Request command, the Unit-Value AVP specifies the used number of 1558 service specific units (e.g. number of events) given in a selected 1559 service. 1561 If the Unit-Type AVP is set to money in the Accounting-Request 1562 command, the Unit-Value AVP specifies the used monetary amount in the 1563 given currency. If the unit type is money, a Currency-Code AVP SHOULD 1564 be included. 1566 It has the following ABNF grammar: 1568 ::=< AVP Header: TBD > 1569 { Unit-Type } 1570 { Unit-Value } 1571 [ Currency-Code ] 1573 4.22 Value-Digits AVP 1575 The Value-Digits AVP is of type Unsigned64 (AVP code TBD) and 1576 contains the number of seconds, volume in bytes, number of service 1577 specific units or monetary amount depending on the given Unit-Type 1578 AVP. If decimal values are needed to present the units, the scaling 1579 MUST be indicated with the related Exponent AVP. For example for the 1580 monetary amount $ 0,05 the value of Value-Digits AVP MUST be set to 5 1581 and the scaling MUST be indicated with the Exponent AVP set to �2. 1583 5 Result Code AVP values 1585 This section defines new Result-Code AVP [DIAMBASE] values that must 1586 be supported by all Diameter implementations that conform to this 1587 specification. 1589 The Accounting-Answer message includes the Result-Code AVP, which MAY 1590 indicate that an error was present in the Accounting-Request message. 1591 A rejected Accounting-Request message SHOULD cause the user�s session 1592 to be terminated. 1594 5.1 Transient Failure 1596 Errors that fall within the transient failures category are used to 1597 inform a peer that the request could not be satisfied at the time it 1598 was received, but MAY be able to satisfy the request in the future. 1600 DIAMETER_END_USER_SERVICE_DENIED 40XX 1601 The credit control server denies the service request due to 1602 service restrictions or limitations related to the end-user, 1603 for example the end-user's account could not cover the requested 1604 service. The possibly reported used-service-units with the ACR 1605 are deducted. 1607 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 40XX 1608 The credit control server determines that the service can be 1609 granted to the end user but no further credit control is needed 1610 for the service (e.g. service is free of charge). 1612 5.2 Permanent Failures 1614 Errors that fall within permanent failure category are used to inform 1615 the peer that the request failed, and should not be attempted again. 1617 DIAMETER_USER_UNKNOWN 50XX 1618 The specified end user is unknown in the credit control server. 1620 DIAMETER_RATING_FAILED 50xx 1621 This error code is used to inform the credit control client that 1622 the credit control server cannot rate the service request due to 1623 insufficient rating input, incorrect AVP combination or due to 1624 an AVP or an AVP value that is not recognized or supported in the 1625 rating. The Failed-AVP AVP MUST be included and contain a copy of 1626 the entire AVP(s) that could not be processed successfully or an 1627 example of the missing AVP complete with the Vendor-Id if applicable. 1628 The value field of the missing AVP should be of correct minimum 1629 length and contain zeroes. 1631 6 AVP Occurrence Table 1632 The following table presents the AVPs defined in this document, and 1633 specifies in which Diameter messages they MAY, or MAY NOT be present. 1634 Note that AVPs that can only be present within a Grouped AVP are not 1635 represented in this table. 1637 The table uses the following symbols: 1638 0 The AVP MUST NOT be present in the message. 1639 0+ Zero or more instances of the AVP MAY be present in the 1640 message. 1641 0-1 Zero or one instance of the AVP MAY be present in the 1642 message. It is considered an error if there are more than 1643 once instance of the AVP. 1644 1 One instance of the AVP MUST be present in the message. 1645 1+ At least one instance of the AVP MUST be present in the 1646 message. 1648 6.1 Accounting AVP Table 1650 The table in this section is used to represent which Credit Control 1651 applications specific AVPs defined in this document are to be present 1652 in the accounting messages. 1654 +-----------+ 1655 | Command | 1656 | Code | 1657 |-----+-----+ 1658 Attribute Name | ACR | ACA | 1659 ------------------------------|-----+-----+ 1660 Abnormal-Termination-Reason | 0-1 | 0 | 1661 Accounting-Correlation-Id | 0-1 | 0 | 1662 Credit-Control-Failure- | 0-1 | 0-1 | 1663 Handling | | | 1664 Check-Balance-Result | 0 | 0-1 | 1665 Cost-Information | 0 | 0-1 | 1666 Direct-Debiting-Failure- | 0 | 0 | 1667 Handling AVP | | | 1668 Final-Unit-Indication | 0 | 0-1 | 1669 Granted-Service-Unit | 0 | 0+ | 1670 Requested-Action | 0-1 | 0 | 1671 Requested-Service-Unit | 0-1 | 0 | 1672 Service-Parameter-Info | 0+ | 0 | 1673 Subscription-Id | 0-1 | 0-1 | 1674 Used-Service-Unit | 0+ | 0 | 1675 ------------------------------|-----+-----+ 1677 7 IANA Considerations 1679 This section contains the namespaces that have either been created in 1680 this specification, or the values assigned to existing namespaces 1681 managed by IANA. 1683 7.1 Application Identifier 1684 This specification assigns the value TBD to the Application 1685 Identifier namespace defined in [DIAMBASE]. See section 1.3 for more 1686 information. 1688 7.2 Command Codes 1690 This specification uses the value 271 from the Command code namespace 1691 defined in [DIAMBASE]. 1693 7.3 AVP Codes 1695 This specification assigns the values TBD - TBD from the AVP code 1696 namespace defined in [DIAMBASE] See section 4.0 for the assignment of 1697 the namespace in this specification. 1699 7.4 Result-Code AVP Values 1701 This specification assigns the values 40XX and 50XX from the Result- 1702 Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. See 1703 section 5.0 for the assignment of the namespace in this 1704 specification. 1706 7.5 Abnormal-Termination-Reason AVP 1708 As defined in Section 4.1, the Abnormal-Termination-Reason AVP (AVP 1709 Code TBD) defines the values 0-1. All remaining values are available 1710 for assignment via Designated Expert [IANA]. 1712 7.6 Check-Balance-Result AVP 1714 As defined in Section 4.3, the Check-Balance-Result AVP (AVP Code 1715 TBD) defines the values 0-1. All remaining values are available for 1716 assignment via Designated Expert [IANA]. 1718 7.7 Credit-Control-Failure-Handling AVP 1720 As defined in Section 4.6, the Credit-Control-Failure-Handling AVP 1721 (AVP Code TBD) defines the values 0-1. All remaining values are 1722 available for assignment via Designated Expert [IANA]. 1724 7.8 Direct-Debiting-Failure-Handling AVP 1726 As defined in Section 4.8, the Direct-Debiting-Failure-Handling AVP 1727 (AVP Code TBD) defines the values 0-1. All remaining values are 1728 available for assignment via Designated Expert [IANA]. 1730 7.9 Requested-Action AVP 1732 As defined in Section 4.11, the Requested-Action AVP (AVP Code TBD) 1733 defines the values 0-3. All remaining values are available for 1734 assignment via Designated Expert [IANA]. 1736 7.10 Subscription-Id-Type AVP 1738 As defined in Section 4.17, the Subscription-Id-Type AVP (AVP Code 1739 TBD) defines the values 0-4. All remaining values are available for 1740 assignment via Designated Expert [IANA]. 1742 7.11 Unit-Type AVP 1744 As defined in Section 4.20, the Unit-Type AVP (AVP Code TBD) defines 1745 the values 0-3. All remaining values are available for assignment via 1746 Designated Expert [IANA]. 1748 8 Credit Control Application related parameter 1750 Tx timer 1751 When real-time credit control is required, the credit control 1752 client contacts the credit control server before and during the 1753 service is provided to an end user. Due to real-time nature of 1754 application the communication delays SHOULD be minimized, e.g. to 1755 avoid too long service set up time experienced by the end user. The 1756 Tx timer is introduced to control the waiting time in the client in 1757 the PENDING state. 1759 The recommended value is 10 seconds. 1761 9 Security Considerations 1763 The security models as defined in the Diameter base protocol 1764 [DIAMBASE] applies to this application too. 1766 10 References 1768 10.1 Normative 1770 [DIAMBASE] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney 1771 "Diameter Base Protocol", draft-ietf-aaa-diameter-17.txt, 1772 IETF work in progress, December 2003. 1774 [3GPPCHARG] 3rd Generation Partnership Project; Technical Specification 1775 Group Services and System Aspects, Service aspects; 1776 Charging and Billing, (release 5), 3GPP TS 22.115 v. 5.2.1, 1777 2003-03 1779 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, G. 1780 Camarillo, A. Johnston, J. Peterson, R. Sparks 1781 "SIP: Session Initiation Protocol", RFC 3261. June 2003. 1783 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486. 1784 January 1999. 1786 [E164] Recommendation E.164/I.331 (05/97): The International 1787 Public Telecommunication Numbering Plan. 1997. 1789 [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List of 1790 ITU-T Recommendation E.164 assigned country codes", June 1791 2000. 1793 [E212] Recommendation E.212 (11/98): The international 1794 identification plan for mobile terminals and mobile users. 1795 1998. 1797 [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List 1798 of mobile country or geographical area codes ", February 1799 1999. 1801 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 1802 Considerations Section in RFCs", BCP 26, RFC 2434, October 1803 1998 1805 10.2 Non-Normative 1807 [KEYWORDS] S.Bradner, "Key words for use in RFCs to Indicate 1808 Requirement Levels�, BCP 14, RFC 2119, August 1997. 1810 [ACCMGMT] B.Aboba, J.Arkko, D.Harrington. "Introduction to Accounting 1811 Management", RFC 2975, October 2000. 1813 11 Acknowledgement 1815 The authors would like to thank Paco Marin at Vodafone R&D and our 1816 colleagues with Ericsson and Nokia for their comments and 1817 suggestions. 1819 12 Author's Address 1821 Harri Hakala 1822 Oy L M Ericsson Ab 1823 Joukahaisenkatu 1 1824 20520 Turku 1825 Finland 1827 Phone: +358 2 265 3722 1828 EMail: Harri.Hakala@ericsson.fi 1830 Leena Mattila 1831 Oy L M Ericsson Ab 1832 Joukahaisenkatu 1 1833 20520 Turku 1834 Finland 1836 Phone: +358 2 265 3731 1837 EMail: Leena.Mattila@ericsson.fi 1839 Juha-Pekka Koskinen 1840 Nokia Networks 1841 Hatanpaanvaltatie 30 1842 33100 Tampere 1843 Finlad 1845 Phone: +358 7180 74027 1846 Email: juha-pekka.koskinen@nokia.com 1848 Marco Stura 1849 Nokia Networks 1850 Valimotie 21 1851 00380 Helsinki 1853 Phone: +358 7180 64308 1854 Email: marco.stura@nokia.com 1856 John Loughney 1857 Nokia Research Center 1858 Itamerenkatu 11-13 1859 00180 Helsinki 1861 Phone: +358 50 483 642 1862 Email: john.Loughney@nokia.com 1864 13 Full Copyright Statement 1866 Copyright (C) The Internet Society (2003). All Rights Reserved. 1868 This document and translations of it MAY be copied and furnished to 1869 others, and derivative works that comment on or otherwise explain it 1870 or assist in its implementation MAY be prepared, copied, published 1871 and distributed, in whole or in part, without restriction of any 1872 kind, provided that the above copyright notice and this paragraph are 1873 included on all such copies and derivative works. However, this docu- 1874 ment itself MAY not be modified in any way, such as by removing the 1875 copyright notice or references to the Internet Society or other 1876 Internet organizations, except as needed for the purpose of 1877 developing Internet standards in which case the procedures for 1878 copyrights defined in the Internet Standards process must be 1879 followed, or as required to translate it into languages other than 1880 English. The limited permissions granted above are perpetual and will 1881 not be revoked by the Internet Society or its successors or assigns. 1882 This document and the information contained herein is provided on an 1883 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1884 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1885 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1886 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1887 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1889 14 Expiration Date 1891 This memo is filed as 1892 and expires in August 2003.