idnits 2.17.1 draft-dickel-ascertech-base-01.txt: -(1277): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1284): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1331): 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 662 has weird spacing: '... Length var...' == Line 710 has weird spacing: '... Length var...' == Line 741 has weird spacing: '... Length var...' == Line 758 has weird spacing: '... Length var...' == Line 787 has weird spacing: '... Length var...' == (9 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7651 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: 'Byte' is mentioned on line 1703, but not defined == Missing Reference: '0-9' is mentioned on line 1815, but not defined == Missing Reference: '0-9a-f' is mentioned on line 1835, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Dickel 3 Internet Draft C. Steigner 4 Category : Informational University of Koblenz 5 Document: draft-dickel-ascertech-base-01.txt O. Maletzki 6 Expires: November 2003 T. Dieckmann 7 M. Grundmann 8 S. Busse 9 ascertech 10 May 2003 12 Ascertech's Billing and Accounting System Exchange (BASE) Protocol 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026 except that the right to produce derivative 18 works is not granted. 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 months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes the Billing and Accounting System Exchange 43 (BASE) protocol. BASE is an application level protocol for carrying 44 billing information between distributed Billing Agents and a shared 45 Billing Engine. 47 Table of Contents 49 1. Introduction...................................................3 50 1.1 Terminology................................................4 51 2. Concept of Base................................................5 52 3. BASE Transactions..............................................8 53 3.1 Registration...............................................8 54 3.2 Configuration of Source Systems............................9 55 3.3 Configuration of Billing Agents...........................10 56 3.4 Load Data Transmission....................................11 57 3.5 Miscellaneous.............................................11 58 4. BASE Messages.................................................12 59 4.1 BASE Message Format.......................................12 60 4.2 BASE Message Header.......................................12 61 4.3 Registration of a Billing Agent...........................14 62 4.4 Source System management..................................16 63 4.5 Billing Agent management..................................20 64 4.6 Transfer of load information..............................24 65 4.7 Miscellaneous BASE Messages...............................24 66 4.8 State Machine of the BASE Message Layer...................25 67 5. BASE Message Elements.........................................27 68 5.1 Service Message Element...................................27 69 5.2 Service Parameter Element.................................28 70 5.3 Booking Message Element...................................30 71 5.4 Parameter Value Element...................................31 72 5.5 LIFDATA Message Element...................................31 73 5.6 Identification Message Element............................32 74 5.7 Policy Message Element....................................33 75 5.8 Notification Message Element..............................34 76 6. Error Handling................................................34 77 7. Definitions...................................................35 78 7.1 BASE Data Types...........................................35 79 7.2 BASE Load Types...........................................35 80 7.3 Compose a BASE Load Type..................................37 81 7.4 Regular BASE Expressions..................................38 82 8. Security Considerations.......................................40 83 9. References....................................................40 84 10. Acknowledgements.............................................41 85 11. Authors' Addresses...........................................41 86 12. Full Copyright Statement.....................................42 87 13. Expiration Date..............................................43 89 Requirements Language 91 In this document, the key words "MAY", "MUST", "MUST NOT","OPTIONAL", 92 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 93 described in [RFC2119]. 95 1. Introduction 97 Recording and evaluating billing information from a large number of 98 dispersed resources can create the need for significant 99 administrative support. Since every resource in a local computer 100 infrastructure causes its specific costs due to the maintenance and 101 the investment for the infrastructure, billing facilities for the 102 exchange of auto-configuration- and billing information have to be 103 provided. Only if the costs for all activities can be made 104 transparent, the accounting process needs no longer be based on rough 105 estimations. This BASE (Billing and Accounting System Exchange) 106 protocol document specifies an interface for all data transfer 107 between the subsystems of a distributed billing and accounting 108 system. This billing and accounting system consists of a central 109 control module called Billing Engine (BE) and a number of dispersed 110 Billing Agents (BA). The BE is solely responsible for the collection 111 of all billing information that may appear in a corporate network. 112 Billing information may be the amount of network traffic, the 113 database usage or the allocation of disk space. 115 The BASE protocol was developed by the ascertech corporation and is 116 implemented in the ascertech BillingWare software products. 118 Key features of the BASE protocol are: 120 Client/Server Model 122 A Billing Agent (BA) operates as a client of the Billing Engine 123 (BE) during the registration and configuration (Check-In) of a BA. 124 During this transaction the BE acts as a server. The peers, 125 however, may change their part of being client or server due to the 126 fact that each peer may be the initiator of a transaction. 128 TCP-based 130 All transactions are carried out on top of TCP due to the pervasive 131 availability and connection-oriented reliability of TCP. 133 Agent based 135 Billing Agents have to be disposed in all active resources and have 136 to be activated as soon as billing information of that resource has 137 to be recorded or administrative tasks have to be performed to 138 enable this process. The agent actively introduces itself to the 139 billing engine in order to negotiate the conditions of the 140 acquisition of the billing information and its pooled transmission 141 of billing information to the BE. Thus, agents request a 142 bookkeeping service from the BE. 144 Application domain 146 The BASE protocol acts as means of transport for all relevant 147 billing information which affect the costs for maintenance and 148 investment of all components of a corporate computer network domain, 149 as well as related administrative information. In contrast to 150 network accounting servers all components like disks, databases, 151 printers, routers, CPUs etc. are items for the billing process. 153 1.1 Terminology 155 This document uses the following terms: 157 BASE 159 The Billing and Accounting System Exchange protocol is used for all 160 communication between a Billing Engine and a Billing Agent and is 161 covered by this document. 163 Billing Engine 165 The Billing Engine (BE) is a facility within a corporate computer 166 network which serves as central bookkeeper for all agent-based 167 incoming billing messages. The BE may open a new account for a 168 requesting agent and negotiate on details for the management of 169 the billing information to be transferred after the negotiation. 171 Billing Agent 173 The Billing Agent (BA) is part of all active resources and is 174 activated if the cost-relevant billing information of the resource 175 has to be recorded or administrative tasks have to be performed to 176 enable this process. The Billing Agent actively introduces itself 177 to the Billing Engine in order to negotiate the conditions of the 178 acquisition of the billing information and its pooled transmission 179 to the BE. Thus, agents request a bookkeeping service from the BE. 181 BASE Peer 183 A BASE Peer is a Billing Agent or the Billing Engine. 185 Source System 187 A Source System is a system that produces the load data gathered by 188 a Billing Agent, the system that is monitored and may be configured 189 by a Billing Agent. 191 BASE Message 193 A message that is exchanged between BASE Peers is called BASE 194 Message. 196 BASE Transaction 198 A task that is performed by the exchange of BASE Messages between 199 BASE Peers is called a BASE Transaction. 201 Initiating Peer 203 An Initiating Peer may either be the BA or BE which is actively 204 opening a dialog with its peer. 206 Receiving Peer 208 A Receiving Peer may either be the BA or BE which is has already 209 undergone a passive open procedure in order to listen to the dialog 210 opening with its peer. 212 Syntax specifications within this document are done using Augmented 213 Backus-Naur Form (ABNF) [RFC2234]. 215 2. Concept of Base 217 The BASE protocol is an application protocol which is running on top 218 of TCP [RFC793]. The Billing Engine is listening on TCP port 5429 for 219 incoming connection requests. A Billing Agent performs an active open 220 on TCP port 5429 to establish a TCP connection with the Billing 221 Engine. The TCP port 5429 has been officially assigned to BASE by the 222 Internet Assigned Numbers Authority (IANA). 224 After the TCP connection is established, the BASE protocol is used to 225 perform the following tasks: 227 - registration of the Billing Agent to the Billing Engine 228 - configuration of the Billing Agent by the Billing Engine 229 - transmission of gathered load data from the Billing Agent to the 230 Billing Engine 232 Such a task is called a BASE Transaction. To perform a BASE 233 Transaction, it is necessary to exchange messages between the 234 participating peers. These messages are called BASE Messages. The 235 communication layer on which the BASE messages are exchanged between 236 two BASE peers is called the BASE Message layer and is placed on top 237 of TCP as stated above. 239 A BASE Transaction is initiated by the Billing Engine or the Billing 240 Agent and consists either of the exchange of a single BASE Message or 241 the exchange of two BASE Messages. Within the BASE protocol the 242 following BASE Transactions are defined: 244 --------------------------------------------------------------------- 245 Transaction Initiated by Transaction Type 246 Name B-Agent B-Engine Single message Two message 247 --------------------------------------------------------------------- 248 Check-In X X 249 Register X X 250 Policies X X 251 Account-Add X X 252 Account-Delete X X 253 Account-Change X X 254 Account-Suspend X X 255 Account-Unsuspend X X 256 Policy-Add X X 257 Policy-Delete X X 258 Policy-Change X X 259 Policies-Start X X 260 Policies-Stop X X 261 Policies-Reset X X 262 LIF-Data X X 263 Ping X X X 264 Notification X X X 265 Disconnect X X X 267 Two message BASE Transactions 269 For the initiating side, a two message BASE Transaction is started 270 with the transmission of the corresponding BASE Message (request) to 271 the BASE peer and completed by the reception of the according BASE 272 Message from this BASE peer (response). 274 For the receiving side, a two message BASE Transaction is started by 275 the reception of a BASE message from the BASE peer as a request and 276 completed with the transmission of the corresponding BASE Message 277 as response. 279 request message response message 280 initiating peer --------> receiving peer ---------> initiating peer 282 Single message BASE Transactions 284 A single message BASE Transaction is completely performed with the 285 transmission/reception of the according BASE Message. 287 message 288 initiating peer -------> receiving peer 290 The chapter BASE Transactions provides a description of these BASE 291 Transactions. 293 The following table lists the currently defined BASE Messages. The 294 names of the BASE Messages are derived from the corresponding BASE 295 Transactions: 297 Possible Sender 298 BASE Message name Billing Engine Billing Agent 299 --------------------------------------------------------------- 300 CHECKINREQ X 301 CHECKINRES X 302 REGISTERREQ X 303 REGISTERRES X 304 POLICIESREQ X 305 POLICIESRES X 306 ACCOUNTADDREQ X 307 ACCOUNTADDRES X 308 ACCOUNTDELETEREQ X 309 ACCOUNTDELETERES X 310 ACCOUNTCHANGEREQ X 311 ACCOUNTCHANGERES X 312 ACCOUNTSUSPENDREQ X 313 ACCOUNTSUSPENDRES X 314 ACCOUNTUNSUSPENDREQ X 315 ACCOUNTUNSUSPENDRES X 316 POLICYADDREQ X 317 POLICYADDRES X 318 POLICYDELETEREQ X 319 POLICYDELETERES X 320 POLICYCHANGEREQ X 321 POLICYCHANGERES X 322 POLICIESSTARTREQ X 323 POLICIESSTARTRES X 324 POLICIESSTOPREQ X 325 POLICIESSTOPRES X 326 POLICIESRESETREQ X 327 POLICIESRESETRES X 328 LIFDATA X 329 PINGREQ X X 330 PINGRES X X 331 NOTIFICATION X X 332 DISCONNECT X X 333 ---------------------------------------------------------------- 335 The BASE Message format is described in detail in the chapter BASE 336 Messages. 338 BASE Message Layer acknowledgements 340 On the BASE Message Layer every BASE Message, except Disconnect, is 341 acknowledged from the receiving BASE peer by sending one byte of 342 value %xFF. This enables the implementation of an "blocking send" for 343 BASE Messages. The arrival of the acknowledgement byte is signaling 344 that the BASE Message has been received by the peer's BASE Message 345 layer. The acknowledgement byte does not indicate that the BASE 346 Message was processed by the BASE peer. 348 3. BASE Transactions 350 BASE Transactions are classified in four categories. BASE 351 Transactions in relation to the registration process of a Billing 352 Agent (3.1), BASE Transactions in relation to the configuration 353 process of a Source System (3.2) or a Billing Agent (3.3), a BASE 354 Transaction to transmit gathered load data (3.4), and the remaining 355 BASE Transactions which are not assigned to these previous categories 356 (3.4). 358 BASE Transactions of category 3.2, 3.3, and 3.3 are tagged by 359 transaction identifiers. A transaction identifier is a 16 bit value 360 and has to be unique within each of the categories 3.2, 3.3, and 3.4. 361 The transaction identifier of a BASE Transaction belonging to 362 category 3.2 and 3.3 is generated by the Billing Engine and the 363 transaction identifier of a BASE Transaction belonging to category 364 3.4 is generated by the Billing Agent. 366 3.1 Registration 368 Check-In 370 The first task, which had to be performed by a Billing Agent, is to 371 identify itself to the Billing Engine. Therefore, every BASE peer 372 has a unique BASE identifier. The BASE idenfifier is a 32 bit value 373 and is assigned at installation time. 374 To start a Check-In transaction a Billing Agent sends a CHECKINREQ 375 BASE Message to the Billing Engine. The Billing Engine responds 376 with the corresponding CHECKINRES BASE Message, which signals 377 whether the Billing Agent is accepted or not. 379 Register 381 If type and functionality of a Billing Agent is unknown, the 382 Billing Engine starts a Register transaction by sending a 383 REGISTERREQ BASE Message to that Billing Agent. The Billing Agent 384 answers with a REGISTERRES BASE Message, which contains all 385 registration information, needed by the Billing Engine in order to 386 configure the Billing Agent. 388 Policies 390 The Policy transaction is intended to provide the Billing Engine 391 with a list of all policies, which are stored on a Billing Agent. 392 This transaction is started by the Billing Engine with a 393 POLICIESREQ BASE Message and is answered by the Billing Agent with 394 the complete information about all booked policies. This 395 information is delivered within an POLICIESRES BASE Message form 396 the Billing Agent. 398 3.2 Configuration of Source Systems 400 Account-Add 402 The Account-Add transaction is intended to create a new service for 403 a user on a source system. This transaction is initiated from the 404 Billing Engine by sending an ACCOUNTADDREQ BASE Message to the 405 Billing Agent and is answered by the Billing Agent with the 406 corresponding ACCOUNTADDRES BASE Message. 408 Account-Delete 410 The Account-Delete transaction is intended to remove an existing 411 service for a user on a source system. This transaction is 412 initiated from the Billing Engine by sending an ACCOUNTDELETEREQ 413 BASE Message to the Billing Agent and is answered by the Billing 414 Agent with the corresponding ACCOUNTDELETERES BASE Message. 416 Account-Change 418 The Account-Change transaction is intended to change the 419 configuration of an existing service for a user on a source system. 420 This transaction is initiated from the Billing Engine by sending an 421 ACCOUNTCHANGEREQ BASE Message to the Billing Agent and is answered 422 by the Billing Agent with the corresponding ACCOUNTCHANGERES BASE 423 Message. 425 Account-Suspend 427 The Account-Suspend transaction is intended to temporarily lock a 428 service for a user on a source system. This transaction is 429 initiated from the Billing Engine by sending an ACCOUNTSUSPENDREQ 430 BASE Message to the Billing Agent and is answered by the Billing 431 Agent with the corresponding ACCOUNTSUSPENDRES BASE Message. 433 Account-Unsuspend 435 The Account-Unsuspend transaction is intended to unlock a service 436 previously locked for a user on a source system. This transaction 437 is initiated from the Billing Engine by sending an 438 ACCOUNTUNSUSPENDREQ BASE Message to the Billing Agent and is 439 answered by the Billing Agent with the corresponding 440 ACCOUNTUNSUSPENDRES BASE Message. 442 3.3 Configuration of Billing Agents 444 Policy-Add 446 The Policy-Add transaction is intended to create a policy at a 447 Billing Agent. This means to book a service on a Billing Agent. A 448 policy is a set of rules, which controls the gathering and delivery 449 of load data. This transaction is initiated from the Billing Engine 450 by sending a POLICYADDREQ BASE Message to the Billing Agent and is 451 answered by the Billing Agent with the corresponding POLICYADDRES 452 BASE Message. 454 Policy-Delete 456 The Policy-Delete transaction is intended to delete a policy. This 457 is used to cancel the booking of a service on a Billing Agent. This 458 transaction is initiated from the Billing Engine by sending a 459 POLICYDELETEREQ BASE Message to the Billing Agent and is answered 460 by the Billing Agent with the corresponding POLICYDELETERES BASE 461 Message. 463 Policy-Change 465 The Policy-Change transaction is intended to modify a policy on a 466 Billing Agent. This transaction is initiated from the Billing 467 Engine by sending a POLICYCHANGEREQ BASE Message to the Billing 468 Agent and is answered by the Billing Agent with the corresponding 469 POLICYCHANGERES BASE Message. 471 Policies-Start 473 The Policies-Start transaction is intended to activate all policies 474 that are stored on a Billing Agent. It causes the Billing Agent to 475 gather and deliver load data accordingly. This transaction is 476 initiated from the Billing Engine by sending a POLICIESSTARTREQ 477 BASE Message to the Billing Agent and is answered by the Billing 478 Agent with the corresponding POLICIESSTARTRES BASE Message. 480 Policies-Stop 482 The Policies-Stop transaction is intended to deactivate all stored 483 policies on a Billing Agent. It causes the Billing Agent to stop 484 gathering and delivering load data. This transaction is initiated 485 from the Billing Engine by sending a POLICIESSTOPREQ BASE Message 486 to the Billing Agent and is answered by the Billing Agent with the 487 corresponding POLICIESSTOPRES BASE Message. 489 Policies-Reset 491 The Policies-Reset transaction is intended to restore the initial 492 configuration of a Billing Agent. Therefore all policies created by 493 Policy-Add transactions are discarded. This transaction is 494 initiated from the Billing Engine by sending a POLICIESRESETREQ 495 BASE Message to the Billing Agent and is answered by the Billing 496 Agent with the corresponding POLICIESRESETRES BASE Message. 498 3.4 Load Data Transmission 500 LIF-Data 502 The LIF-Data (Load Information Data) transaction is intended to 503 transmit gathered load data from a Billing Agent to the Billing 504 Engine. LIF-Data is a single message transaction and is initiated by 505 a Billing Agent with a LIF-DATA BASE Message. 507 3.5 Miscellaneous 509 Ping 511 The Ping transaction is intended to detect if the BASE peer is 512 still reachable and working. A Ping transaction can initiated by 513 the Billing Engine or a Billing Agent. The initiating peer is 514 sending a PINGREQ BASE Message and the receiving peer answers with 515 a PINGRES BASE Message. 517 Notification 519 The Notification transaction is intended to transfer a notice from 520 BASE peer to BASE peer. In special the Notification transaction is 521 used by a Billing Agent to inform the Billing Engine about the 522 occurrence of an error in connection with a active policy. 523 Notification is a single message transaction and is initiated by a 524 Billing Agent or the Billing Engine by sending a NOTIFICATION BASE 525 Message. 527 Disconnect 529 The Disconnect transaction is intended to disconnect a Billing 530 Agent and the Billing Engine. Disconnect is a single message 531 transaction and is initiated by a Billing Agent or the Billing 532 Engine by sending a DISCONNECT BASE Message. (Note: A DISCONNECT 533 BASE Message is not acknowledged at the BASE Message Layer.) 535 4. BASE Messages 537 4.1 BASE Message Format 539 BASE Message consists of a BASE Message Header and a BASE Message 540 Element Container. 542 +---------------------+--------------------------------+ 543 | BASE Message Header | BASE Message Element Container | 544 +---------------------+--------------------------------+ 546 The size of the BASE Message Header is 16 bytes. The size of the BASE 547 Message Element Container is variable. 549 4.2 BASE Message Header 551 0 1 2 3 552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Version | Message Type | Message State | reserved | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Peer Identifier | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Transaction ID | Message Element Count | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Message Element Container Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 BASE Message Header fields 565 Version: 8 bits 567 Identifies the BASE protocol version. This document describes the 568 BASE Protocol version 3. To indicate the usage of BASE Protocol 569 Version 3 the Version field MUST be set to 3. 571 Msg Type: 8 bits 573 Identifies the BASE Message. The following message types are 574 assigned: 576 ---------------------------------------------------------- 577 MsgType BASE Message | MsgType BASE Message 578 ---------------------------------------------------------- 579 %x00 not assigned | %x20 POLICYADDREQ 580 %x01 CHECKINREQ | %x21 POLICYADDRES 581 %x02 CHECKINRES | %x22 POLICYDELETEREQ 582 %x03 not assigned | %x23 POLICYDELETERES 583 %x04 REGISTERREQ | %x24 POLICYCHANGEREQ 584 %x05 REGISTERRES | %x25 POLICYCHANGERES 585 %x06 POLICIESREQ | %x26 POLICIESSTARTREQ 586 %x07 POLICIESRES | %x27 POLICIESSTARTRES 587 %x08 | %x28 POLICIESTOPREQ 588 : not assigned | %x29 POLICIESTOPRES 589 %x0F | %x2A POLICIESRESETREQ 590 %x10 ACCOUNTADDREQ | %x2B POLICIESRESETRES 591 %x11 ACCOUNTADDRES | %x2C 592 %x12 ACCOUNTDELETEREQ | : not assigned 593 %x13 ACCOUNTDELETERES | %x30 594 %x14 ACCOUNTCHANGEREQ | %x31 LIFDATA 595 %x15 ACCOUNTCHANGERES | %x32 PINGREQ 596 %x16 ACCOUNTSUSPENDREQ | %x33 PINGRES 597 %x17 ACCOUNTSUSPENDRES | %x34 NOTIFICATION 598 %x18 ACCOUNTUNSUSPENDREQ | %x35 599 %x19 ACCOUNTUNSUSPENDRES | : not assigned 600 %x1A | %xFE 601 : not assigned | %xFF DISCONNECT 602 %x1F | 604 Msg State: 8 bits 606 The Msg State field contains status information or an error code. 607 The following values are defined: 609 0 SUCCESS / No error occurred 610 1 ERROR 611 2 Identifier already in use 612 3 Invalid identifier 613 4 Open in progress 614 5 SHUTDOWN 615 6 Buffer full 616 7 Action superfluous 617 8 Policy already exists 618 9 Rollback failed / Action on account failed; 620 10 Agent identifier not valid 621 11 Timeout 622 12 Policy does not exist 623 13 - 624 14 Protocol violation 625 15 An internal error occurred 626 16 - 255 undefined 628 Peer Identifier: 32 bits 630 This field contains the unique BASE Peer Identifier. 632 Transaction ID: 16 bits 634 This field contains the Transaction Identifier. 636 Message Element Count: 16 bits 638 This field contains the number of Message Elements in the BASE 639 Message Element Container. 641 Message Element Container Length: 32 bits 643 This field contains the length of the BASE Message Container in 644 octets. 646 4.3 Registration of a Billing Agent 648 CHECKINREQ 650 A CHECKINREQ message is sent from a Billing Agent to a Billing 651 Engine in order to connect the Billing Agent. The Msg Type field 652 value MUST be %x01. Possible Msg State field values are 0 and 13. A 653 CHECKINREQ message always uses a Transaction ID of 0 and has an 654 Identification Message Element (see 5.6). 656 Message Header field values: 658 Msg Type %x01 659 Msg State 0 660 Transaction ID 0 661 Message Element Count 1 662 Message Element Container Length variable 664 CHECKINRES 666 A CHECKINRES message is sent from a Billing Engine to a Billing 667 Agent in response to a CHECKINREQ message from that Billing Agent 668 and is signaling weather the connection of the Billing Agent is 669 accepted by the Billing Engine or not. The Msg Type field value 670 MUST be %x02. A CHECKINRES message uses a Transaction ID of 0 and 671 has no Message Elements. 673 Message Header field values: 675 Msg Type %x02 676 Msg State variable 677 Transaction ID 0 678 Message Element Count 0 679 Message Element Container Length 0 681 REGISTERREQ 683 A REGISTERREQ message is sent from a Billing Engine to a Billing 684 Agent in order to proceed a Register transaction. The Msg Type 685 field value MUST be %x04. The Msg State field value is 0. A 686 REGISTERREQ message uses a Transaction ID of 0 and has no Message 687 Elements. 689 Message Header field values: 691 Msg Type %x04 692 Msg State 0 693 Transaction ID 0 694 Message Element Count 0 695 Message Element Container Length 0 697 REGISTERRES 699 A REGISTERRES message is sent from a Billing Agent to a Billing 700 Engine in order to complete a Register transaction. The Msg Type 701 field value MUST be %x05. A REGISTERRES message uses a Transaction 702 ID of 0 and has Service Message Elements (see 5.1). 704 Message Header field values: 706 Msg Type %x05 707 Msg State variable 708 Transaction ID 0 709 Message Element Count variable 710 Message Element Container Length variable 712 POLICIESREQ 714 A POLICIESREQ message is sent from a Billing Engine to a Billing 715 Agent in order to proceed a Policies transaction. The Msg Type 716 field value MUST be %x06. The Msg State field value is 0. A 717 POLICIESREQ message uses a Transaction ID of 0 and has no Message 718 Elements. 720 Message Header field values: 722 Msg Type %x06 723 Msg State 0 724 Transaction ID 0 725 Message Element Count 0 726 Message Element Container Length 0 728 POLICIESRES 730 A POLICIESRES message is sent from a Billing Agent to a Billing 731 Engine in order to complete a Policies transaction. The Msg Type 732 field value MUST be %x07. A POLICIESRES message uses a Transaction 733 ID of 0 and has Policy Message Elements (see 5.7). 735 Message Header field values: 737 Msg Type %x07 738 Msg State variable 739 Transaction ID 0 740 Message Element Count variable 741 Message Element Container Length variable 743 4.4 Source System management 745 ACCOUNTADDREQ 747 An ACCOUNTADDREQ message is sent from a Billing Engine to a Billing 748 Agent in order to proceed an Account-Add transaction. The Msg Type 749 field value MUST be %x10. The Msg State field value is 0. The 750 Transaction ID is determined by the Billing Engine. An 751 ACCOUNTADDREQ message has one Booking Message Element (see 5.3). 753 Message Header field values: 754 Msg Type %x10 755 Msg State 0 756 Transaction ID variable 757 Message Element Count 1 758 Message Element Container Length variable 760 ACCOUNTADDRES 762 An ACCOUNTADDRES message is sent from a Billing Agent to a Billing 763 Engine in order to complete the Account-Add transaction identified 764 by the specified Transaction ID. The Msg Type field value MUST be 765 %x11. An ACCOUNTADDRES message has no Message Elements. 767 Message Header field values: 768 Msg Type %x11 769 Msg State variable 770 Transaction ID variable 771 Message Element Count 0 772 Message Element Container Length 0 774 ACCOUNTDELETEREQ 776 An ACCOUNTDELETEREQ message is sent from a Billing Engine to a 777 Billing Agent in order to proceed an Account-Delete transaction. 778 The Msg Type field value MUST be %x12. The Msg State field value is 779 0. The Transaction ID is determined by the Billing Engine. An 780 ACCOUNTDELETEREQ message has one Booking Message Element (see 5.3). 782 Message Header field values: 783 Msg Type %x12 784 Msg State 0 785 Transaction ID variable 786 Message Element Count 1 787 Message Element Container Length variable 789 ACCOUNTDELETERES 791 An ACCOUNTDELETERES message is sent from a Billing Agent to a 792 Billing Engine in order to complete an Account-Delete transaction 793 identified by the specified Transaction ID. The Msg Type field 794 value MUST be %x09. An ACCOUNTDELETERES message has no Message 795 Elements. 797 Message Header field values: 798 Msg Type %x13 799 Msg State variable 800 Transaction ID variable 801 Message Element Count 0 802 Message Element Container Length 0 804 ACCOUNTCHANGEREQ 806 An ACCOUNTCHANGEREQ message is sent from a Billing Engine to a 807 Billing Agent in order to proceed an Account-Change transaction. 808 The Msg Type field value MUST be %x14. The Msg State field value is 809 0. The Transaction ID is determined by the Billing Engine. An 810 ACCOUNTCHANGEREQ message has one Booking Message Element (see 5.3). 812 Message Header field values: 813 Msg Type %x14 814 Msg State 0 815 Transaction ID variable 816 Message Element Count 1 817 Message Element Container Length variable 819 ACCOUNTCHANGERES 821 An ACCOUNTCHANGERES message is sent from a Billing Agent to a 822 Billing Engine in order to complete an Account-Change transaction 823 identified by the specified Transaction ID. The Msg Type field 824 value MUST be %x15. An ACCOUNTCHANGERES message has no Message 825 Elements. 827 Message Header field values: 828 Msg Type %x15 829 Msg State variable 830 Transaction ID variable 831 Message Element Count 0 832 Message Element Container Length 0 834 ACCOUNTSUSPENDREQ 836 An ACCOUNTSUSPENDREQ message is sent from a Billing Engine to a 837 Billing Agent in order to proceed an Account-Suspend transaction. 838 The Msg Type field value MUST be %x16. The Msg State field value is 839 0. The Transaction ID is determined by the Billing Engine. An 840 ACCOUNTSUSPENDREQ message has one Booking Message Element (see 841 5.3). 843 Message Header field values: 844 Msg Type %x16 845 Msg State 0 846 Transaction ID variable 847 Message Element Count 1 848 Message Element Container Length variable 850 ACCOUNTSUSPENDRES 852 An ACCOUNTSUSPENDRES message is sent from a Billing Agent to a 853 Billing Engine in order to complete an Account-Suspend transaction 854 identified by the specified Transaction ID. The Msg Type field 855 value MUST be %x17. An ACCOUNTSUSPENDRES message has no Message 856 Elements. 858 Message Header field values: 859 Msg Type %x17 860 Msg State variable 861 Transaction ID variable 862 Message Element Count 0 863 Message Element Container Length 0 865 ACCOUNTUNSUSPENDREQ 867 An ACCOUNTUNSUSPENDREQ message is sent from a Billing Engine to a 868 Billing Agent in order to proceed an Account-Unsuspend transaction. 869 The Msg Type field value MUST be %x18. The Msg State field value is 870 0. The Transaction ID is determined by the Billing Engine. An 871 ACCOUNTUNSUSPENDREQ message has one Booking Message Element (see 872 5.3). 874 Message Header field values: 875 Msg Type %x18 876 Msg State 0 877 Transaction ID variable 878 Message Element Count 1 879 Message Element Container Length variable 881 ACCOUNTUNSUSPENDRES 883 An ACCOUNTUNSUSPENDRES message is sent from a Billing Agent to a 884 Billing Engine in order to complete an Account-Unsuspend 885 transaction identified by the specified Transaction ID. The Msg 886 Type field value MUST be %x19. An ACCOUNTUNSUSPENDRES message has 887 no Message Elements. 889 Message Header field values: 890 Msg Type %x19 891 Msg State variable 892 Transaction ID variable 893 Message Element Count 0 894 Message Element Container Length 0 896 4.5 Billing Agent management 898 POLICYADDREQ 900 A POLICYADDREQ message is sent from a Billing Engine to a Billing 901 Agent in order to proceed a Policy-Add transaction. The Msg Type 902 field value MUST be %x20. The Msg State field value is 0. The 903 Transaction ID is determined by the Billing Engine. A POLICYADDREQ 904 message has one Booking Message Element (see 5.3). 906 Message Header field values: 907 Msg Type %x20 908 Msg State 0 909 Transaction ID variable 910 Message Element Count 1 911 Message Element Container Length variable 913 POLICYADDRES 915 A POLICYADDRES message is sent from a Billing Agent to a Billing 916 Engine in order to complete a Policy-Add transaction identified by 917 the specified Transaction ID. The Msg Type field value MUST be 918 %x21. A POLICYADDRES message has no Message Elements. 920 Message Header field values: 921 Msg Type %x21 922 Msg State variable 923 Transaction ID variable 924 Message Element Count 0 925 Message Element Container Length 0 927 POLICYDELETEREQ 929 A POLICYDELETEREQ message is sent from a Billing Engine to a 930 Billing Agent in order to proceed a Policy-Delete transaction. The 931 Msg Type field value MUST be %x22. The Msg State field value is 0. 932 The Transaction ID is determined by the Billing Engine. A 933 POLICYDELETEREQ message has one Booking Message Element (see 5.3). 935 Message Header field values: 936 Msg Type %x22 937 Msg State 0 938 Transaction ID variable 939 Message Element Count 1 940 Message Element Container Length variable 942 POLICYDELETERES 944 A POLICYDELETERES message is sent from a Billing Agent to a Billing 945 Engine in order to complete a Policy-Delete transaction identified 946 by the specified Transaction ID. The Msg Type field value MUST be 947 %x23. A POLICYDELETERES message has no Message Elements. 949 Message Header field values: 950 Msg Type %x23 951 Msg State variable 952 Transaction ID variable 953 Message Element Count 0 954 Message Element Container Length 0 956 POLICYCHANGEREQ 958 A POLICYCHANGEREQ message is sent from a Billing Engine to a 959 Billing Agent in order to proceed a Policy-Change transaction. The 960 Msg Type field value MUST be %x24. The Msg State field value is 0. 961 The Transaction ID is determined by the Billing Engine. A 962 POLICYCHANGEREQ message has one Booking Message Element. 964 Message Header field values: 965 Msg Type %x24 966 Msg State 0 967 Transaction ID variable 968 Message Element Count 1 969 Message Element Container Length variable 971 POLICYCHANGERES 973 A POLICYCHANGERES message is sent from a Billing Agent to a Billing 974 Engine in order to complete a Policy-Change transaction identified 975 by the specified Transaction ID. The Msg Type field value MUST be 976 %x25. A POLICYCHANGERES message has no Message Elements. 978 Message Header field values: 979 Msg Type %x25 980 Msg State variable 981 Transaction ID variable 982 Message Element Count 0 983 Message Element Container Length 0 985 POLICIESSTARTREQ 987 A POLICCIESTARTREQ message is sent from a Billing Engine to a 988 Billing Agent in order to proceed a Policies-Start transaction. The 989 Msg Type field value MUST be %x26. The Msg State field value is 0. 990 The Transaction ID is determined by the Billing Engine. A 991 POLICIESSTARTREQ message has no Message 992 Elements. 994 Message Header field values: 995 Msg Type %x26 996 Msg State 0 997 Transaction ID variable 998 Message Element Count 0 999 Message Element Container Length 0 1001 POLICIESSTARTRES 1003 A POLICIESSTARTRES message is sent from a Billing Agent to a 1004 Billing Engine in order to complete a Policies-Start transaction 1005 identified by the specified Transaction ID. The Msg Type field 1006 value MUST be %x27. A POLICIESSTARTRES message has no Message 1007 Elements. 1009 Message Header field values: 1010 Msg Type %x27 1011 Msg State variable 1012 Transaction ID variable 1013 Message Element Count 0 1014 Message Element Container Length 0 1016 POLICIESSTOPREQ 1018 A POLICIESSTOPREQ message is sent from a Billing Engine to a 1019 Billing Agent in order to proceed a Policies-Stop transaction. The 1020 Msg Type field value MUST be %x28. The Msg State field value is 0. 1021 The Transaction ID is determined by the Billing Engine. A 1022 POLICIESSTOPREQ message has no Message Elements. 1024 Message Header field values: 1025 Msg Type %x28 1026 Msg State 0 1027 Transaction ID variable 1028 Message Element Count 0 1029 Message Element Container Length 0 1031 POLICIESSTOPRES 1033 A POLICIESSTOPRES message is sent from a Billing Agent to a Billing 1034 Engine in order to complete a Policies-Stop transaction identified 1035 by the specified Transaction ID. The Msg Type field value MUST be 1036 %x29. A POLICIESSTOPRES message has no Message Elements. 1038 Message Header field values: 1039 Msg Type %x29 1040 Msg State variable 1041 Transaction ID variable 1042 Message Element Count 0 1043 Message Element Container Length 0 1045 POLICIESRESETREQ 1047 A POLICIESRESETREQ message is sent from a Billing Engine to a 1048 Billing Agent in order to proceed a Policies-Reset transaction. The 1049 Msg Type field value MUST be %x2A. The Msg State field value is 0. 1050 The Transaction ID is determined by the Billing Engine. A 1051 POLICIESRESETREQ message has no Message Elements. 1053 Message Header field values: 1054 Msg Type %x2A 1055 Msg State 0 1056 Transaction ID variable 1057 Message Element Count 0 1058 Message Element Container Length 0 1060 POLICIESRESETRES 1062 A POLICIESRESETRES message is sent from a Billing Agent to a 1063 Billing Engine in order to complete a Policies-Reset transaction 1064 identified by the specified Transaction ID. The Msg Type field 1065 value MUST be %x2B. A POLICIESSTOPRES message has no Message 1066 Elements. 1068 Message Header field values: 1069 Msg Type %x2B 1070 Msg State variable 1071 Transaction ID variable 1072 Message Element Count 0 1073 Message Element Container Length 0 1075 4.6 Transfer of load information 1077 LIFDATA 1079 A LIFDATA message is sent from a Billing Agent to a Billing Engine 1080 in order to perform a LIF-Data transaction. The Msg Type field 1081 value MUST be %x31. The Msg State field value is 0. The Transaction 1082 ID is determined by the Billing Agent. A LIFDATA message has 1083 LIFDATA Message Elements (see 5.5). 1085 Message Header field values: 1086 Msg Type %x31 1087 Msg State 0 1088 Transaction ID variable 1089 Message Element Count variable 1090 Message Element Container Length variable 1092 4.7 Miscellaneous BASE Messages 1094 PINGREQ 1096 A PINGREQ message is sent from a Billing Engine to a Billing Agent 1097 or a Billing Agent to a Billing Engine in order to test that the 1098 BASE peer is still reachable and operating. The Msg Type field 1099 value MUST be %x33. The Msg State field value and the used 1100 Transaction ID are 0. A PING message has no Message Elements. 1102 Message Header field values: 1103 Msg Type %x32 1104 Msg State 0 1105 Transaction ID 0 1106 Message Element Count 0 1107 Message Element Container Length 0 1109 PINGRES 1111 A PINGRES message is sent from a Billing Engine to a Billing Agent 1112 or a Billing Agent to a Billing Engine in order to confirm that he 1113 is still reachable and operating. The Msg Type field value MUST be 1114 %x33. The Msg State field value and the used Transaction ID are 0. 1115 A PING message has no Message Elements. 1117 Message Header field values: 1118 Msg Type %x33 1119 Msg State 0 1120 Transaction ID 0 1121 Message Element Count 0 1122 Message Element Container Length 0 1124 NOTIFICATION 1126 A NOTIFICATION message is sent from a Billing Agent to a Billing 1127 Engine or a Billing Engine to a Billing Agent in order to perform a 1128 Notification transaction. The Msg Type field value MUST be %x34. 1129 The Msg State field value and the used Transaction ID are 0. A 1130 NOTIFICATION message has one Notification Message Element (see 1131 5.8). 1133 Message Header field values: 1134 Msg Type %x34 1135 Msg State 0 1136 Transaction ID 0 1137 Message Element Count 1 1138 Message Element Container Length variable 1140 DISCONNECT 1142 A DISCONNECT message is sent from a Billing Agent to a Billing 1143 Engine or a Billing Engine to a Billing Agent in order to signalize 1144 that this peer stops the transaction processing and is tearing down 1145 the connection. The Msg Type field value MUST be %xFF. Possible Msg 1146 State field values are 0, 5, 10, 14 or 15. A DISCONNECT message 1147 uses a Transaction ID of 0 and has no Message Elements. (Note: A 1148 DISCONNECT Message is not acknowledged at the BASE Message Layer.) 1150 Message Header field values: 1151 Msg Type %xFF 1152 Msg State variable 1153 Transaction ID 0 1154 Message Element Count 0 1155 Message Element Container Length 0 1157 4.8 State Machine of the BASE Message Layer 1159 An event or an action in lower case letters indicates a communication 1160 from or to the application process (vertical communication) and an 1161 event or an action in upper case letters indicates a communication 1162 between the BASE Message Layers of two BASE Peers (horizontal 1163 communication). 1165 state event action next state 1166 --------------------------------------------------------------------- 1167 INIT prepare - CON_WAIT_BE 1168 checkinreq CHECKINREQ ACK_WAIT_1 1169 CON_WAIT_BE CHECKINREQ ACK + checkinreq CON_CHECK 1170 ACK_WAIT_1 ACK - CON_WAIT_BA 1171 CON_CHECK accept ACCEPT ACK_WAIT_2 1172 reject REJECT ACK_WAIT_3 1173 CON_WAIT_BA ACCEPT ACK + accept CONNECTED_BA 1174 REJECT ACK + reject INIT 1175 ACK_WAIT_2 ACK - CONNECTED_BE 1176 ACK_WAIT_3 ACK - CON_WAIT_BE 1177 CONNECTED_BA EN_MESSAGE ACK + en_message CONNECTED_BA 1178 CONNECTED_BA DISCONNECT disconnect DISCONNECTED 1179 CONNECTED_BA ag_message AG_MESSAGE ACK_WAIT_4 1180 CONNECTED_BA disconnect DISCONNECT DISCONNECTED 1181 CONNECTED_BE AG_MESSAGE ACK + ag_message CONNECTED_BE 1182 CONNECTED_BE DISCONNECT disconnect DISCONNECTED 1183 CONNECTED_BE en_message EN_MESSAGE ACK_WAIT_5 1184 CONNECTED_BE disconnect DISCONNECT DISCONNECTED 1185 ACK_WAIT_4 ACK - CONNECTED_BA 1186 ACK_WAIT_4 EN_MESSAGE ACK + en_message ACK_WAIT_6 1187 ACK_WAIT_4 DISCONNECT disconnect DISCONNECTED 1188 ACK_WAIT_5 ACK - CONNECTED_BE 1189 ACK_WAIT_5 AG_MESSAGE ACK + ag_message ACK_WAIT_7 1190 ACK_WAIT_5 DISCONNECT disconnect DISCONNECTED 1191 ACK_WAIT_6 ACK - CONNECTED_BA 1192 ACK_WAIT_7 ACK - CONNECTED_BE 1194 ACCEPT: CHECKINRES with Msg State field value 0 1196 REJECT: CHECKINRES with Msg State field value other than 0 1198 EN_MESSAGE is an element of the set {REGISTERREQ, POLICIESREQ, 1199 ACCOUNTADDREQ, ACCOUNTDELETEREQ, ACCOUNTCHANGEREQ, ACCOUNTSUSPENDREQ, 1200 ACCOUNTUNSUSPENDREQ, POLICYADDREQ, POLICYDELETEREQ, POLICYCHANGEREQ, 1201 POLICIESSTARTREQ, POLICIESTOPREQ,POLICIESRESETREQ, PINGREQ, PINGRES, 1202 NOTIFICATION} 1204 AG_MESSAGE is an element of the set {REGISTERRES, POLICIESRES, 1205 ACCOUNTADDRES, ACCOUNTDELETERES, ACCOUNTCHANGERES, ACCOUNTSUSPENDRES, 1206 ACCOUNTUNSUSPENDRES, POLICYADDRES, POLICYDELETERES, POLICYCHANGERES, 1207 POLICIESSTARTRES, POLICIESTOPRES, POLICIESRESETRES, LIFDATA, PINGREQ, 1208 PINGRES, NOTIFICATION} 1210 ACK: %xFF (acknowledgement byte) 1212 5. BASE Message Elements 1214 5.1 Service Message Element 1216 A Billing Agent offers a number of services. These services are 1217 describing the abilities of the Billing Agent and how they are used. 1219 While proceeding a Register BASE Transaction the Billing Agent 1220 transmits all information, needed by the Billing Engine for later 1221 use. Therefore each service offered by the Billing Agent is described 1222 by a Service Message Element. These Service Message Elements are sent 1223 within the Message Element Container of a REGISTERRES BASE Message 1224 from the Billing Agent to the Billing Engine. 1226 A Service Message Element consists of a service type, a service 1227 identifier, a service name, the number of Service Parameter Elements 1228 and eventually the Service Parameter Elements themselves. 1230 Service Type(BASE Data Type: BYTE) 1232 is one of POLICYADDREQ, ACCOUNTADDREQ, ACCOUNTDELREQ, 1233 ACCOUNTSUSPENDREQ, ACCOUNTUNSUSPENDREQ, ACCOUNTCHANGEREQ. 1235 POLICYADDREQ implicitly states that the agent also knows the other 1236 POLICY messages, like POLICYDELETEREQ, POLICYCHANGEREQ, 1237 POLICYSTARTREQ, POLICYSTOPREQ, POLICYRESETREQ. 1239 Service ID (BASE Data Type: WORD) 1241 is within the Billing Agent a unique identifier of the service. 1243 Service Name (BASE Data Type: String) 1245 is a textual description of the service. 1247 Parameter Count (BASE Data Type: Byte) 1249 is the number of Service Parameter Elements that are following. 1251 Structure of a Service Message Element: 1253 +---------------------------------------------------------------------+ 1254 |S.Type |Service ID |Service Name |Param. Count | S. Param. Elements | 1255 +---------------------------------------------------------------------+ 1256 1 Byte 2 Bytes variable 1 Byte variable 1257 (String) 1259 5.2 Service Parameter Element 1261 A Service Parameter Element consists of a parameter group field, a 1262 parameter identifier, a parameter name, a parameter data type 1263 identifier and a parameter domain. 1265 Parameter Group (BASE Data Type: Word) 1267 A service may have a number of parameters, who can be used to 1268 configure it. The BASE protocol assigns every service parameter to 1269 one or more parameter groups. There are existing five different 1270 service parameter groups. 1272 C: Configurable, parameter is used for the configuration of the 1273 agent 1275 A parameter used to configure the service of the agent is flagged 1276 as "C" (configurable), thus making system policies possible. These 1277 parameters influence the agent�s behavior. Note, that "C"-flagged 1278 parameters do not configure the source system. The source system 1279 can be changed exclusively with ACCOUNT* messages. 1281 K: Key, parameter is key member of the service 1283 A parameter is flagged as "K" (key), if it is part of the 1284 service�s primary key. With K-parameters the agent identifies the 1285 object on which it executes the service. When the BE wants to book 1286 a service, it must specify "K"-flagged parameters. 1288 I: Informational, parameter carries additional information 1290 Parameters flagged as "I" (informational), can be used to provide 1291 additional, billing-irrelevant, information, to the BE or the 1292 source system. They also can be used to configure parameters on a 1293 source system not necessary for its operation. I-parameters are 1294 not part of the primary key. 1296 L: Load, parameter defines load data 1298 "L"-flagged parameters indicate that this parameter will be used 1299 in LIFDATA BASE Messages for transferring load data from the 1300 Billing Agent to the Billing Engine. The data is used for billing 1301 of the subscribed services. 1303 Z: Zone, parameter is member of zone info 1305 "Z"-flagged parameters are used by the BA to indicate that the 1306 load has been collected in a different time zone than the BA is 1307 running. 1309 The parameter group flags C, K, I, L, Z are positioned in a Word 1310 (BASE Data Type) as shown below: 1312 1 0 1313 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | | Z L - I K C| 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Parameter ID (BASE Data Type: Word) 1320 The Parameter ID is used to identify the parameter in the list of 1321 parameters. It is set by the agent and is sequentially numbered, 1322 starting with "1". 1324 Parameter Name (Base Data Type: String) 1326 Parameter Name is a string containing the name of the parameter. 1328 Parameter Data Type ID (BASE Data Type: Byte) 1330 Parameter Data Type ID is a BASE Data Type ID (see 7.1) and 1331 indicates the type of the parameter�s value, when the parameter is 1332 used for future POLICY*, ACCOUNT* or LIFDATA BASE Messages. 1334 Parameter Domain (BASE Data Type: String) 1336 Parameter Domain defines the range of values that are allowed for 1337 the registered parameter. The value range is defined as a string 1338 containing a regular BASE expression. When the parameter is used 1339 afterwards the value must be within the range defined through 1340 Parameter Domain. The sender is responsible to send values within 1341 the correct domain only. 1343 Structure of a Service Parameter Element: 1345 +----------------------------------------------------------------------+ 1346 | Param. Group | Param. ID | Param. Name | DataTypeID | Param. Domain | 1347 +----------------------------------------------------------------------+ 1348 2 Bytes 2 Bytes variable 1 Byte variable 1349 (String) (String) 1351 Comments: The use of "L"-flagged parameters changes with the BASE 1352 message type. A typical simplified sequence of messages would be 1353 the following: the agent registers with a REGISTERRES message the 1354 service with it�s parameters. Then the BE subscribes to the service 1355 with a POLICYADDREQ message and activates collecting and sending of 1356 data with a POLICYSTARTREQ message. After this the agent may send 1357 LIFDATA messages. In the REGISTERRES message "L"-flagged parameters 1358 are defined: The BASE Load Type of the parameter is defined in the 1359 "ParameterDomain" field which is a string. When the BE subscribes to 1360 load data with a POLICYADDREQ message it specifies the "L"- 1361 parameters. The registered BASE Load Type is implicitly booked. When 1362 the agent sends load data in a LIFDATA message the parameter contains 1363 the actual value of the load data. The BASE Load Type of the "L"- 1364 flagged parameter corresponds to the one disclosed to the BE in the 1365 REGISTERRES message. 1367 5.3 Booking Message Element 1369 A Booking Message Element is used to book and configure a service 1370 offered by a Billing Agent. 1372 Booking Message Elements are used by the BASE Messages ACCOUNTADDREQ, 1373 ACCOUNTDELREQ, ACCOUNTCHANGEREQ, ACCOUNTSUSPENDREQ, 1374 ACCOUNTUNSUSPENDREQ, POLICYADDREQ, POLICYDELETEREQ, POLICYCHANGEREQ. 1376 A Booking Message Element consists of a service identifier, the 1377 number of specified parameters and the according Parameter Value 1378 Elements. 1380 Service ID (BASE Data Type: WORD) 1382 is the unique identifier of a service offered by the Billing Agent. 1383 This identifier corresponds to the service identifier published to 1384 the Billing Engine via a Register Base Transaction and specifies 1385 that special service. 1387 Parameter Count (BASE Data Type: WORD) 1389 is the number of Parameter Value Elements that are following. 1391 Structure of a Booking Message Element: 1393 +------------------------------------------------------------------+ 1394 | Service ID | Param. Count | Parameter Value Elements | 1395 +------------------------------------------------------------------+ 1396 2 Bytes 2 Bytes variable 1398 5.4 Parameter Value Element 1400 A Booking Parameter Element consists of a parameter identifier, the 1401 parameter data type specification and the parameter value. 1403 Parameter ID (BASE Data Type: WORD) 1405 is the unique identifier of a service parameter. This identifier 1406 corresponds to the parameter identifier published to the Billing 1407 Engine via a Register Base Transaction and specifies a special 1408 parameter of a service. 1410 Parameter Data Type ID (BASE Data Type: Byte) 1412 specifies the BASE Data Type ID of the parameter value (see 7.1). 1414 Parameter Value 1416 contains the parameter value. 1418 Structure of a Parameter Value Element: 1420 +-------------------------------------------------------+ 1421 | Parameter ID | Data Type ID | Parameter Value | 1422 +-------------------------------------------------------+ 1423 2 Bytes 1 Byte variable 1425 5.5 LIFDATA Message Element 1427 A LIFDATA Message Element contains gathered load data and consists of 1428 a policy identifier, a service identifier, timestamps of the 1429 beginning and the end of the data collection, the number of 1430 transmitted parameter values and the according Parameter Value 1431 Elements. 1433 Policy ID (BASE Data Type: WORD) 1435 is the Transaction Identifier of the POLICYADDREQ BASE Message that 1436 caused this load data. 1438 Service ID (BASE Data Type: Word) 1440 is the Service ID of the requested service. 1442 Begin (BASE Data Type: Time) 1444 marks the starting point of data collection. 1446 End (BASE Data Type: Time) 1448 marks the ending point of data collection. 1450 Parameter Count (BASE Data Type: Word) 1452 is the number of Parameter Value Elements that are following. 1454 Structure of a LIFDATA Message Element: 1456 +----------------------------------------------------------------------+ 1457 | P.ID | S.ID | Begin | End | P.Count | Param. Value Elements| 1458 +----------------------------------------------------------------------+ 1459 2 Bytes 2 Bytes 10 Bytes 10 Bytes 2 Bytes variable 1461 Comments: Depending on the policy, the agent may collect data from an 1462 interval. In this case Begin specifies the begin and End the end of 1463 the collection interval. If the agent collects data to a point in 1464 time, then both parameters are set to the same value. This is the 1465 time when the agent took the measurement. 1467 LIFDATA BASE Messages only transmit parameters of types K/I/L/Z. Any 1468 parameter flagged differently will be ignored. K-, I-, L- and Z- 1469 parameters are always transmitted atomic (without regular 1470 expressions). L-parameter are transmitted according to their 1471 registered Load Type. 1473 5.6 Identification Message Element 1475 A CHECKINREQ Base Message contains an Identification Message Element. 1476 It consists of the peer state information, a type identifier, a 1477 version number, a type name and a type description. 1479 Peer State (BASE Data Type: Byte) 1481 The Peer State Byte contains 4 Flags to indicate the current state 1482 of the peer. 1484 R: (Reconnect) Is set, if the BASE Agent is reconnecting to the 1485 BASE Engine. 1487 D: (Disconnect) Is set, if the R-Flag is set and the former 1488 connection was closed with a DISCONNECT BASE Message. 1490 P: (Policies) Is set, if the BASE Agent is currently configured by 1491 policies. 1493 A: (Active) Is set, if the BASE Agent is active. 1495 Structure of the Peer State Byte 1497 7 6 5 4 3 2 1 0 1498 +-------------------------------+ 1499 | | | | | A | P | D | R | 1500 +-------------------------------+ 1502 Peer Type ID (BASE Data Type: Word) 1504 identifies the type of the Billing Agent. 1506 Peer Version (BASE Data Type: Word) 1508 is the version number of the Billing Agent. 1510 Peer Type Name (BASE Data Type: String) 1512 is the name of the Billing Agent type. 1514 Peer Type Description (BASE Data Type: String) 1516 describes textually the Billing Agent type. 1518 Structure of an Identification Message Element: 1520 +----------------------------------------------------------------------+ 1521 | State | P.Type ID | P.Version | P.Type Name | Peer Type Description | 1522 +----------------------------------------------------------------------+ 1523 1 Byte 2 Bytes 2 Bytes variable variable 1524 (String) (String) 1526 5.7 Policy Message Element 1528 Policy Message Elements are transmitted by a POLICIESRES Base Message 1529 and contain the booked policies by POLICYADDREQ Base Messages that 1530 are stored on the Billing Agent. A Policy Message Element consists of 1531 a Policy ID and the according Booking Message Element of the 1532 POLICYADDREQ or POLICYCHANGEREQ BASE Message that caused this policy. 1534 Policy ID (BASE Data Type: Word) 1536 is the Transaction ID of the POLICYADDREQ or POLICYCHANGEREQ Base 1537 Message that caused this policy. 1539 Structure of a Policy Message Element: 1541 +-------------------------------------------------+ 1542 | Policy ID | Booking Message Element | 1543 +-------------------------------------------------+ 1544 2 Bytes variable 1546 5.8 Notification Message Element 1548 A Notification Base Message contains a Notification Message Element. 1549 It consists of a Policy ID and 2 Strings. 1551 Policy ID (BASE Data Type: Word) 1553 is the Transaction ID of the POLICYADDREQ or POLICYCHANGEREQ Base 1554 Message that caused this notification message. 1556 String 1 (BASE Data Type: String) 1558 is intended to be the short version of the notice. 1560 String 2 (BASE Data Type: String) 1562 is intended to be the detailed version of the notice. 1564 6. Error Handling 1566 Errors that occur by the interpretation or processing of the request 1567 part of a two message BASE Transaction are signaled within the 1568 Message State field of the appropriate response message from the BASE 1569 Peer. 1571 In the BASE protocol all BASE Messages (except DISCONNECT) are 1572 acknowledged by an ACK Byte (%xFF). If a BASE Message Layer timeout 1573 occurs without reception of an expected ACK Byte, the BASE Peer is 1574 assuming that the TCP connection is broken. 1576 In this case, a Billing Agent attempts periodically to establish a 1577 new TCP connection to the Billing Engine. If a new TCP connection is 1578 established, the Billing Agent signals the former connection abort by 1579 setting the appropriate Peer State within the Identification Message 1580 Element (see 5.6) within the CHECKINREQ BASE Message. 1582 7. Definitions 1584 7.1 BASE Data Types 1586 Within the BASE protocol the following data types are defined: 1588 Data Type ID Name Length in byte Signed 1589 %x01 BYTE 1 no 1590 %x02 WORD 2 no 1591 %x03 DWORD 4 no 1592 %x04 DOUBLE 8 no 1593 %x05 STRING variable - 1594 %x06 - - - 1595 %x07 TIME 10 - 1596 %x08 INTEGER16 2 yes 1597 %x09 INTEGER32 4 yes 1599 WORD, DWORD, DOUBLE, INTEGER16, INTEGER32 are transferred in network 1600 byte order. 1602 The first two bytes of data type STRING indicates the length of the 1603 following string in octets (most significant byte first). The string 1604 format is UTF-8. 1606 The data type TIME uses the format YYYYMMDDhhmmssZ+hhmm or 1607 YYYYMMDDhhmmssZ-hhmm. Y,M,D,h,m,s are decimal digits in the packed 1608 BCD format. 7 Bytes for YYYYMMDDhhmmss, 1 Byte for + or - and 2 Bytes 1609 for hhmm. 1611 7.2 BASE Load Types 1613 BASE Load Types indicate the interpretation and measurement unit of 1614 load data. A BASE Load Type is composed from a measurement unit, a 1615 computing operation and an interpretation. 1617 Time Unit 1619 The following section lists the predefined time units. 1621 %x00 Millisecond 1622 %x01 Second 1623 %x02 Minute 1624 %x03 Hour 1625 %x04 Day 1626 %x05 Week 1627 %x06 Month 1628 %x07 Year 1630 Basic Unit 1632 %x08 1 (without unit) 1633 %x09 BIT 1634 %x0A KILO BIT 1635 %x0B BYTE 1636 %x0C KILO BYTE // 1024 BIT = 2**10 BIT 1637 %x0D MEGA BYTE // 1048576 BIT = 2**20 BIT 1638 %x0E GIGA BYTE // 1073741824 BIT = 2**30 BIT 1639 %x0F 250 MEGA BYTE // 262144000 BIT = 250* 2**20 BIT 1641 Computing Operation 1643 The following section lists the predefined measurement. 1645 %x01 average 1646 %x02 absolute value 1647 %x03 adding values 1648 %x04 delta to previous value 1649 %x05 percentage of the total available value 1650 %x06 percentage of the used value 1651 %x07 maximum 1652 %x08 minimum 1654 Interpretation 1656 The following section lists the predefined interpretations. 1658 %x01 transmitted amount of data 1659 %x02 duration of usage 1660 %x03 used transmission capacity 1661 %x04 consumed amount 1662 %x05 number of mails sent 1663 %x06 number of mails received 1664 %x07 total number of mails 1665 %x08 used processing time 1666 %x09 used disk space 1667 %x0A memory usage 1668 %x0B number of sessions 1669 %x0C number of transactions 1670 %x0D number of read accesses 1671 %x0E number of write accesses 1672 %x0F number of I/O accesses 1674 7.3 Compose a BASE Load Type 1676 Syntax of a BASE Load Type: 1678 load-type = interpretation computing-operation measurement-unit 1680 measurement-unit = time-unit / 1681 basic-unit / 1682 basic-unit time-unit / 1683 time-unit time-unit 1685 interpretation = %x01-0F 1686 computing-operation = %x01-08 1687 time-unit = %x00-07 1688 basic-unit = %x08-0F 1690 allows to specify a basic unit per time 1691 unit, for example bits per second. The composed BASE Load Type uses 1692 three bytes if the rule for is or 1693 . Otherwise it uses four bytes. 1695 allows to specify that the measured time 1696 value refers to a measurement period. For example if the CPU-time in 1697 milliseconds shall be measured every week, the BASE Load Type could 1698 be %x08 %x02 %x00 %x05. 1700 Example 1702 Interpretation composed LoadType 1703 max 4[Byte] 1704 -------------------------------------------------------------- 1705 total used general %x04 %x02 %x08 1706 delta used general %x04 %x04 %x08 1707 average used general %x04 %x09 %x08 1708 percent of usage %x04 %x05 %x08 1709 total used traffic in octets %x01 %x02 %x0B 1710 delta used traffic in octets %x01 %x04 %x0B 1711 total resource usage in octets %x04 %x02 %x0B 1712 delta resource usage in octets %x04 %x04 %x0B 1713 average resource usage in octets %x04 %x09 %x0B 1714 number used per second %x04 %x02 %x08 %x01 1715 average used bandwidth in bits per second %x03 %x09 %x09 %x01 1716 maximum used bandwidth in bits per second %x03 %x07 %x09 %x01 1717 minimum used bandwidth in bits per second %x03 %x08 %x09 %x01 1718 total used time in seconds %x02 %x02 %x01 or 1719 %x02 %x03 %x01 1721 Please note that "percent of usage" here has been defined to use the 1722 computing operation "percentage of the total available value". The 1723 composed BASE Load Type of "total used time in seconds" depends on 1724 the agent�s service. 1726 7.4 Regular BASE Expressions 1728 To allow not just fixed strings of characters, variable patterns of 1729 words may be used. These patterns are referred to as "regular 1730 expressions". They are made up by combining literal characters with a 1731 number of special characters called metacharacters. BASE lets you use 1732 regular expressions instead of fixed strings for the domains of a 1733 parameter. Regular BASE expressions have to follow the rules below. 1734 They come in two different variants: 1736 1. Character sets, matching a character at a single position 1738 2. Modifiers, specifying how many times the previous expression has 1739 to be repeated 1741 BASE expects that it is always the longest match that will be taken, 1742 if more than one match is found. The syntax of regular BASE 1743 expressions is as follows: 1745 base-expression = 1*expression / 1746 base-expression *WSP "|" *WSP base-expression 1747 expression = term / 1748 term "?" / 1749 term "+" / 1750 term "*" / 1751 term "{" *DIGIT "," *DIGIT "}" / 1752 "!" term 1753 term = label / 1754 "(" base-expression ")" 1755 label = symbol / 1756 "[" 1*range "]" 1757 range = symbol / 1758 character "-" character 1759 symbol = "." / 1760 character / 1761 "\" special 1762 character = %d32-39 / %d44 / %d47-62 / %d64-90 / 1763 %d94-122 / %d126 1764 special = "\" / "|" / "(" / ")" / "[" / "]" / "{" / "}" / 1765 "-" / "+" / "?" / "*" / "." / "d" / "D" / "s" / 1766 "S" / "a" / "A" / 1767 %d116 / %d110 / %d114 / ; t,n,r 1768 %d119 4HEXDIG / %d98 2HEXDIG ; wnnmm / bnn 1770 Explanation: 1772 Any character except \ | ( ) [ ] { } - + * ? . matches itself 1774 \ | ( ) [ ] { } - + * ? . are metacharacters and can be escaped with 1775 a leading backslash ("\"), i. e. "\?" matches "?" and "\\" matches 1776 "\" 1778 . matches any single character 1780 abc matches abc 1782 [abc] matches any one of the characters enclosed between the 1783 brackets 1785 [a-d] matches any character in the enclosed range. Ranges can 1786 be combined, i. e. "a-d0-8YZ" 1788 ! negates the match of the following term 1790 {n,m} match the preceding regular expression a minimum number 1791 of n times and a maximum of m times. n and m can be 1792 omitted. Omitting n is interpreted as n=0, omitting m 1793 is interpreted as m=65535 1795 + match one or more of the preceding expression. Same as 1796 {1,} 1798 ? match zero or one of the preceding expression. Same as 1799 {,1} 1801 * match zero or more of the preceding expression. Same as 1802 {,} 1804 | Separator; match either the preceding or the following 1805 expression 1807 () group, regular expressions enclosed in parentheses are 1808 treated as a single element 1810 \ treat the next character literally. This is normally 1811 used to escape the meaning of special characters such 1812 as "." and "*". 1814 \d matches any decimal digit; this is equivalent to the 1815 class [0-9] 1817 \D matches any non-digit character; this is equivalent to 1818 the class ![0-9] 1820 \s matches any whitespace character; this is equivalent to 1821 the class [\t\n\r] 1823 \S matches any non-whitespace character; this is 1824 equivalent to the class ![\t\n\r] 1826 \a matches any alphanumeric character; this is equivalent 1827 to the class [a-zA-Z0-9_] 1829 \A matches any non-alphanumeric character; this is 1830 equivalent to the class ![a-zA-Z0-9_] 1832 \bnn matches the hex-code %xnn with n in [0-9a-f]. \b 1833 matches one byte with ASCII-code nn 1835 \wnnmm matches the hex-code %xnnmm with n in [0-9a-f]; this is 1836 equivalent to \bnn\bmm 1838 \t matches the tab-character 1840 \n matches the newline-character 1842 \r matches the return-character 1844 8. Security Considerations 1846 Billing information typically is confidential information. In order 1847 to prevent unpermitted access to confidential billing data, all data 1848 should be encrypted. This is even a leading point in corporate 1849 networks. Therefore it is recommended to use TLS [RFC2246] or IPsec 1850 [RFC2407] to secure an implementation of the BASE protocol. 1852 9. References 1854 Normative 1856 [RFC793] Postel, J. "Transmission Control Protocol", RFC 793, 1857 January 1981. 1859 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1860 Requirement Levels", BCP 14, RFC 2119, March 1997. 1862 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 1863 Specifications: ABNF", RFC 2234, November 1997 1865 [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 1866 RFC 2246, January 1999. 1868 [RFC2407] D. Piper, "The Internet IP Security Domain of 1869 Interpretation for ISAKMP", RFC 2407, November 1998. 1871 10. Acknowledgements 1873 The authors would like to thank the ascertech AG software-development 1874 team for the careful specification and design, test and 1875 implementation of the BASE protocol software. As this implementation 1876 had to be adjusted and redesigned in order to meet all the 1877 requirements of various customers, the team developed a convincing 1878 model for the BASE protocol. As a large variety of very different 1879 resources had to be equipped with a Billing Agent, the protocol 1880 design showed sufficient openness and flexibility. 1882 Finally, Odo Maletzki would like to thank Jochen Koerner from IBM 1883 for the comprehensive dialog on requirement specifications for the 1884 BASE-protocol. 1886 11. Authors' Addresses 1888 Questions about this memo can be directed to: 1890 Harald Dickel 1891 University of Koblenz 1892 Postfach 201 602 1893 D-56016 Koblenz Germany 1894 Phone: +49 261 2763 1895 Fax: +49 261 2731 1896 E-mail: dickel@uni-koblenz.de 1898 Christoph Steigner 1899 University of Koblenz 1900 Postfach 201 602 1901 D-56016 Koblenz Germany 1902 Phone: +49 261 2726 1903 Fax: +49 261 2731 1904 E-mail: steigner@uni-koblenz.de 1905 Odo Maletzki 1906 ascertech AG 1907 KoelnTurm 1908 Im Mediapark 8 1909 D-50670 Koeln 1910 Phone: +49 / 221 / 2766-250 1911 Fax: +49 / 221 / 2766-100 1912 E-mail: odo.maletzki@ascertech.com 1914 Thilo Dieckmann 1915 ascertech AG 1916 KoelnTurm 1917 Im Mediapark 8 1918 D-50670 Koeln 1919 Phone: +49 / 221 / 2766-222 1920 Fax: +49 / 221 / 2766-100 1921 E-mail: thilo.dieckmann@ascertech.com 1923 Martin Grundmann 1924 ascertech AG 1925 KoelnTurm 1926 Im Mediapark 8 1927 D-50670 Koeln 1928 Phone: +49 / 221 / 2766-205 1929 Fax: +49 / 221 / 2766-100 1930 E-mail: martin.grundmann@ascertech.com 1932 Sascha Busse 1933 ascertech AG 1934 KoelnTurm 1935 Im Mediapark 8 1936 D-50670 Koeln 1937 Phone: +49 / 221 / 2766-240 1938 Fax: +49 / 221 / 2766-100 1939 E-mail: sascha.busse@ascertech.com 1941 12. Full Copyright Statement 1943 Copyright (C) The Internet Society (2003). All Rights Reserved. 1945 This document and translations of it may be copied and furnished to 1946 others, and derivative works that comment on or otherwise explain it 1947 or assist in its implementation may be prepared, copied, published 1948 and distributed, in whole or in part, without restriction of any 1949 kind, provided that the above copyright notice and this paragraph are 1950 included on all such copies and derivative works. However, this 1951 document itself may not be modified in any way, such as by removing 1952 the copyright notice or references to the Internet Society or other 1953 Internet organizations, except as needed for the purpose of 1954 developing Internet standards in which case the procedures for 1955 copyrights defined in the Internet Standards process must be 1956 followed, or as required to translate it into languages other than 1957 English. 1959 The limited permissions granted above are perpetual and will not be 1960 revoked by the Internet Society or its successors or assigns. 1962 This document and the information contained herein is provided on an 1963 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1964 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1965 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1966 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1967 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1969 13. Expiration Date 1971 This memo is filed as and 1972 expires November 2003.