idnits 2.17.1 draft-hakala-aaa-diameter-cc-00.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 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 232: '...to this specification SHOULD advertise...' RFC 2119 keyword, line 249: '... MAY perform the rating of the servi...' RFC 2119 keyword, line 300: '...ontrol server, they MUST advertise the...' RFC 2119 keyword, line 311: '... service element SHOULD authenticate a...' RFC 2119 keyword, line 316: '...-control session MUST have globally un...' (106 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 279 has weird spacing: '...Element acco...' == Line 862 has weird spacing: '...control use...' == Line 898 has weird spacing: '...elapses acc...' == Line 938 has weird spacing: '...g equal end ...' == Line 995 has weird spacing: '...quested to en...' == (1 more instance...) -- 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, the usage of alternative destinations and the 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 can perform failover to an alternative agent when they detect a transport failure. As a consequence the credit-control server might 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: 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 (April 2003) is 7683 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 1824, but not defined == Missing Reference: 'E121' is mentioned on line 1495, but not defined == Missing Reference: 'CE121' is mentioned on line 1496, but not defined == Missing Reference: 'ACCMGMT' is mentioned on line 1827, but not defined == Unused Reference: 'E212' is defined on line 1810, but no explicit reference was found in the text == Unused Reference: 'CE212' is defined on line 1814, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DIAMBASE' -- 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: 6 errors (**), 0 flaws (~~), 16 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Harri Hakala, 3 INTERNET-DRAFT Leena Mattila 4 Category: Standards Track Ericsson, 5 Draft: Juha-Pekka Koskinen, 6 Expires: October 2003 Marco Stura, 7 John Loughney, 8 Nokia 10 April 2003 12 Diameter Credit-control Application 14 Status of this memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a product of the Authentication, Authorization and 35 Accounting (AAA) Working Group of the Internet Engineering Task Force 36 (IETF). Comments are welcome should be submitted to the mailing list 37 aaa-wg@merit.edu. 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 a service environment. 45 Diameter accounting messages using additional AVPs defined in the 46 document are used to transfer service and credit-control information 47 between the service 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 Notices 132 15 Expiration Date 134 1 Introduction 136 This Diameter application, combined with the Diameter base protocol 137 [DIAMBASE], describes the accounting protocol that can be used for 138 real time cost and credit-control in a service environment. 140 Next generation wireless networks specify, for example the 3GPP 141 Charging and Billing requirements [3GPPCHARG], critical requirements 142 for accounting applications. The accounting application must be able 143 to rate accounting information in real-time. For example, for the 144 service environment it is vital to be able to rate service event 145 information instantly. 147 There also exists a demand for the end user credit-control. The 148 accounting application must be able to check the end user's account 149 for coverage for the requested service event charge prior to 150 execution of that service event. All the chargeable events related to 151 a specific account must be prevented from the end user when the 152 credit of that account is exhausted or expired. 154 Also a mechanism should be provided to indicate to the end user of 155 the charges to be levied for a chargeable event. 157 There are as well services such as gaming or advertising that may 158 credit as opposed to deducting from the end user's account. 160 To fulfil all these needs, a new type of accounting application is 161 needed, the credit-control application. This application is used for 162 real-time delivery of service event information in the service 163 environment from the service element to the credit-control server to 164 minimize the financial risk. 166 1.1. Requirements language 168 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 169 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 170 described in [KEYWORDS]. 172 1.2 Terminology 174 AAA 175 Authentication, Authorization and Accounting 177 Accounting 178 The act of collection of information on resource usage for the 179 purposes of trend analysis, auditing, billing or cost allocation. 181 Accounting Server 182 The accounting server receives accounting data from the service 183 elements and other devices and translates it into session records. 184 It acts as an interface to back-end rating, billing, and operations 185 support systems. 187 Charging 188 In the telecom world charging is synonym to accounting. A function 189 whereby information related to a chargeable event is transferred in 190 order to make it possible to determine usage for which the charged 191 party may be billed. 193 Credit-control 194 Credit-control is a mechanism, which directly interacts in real- 195 time with an account and controls or monitors the charges, related 196 to the service usage. Credit-control is a process of checking if 197 credit is available, credit-reservation, reduction of credit from 198 the end user account when service is completed and refunding of 199 reserved credit not used. 201 Credit-control Server 202 It is located in the home domain and is accessed by service 203 elements in real-time for purpose of price determination and 204 credit-control before the service event is delivered to the end- 205 user. It may also interact with business support systems. 207 Diameter Credit-control Client 208 A Diameter credit-control client is an entity that interacts with a 209 credit-control server. 211 Diameter Credit-control Server 212 A Diameter credit-control server is an entity that handles credit- 213 control request. 215 Rating 216 The act of determining the cost of the service event. 218 Service 219 A type of task that is performed by a service element for an end 220 user. 222 Service Element 223 A network element that provides a service to end user. A service 224 element itself can include the application service providers or 225 application service providers can be located in an other domain. 227 Service Event 228 Any event that creates value for the end-user. 230 1.3 Advertising application support 232 Diameter nodes conforming to this specification SHOULD advertise 233 support by including the value of TBD (X) in the Acct-Application-Id 234 AVP of the Capabilities-Exchange-Request and Capabilities-Exchange- 235 Answer command [DIAMBASE]. 237 2 Architecture Model 238 A service element collects service event information and reports it 239 to the accounting server using an accounting protocol while and/or 240 after services are provided to an end-user. 242 The accounting protocol can for example be RADIUS accounting protocol 243 or the Diameter base protocol with a possible Diameter application. 245 If real-time credit-control is required, the credit-control client in 246 the service element contacts the credit-control server with service 247 event information included before the service is provided. The 248 credit-control server, depending on the service event information, 249 MAY perform the rating of the service event, pricing of the service 250 event, credit check and credit-reservation from the account. The 251 credit-control client in the service element monitors the service 252 execution according to the instructions returned by the credit- 253 control server. After the service completion the credit-control 254 server deducts the money from the account. 256 If direct debiting/refunding is requested, the credit-control server 257 deducts/increases the end user's account, respectively. The service 258 element can also enquire the price of the service or the account 259 balance status from the credit-control server. 261 In a multi-service environment, an end user may issue an additional 262 service request (e.g. data service) during an ongoing service (e.g. 263 voice call) towards the same account; or during an active multimedia 264 session an additional media type is added to the session causing a 265 new simultaneous request towards same account. Consequently this 266 needs to be considered when units are granted to the services. 268 There can be multiple credit-control servers in the system for 269 reasons of redundancy and load balancing. The system can also contain 270 separate rating server(s) and accounts can locate in a centralized 271 database. System internal interfaces can exist to relay messages 272 between servers and an account manager. However the detailed 273 architecture of credit-control system and its interfaces are 274 implementation specific and are out of scope of this specification. 276 The credit-control protocol is the Diameter base protocol with the 277 Diameter credit-control application. 279 Service Element accounting 280 +------------+ +-----------+ protocol +--------------+ 281 | End |<----->| +-------+ |<------------>| Accounting | 282 | User | +-->| | client| |<-----+ | Server | 283 +------------+ | | +-------+ | | +--------------+ 284 | +-----------+ | 285 +------------+ | | 286 | End |<--+ | +--------------+ 287 | User | +------>|Credit-control| 288 +------------+ credit-control | Server | 289 protocol +--------------+ 291 credit-controlThe credit-control server and accounting server in this 292 architecture model are logical entities. The real configuration can 293 combine them into a single host. 295 There can exist protocol transparent Diameter relays and redirect 296 agents between credit-control client and credit-control server. These 297 agents transparently support the Diameter credit-control application. 299 If Diameter credit-control proxies exist between the credit-control 300 client and the credit-control server, they MUST advertise the 301 Diameter credit-control application support. 303 3 Service Control 305 When an end user requests a service, the request is forwarded to a 306 service element in the user's home domain. In some cases it might be 307 possible that the service element in the visited domain can offer 308 service event to the end user, however a commercial agreement must 309 exist between the visited domain and the home domain. 311 The service element SHOULD authenticate and authorize the end user 312 before any request is sent to the credit-control server. The 313 authentication and authorization mechanisms are outside of the scope 314 of this document. 316 Each credit-control session MUST have globally unique Session-Id as 317 defined in [DIAMBASE] and it MUST NOT be changed during the lifetime 318 of a credit-control session. 320 The Diameter credit-control client in the service element may get 321 information from the authorization server regarding the way 322 accounting data shall be forwarded (accounting protocol, credit- 323 control protocol or both) based on its knowledge of the end user. 324 This means that either the accounting information is forwarded to the 325 accounting server as defined in [DIAMBASE]; the credit-control server 326 needs to be contacted before the service event is offered to the end 327 user or that both the accounting protocol and the credit-control 328 protocol can be used in parallel. 330 The authorization server MAY include the Accounting-Realtime-Required 331 AVP to determine what to do if the sending of accounting records to 332 the accounting server has been temporarily prevented as defined in 333 [DIAMBASE]. The Accounting-Realtime-Required AVP is not used by this 334 application. Instead of or in addition to the Accounting-Realtime- 335 Required AVP the authorization server MAY include the Credit-Control- 336 Failure-Handling AVP and Direct-Debiting-Failure-Handling AVP to 337 determine what to do if the sending of credit-control messages to the 338 credit-control server has been temporarily prevented. The usage of 339 Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure- 340 Handling AVP gives flexibility to have different failure handling for 341 credit-control session and one time event direct debiting. The 342 credit-control server MAY override the failure handling for credit- 343 control session by including the Credit-Control-Failure-Handling AVP 344 in the Accounting-Answer. 346 The usage of separate AVPs makes it possible to have different 347 failure handling towards accounting servers and credit-control 348 servers, in case both should be used parallel. It is recommended that 349 the client complement the credit-control failure procedures with 350 backup accounting flow towards an accounting server. Using different 351 combinations of above AVPs different safety levels can be built. For 352 example by choosing the Credit-Control-Failure-Handling AVP equal to 353 CONTINUE and Accounting-Realtime-Required AVP equal to 354 DELIVER_AND_GRANT the service can be granted to the end user even if 355 the connection to the credit-control server is down but the 356 accounting server is able to collect the accounting information, 357 provided that there is information exchange taking place between the 358 accounting server and credit-control server. 360 If authentication and authorization is done based on Diameter 361 application the authorization server MAY include the Acct-Interim- 362 Interval AVP to control the operation of the device in the service 363 element operating as a client as defined in [DIAMBASE]. If the Acct- 364 Interim-Interval AVP is included then the interim interval MAY be 365 present in the request message sent to the credit-control server. 367 The Diameter credit-control server MAY override the interim interval. 368 It is up to the credit-control server to determine, even 369 independently from the requested value, the allowed interim interval 370 to be used for consumption of the granted service units. The credit- 371 control server MAY return the interim interval in the Answer message 372 to the credit-control client. It can be included in the Answer 373 message even in case it is not present in the Request message. 374 Alternatively the accounting interim interval can be omitted from the 375 Answer message. However, since interim records are also produced at 376 the expiry of granted service units and/or for mid-session service 377 events the omission of Acct-Interim-Interval does not mean that 378 interim records are not produced. 380 During authorization, the authorization server MAY return the 381 Accounting-Multi-Session-Id, which the Diameter credit-control client 382 MAY include in all subsequent accounting messages. The Accounting- 383 Multi-Session-Id AVP MAY include the value of the original Session- 384 Id. It's contents are implementation specific, but MUST be globally 385 unique across other Accounting-Multi-Session-Id, and MUST NOT be 386 changed during the life time of a credit-control session. 387 There are certain applications that require multiple accounting sub- 388 sessions. Such applications would send messages with a constant 389 Session-Id AVP, but a different Accounting Sub-Session-Id AVP. 390 If several credit sub-sessions will be used, all sub-sessions MUST be 391 closed separately before the closing the main session. The absence of 392 this AVP implies no sub-sessions are in use. 394 If the credit-control client performs credit-reservation before 395 granting service to the end user it MUST use several interrogations 396 towards the credit-control server. In this case the credit-control 397 server MUST maintain the accounting session state. 399 A one-time event MAY be used when there is no need to maintain any 400 state in the Diameter credit-control server, for example enquiring 401 the price of the service. 403 3.1 Session Based Credit-control 405 For a session-based credit-control, several interrogations are 406 needed: the first, intermediate (optional) and the final 407 interrogation. 409 3.1.1 First Interrogation 411 The first interrogation MUST be sent before the Diameter credit- 412 control client allows any service event to the end user. The 413 Accounting-Record-Type is set to the value START_RECORD in the first 414 request message. The Subscription-Id-Data AVP SHOULD be included to 415 identify the end-user in the credit-control server. 417 If the Diameter credit-control client knows the cost of the service 418 event the monetary amount to be charged is included in the Requested- 419 Service-Unit AVP. If the Diameter credit-control client does not know 420 the cost of the service event, the Requested-Service-Unit AVP MAY 421 contain the number of requested service events and the Service- 422 Parameter-Info AVP SHOULD contain the service event information to be 423 rated by the credit-control server. The Service-Parameter-Info AVP 424 always refers to the requested service units. 426 The Event-Timestamp AVP contains the time when the service event is 427 requested in the service element. 429 The credit-control server SHOULD rate the service event and make a 430 credit-reservation from the end user's account that covers the cost 431 of the service event. If the type of the Requested-Service-Unit AVP 432 is money, no rating is needed but the corresponding monetary amount 433 is reserved from end user's account. 435 The credit-control server returns the Granted-Service-Unit AVP in the 436 Answer message to the Diameter credit-control client. The Granted- 437 Service-Unit AVP contains the amount of service units that the 438 Diameter credit-control client can provide to the end user until a 439 new Accounting-Request MUST be sent to the credit-control server. If 440 several unit types are sent in the Answer message the credit-control 441 client MUST handle each unit type separately. However there MUST be 442 maximum one instance of the same unit type in one Answer message. 443 When the granted service units for one unit type have been spent a 444 new Accounting-Request MUST be sent to the credit-control server even 445 though there would be service units left for other units types. The 446 type of the Granted-Service-Unit AVP can be time, volume, service 447 specific or money depending on the type of service event. It is not 448 allowed to change the unit type(s) within the session. 450 If the credit-control server determines that no further control is 451 needed for the service it MAY include the result code indicating that 452 the credit-control is not applicable (e.g. service is free of charge) 453 and terminate the credit-control session. 455 The Accounting-Answer message MAY also include the Final-Unit- 456 Indication AVP to indicate that the Answer message contains the final 457 units for the service session. After the end user has used these 458 units, the Diameter credit-control client is responsible for 459 terminating the service session and the credit-control session by 460 sending the final interrogation to the credit-control server. 462 3.1.2 Intermediate Interrogation 464 When all of the granted service units for one unit type are spent by 465 the end user or the interim interval is expired, the Diameter credit- 466 control client MUST send a new Accounting-Request to the credit- 467 control server. In the case when the Acct-Interim-Interval is used, 468 it is always up to the Diameter credit-control client to send a new 469 request well in advance before the expiration of the previous request 470 in order to avoiding interruption in the service element. Even if the 471 granted service units reserved by the credit-control server have not 472 been spent upon expiration of the accounting interim interval, the 473 Diameter credit-control client MUST send a new Accounting-Request to 474 the credit-control server. 476 There can be also mid-session service events, which might affect the 477 rating of the current service events. In this case a spontaneous 478 updating (a new Accounting-Request) SHOULD be sent including 479 information related to the service event even if all the granted 480 service units have not been spent or the accounting interim interval 481 has not expired. 483 When the used units are reported to the credit-control server the 484 credit-control client will not have any units in its possession 485 before new granted units are received from the credit-control server. 486 When the new granted units are received from the credit-control 487 server these units apply from the point where the measurement of the 488 reported used units stopped. 490 The Accounting-Record-Type AVP is set to the value INTERIM_RECORD in 491 the intermediate request message. The Subscription-Id-Data AVP SHOULD 492 be included in the intermediate message to identify the end user in 493 the credit-control server. 495 The Requested-Service-Unit AVP contains the new amount of requested 496 service units. The Used-Service-Unit AVP contains the amount of used 497 service units measured from the point when the service became active 498 or, in case of interim interrogations are used during the session, 499 from the point when the previous measurement ended. The same unit 500 types that are used in the previous message MUST be used. If several 501 unit types were included in the previous Answer message the used 502 service units for each unit type MUST be reported. 504 The Event-Timestamp AVP contains the time of the event that triggered 505 the sending of the new Accounting-Request. 507 The credit-control server MUST deduct the used amount from the end 508 user's account. It MAY rate the new request and make a new credit- 509 reservation from the end user's account that covers the cost of the 510 requested service event. 512 The Accounting-Answer message with the Accounting-Record-Type AVP set 513 to the value INTERIM_RECORD can include the Cost-Information AVP 514 containing the accumulated cost estimation for the session without 515 taking any credit-reservation into account. 517 The Accounting-Answer message MAY also include the Final-Unit- 518 Indication AVP to indicate that the Answer message contains the final 519 units for the service session. After the end user has used these 520 units, the Diameter credit-control client is responsible for 521 terminating the service session and the credit-control session by 522 sending the final interrogation to the credit-control server. 524 There can be several intermediate interrogations within a session. 526 3.1.3 Final Interrogation 528 When the end user terminates the service session or when all the 529 granted units are used after a Final-Unit-Indication AVP has been 530 received from the credit-control server, the Diameter credit-control 531 client MUST send a final Accounting-Request message to the credit- 532 control server. The Accounting-Record-Type AVP is set to the value 533 STOP_RECORD. 535 The Event-Timestamp AVP MAY contain the time of the session was 536 terminated. 538 The Used-Service-Unit AVP contains the amount of used service units 539 measured from the point when the service became active or, in case of 540 interim interrogations are used during the session, from the point 541 when the previous measurement ended. If several unit types were 542 included in the previous answer message the used service units for 543 each unit type MUST be reported. 545 After final interrogation the credit-control server MUST refund the 546 reserved credit amount not used to the end user's account and deduct 547 the used monetary amount from the end user's account. 549 The Accounting-Answer message with the Accounting-Record-Type set to 550 the value STOP_RECORD SHOULD include the Cost-Information AVP 551 containing the estimated total cost for the session in question. 553 3.1.4 Failure Procedures 555 Since the credit-control application is based on real-time bi- 556 directional communication between the credit-control client and the 557 credit-control server, the usage of alternative destinations and the 558 buffering of messages are not sufficient in the event of 559 communication failures. Since the credit-control server has to 560 maintain a session state the credit-control message stream MUST not 561 be moved to a backup credit-control server during an ongoing credit- 562 control session. However, Diameter agents can perform failover to an 563 alternative agent when they detect a transport failure. As a 564 consequence the credit-control server might receive duplicate 565 messages. These duplicates or out of sequence messages can be 566 detected in the credit-control server based on the credit-control 567 server session state machine (section 3.3), Session-Id AVP and 568 Accounting-Record-Number AVP. 570 If a communication failure occurs during an ongoing credit-control 571 session the credit-control client will terminate or continue the 572 service depending on the value set in the Credit-Control-Failure- 573 Handling AVP. The Credit-Control-Failure-Handling AVP MAY be sent 574 from the authorization server and in the Accounting-Answer from the 575 credit-control server. For new credit-control sessions, failover to 576 an alternate credit-control server SHOULD be performed, if possible. 578 The timer, Tx (as defined in section 8), is used in the credit- 579 control client to supervise the communication with the credit-control 580 server. 582 If the credit-control server detects a failure during an ongoing 583 credit-control session, it will terminate the credit-control session 584 and return the reserved units back to the end user's account. 586 The supervision session timer Ts as defined in [DIAMBASE] is used in 587 the credit-control server. 589 3.2 One Time Event 591 The one time event is used when there is no need to maintain 592 accounting session state in the credit-control server. 594 The one time event can be used when the service element wants to know 595 the cost of the service event without any credit-reservation or to 596 check the account balance without any credit-reservation. It can be 597 used also for refunding service units on the user's account or direct 598 debiting without any credit-reservation. 600 3.2.1 Service Price Enquiry 602 The service element may need to know the price of the service event. 603 There might exist services offered by application service providers, 604 whose prices are not known in the service element. End user might 605 also want to get an estimation of the price of a service event before 606 requesting it. 608 A Diameter credit-control client requesting the cost information MUST 609 set the Accounting-Record-Type AVP equal to EVENT_RECORD, include the 610 Requested-Action AVP set to PRICE_ENQUIRY and set the requested 611 service event information into the Service-Parameter-Info AVP in the 612 Accounting-Request message. 614 The credit-control server calculates the cost of the requested 615 service event, but it does not perform any account balance check or 616 credit-reservation from the account. 618 The estimated price of the requested service event is returned to the 619 credit-control client in the Cost-Information AVP in the Accounting- 620 Answer message. 622 3.2.2 Balance Check 624 The Diameter credit-control client may need only to verify that the 625 end user's account balance covers the cost for a certain service 626 without reserving any units from the account at the time of the 627 enquiry. This method does not guarantee that there would be credit 628 left when the Diameter credit-control client requests the debiting of 629 the account with a separate request. 631 A Diameter credit-control client requesting the balance check MUST 632 set the Accounting-Record-Type AVP equal to EVENT_RECORD, include 633 Requested-Action AVP set to CHECK_BALANCE and include the 634 Subscription-Id-Data to identify the End-User in the credit-control 635 server. 637 The credit-control server makes the balance check, but it does not do 638 any credit-reservation from the account. 640 The result of balance check (Credit/No Credit) is returned to the 641 credit-control client in the Check-Balance-Result AVP in the 642 Accounting-Answer message. 644 3.2.3 Direct Debiting 646 There are certain one-time events for which service execution is 647 always successful in the service environment. The delay between the 648 service invocation and the actual service delivery to the end user 649 can be sufficiently long that the use of the session based credit- 650 control would lead to unreasonable long credit-control sessions. In 651 these cases the Diameter credit-control client can use the one-time 652 event scenario for direct debiting. The Diameter credit-control 653 client SHOULD be sure that the requested service event execution 654 would be successful, when this scenario is used. 656 The Accounting-Record-Type is set to the value EVENT_RECORD and the 657 Requested-Action AVP set to DIRECT_DEBITING in the Accounting-Request 658 message. The Subscription-Id-Data AVP SHOULD be included to identify 659 the End-User in the credit-control server. The Event-Timestamp AVP 660 contains the time when the service event is requested in the service 661 element. 663 The Diameter credit-control client can include the monetary amount to 664 be charged in the Request-Service-Unit AVP, if it knows the cost of 665 the service event. If the Diameter credit-control client does not 666 know the cost of the service event, then the Service-Parameter-Info 667 AVP SHOULD contain the service event information to be rated by the 668 credit-control server. The Service-Parameter-Info AVP always refers 669 to the requested service unit. 671 The credit-control server SHOULD rate the service event and deduct 672 the corresponding monetary amount from end user's account. If the 673 type of the Requested-Service-Unit AVP is money, no rating is needed 674 but the corresponding monetary amount is deducted from the End User's 675 account. 677 The credit-control server returns the Granted-Service-Unit AVP in the 678 Answer message to the Diameter credit-control client. The Granted- 679 Service-Unit AVP contains the amount of service units that the 680 Diameter credit-control client can provide to the end user. The type 681 of the Granted-Service-Unit can be time, volume, service specific or 682 money depending on the type of service event. 684 If the credit-control server determines that no credit-control is 685 needed for the service it can include the result code indicating that 686 the credit-control is not applicable (e.g. service is free of 687 charge). 689 For informative purposes, the Accounting-Answer message SHOULD also 690 include the Cost-Information AVP containing the estimated total cost 691 of the requested service. 693 3.2.4 Refund 695 Some services may refund service units to the end user's account, for 696 example gaming services. 698 The credit-control client MUST set Accounting-Record-Type AVP to the 699 value EVENT_RECORD and the Requested-Action AVP to REFUND in the 700 Accounting-Request message. The Subscription-Id-Data AVP SHOULD be 701 included to identify the End-User in the credit-control server. 703 The Diameter credit-control client MAY include the monetary amount to 704 be refunded in the Request-Service-Unit AVP, if it knows the cost of 705 the service event. If the Diameter credit-control client does not 706 know the cost of the service event, then the Service-Parameter-Info 707 AVP SHOULD contain the service event information to be rated by the 708 credit-control server. The Service-Parameter-Info AVP always refers 709 to the requested service unit. 711 For informative purposes, the Accounting-Answer message MAY also 712 include the Cost-Information AVP containing the estimated monetary 713 amount of refunded unit. 715 3.2.5 Failure Procedure 717 There MAY exist protocol transparent Diameter relays and redirect 718 agents or Diameter credit-control proxies between credit-control 719 client and credit-control server. These agents can perform failover 720 procedures if they detect transport failure as described in 721 [DIAMBASE]. 723 When the credit-control client detects a communication failure to the 724 credit-control server, its behavior depends on the requested action. 725 The timer Tx (as defined in section 8) is used in the credit-control 726 client to supervise the communication with the credit-control server. 728 In case the requested action is Service Price Enquiry or Balance 729 Check and communication failure is detected the credit-control client 730 SHOULD forward the request messages to an alternative credit-control 731 server, if possible. 733 If the requested action is DIRECT_DEBITING and the Direct-Debiting- 734 Failure-Handling AVP is set to TERMINATE_OR_BUFFER the credit-control 735 client SHOULD terminate the service if it can determine from the 736 result code or error code in the answer message that units have not 737 been debited. Otherwise the credit-control client SHOULD grant the 738 service to the end user and store the record in the credit-control 739 application level non-volatile storage. The credit-control client 740 MUST mark these request messages as possible duplicate by setting the 741 T-flag in the command header as described in [DIAMBASE] section 3. If 742 the Direct-Debiting-Failure-Handling AVP is set to CONTINUE the 743 service SHOULD be granted even if credit-control messages can't be 744 delivered. If the timer Tx expires the credit-control client MUST 745 continue the service and eventually buffer the request according to 746 the value of the Direct-Debiting-Failure-Handling AVP. 748 The Accounting-Request with requested action REFUND should always be 749 stored in the credit-control application level non-volatile storage 750 in case of temporary failure. The credit-control client MUST mark the 751 re-transmitted request message as possible duplicate by setting the 752 T-flag in the command header as described in [DIAMBASE] section 3. 754 The implementation may choose to limit the number of re-transmission 755 attempts and define a re-transmission interval. 757 Because there can appear duplicate request for various reason the 758 credit-control server is therefore responsible for the real time 759 duplicate detection. Implementation issues for duplicate detection 760 are discussed in [DIAMBASE] Appendix C. When the credit-control 761 client re-sends messages from its application level non-volatile 762 storage it MUST mark these request messages as possible duplicate by 763 setting the T-flag in the command headers as described in [DIAMBASE] 764 section 3. 766 Only one place in the credit-control system SHOULD be responsible for 767 duplicate detection. If there is only one credit-control server 768 within the given realm the credit-control server may perform 769 duplicate detection. In case when more than one credit-control server 770 are supporting the credit-control application the accounting manager 771 controlling the account database MAY be responsible for duplicate 772 detection. 774 3.3 Credit-control Session State Machine 776 The following state machines MUST be supported for credit-control 777 applications. 779 The first two state machines are to be observed by credit-control 780 clients. The first one describes the session-based credit-control and 781 the second one event based credit-control. The third state machine 782 describes the credit-control session from a credit-control server 783 perspective. 785 Any event not listed in the state machines MUST be considered as an 786 error condition, and a corresponding answer, if applicable, MUST be 787 returned to the originator of the message. 789 In the state table, the event 'Failure to send' means that the 790 Diameter credit-control client is unable to communicate with the 791 desired destination (i.e. the answer message is not received within 792 the validity time of the request). This could be due to the peer 793 being down, or due to a physical link failure in the path to/from the 794 credit-control server. 796 The event 'Temporary error' means that the Diameter credit-control 797 client received a transient failure notification in the Accounting 798 Answer command (i.e. the peer sending back a transient failure or 799 temporary protocol error notification DIAMETER_TOO_BUSY, or 800 DIAMETER_LOOP_DETECTED in the Result-Code AVP). 802 The event 'Failed answer' means that the Diameter credit-control 803 client received non-transient failure (permanent failure) 804 notification in the Accounting Answer command. 806 The action 'store record' means that a record is stored in the 807 credit-control application level non-volatile storage. 809 The event 'Not successfully processed' means that the credit-control 810 server could not process the message, e.g. due to unknown end user, 811 account being empty or due to errors defined in [DIAMBASE]. 813 The states PendingS, PendingI, PendingL PendingE and PendingB stand 814 for pending states to wait for an answer to an accounting request 815 related to a Start, Interim, Stop, Event or Buffered record 816 respectively. 818 CLIENT, SESSION BASED 819 State Event Action New State 820 --------------------------------------------------------------- 821 Idle Client or device requests Send PendingS 822 access accounting 823 start req., 824 start Tx. 826 PendingS Successful accounting Stop Tx Open 827 start answer received 829 PendingS Failure to send, or Grant Idle 830 temporary error and service to 831 credit-control fault end user 832 handling equal to CONTINUE 834 PendingS Failure to send, or Disconnect Idle 835 temporary error and user/dev 836 credit-control fault 837 handling equal to TERMINATE 839 PendingS Tx expired and credit Disconnect Idle 840 Control fault handling user/dev 841 equal to TERMINATE 843 PendingS Tx expired and credit-control Grant 844 fault handling equal to service to Idle 845 CONTINUE end user 847 PendingS Accounting start answer Disconnect Idle 848 received with result code user/dev 849 SERVICE_ DENIED or 850 USER_NOT_FOUND 852 PendingS Accounting start answer Grant Idle 853 received with result code service 854 equal to credit-control N/A to end user 856 PendingS Failed accounting start answer Grant Idle 857 received and credit-control Service to 858 fault handling end user 859 equal to CONTINUE 861 PendingS Failed accounting start answer Disconnect Idle 862 received and credit-control user/dev 863 failure handling equal to 864 TERMINATE 866 PendingS User service terminated Queue PendingS 867 termination 868 event 870 PendingS Change in rating condition Queue PendingS 871 changed 872 rating 873 condition 874 event 876 Open Granted unit elapses Send PendingI 877 and no final unit accounting 878 indication received interim req., 879 start Tx. 881 Open Granted unit elapses Disconnect PendingL 882 and final unit indication send 883 received accounting 884 stop req., 885 start Tx. 887 Open Change in rating condition Send PendingI 888 in queue accounting 889 interim req., 890 Start Tx. 892 Open Service terminated in queue Send PendingL 893 accounting 894 stop req., 895 start Tx 897 Open Change in rating condition Send PendingI 898 or interim interval elapses accounting 899 interim req., 900 Start Tx. 902 Open User service terminated Send PendingL 903 accounting 904 stop req., 905 start Tx 907 PendingI Successful accounting interim Stop Tx Open 908 answer received 910 PendingI Failure to send, or Grant Idle 911 temporary error and service to 912 credit-control fault end user 913 handling equal to CONTINUE 915 PendingI Failure to send, or Disconnect Idle 916 temporary error and user/dev 917 credit-control fault 918 handling equal to TERMINATE 920 PendingI Tx expired and credit-control Disconnect Idle 921 fault handling equal to user/dev 922 TERMINATE 924 PendingI Tx expired and credit-control Grant 925 fault handling equal to service to Idle 926 CONTINUE end user. 928 PendingI Accounting interim answer Disconnect Idle 929 received with result code user/dev 930 SERVICE_DENIED 932 PendingI Accounting interim answer Grant Idle 933 received with result code service 934 equal to credit-control N/A to end user 936 PendingI Failed accounting interim Grant Idle 937 answer received and credit service to 938 control fault handling equal end user. 939 to CONTINUE 941 PendingI Failed accounting interim Disconnect Idle 942 answer received and credit user/dev 943 control fault handling 944 equal to TERMINATE 946 PendingI User service terminated Queue PendingI 947 termination 948 event 950 PendingI Change in rating Queue PendingI 951 condition changed 952 rating 953 condition 954 event 956 PendingL Successful accounting stop Idle 957 answer received 959 PendingL Tx expired Idle 961 PendingL Failure to send, or temporary Idle 962 error or failed answer 964 PendingL Change in rating condition PendingL 966 CLIENT, EVENT BASED 967 State Event Action New State 968 ---------------------------------------------------------------- 969 Idle Client or device requests Send PendingE 970 a one-time service accounting 971 event req., 972 Start Tx. 974 Idle Records in storage Send PendingB 975 stored 976 records 978 PendingE Successful accounting Idle 979 event answer received 981 PendingE Failure to send, temporary Indicate Idle 982 error or failed accounting service 983 event answer received, or error 984 Tx expired, requested 985 action GET_BALANCE or 986 PRICE_ENQUIRY 988 PendingE Accounting event answer Disconnect Idle 989 received with result code user/dev 990 SERVICE_ DENIED or 991 USER_NOT_FOUND 993 PendingE Accounting event answer Grant Idle 994 received with result code service 995 credit-control N/A, requested to end 996 action DIRECT_DEBITING user 998 PendingE Failure to send, temporary Grant Idle 999 error or failed accounting service 1000 event answer received, or Tx to end 1001 expired, requested user 1002 action DIRECT_DEBITING and 1003 fault handling equal to 1004 CONTINUE 1006 PendingE Failed accounting event Disconnect Idle 1007 answer received, requested user/dev 1008 action DIRECT_DEBITING and 1009 fault handling equal to 1010 TERMINATE_OR_BUFFER 1012 PendingE Failure to send or Tx Grant Idle 1013 expired, requested service 1014 action DIRECT_DEBITING and to end user 1015 fault handling equal to and store 1016 TERMINATE_OR_BUFFER record with 1017 T-flag 1019 PendingE Temporary error, requested Disconnect Idle 1020 action DIRECT_DEBITING and user/dev 1021 fault handling equal to 1022 TERMINATE_OR_BUFFER 1024 PendingE Failed accounting event Indicate Idle 1025 answer received, requested service 1026 action REFUND error and 1027 delete record 1029 PendingE Failure to send or Store record Idle 1030 Tx expired, requested with T-flag 1031 action REFUND 1033 PendingE Temporary error Store record Idle 1034 and requested action 1035 REFUND 1037 PendingB Successful accounting answer Delete Idle 1038 received record 1040 PendingB Failed accounting answer Delete Idle 1041 received record 1043 PendingB Failure to send or Idle 1044 temporary error 1046 SERVER, SESSION AND EVENT BASED 1047 State Event Action New State 1048 ---------------------------------------------------------------- 1050 Idle Accounting start request Send Open 1051 received and successfully accounting 1052 processed. start 1053 answer, 1054 reserve units, 1055 start Ts 1057 Idle Accounting start request Send Idle 1058 received, but not accounting 1059 successfully processed. start 1060 Answer with 1061 Result-Code 1062 != SUCCESS 1064 Idle Accounting event request Send Idle 1065 received and successfully accounting 1066 processed. event 1067 answer, 1068 debit units 1070 Idle Accounting event request Send Idle 1071 received, but not accounting 1072 successfully processed. event 1073 Answer with 1074 Result-Code 1075 != SUCCESS 1077 Open Accounting Interim request Send Open 1078 received and successfully accounting 1079 processed answer, 1080 debit used 1081 units and 1082 reserve 1083 new units, 1084 Restart Ts 1086 Open Accounting interim request Send Idle 1087 received, but not accounting 1088 successfully processed. interim 1089 Answer with 1090 Result-Code 1091 != SUCCESS, 1092 debit used 1093 units 1095 Open Accounting stop request Send Idle 1096 received, and successfully accounting 1097 processed stop answer, 1098 Stop Ts, 1099 debit used 1100 units 1102 Open Accounting stop request Send Idle 1103 received, but not accounting 1104 successfully processed. stop 1105 Answer with 1106 Result-Code 1107 != SUCCESS, 1108 debit used 1109 units 1111 Open Session supervision timer Ts Stop Ts, Idle 1112 expired release 1113 reserved 1114 units 1116 4 Accounting AVPs 1118 This section defines the accounting AVPs that are specific to 1119 Diameter Credit-control Application and MAY be included in the 1120 Diameter accounting messages [DIAMBASE]. 1122 Accounting-Request command MAY include the following additional AVPs: 1124 [ Subscription-Id ] 1125 [ Requested-Action ] 1126 *[ Requested-Service Unit ] 1127 *[ Used-Service-Unit ] 1128 *[ Service-Parameter-Info ] 1129 [ Abnormal-Termination-Reason] 1130 *[ Accounting-Correlation-Id ] 1131 [ Credit-Control-Failure-Handling ] 1133 Accounting-Answer command MAY include a following additional AVPs: 1134 [ Subscription-Id ] 1135 *[ Granted-Service-Unit ] 1136 [ Cost-Information] 1137 [ Final-Unit-Indication ] 1138 [ Check-Balance-Result ] 1139 [ Credit-Control-Failure-Handling ] 1141 The following table describes the Diameter AVPs defined in Credit- 1142 control application, their AVP Code values, types, possible flag 1143 values and whether the AVP MAY be encrypted. 1145 +---------------------+ 1146 | AVP Flag rules | 1147 |----+-----+----+-----|----+ 1148 AVP Section | | |SHLD| MUST| | 1149 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 1150 -----------------------------------------|----+-----+----+-----|----| 1151 Abnormal- XXX 4.1 Enumerated | - | P | | V | Y | 1152 Termination-Reason | | | | | | 1153 Accounting- XXX 4.2 OctetString| - | P | | V | Y | 1154 Correlation-Id | | | | | | 1155 Check-Balance- XXX 4.3 Enumerated | M | P | | V | Y | 1156 Result | | | | | | 1157 Cost-Information XXX 4.5 Grouped | - | P | | V | Y | 1158 Credit-Control- XXX 4.6 Enumerated | M | P | | V | Y | 1159 Failure-Handling | | | | | | 1160 Direct-Debiting XXX 4.8 Enumerated | M | P | | V | Y | 1161 Failure-Handling | | | | | | 1162 Final-Unit- XXX 4.9 Unsigned32 | M | P | | V | Y | 1163 Indicator | | | | | | 1164 Granted-Service- XXX 4.10 Grouped | M | P | | V | Y | 1165 Unit | | | | | | 1166 Requested-Action XXX 4.11 Enumerated | M | P | | V | Y | 1167 Requested-Service XXX 4.12 Grouped | M | P | | V | Y | 1168 Unit | | | | | | 1169 Service-Parameter XXX 4.14 Grouped | M | P | | V | Y | 1170 Info | | | | | | 1171 Subscription-Id XXX 4.17 Grouped | M | P | | V | Y | 1172 Used-Service-Unit XXX 4.22 Grouped | M | P | | V | Y | 1173 -----------------------------------------+----+-----+----+-----+----+ 1175 4.1 Abnormal-Termination-Reason AVP 1176 The Abnormal-Termination-Reason AVP (AVP Code TBD) is of type 1177 Enumerated and contains information about the reason for an abnormal 1178 service termination in a service element. 1180 The following reasons are defined: 1182 SERVICE_ELEMENT_TERMINATION 0 1183 An error occurred in the service element. 1185 CONNECTION_TO_END-USER_BROKEN 1 1186 The connection to the end-user is broken. 1188 4.2 Accounting-Correlation-Id AVP 1190 The Accounting-Correlation-Id AVP (AVP Code TBD) is type of 1191 OctetString and contains information to correlate accounting data 1192 generated for different components of the service, e.g. transport and 1193 service level. 1195 4.3 Check-Balance-Result AVP 1197 The Check Balance Result AVP (AVP code TBD) is of type Enumerated and 1198 contains the result of the balance check. This AVP is applicable only 1199 when the Requested-Action AVP indicates CHECK_BALANCE in the 1200 Accounting-Request command. 1202 The following values are defined for the Check-Balance-Result AVP. 1204 ENOUGH_CREDIT 0 1205 There is enough credit in the account to cover the requested 1206 service. 1208 NO_CREDIT 1 1209 There isn't enough credit in the account to cover the 1210 requested service. 1212 4.4 Cost-Information AVP 1214 The Cost-Information AVP (AVP Code TBD) is of type Grouped and is 1215 used to return the cost information of a service in the Accounting- 1216 Answer command. The included Unit-Value AVP contains the cost 1217 estimate (always type of money) of the service in case of price 1218 enquiry or the accumulated cost estimation in the case of credit- 1219 control session. 1220 The Currency-Code specifies in which currency the cost was given. 1222 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 1223 the Accounting-Request command the Cost-Information AVP sent in the 1224 succeeding Accounting-Answer command contains the cost estimation of 1225 the requested service, without any reservation being made. 1227 The Cost-Information AVP included in the Accounting-Answer command 1228 with the Accounting-Record-Type set to INTERIM_RECORD contains the 1229 accumulated cost estimation for the session without taking any 1230 credit-reservation into account. 1232 The Cost-Information AVP included in the Accounting-Answer command 1233 with the Accounting-Record-Type set to EVENT_RECORD or STOP_RECORD 1234 contains the estimated total cost for the requested service. 1236 It has the following ABNF grammar: 1238 ::=< AVP Header: TBD > 1239 { Unit-Value } 1240 { Currency-Code } 1242 4.5 Credit-Control-Failure-Handling AVP 1244 The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type 1245 Enumerated. The credit-control client uses information in this AVP to 1246 decide what to do if the sending of credit-control messages to the 1247 credit-control server has been for instance temporarily prevented due 1248 to a network problem. 1250 TERMINATE 0 1251 When the Credit-Control-Failure-Handling AVP is set to TERMINATE 1252 the service MUST only be granted as long as there is a 1253 connection to the credit-control server. If the credit-control 1254 client does not receive any Accounting-Answer message within the 1255 Tx timer (as defined in section 8) the credit-control request is 1256 regarded failed. The moving of already started credit-control 1257 session to alternative server is not allowed. 1259 This is the default behavior if the AVP isn't included in the 1260 reply from the authorization or credit-control server. 1262 CONTINUE 1 1263 When the Credit-Control-Failure-Handling AVP is set to CONTINUE 1264 the service SHOULD be granted even if credit-control messages 1265 can't be delivered. 1267 4.6 Currency-Code AVP 1269 The Currency-Code AVP (AVP Code TBD) is of type Unsigned32 and 1270 contains a currency code that specifies in which currency the values 1271 of AVPs containing monetary units were given. It is specified using 1272 the numeric values defined in the ISO 4217 standard. 1274 4.7 Direct-Debiting-Failure-Handling AVP 1276 The Direct-Debiting-Failure-Handling AVP (AVP Code TBD) is of type 1277 Enumerated. The credit-control client uses information in this AVP to 1278 decide what to do if the sending of credit-control messages 1279 (Requested-Action AVP set to Direct Debiting) to the credit-control 1280 server has been for instance temporarily prevented due to a network 1281 problem. 1283 TERMINATE_OR_BUFFER 0 1284 When the Direct-Debiting-Failure-Handling AVP is set to 1285 TERMINATE_OR_BUFFER the service MUST be granted as long as there 1286 is a connection to the credit-control server. If the credit- 1287 control client does not receive any Accounting-Answer message 1288 within the Tx timer (as defined in section 8) the credit-control 1289 request is regarded failed. The client SHOULD terminate the 1290 service if it can determine from the failed answer that units 1291 have not been debited. Otherwise the credit-control client 1292 SHOULD grant the service, store the request to application level 1293 non-volatile storage and try to re-send the request. These 1294 requests MUST be marked as possible duplicate by setting the T- 1295 flag in the command header as described in [DIAMBASE] section 3. 1297 This is the default behavior if the AVP isn't included in the 1298 reply from the authorization server. 1300 CONTINUE 1 1301 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE 1302 the service SHOULD be granted even if credit-control messages 1303 can't be delivered. 1305 4.8 Exponent AVP 1307 Exponent AVP is of type Integer32 (AVP code TBD) and contains the 1308 exponent value to be applied for the Value-Digit AVP within the Unit- 1309 Value AVP. 1311 4.9 Final-Unit-Indication AVP 1313 The Final-Unit-Indication AVP (AVP Code TBD) is of type Unsigned32 1314 and indicates that the Granted-Service-Unit AVP in the accounting 1315 command contains the final units for the service. After these units 1316 have expired, the Diameter credit-control client in a service element 1317 is responsible for terminating the service and sending the 1318 STOP_RECORD to the credit-control server. 1320 If more than one unit types are received in the Accounting-Answer, 1321 the Unit type which first expired SHOULD cause the termination. 1322 If included in a command, the value of this AVP is always 1. 1324 4.10 Granted-Service-Unit AVP 1326 Granted-Service-Unit AVP (AVP Code TBD) is of type Grouped and 1327 contains the amount of units that the Diameter credit-control client 1328 can provide to the end user until the service must be released or the 1329 new Accounting-Request must be sent. The Unit-Value AVP contains the 1330 granted units and the Unit-Type AVP defines the type of the unit. 1332 If the Unit-Type AVP is set to time in the Accounting-Answer command, 1333 the Unit Value AVP specifies the granted time in seconds. 1335 If the Unit-Type AVP is set to volume in the Accounting-Answer 1336 command, the Unit-Value AVP specifies the granted volume in bytes. 1338 If the Unit-Type AVP is set to service specific in the Accounting- 1339 Answer command, the Unit-Value AVP specifies the granted number of 1340 service specific units (e.g. number of events, points) given in a 1341 selected service. 1343 If the Unit-Type AVP is set to money in the Accounting-Answer 1344 command, the Unit-Value AVP specifies the granted monetary amount in 1345 the given currency. If the unit type is money, a Currency-Code AVP 1346 SHOULD be included. 1348 It has the following ABNF grammar: 1350 ::=< AVP Header: TBD > 1351 { Unit-Type } 1352 { Unit-Value } 1353 [ Currency-Code ] 1354 4.11 Requested-Action AVP 1356 The Requested-Action AVP (AVP Code TBD) is type of Enumerated and 1357 contains the requested action being sent by Accounting-Request 1358 command where the Accounting-Record-Type is set to EVENT_RECORD. 1359 The following values are defined for the Requested-Action AVP: 1361 DIRECT DEBITING 0 1362 Direct debiting indicates that the request is to decrease the 1363 end user's account according to information specified in the 1364 Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 1365 The Granted-Service Unit AVP in the Accounting-Answer command 1366 contains the debited units. 1368 REFUND ACCOUNT 1 1369 Refund account indicates that the request is to increase the end 1370 user's account according to information specified in the 1371 Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 1372 The Granted-Service Unit AVP in the Accounting-Answer command 1373 contains the refunded units. 1375 CHECK_BALANCE 2 1376 Check balance indicates that the request is a balance check 1377 request. In this case the checking of the account balance is 1378 done without any credit reservation from the account. The Check- 1379 Balance-Result AVP in the Accounting-Answer command contains the 1380 result of the Balance Check. 1382 PRICE_ENQUIRY 3 1383 Price Enquiry indicates that the request is a price enquiry 1384 request. In this case neither checking of the account balance 1385 nor reservation from the account will be done, only the price of 1386 the service will be returned in the Cost-Information AVP in the 1387 Accounting-Answer Command. 1389 4.12 Requested-Service-Unit AVP 1391 The Requested-Service-Unit AVP (AVP Code TBD) is of type Grouped and 1392 contains the amount of requested units specified by the Diameter 1393 credit-control client. The included Unit-Value AVP contains the 1394 requested Unit-Value and the Unit-Type AVP defines the type of the 1395 unit. A server is not required to implement all of the unit types, 1396 and must treat unknown or unsupported unit types as invalid AVP 1397 values. 1399 If the Unit Type AVP is set to time in the Accounting-Request 1400 command, the Unit-Value AVP specifies the requested time in seconds. 1402 If the Unit-type AVP is set to volume in the Accounting-Request 1403 command, the Unit-Value AVP specifies the requested volume in bytes. 1405 If the Unit-type AVP is set to service specific in the Accounting- 1406 Request command, the Unit-Value AVP specifies the requested 1407 number of service specific units (e.g. number of events) given in a 1408 selected service. 1410 If the Unit-Type AVP is set to money in the Accounting-Request 1411 command, the Unit-Value AVP specifies the monetary amount in the 1412 given currency. If the unit type is money, a Currency-Code AVP SHOULD 1413 be included. 1415 It has the following ABNF grammar: 1417 ::=< AVP Header: TBD > 1418 { Unit-Type } 1419 { Unit-Value } 1420 [ Currency-Code ] 1422 4.13 Service-Parameter-Info AVP 1424 The Service-Parameter-Info AVP (AVP Code TBD) is of type Grouped and 1425 contains a service specific information used for price calculation or 1426 rating. The Service-Parameter-Type AVP defines the service parameter 1427 type and the Service-Parameter-Value AVP contains the parameter 1428 value. The actual contents of these AVPs are not within the scope of 1429 this document and SHOULD be defined in another Diameter application, 1430 standards written by other standardization bodies, or service 1431 specific documentation. 1433 In case of unknown service request (e.g. unknown Service-Parameter- 1434 Type), the corresponding answer message MUST contain error code 1435 DIAMETER_RATING_FAILED. An Accounting Answer message with this error 1436 MUST contain one or more Failed-AVP AVPs containing the Service- 1437 Parameter-Info AVPs that caused the failure. 1439 It has the following ABNF grammar: 1441 ::=< AVP Header: TBD > 1442 [ Service-Parameter-Type ] 1443 [ Service-Parameter-Value ] 1445 4.14 Service-Parameter-Type AVP 1447 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code TBD) 1448 and defines the type of the service event specific parameter (e.g. it 1449 can be end-user location, service name). The different parameters and 1450 their types are service specific and the meanings of these parameters 1451 are not defined in this document. The Service-Parameter-Value AVP 1452 contains the service parameter type. 1454 4.15 Service-Parameter-Value AVP 1456 The Service-Parameter-Value AVP is of type UTF8String (AVP Code TBD) 1457 and contains the value of the service parameter type. 1459 4.16 Subscription-Id AVP 1461 The Subscription-Id AVP (AVP Code TBD) is used to identify the end 1462 user's subscription and is of type Grouped. The Subscription-Id AVP 1463 includes a Subscription-Id-Data AVP that hold the identifier and a 1464 Subscription-Id-Type AVP that defines the identifier type. 1466 It has the following ABNF grammar: 1468 ::=< AVP Header: TBD > 1469 { Subscription-Id-Data } 1470 { Subscription-Id-Type } 1472 4.17 Subscription-Id-Data AVP 1474 The Subscription-Id-Data AVP (AVP Code TBD) is used to identify the 1475 end-user and is of type UTF8String. The Subscription-Id-Type AVP 1476 defines which type of identifier is used. 1478 4.18 Subscription-Id-Type AVP 1480 The Subscription-Id-Type AVP (AVP Code TBD) is of type Enumerated and 1481 it is used to determine which type of identifier that is carried by 1482 the Subscription-Id AVP. A server is not required to implement all 1483 of the Subscription-Id-Types, and MUST treat unknown or unsupported 1484 Subscription-Id-Types as invalid AVP values. 1486 The identifier can be one of the following: 1488 END_USER_MSISDN 0 1489 The identifier is in international MSISDN format, according 1490 to the ITU-T E.164 numbering plan as defined in [E164] and 1491 [CE164]. 1493 END_USER_IMSI 1 1494 The identifier is in international IMSI format, according to 1495 the ITU-T E.212 numbering plan as defined in [E121] and 1496 [CE121]. 1498 END_USER_SIP_URL 2 1499 The identifier is in the form of a SIP URL as defined in 1500 [SIP]. 1502 END_USER_NAI 3 1503 The identifier is in the form of a Network Access Identifier 1504 as defined in [NAI]. 1506 END_USER_PRIVATE 4 1507 The Identifier is a credit-control server private identifier. 1509 4.19 Unit-Type AVP 1511 The Unit-Type AVP is of type Enumerated (AVP Code TBD) and contains 1512 the type of the unit. 1514 The unit type can be one of the following: 1516 CREDIT_TYPE_TIME 0 1517 The unit is of type time, given in seconds. 1519 CREDIT_TYPE_VOLUME 1 1520 The unit is of type volume, given in bytes. 1522 CREDIT_TYPE_SERVICE_SPECIFIC 2 1523 The unit is service specific (e.g. number of events, 1524 points, chips, services etc), given in a selected service. 1526 CREDIT_TYPE_MONEY 3 1527 The unit is of type money, given as a monetary value, whose 1528 currency SHOULD be specified by the Currency-Code AVP. 1530 4.20 Unit-Value AVP 1532 Unit-Value AVP is of type Grouped (AVP Code TBD). The value can be 1533 time in seconds, volume in bytes, number of service specific units or 1534 monetary amount depending on the given unit type. The Unit-Value is a 1535 value together with an exponent, i.e. Unit-Value = Value-Digits AVP * 1536 10^Exponent. This representation avoids unwanted rounding off. For 1537 example the value of 2,3 is represented as Value-Digits = 23 and 1538 Exponent = -1. The absence of exponent part MUST be interpreted as 1539 exponent being equal to zero. 1541 It has the following ABNF grammar: 1543 ::=< AVP Header: TBD > 1544 { Value-Digits } 1545 [ Exponent ] 1547 4.21 Used-Service-Unit AVP 1549 The Used-Service-Unit AVP is of type Grouped AVP (AVP Code TBD) and 1550 contains the amount of used units measured from the point when the 1551 service became active or, in case of interim interrogations are used 1552 during the session, from the point when the previous measurement 1553 ended. The included Unit-Type AVP defines the type of the unit and 1554 the Unit-Value AVP contains the used amount. 1556 If the Unit Type AVP is set to time in the Accounting-Request 1557 command, the Unit-Value AVP specifies the used time in seconds. 1559 If the Unit-Type AVP is set to volume in the Accounting-Request 1560 command, the Unit-Value AVP specifies the used volume in bytes. 1562 If the Unit-type AVP is set to service specific in the Accounting- 1563 Request command, the Unit-Value AVP specifies the used number of 1564 service specific units (e.g. number of events) given in a selected 1565 service. 1567 If the Unit-Type AVP is set to money in the Accounting-Request 1568 command, the Unit-Value AVP specifies the used monetary amount in the 1569 given currency. If the unit type is money, a Currency-Code AVP SHOULD 1570 be included. 1572 It has the following ABNF grammar: 1573 ::=< AVP Header: TBD > 1574 { Unit-Type } 1575 { Unit-Value } 1576 [ Currency-Code ] 1578 4.22 Value-Digits AVP 1580 The Value-Digits AVP is of type Unsigned64 (AVP code TBD) and 1581 contains the number of seconds, volume in bytes, number of service 1582 specific units or monetary amount depending on the given Unit-Type 1583 AVP. If decimal values are needed to present the units, the scaling 1584 MUST be indicated with the related Exponent AVP. For example for the 1585 monetary amount $ 0,05 the value of Value-Digits AVP MUST be set to 5 1586 and the scaling MUST be indicated with the Exponent AVP set to -2. 1588 5 Result Code AVP values 1590 This section defines new Result-Code AVP [DIAMBASE] values that must 1591 be supported by all Diameter implementations that conform to this 1592 specification. 1594 The Accounting-Answer message includes the Result-Code AVP, which MAY 1595 indicate that an error was present in the Accounting-Request message. 1596 A rejected Accounting-Request message SHOULD cause the user's session 1597 to be terminated. 1599 5.1 Transient Failure 1601 Errors that fall within the transient failures category are used to 1602 inform a peer that the request could not be satisfied at the time it 1603 was received, but MAY be able to satisfy the request in the future. 1605 DIAMETER_END_USER_SERVICE_DENIED 40XX 1606 The credit-control server denies the service request due to 1607 service restrictions or limitations related to the end-user, 1608 for example the end-user's account could not cover the requested 1609 service. The possibly reported used-service-units with the ACR 1610 are deducted. 1612 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 40XX 1613 The credit-control server determines that the service can be 1614 granted to the end user but no further credit-control is needed 1615 for the service (e.g. service is free of charge). 1617 5.2 Permanent Failures 1619 Errors that fall within permanent failure category are used to inform 1620 the peer that the request failed, and should not be attempted again. 1622 DIAMETER_USER_UNKNOWN 50XX 1623 The specified end user is unknown in the credit-control server. 1625 DIAMETER_RATING_FAILED 50xx 1626 This error code is used to inform the credit-control client that 1627 the credit-control server cannot rate the service request due to 1628 insufficient rating input, incorrect AVP combination or due to 1629 an AVP or an AVP value that is not recognized or supported in the 1630 rating. The Failed-AVP AVP MUST be included and contain a copy of 1631 the entire AVP(s) that could not be processed successfully or an 1632 example of the missing AVP complete with the Vendor-Id if 1633 applicable. The value field of the missing AVP should be of 1634 correct minimum length and contain zeroes. 1636 6 AVP Occurrence Table 1638 The following table presents the AVPs defined in this document, and 1639 specifies in which Diameter messages they MAY, or MAY NOT be present. 1640 Note that AVPs that can only be present within a Grouped AVP are not 1641 represented in this table. 1643 The table uses the following symbols: 1644 0 The AVP MUST NOT be present in the message. 1645 0+ Zero or more instances of the AVP MAY be present in the 1646 message. 1647 0-1 Zero or one instance of the AVP MAY be present in the 1648 message. It is considered an error if there are more than 1649 once instance of the AVP. 1650 1 One instance of the AVP MUST be present in the message. 1651 1+ At least one instance of the AVP MUST be present in the 1652 message. 1654 6.1 Accounting AVP Table 1656 The table in this section is used to represent which Credit-control 1657 applications specific AVPs defined in this document are to be present 1658 in the accounting messages. 1660 +-----------+ 1661 | Command | 1662 | Code | 1663 |-----+-----+ 1664 Attribute Name | ACR | ACA | 1665 ------------------------------|-----+-----+ 1666 Abnormal-Termination-Reason | 0-1 | 0 | 1667 Accounting-Correlation-Id | 0-1 | 0 | 1668 Credit-Control-Failure- | 0-1 | 0-1 | 1669 Handling | | | 1670 Check-Balance-Result | 0 | 0-1 | 1671 Cost-Information | 0 | 0-1 | 1672 Direct-Debiting-Failure- | 0 | 0 | 1673 Handling AVP | | | 1674 Final-Unit-Indication | 0 | 0-1 | 1675 Granted-Service-Unit | 0 | 0+ | 1676 Requested-Action | 0-1 | 0 | 1677 Requested-Service-Unit | 0-1 | 0 | 1678 Service-Parameter-Info | 0+ | 0 | 1679 Subscription-Id | 0-1 | 0-1 | 1680 Used-Service-Unit | 0+ | 0 | 1681 ------------------------------|-----+-----+ 1683 7 IANA Considerations 1685 This section contains the namespaces that have either been created in 1686 this specification, or the values assigned to existing namespaces 1687 managed by IANA. 1689 7.1 Application Identifier 1691 This specification assigns the value TBD to the Application 1692 Identifier namespace defined in [DIAMBASE]. See section 1.3 for more 1693 information. 1695 7.2 Command Codes 1697 This specification uses the value 271 from the Command code namespace 1698 defined in [DIAMBASE]. 1700 7.3 AVP Codes 1702 This specification assigns the values TBD - TBD from the AVP code 1703 namespace defined in [DIAMBASE] See section 4.0 for the assignment of 1704 the namespace in this specification. 1706 7.4 Result-Code AVP Values 1708 This specification assigns the values 40XX and 50XX from the Result- 1709 Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. See 1710 section 5.0 for the assignment of the namespace in this 1711 specification. 1713 7.5 Abnormal-Termination-Reason AVP 1715 As defined in Section 4.1, the Abnormal-Termination-Reason AVP (AVP 1716 Code TBD) defines the values 0-1. All remaining values are available 1717 for assignment via Designated Expert [IANA]. 1719 7.6 Check-Balance-Result AVP 1721 As defined in Section 4.3, the Check-Balance-Result AVP (AVP Code 1722 TBD) defines the values 0-1. All remaining values are available for 1723 assignment via Designated Expert [IANA]. 1725 7.7 Credit-Control-Failure-Handling AVP 1727 As defined in Section 4.6, the Credit-Control-Failure-Handling AVP 1728 (AVP Code TBD) defines the values 0-1. All remaining values are 1729 available for assignment via Designated Expert [IANA]. 1731 7.8 Direct-Debiting-Failure-Handling AVP 1733 As defined in Section 4.8, the Direct-Debiting-Failure-Handling AVP 1734 (AVP Code TBD) defines the values 0-1. All remaining values are 1735 available for assignment via Designated Expert [IANA]. 1737 7.9 Requested-Action AVP 1739 As defined in Section 4.11, the Requested-Action AVP (AVP Code TBD) 1740 defines the values 0-3. All remaining values are available for 1741 assignment via Designated Expert [IANA]. 1743 7.10 Subscription-Id-Type AVP 1745 As defined in Section 4.17, the Subscription-Id-Type AVP (AVP Code 1746 TBD) defines the values 0-4. All remaining values are available for 1747 assignment via Designated Expert [IANA]. 1749 7.11 Unit-Type AVP 1750 As defined in Section 4.20, the Unit-Type AVP (AVP Code TBD) defines 1751 the values 0-3. All remaining values are available for assignment via 1752 Designated Expert [IANA]. 1754 8 Credit-control Application related parameter 1756 Tx timer 1758 When real-time credit-control is required, the credit-control 1759 client contacts the credit-control server before and during the 1760 service is provided to an end user. Due to real-time nature of 1761 application the communication delays SHOULD be minimized, e.g. to 1762 avoid too long service set up time experienced by the end user. The 1763 Tx timer is introduced to control the waiting time in the client in 1764 the PENDING state. 1766 The recommended value is 10 seconds. 1768 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 1770 Client implementations may offer the possibility to locally 1771 configure these AVPs. In such a case their value and behavior is 1772 defined in section 4.5 for the Credit-Control-Failure-Handling and 1773 in section 4.7 for the Direct-Debiting-Failure-Handling. 1775 The credit control server may override the failure handling by 1776 including for credit control session by including the Credit- 1777 Control-Failure-Handling AVP in the Accounting-Answer command. 1779 9 Security Considerations 1781 The security models as defined in the Diameter base protocol 1782 [DIAMBASE] applies to this application too. 1784 10 References 1786 10.1 Normative 1788 [DIAMBASE] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney 1789 "Diameter Base Protocol", IETF work in progress. 1791 [3GPPCHARG] 3rd Generation Partnership Project; Technical Specification 1792 Group Services and System Aspects, Service aspects; 1793 Charging and Billing, (release 5), 3GPP TS 22.115 v. 5.2.1, 1794 2002-03 1796 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, G. 1797 Camarillo, A. Johnston, J. Peterson, R. Sparks 1798 "SIP: Session Initiation Protocol", RFC 3261. June 2002. 1800 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486. 1801 January 1999. 1803 [E164] Recommendation E.164/I.331 (05/97): The International 1804 Public Telecommunication Numbering Plan. 1997. 1806 [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List of 1807 ITU-T Recommendation E.164 assigned country codes", June 1808 2000. 1810 [E212] Recommendation E.212 (11/98): The international 1811 identification plan for mobile terminals and mobile users. 1812 1998. 1814 [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List 1815 of mobile country or geographical area codes ", February 1816 1999. 1818 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 1819 Considerations Section in RFCs", BCP 26, RFC 2434, October 1820 1998 1822 10.2 Non-Normative 1824 [KEYWORDS] S.Bradner, "Key words for use in RFCs to Indicate 1825 Requirement Levels", BCP 14, RFC 2119, March 1997. 1827 [ACCMGMT] B.Aboba, J.Arkko, D.Harrington. "Introduction to Accounting 1828 Management", RFC 2975, October 2000. 1830 11 Acknowledgement 1832 The authors would like to thank Paco Marin at Vodafone R&D and our 1833 colleagues with Ericsson and Nokia for their comments and 1834 suggestions. 1836 12 Author's Address 1838 Harri Hakala 1839 Oy L M Ericsson Ab 1840 Joukahaisenkatu 1 1841 20520 Turku 1842 Finland 1844 Phone: +358 2 265 3722 1845 EMail: Harri.Hakala@ericsson.fi 1847 Leena Mattila 1848 Oy L M Ericsson Ab 1849 Joukahaisenkatu 1 1850 20520 Turku 1851 Finland 1853 Phone: +358 2 265 3731 1854 EMail: Leena.Mattila@ericsson.fi 1855 Juha-Pekka Koskinen 1856 Nokia Networks 1857 Hatanpaanvaltatie 30 1858 33100 Tampere 1859 Finlad 1861 Phone: +358 7180 74027 1862 Email: juha-pekka.koskinen@nokia.com 1864 Marco Stura 1865 Nokia Networks 1866 Valimotie 21 1867 00380 Helsinki 1868 Finland 1870 Phone: +358 7180 64308 1871 Email: marco.stura@nokia.com 1873 John Loughney 1874 Nokia Research Center 1875 Itamerenkatu 11-13 1876 00180 Helsinki 1877 Finland 1879 Phone: +358 50 483 642 1880 Email: John.Loughney@nokia.com 1882 13 Full Copyright Statement 1884 Copyright (C) The Internet Society (2002). All Rights Reserved. 1886 This document and translations of it may be copied and furnished to 1887 others, and derivative works that comment on or otherwise explain it 1888 or assist in its implementation may be prepared, copied, published 1889 and distributed, in whole or in part, without restriction of any 1890 kind, provided that the above copyright notice and this paragraph are 1891 included on all such copies and derivative works. However, this docu- 1892 ment itself may not be modified in any way, such as by removing the 1893 copyright notice or references to the Internet Society or other 1894 Internet organizations, except as needed for the purpose of 1895 developing Internet standards in which case the procedures for 1896 copyrights defined in the Internet Standards process must be 1897 followed, or as required to translate it into languages other than 1898 English. The limited permissions granted above are perpetual and will 1899 not be revoked by the Internet Society or its successors or assigns. 1900 This document and the information contained herein is provided on an 1901 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1902 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1903 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1904 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1905 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1907 14 Notices 1909 The IETF takes no position regarding the validity or scope of any 1910 intellectual property or other rights that might be claimed to 1911 pertain to the implementation or use of the technology described in 1912 this document or the extent to which any license under such rights 1913 might or might not be available; neither does it represent that it 1914 has made any effort to identify any such rights. Information on the 1915 IETF's procedures with respect to rights in standards-track and 1916 standards-related documentation can be found in BCP-11. Copies of 1917 claims of rights made available for publication and any assurances of 1918 licenses to be made available, or the result of an attempt made to 1919 obtain a general license or permission for the use of such 1920 proprietary rights by implementors or users of this specification can 1921 be obtained from the IETF Secretariat. 1923 The IETF invites any interested party to bring to its attention any 1924 copyrights, patents or patent applications, or other proprietary 1925 rights, which may cover technology that may be required to practice 1926 this standard. Please address the information to the IETF Executive 1927 Director. 1929 15 Expiration Date 1931 This memo is filed as and expires 1932 in October 2003.