Network Working Group H. Dickel Internet Draft C. Steigner Category : Informational University of Koblenz Document: draft-dickel-ascertech-base-01.txt O. Maletzki Expires: November 2003 T. Dieckmann M. Grundmann S. Busse ascertech May 2003 Ascertech's Billing and Accounting System Exchange (BASE) Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the Billing and Accounting System Exchange (BASE) protocol. BASE is an application level protocol for carrying billing information between distributed Billing Agents and a shared Billing Engine. Dickel et al. Expires November 2003 [Page 1] Internet Draft BASE Protocol May 2003 Table of Contents 1. Introduction...................................................3 1.1 Terminology................................................4 2. Concept of Base................................................5 3. BASE Transactions..............................................8 3.1 Registration...............................................8 3.2 Configuration of Source Systems............................9 3.3 Configuration of Billing Agents...........................10 3.4 Load Data Transmission....................................11 3.5 Miscellaneous.............................................11 4. BASE Messages.................................................12 4.1 BASE Message Format.......................................12 4.2 BASE Message Header.......................................12 4.3 Registration of a Billing Agent...........................14 4.4 Source System management..................................16 4.5 Billing Agent management..................................20 4.6 Transfer of load information..............................24 4.7 Miscellaneous BASE Messages...............................24 4.8 State Machine of the BASE Message Layer...................25 5. BASE Message Elements.........................................27 5.1 Service Message Element...................................27 5.2 Service Parameter Element.................................28 5.3 Booking Message Element...................................30 5.4 Parameter Value Element...................................31 5.5 LIFDATA Message Element...................................31 5.6 Identification Message Element............................32 5.7 Policy Message Element....................................33 5.8 Notification Message Element..............................34 6. Error Handling................................................34 7. Definitions...................................................35 7.1 BASE Data Types...........................................35 7.2 BASE Load Types...........................................35 7.3 Compose a BASE Load Type..................................37 7.4 Regular BASE Expressions..................................38 8. Security Considerations.......................................40 9. References....................................................40 10. Acknowledgements.............................................41 11. Authors' Addresses...........................................41 12. Full Copyright Statement.....................................42 13. Expiration Date..............................................43 Requirements Language In this document, the key words "MAY", "MUST", "MUST NOT","OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. Dickel et al. Expires November 2003 [Page 2] Internet Draft BASE Protocol May 2003 1. Introduction Recording and evaluating billing information from a large number of dispersed resources can create the need for significant administrative support. Since every resource in a local computer infrastructure causes its specific costs due to the maintenance and the investment for the infrastructure, billing facilities for the exchange of auto-configuration- and billing information have to be provided. Only if the costs for all activities can be made transparent, the accounting process needs no longer be based on rough estimations. This BASE (Billing and Accounting System Exchange) protocol document specifies an interface for all data transfer between the subsystems of a distributed billing and accounting system. This billing and accounting system consists of a central control module called Billing Engine (BE) and a number of dispersed Billing Agents (BA). The BE is solely responsible for the collection of all billing information that may appear in a corporate network. Billing information may be the amount of network traffic, the database usage or the allocation of disk space. The BASE protocol was developed by the ascertech corporation and is implemented in the ascertech BillingWare software products. Key features of the BASE protocol are: Client/Server Model A Billing Agent (BA) operates as a client of the Billing Engine (BE) during the registration and configuration (Check-In) of a BA. During this transaction the BE acts as a server. The peers, however, may change their part of being client or server due to the fact that each peer may be the initiator of a transaction. TCP-based All transactions are carried out on top of TCP due to the pervasive availability and connection-oriented reliability of TCP. Agent based Billing Agents have to be disposed in all active resources and have to be activated as soon as billing information of that resource has to be recorded or administrative tasks have to be performed to enable this process. The agent actively introduces itself to the billing engine in order to negotiate the conditions of the acquisition of the billing information and its pooled transmission of billing information to the BE. Thus, agents request a bookkeeping service from the BE. Dickel et al. Expires November 2003 [Page 3] Internet Draft BASE Protocol May 2003 Application domain The BASE protocol acts as means of transport for all relevant billing information which affect the costs for maintenance and investment of all components of a corporate computer network domain, as well as related administrative information. In contrast to network accounting servers all components like disks, databases, printers, routers, CPUs etc. are items for the billing process. 1.1 Terminology This document uses the following terms: BASE The Billing and Accounting System Exchange protocol is used for all communication between a Billing Engine and a Billing Agent and is covered by this document. Billing Engine The Billing Engine (BE) is a facility within a corporate computer network which serves as central bookkeeper for all agent-based incoming billing messages. The BE may open a new account for a requesting agent and negotiate on details for the management of the billing information to be transferred after the negotiation. Billing Agent The Billing Agent (BA) is part of all active resources and is activated if the cost-relevant billing information of the resource has to be recorded or administrative tasks have to be performed to enable this process. The Billing Agent actively introduces itself to the Billing Engine in order to negotiate the conditions of the acquisition of the billing information and its pooled transmission to the BE. Thus, agents request a bookkeeping service from the BE. BASE Peer A BASE Peer is a Billing Agent or the Billing Engine. Source System A Source System is a system that produces the load data gathered by a Billing Agent, the system that is monitored and may be configured by a Billing Agent. Dickel et al. Expires November 2003 [Page 4] Internet Draft BASE Protocol May 2003 BASE Message A message that is exchanged between BASE Peers is called BASE Message. BASE Transaction A task that is performed by the exchange of BASE Messages between BASE Peers is called a BASE Transaction. Initiating Peer An Initiating Peer may either be the BA or BE which is actively opening a dialog with its peer. Receiving Peer A Receiving Peer may either be the BA or BE which is has already undergone a passive open procedure in order to listen to the dialog opening with its peer. Syntax specifications within this document are done using Augmented Backus-Naur Form (ABNF) [RFC2234]. 2. Concept of Base The BASE protocol is an application protocol which is running on top of TCP [RFC793]. The Billing Engine is listening on TCP port 5429 for incoming connection requests. A Billing Agent performs an active open on TCP port 5429 to establish a TCP connection with the Billing Engine. The TCP port 5429 has been officially assigned to BASE by the Internet Assigned Numbers Authority (IANA). After the TCP connection is established, the BASE protocol is used to perform the following tasks: - registration of the Billing Agent to the Billing Engine - configuration of the Billing Agent by the Billing Engine - transmission of gathered load data from the Billing Agent to the Billing Engine Such a task is called a BASE Transaction. To perform a BASE Transaction, it is necessary to exchange messages between the participating peers. These messages are called BASE Messages. The communication layer on which the BASE messages are exchanged between two BASE peers is called the BASE Message layer and is placed on top of TCP as stated above. Dickel et al. Expires November 2003 [Page 5] Internet Draft BASE Protocol May 2003 A BASE Transaction is initiated by the Billing Engine or the Billing Agent and consists either of the exchange of a single BASE Message or the exchange of two BASE Messages. Within the BASE protocol the following BASE Transactions are defined: --------------------------------------------------------------------- Transaction Initiated by Transaction Type Name B-Agent B-Engine Single message Two message --------------------------------------------------------------------- Check-In X X Register X X Policies X X Account-Add X X Account-Delete X X Account-Change X X Account-Suspend X X Account-Unsuspend X X Policy-Add X X Policy-Delete X X Policy-Change X X Policies-Start X X Policies-Stop X X Policies-Reset X X LIF-Data X X Ping X X X Notification X X X Disconnect X X X Two message BASE Transactions For the initiating side, a two message BASE Transaction is started with the transmission of the corresponding BASE Message (request) to the BASE peer and completed by the reception of the according BASE Message from this BASE peer (response). For the receiving side, a two message BASE Transaction is started by the reception of a BASE message from the BASE peer as a request and completed with the transmission of the corresponding BASE Message as response. request message response message initiating peer --------> receiving peer ---------> initiating peer Single message BASE Transactions A single message BASE Transaction is completely performed with the transmission/reception of the according BASE Message. Dickel et al. Expires November 2003 [Page 6] Internet Draft BASE Protocol May 2003 message initiating peer -------> receiving peer The chapter BASE Transactions provides a description of these BASE Transactions. The following table lists the currently defined BASE Messages. The names of the BASE Messages are derived from the corresponding BASE Transactions: Possible Sender BASE Message name Billing Engine Billing Agent --------------------------------------------------------------- CHECKINREQ X CHECKINRES X REGISTERREQ X REGISTERRES X POLICIESREQ X POLICIESRES X ACCOUNTADDREQ X ACCOUNTADDRES X ACCOUNTDELETEREQ X ACCOUNTDELETERES X ACCOUNTCHANGEREQ X ACCOUNTCHANGERES X ACCOUNTSUSPENDREQ X ACCOUNTSUSPENDRES X ACCOUNTUNSUSPENDREQ X ACCOUNTUNSUSPENDRES X POLICYADDREQ X POLICYADDRES X POLICYDELETEREQ X POLICYDELETERES X POLICYCHANGEREQ X POLICYCHANGERES X POLICIESSTARTREQ X POLICIESSTARTRES X POLICIESSTOPREQ X POLICIESSTOPRES X POLICIESRESETREQ X POLICIESRESETRES X LIFDATA X PINGREQ X X PINGRES X X NOTIFICATION X X DISCONNECT X X ---------------------------------------------------------------- Dickel et al. Expires November 2003 [Page 7] Internet Draft BASE Protocol May 2003 The BASE Message format is described in detail in the chapter BASE Messages. BASE Message Layer acknowledgements On the BASE Message Layer every BASE Message, except Disconnect, is acknowledged from the receiving BASE peer by sending one byte of value %xFF. This enables the implementation of an "blocking send" for BASE Messages. The arrival of the acknowledgement byte is signaling that the BASE Message has been received by the peer's BASE Message layer. The acknowledgement byte does not indicate that the BASE Message was processed by the BASE peer. 3. BASE Transactions BASE Transactions are classified in four categories. BASE Transactions in relation to the registration process of a Billing Agent (3.1), BASE Transactions in relation to the configuration process of a Source System (3.2) or a Billing Agent (3.3), a BASE Transaction to transmit gathered load data (3.4), and the remaining BASE Transactions which are not assigned to these previous categories (3.4). BASE Transactions of category 3.2, 3.3, and 3.3 are tagged by transaction identifiers. A transaction identifier is a 16 bit value and has to be unique within each of the categories 3.2, 3.3, and 3.4. The transaction identifier of a BASE Transaction belonging to category 3.2 and 3.3 is generated by the Billing Engine and the transaction identifier of a BASE Transaction belonging to category 3.4 is generated by the Billing Agent. 3.1 Registration Check-In The first task, which had to be performed by a Billing Agent, is to identify itself to the Billing Engine. Therefore, every BASE peer has a unique BASE identifier. The BASE idenfifier is a 32 bit value and is assigned at installation time. To start a Check-In transaction a Billing Agent sends a CHECKINREQ BASE Message to the Billing Engine. The Billing Engine responds with the corresponding CHECKINRES BASE Message, which signals whether the Billing Agent is accepted or not. Register If type and functionality of a Billing Agent is unknown, the Billing Engine starts a Register transaction by sending a REGISTERREQ BASE Message to that Billing Agent. The Billing Agent Dickel et al. Expires November 2003 [Page 8] Internet Draft BASE Protocol May 2003 answers with a REGISTERRES BASE Message, which contains all registration information, needed by the Billing Engine in order to configure the Billing Agent. Policies The Policy transaction is intended to provide the Billing Engine with a list of all policies, which are stored on a Billing Agent. This transaction is started by the Billing Engine with a POLICIESREQ BASE Message and is answered by the Billing Agent with the complete information about all booked policies. This information is delivered within an POLICIESRES BASE Message form the Billing Agent. 3.2 Configuration of Source Systems Account-Add The Account-Add transaction is intended to create a new service for a user on a source system. This transaction is initiated from the Billing Engine by sending an ACCOUNTADDREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding ACCOUNTADDRES BASE Message. Account-Delete The Account-Delete transaction is intended to remove an existing service for a user on a source system. This transaction is initiated from the Billing Engine by sending an ACCOUNTDELETEREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding ACCOUNTDELETERES BASE Message. Account-Change The Account-Change transaction is intended to change the configuration of an existing service for a user on a source system. This transaction is initiated from the Billing Engine by sending an ACCOUNTCHANGEREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding ACCOUNTCHANGERES BASE Message. Account-Suspend The Account-Suspend transaction is intended to temporarily lock a service for a user on a source system. This transaction is initiated from the Billing Engine by sending an ACCOUNTSUSPENDREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding ACCOUNTSUSPENDRES BASE Message. Dickel et al. Expires November 2003 [Page 9] Internet Draft BASE Protocol May 2003 Account-Unsuspend The Account-Unsuspend transaction is intended to unlock a service previously locked for a user on a source system. This transaction is initiated from the Billing Engine by sending an ACCOUNTUNSUSPENDREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding ACCOUNTUNSUSPENDRES BASE Message. 3.3 Configuration of Billing Agents Policy-Add The Policy-Add transaction is intended to create a policy at a Billing Agent. This means to book a service on a Billing Agent. A policy is a set of rules, which controls the gathering and delivery of load data. This transaction is initiated from the Billing Engine by sending a POLICYADDREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding POLICYADDRES BASE Message. Policy-Delete The Policy-Delete transaction is intended to delete a policy. This is used to cancel the booking of a service on a Billing Agent. This transaction is initiated from the Billing Engine by sending a POLICYDELETEREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding POLICYDELETERES BASE Message. Policy-Change The Policy-Change transaction is intended to modify a policy on a Billing Agent. This transaction is initiated from the Billing Engine by sending a POLICYCHANGEREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding POLICYCHANGERES BASE Message. Policies-Start The Policies-Start transaction is intended to activate all policies that are stored on a Billing Agent. It causes the Billing Agent to gather and deliver load data accordingly. This transaction is initiated from the Billing Engine by sending a POLICIESSTARTREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding POLICIESSTARTRES BASE Message. Dickel et al. Expires November 2003 [Page 10] Internet Draft BASE Protocol May 2003 Policies-Stop The Policies-Stop transaction is intended to deactivate all stored policies on a Billing Agent. It causes the Billing Agent to stop gathering and delivering load data. This transaction is initiated from the Billing Engine by sending a POLICIESSTOPREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding POLICIESSTOPRES BASE Message. Policies-Reset The Policies-Reset transaction is intended to restore the initial configuration of a Billing Agent. Therefore all policies created by Policy-Add transactions are discarded. This transaction is initiated from the Billing Engine by sending a POLICIESRESETREQ BASE Message to the Billing Agent and is answered by the Billing Agent with the corresponding POLICIESRESETRES BASE Message. 3.4 Load Data Transmission LIF-Data The LIF-Data (Load Information Data) transaction is intended to transmit gathered load data from a Billing Agent to the Billing Engine. LIF-Data is a single message transaction and is initiated by a Billing Agent with a LIF-DATA BASE Message. 3.5 Miscellaneous Ping The Ping transaction is intended to detect if the BASE peer is still reachable and working. A Ping transaction can initiated by the Billing Engine or a Billing Agent. The initiating peer is sending a PINGREQ BASE Message and the receiving peer answers with a PINGRES BASE Message. Notification The Notification transaction is intended to transfer a notice from BASE peer to BASE peer. In special the Notification transaction is used by a Billing Agent to inform the Billing Engine about the occurrence of an error in connection with a active policy. Notification is a single message transaction and is initiated by a Billing Agent or the Billing Engine by sending a NOTIFICATION BASE Message. Dickel et al. Expires November 2003 [Page 11] Internet Draft BASE Protocol May 2003 Disconnect The Disconnect transaction is intended to disconnect a Billing Agent and the Billing Engine. Disconnect is a single message transaction and is initiated by a Billing Agent or the Billing Engine by sending a DISCONNECT BASE Message. (Note: A DISCONNECT BASE Message is not acknowledged at the BASE Message Layer.) 4. BASE Messages 4.1 BASE Message Format BASE Message consists of a BASE Message Header and a BASE Message Element Container. +---------------------+--------------------------------+ | BASE Message Header | BASE Message Element Container | +---------------------+--------------------------------+ The size of the BASE Message Header is 16 bytes. The size of the BASE Message Element Container is variable. 4.2 BASE Message Header 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Message State | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | Message Element Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Container Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BASE Message Header fields Version: 8 bits Identifies the BASE protocol version. This document describes the BASE Protocol version 3. To indicate the usage of BASE Protocol Version 3 the Version field MUST be set to 3. Dickel et al. Expires November 2003 [Page 12] Internet Draft BASE Protocol May 2003 Msg Type: 8 bits Identifies the BASE Message. The following message types are assigned: ---------------------------------------------------------- MsgType BASE Message | MsgType BASE Message ---------------------------------------------------------- %x00 not assigned | %x20 POLICYADDREQ %x01 CHECKINREQ | %x21 POLICYADDRES %x02 CHECKINRES | %x22 POLICYDELETEREQ %x03 not assigned | %x23 POLICYDELETERES %x04 REGISTERREQ | %x24 POLICYCHANGEREQ %x05 REGISTERRES | %x25 POLICYCHANGERES %x06 POLICIESREQ | %x26 POLICIESSTARTREQ %x07 POLICIESRES | %x27 POLICIESSTARTRES %x08 | %x28 POLICIESTOPREQ : not assigned | %x29 POLICIESTOPRES %x0F | %x2A POLICIESRESETREQ %x10 ACCOUNTADDREQ | %x2B POLICIESRESETRES %x11 ACCOUNTADDRES | %x2C %x12 ACCOUNTDELETEREQ | : not assigned %x13 ACCOUNTDELETERES | %x30 %x14 ACCOUNTCHANGEREQ | %x31 LIFDATA %x15 ACCOUNTCHANGERES | %x32 PINGREQ %x16 ACCOUNTSUSPENDREQ | %x33 PINGRES %x17 ACCOUNTSUSPENDRES | %x34 NOTIFICATION %x18 ACCOUNTUNSUSPENDREQ | %x35 %x19 ACCOUNTUNSUSPENDRES | : not assigned %x1A | %xFE : not assigned | %xFF DISCONNECT %x1F | Msg State: 8 bits The Msg State field contains status information or an error code. The following values are defined: 0 SUCCESS / No error occurred 1 ERROR 2 Identifier already in use 3 Invalid identifier 4 Open in progress 5 SHUTDOWN 6 Buffer full 7 Action superfluous 8 Policy already exists 9 Rollback failed / Action on account failed; Dickel et al. Expires November 2003 [Page 13] Internet Draft BASE Protocol May 2003 10 Agent identifier not valid 11 Timeout 12 Policy does not exist 13 - 14 Protocol violation 15 An internal error occurred 16 - 255 undefined Peer Identifier: 32 bits This field contains the unique BASE Peer Identifier. Transaction ID: 16 bits This field contains the Transaction Identifier. Message Element Count: 16 bits This field contains the number of Message Elements in the BASE Message Element Container. Message Element Container Length: 32 bits This field contains the length of the BASE Message Container in octets. 4.3 Registration of a Billing Agent CHECKINREQ A CHECKINREQ message is sent from a Billing Agent to a Billing Engine in order to connect the Billing Agent. The Msg Type field value MUST be %x01. Possible Msg State field values are 0 and 13. A CHECKINREQ message always uses a Transaction ID of 0 and has an Identification Message Element (see 5.6). Message Header field values: Msg Type %x01 Msg State 0 Transaction ID 0 Message Element Count 1 Message Element Container Length variable Dickel et al. Expires November 2003 [Page 14] Internet Draft BASE Protocol May 2003 CHECKINRES A CHECKINRES message is sent from a Billing Engine to a Billing Agent in response to a CHECKINREQ message from that Billing Agent and is signaling weather the connection of the Billing Agent is accepted by the Billing Engine or not. The Msg Type field value MUST be %x02. A CHECKINRES message uses a Transaction ID of 0 and has no Message Elements. Message Header field values: Msg Type %x02 Msg State variable Transaction ID 0 Message Element Count 0 Message Element Container Length 0 REGISTERREQ A REGISTERREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Register transaction. The Msg Type field value MUST be %x04. The Msg State field value is 0. A REGISTERREQ message uses a Transaction ID of 0 and has no Message Elements. Message Header field values: Msg Type %x04 Msg State 0 Transaction ID 0 Message Element Count 0 Message Element Container Length 0 REGISTERRES A REGISTERRES message is sent from a Billing Agent to a Billing Engine in order to complete a Register transaction. The Msg Type field value MUST be %x05. A REGISTERRES message uses a Transaction ID of 0 and has Service Message Elements (see 5.1). Message Header field values: Msg Type %x05 Msg State variable Transaction ID 0 Message Element Count variable Message Element Container Length variable Dickel et al. Expires November 2003 [Page 15] Internet Draft BASE Protocol May 2003 POLICIESREQ A POLICIESREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policies transaction. The Msg Type field value MUST be %x06. The Msg State field value is 0. A POLICIESREQ message uses a Transaction ID of 0 and has no Message Elements. Message Header field values: Msg Type %x06 Msg State 0 Transaction ID 0 Message Element Count 0 Message Element Container Length 0 POLICIESRES A POLICIESRES message is sent from a Billing Agent to a Billing Engine in order to complete a Policies transaction. The Msg Type field value MUST be %x07. A POLICIESRES message uses a Transaction ID of 0 and has Policy Message Elements (see 5.7). Message Header field values: Msg Type %x07 Msg State variable Transaction ID 0 Message Element Count variable Message Element Container Length variable 4.4 Source System management ACCOUNTADDREQ An ACCOUNTADDREQ message is sent from a Billing Engine to a Billing Agent in order to proceed an Account-Add transaction. The Msg Type field value MUST be %x10. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. An ACCOUNTADDREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x10 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable Dickel et al. Expires November 2003 [Page 16] Internet Draft BASE Protocol May 2003 ACCOUNTADDRES An ACCOUNTADDRES message is sent from a Billing Agent to a Billing Engine in order to complete the Account-Add transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x11. An ACCOUNTADDRES message has no Message Elements. Message Header field values: Msg Type %x11 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 ACCOUNTDELETEREQ An ACCOUNTDELETEREQ message is sent from a Billing Engine to a Billing Agent in order to proceed an Account-Delete transaction. The Msg Type field value MUST be %x12. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. An ACCOUNTDELETEREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x12 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable ACCOUNTDELETERES An ACCOUNTDELETERES message is sent from a Billing Agent to a Billing Engine in order to complete an Account-Delete transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x09. An ACCOUNTDELETERES message has no Message Elements. Message Header field values: Msg Type %x13 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 Dickel et al. Expires November 2003 [Page 17] Internet Draft BASE Protocol May 2003 ACCOUNTCHANGEREQ An ACCOUNTCHANGEREQ message is sent from a Billing Engine to a Billing Agent in order to proceed an Account-Change transaction. The Msg Type field value MUST be %x14. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. An ACCOUNTCHANGEREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x14 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable ACCOUNTCHANGERES An ACCOUNTCHANGERES message is sent from a Billing Agent to a Billing Engine in order to complete an Account-Change transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x15. An ACCOUNTCHANGERES message has no Message Elements. Message Header field values: Msg Type %x15 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 ACCOUNTSUSPENDREQ An ACCOUNTSUSPENDREQ message is sent from a Billing Engine to a Billing Agent in order to proceed an Account-Suspend transaction. The Msg Type field value MUST be %x16. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. An ACCOUNTSUSPENDREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x16 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable Dickel et al. Expires November 2003 [Page 18] Internet Draft BASE Protocol May 2003 ACCOUNTSUSPENDRES An ACCOUNTSUSPENDRES message is sent from a Billing Agent to a Billing Engine in order to complete an Account-Suspend transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x17. An ACCOUNTSUSPENDRES message has no Message Elements. Message Header field values: Msg Type %x17 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 ACCOUNTUNSUSPENDREQ An ACCOUNTUNSUSPENDREQ message is sent from a Billing Engine to a Billing Agent in order to proceed an Account-Unsuspend transaction. The Msg Type field value MUST be %x18. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. An ACCOUNTUNSUSPENDREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x18 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable ACCOUNTUNSUSPENDRES An ACCOUNTUNSUSPENDRES message is sent from a Billing Agent to a Billing Engine in order to complete an Account-Unsuspend transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x19. An ACCOUNTUNSUSPENDRES message has no Message Elements. Message Header field values: Msg Type %x19 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 Dickel et al. Expires November 2003 [Page 19] Internet Draft BASE Protocol May 2003 4.5 Billing Agent management POLICYADDREQ A POLICYADDREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policy-Add transaction. The Msg Type field value MUST be %x20. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. A POLICYADDREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x20 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable POLICYADDRES A POLICYADDRES message is sent from a Billing Agent to a Billing Engine in order to complete a Policy-Add transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x21. A POLICYADDRES message has no Message Elements. Message Header field values: Msg Type %x21 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 POLICYDELETEREQ A POLICYDELETEREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policy-Delete transaction. The Msg Type field value MUST be %x22. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. A POLICYDELETEREQ message has one Booking Message Element (see 5.3). Message Header field values: Msg Type %x22 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable Dickel et al. Expires November 2003 [Page 20] Internet Draft BASE Protocol May 2003 POLICYDELETERES A POLICYDELETERES message is sent from a Billing Agent to a Billing Engine in order to complete a Policy-Delete transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x23. A POLICYDELETERES message has no Message Elements. Message Header field values: Msg Type %x23 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 POLICYCHANGEREQ A POLICYCHANGEREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policy-Change transaction. The Msg Type field value MUST be %x24. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. A POLICYCHANGEREQ message has one Booking Message Element. Message Header field values: Msg Type %x24 Msg State 0 Transaction ID variable Message Element Count 1 Message Element Container Length variable POLICYCHANGERES A POLICYCHANGERES message is sent from a Billing Agent to a Billing Engine in order to complete a Policy-Change transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x25. A POLICYCHANGERES message has no Message Elements. Message Header field values: Msg Type %x25 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 Dickel et al. Expires November 2003 [Page 21] Internet Draft BASE Protocol May 2003 POLICIESSTARTREQ A POLICCIESTARTREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policies-Start transaction. The Msg Type field value MUST be %x26. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. A POLICIESSTARTREQ message has no Message Elements. Message Header field values: Msg Type %x26 Msg State 0 Transaction ID variable Message Element Count 0 Message Element Container Length 0 POLICIESSTARTRES A POLICIESSTARTRES message is sent from a Billing Agent to a Billing Engine in order to complete a Policies-Start transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x27. A POLICIESSTARTRES message has no Message Elements. Message Header field values: Msg Type %x27 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 POLICIESSTOPREQ A POLICIESSTOPREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policies-Stop transaction. The Msg Type field value MUST be %x28. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. A POLICIESSTOPREQ message has no Message Elements. Message Header field values: Msg Type %x28 Msg State 0 Transaction ID variable Message Element Count 0 Message Element Container Length 0 Dickel et al. Expires November 2003 [Page 22] Internet Draft BASE Protocol May 2003 POLICIESSTOPRES A POLICIESSTOPRES message is sent from a Billing Agent to a Billing Engine in order to complete a Policies-Stop transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x29. A POLICIESSTOPRES message has no Message Elements. Message Header field values: Msg Type %x29 Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 POLICIESRESETREQ A POLICIESRESETREQ message is sent from a Billing Engine to a Billing Agent in order to proceed a Policies-Reset transaction. The Msg Type field value MUST be %x2A. The Msg State field value is 0. The Transaction ID is determined by the Billing Engine. A POLICIESRESETREQ message has no Message Elements. Message Header field values: Msg Type %x2A Msg State 0 Transaction ID variable Message Element Count 0 Message Element Container Length 0 POLICIESRESETRES A POLICIESRESETRES message is sent from a Billing Agent to a Billing Engine in order to complete a Policies-Reset transaction identified by the specified Transaction ID. The Msg Type field value MUST be %x2B. A POLICIESSTOPRES message has no Message Elements. Message Header field values: Msg Type %x2B Msg State variable Transaction ID variable Message Element Count 0 Message Element Container Length 0 Dickel et al. Expires November 2003 [Page 23] Internet Draft BASE Protocol May 2003 4.6 Transfer of load information LIFDATA A LIFDATA message is sent from a Billing Agent to a Billing Engine in order to perform a LIF-Data transaction. The Msg Type field value MUST be %x31. The Msg State field value is 0. The Transaction ID is determined by the Billing Agent. A LIFDATA message has LIFDATA Message Elements (see 5.5). Message Header field values: Msg Type %x31 Msg State 0 Transaction ID variable Message Element Count variable Message Element Container Length variable 4.7 Miscellaneous BASE Messages PINGREQ A PINGREQ message is sent from a Billing Engine to a Billing Agent or a Billing Agent to a Billing Engine in order to test that the BASE peer is still reachable and operating. The Msg Type field value MUST be %x33. The Msg State field value and the used Transaction ID are 0. A PING message has no Message Elements. Message Header field values: Msg Type %x32 Msg State 0 Transaction ID 0 Message Element Count 0 Message Element Container Length 0 PINGRES A PINGRES message is sent from a Billing Engine to a Billing Agent or a Billing Agent to a Billing Engine in order to confirm that he is still reachable and operating. The Msg Type field value MUST be %x33. The Msg State field value and the used Transaction ID are 0. A PING message has no Message Elements. Message Header field values: Msg Type %x33 Msg State 0 Transaction ID 0 Message Element Count 0 Dickel et al. Expires November 2003 [Page 24] Internet Draft BASE Protocol May 2003 Message Element Container Length 0 NOTIFICATION A NOTIFICATION message is sent from a Billing Agent to a Billing Engine or a Billing Engine to a Billing Agent in order to perform a Notification transaction. The Msg Type field value MUST be %x34. The Msg State field value and the used Transaction ID are 0. A NOTIFICATION message has one Notification Message Element (see 5.8). Message Header field values: Msg Type %x34 Msg State 0 Transaction ID 0 Message Element Count 1 Message Element Container Length variable DISCONNECT A DISCONNECT message is sent from a Billing Agent to a Billing Engine or a Billing Engine to a Billing Agent in order to signalize that this peer stops the transaction processing and is tearing down the connection. The Msg Type field value MUST be %xFF. Possible Msg State field values are 0, 5, 10, 14 or 15. A DISCONNECT message uses a Transaction ID of 0 and has no Message Elements. (Note: A DISCONNECT Message is not acknowledged at the BASE Message Layer.) Message Header field values: Msg Type %xFF Msg State variable Transaction ID 0 Message Element Count 0 Message Element Container Length 0 4.8 State Machine of the BASE Message Layer An event or an action in lower case letters indicates a communication from or to the application process (vertical communication) and an event or an action in upper case letters indicates a communication between the BASE Message Layers of two BASE Peers (horizontal communication). Dickel et al. Expires November 2003 [Page 25] Internet Draft BASE Protocol May 2003 state event action next state --------------------------------------------------------------------- INIT prepare - CON_WAIT_BE checkinreq CHECKINREQ ACK_WAIT_1 CON_WAIT_BE CHECKINREQ ACK + checkinreq CON_CHECK ACK_WAIT_1 ACK - CON_WAIT_BA CON_CHECK accept ACCEPT ACK_WAIT_2 reject REJECT ACK_WAIT_3 CON_WAIT_BA ACCEPT ACK + accept CONNECTED_BA REJECT ACK + reject INIT ACK_WAIT_2 ACK - CONNECTED_BE ACK_WAIT_3 ACK - CON_WAIT_BE CONNECTED_BA EN_MESSAGE ACK + en_message CONNECTED_BA CONNECTED_BA DISCONNECT disconnect DISCONNECTED CONNECTED_BA ag_message AG_MESSAGE ACK_WAIT_4 CONNECTED_BA disconnect DISCONNECT DISCONNECTED CONNECTED_BE AG_MESSAGE ACK + ag_message CONNECTED_BE CONNECTED_BE DISCONNECT disconnect DISCONNECTED CONNECTED_BE en_message EN_MESSAGE ACK_WAIT_5 CONNECTED_BE disconnect DISCONNECT DISCONNECTED ACK_WAIT_4 ACK - CONNECTED_BA ACK_WAIT_4 EN_MESSAGE ACK + en_message ACK_WAIT_6 ACK_WAIT_4 DISCONNECT disconnect DISCONNECTED ACK_WAIT_5 ACK - CONNECTED_BE ACK_WAIT_5 AG_MESSAGE ACK + ag_message ACK_WAIT_7 ACK_WAIT_5 DISCONNECT disconnect DISCONNECTED ACK_WAIT_6 ACK - CONNECTED_BA ACK_WAIT_7 ACK - CONNECTED_BE ACCEPT: CHECKINRES with Msg State field value 0 REJECT: CHECKINRES with Msg State field value other than 0 EN_MESSAGE is an element of the set {REGISTERREQ, POLICIESREQ, ACCOUNTADDREQ, ACCOUNTDELETEREQ, ACCOUNTCHANGEREQ, ACCOUNTSUSPENDREQ, ACCOUNTUNSUSPENDREQ, POLICYADDREQ, POLICYDELETEREQ, POLICYCHANGEREQ, POLICIESSTARTREQ, POLICIESTOPREQ,POLICIESRESETREQ, PINGREQ, PINGRES, NOTIFICATION} AG_MESSAGE is an element of the set {REGISTERRES, POLICIESRES, ACCOUNTADDRES, ACCOUNTDELETERES, ACCOUNTCHANGERES, ACCOUNTSUSPENDRES, ACCOUNTUNSUSPENDRES, POLICYADDRES, POLICYDELETERES, POLICYCHANGERES, POLICIESSTARTRES, POLICIESTOPRES, POLICIESRESETRES, LIFDATA, PINGREQ, PINGRES, NOTIFICATION} ACK: %xFF (acknowledgement byte) Dickel et al. Expires November 2003 [Page 26] Internet Draft BASE Protocol May 2003 5. BASE Message Elements 5.1 Service Message Element A Billing Agent offers a number of services. These services are describing the abilities of the Billing Agent and how they are used. While proceeding a Register BASE Transaction the Billing Agent transmits all information, needed by the Billing Engine for later use. Therefore each service offered by the Billing Agent is described by a Service Message Element. These Service Message Elements are sent within the Message Element Container of a REGISTERRES BASE Message from the Billing Agent to the Billing Engine. A Service Message Element consists of a service type, a service identifier, a service name, the number of Service Parameter Elements and eventually the Service Parameter Elements themselves. Service Type(BASE Data Type: BYTE) is one of POLICYADDREQ, ACCOUNTADDREQ, ACCOUNTDELREQ, ACCOUNTSUSPENDREQ, ACCOUNTUNSUSPENDREQ, ACCOUNTCHANGEREQ. POLICYADDREQ implicitly states that the agent also knows the other POLICY messages, like POLICYDELETEREQ, POLICYCHANGEREQ, POLICYSTARTREQ, POLICYSTOPREQ, POLICYRESETREQ. Service ID (BASE Data Type: WORD) is within the Billing Agent a unique identifier of the service. Service Name (BASE Data Type: String) is a textual description of the service. Parameter Count (BASE Data Type: Byte) is the number of Service Parameter Elements that are following. Structure of a Service Message Element: +---------------------------------------------------------------------+ |S.Type |Service ID |Service Name |Param. Count | S. Param. Elements | +---------------------------------------------------------------------+ 1 Byte 2 Bytes variable 1 Byte variable (String) Dickel et al. Expires November 2003 [Page 27] Internet Draft BASE Protocol May 2003 5.2 Service Parameter Element A Service Parameter Element consists of a parameter group field, a parameter identifier, a parameter name, a parameter data type identifier and a parameter domain. Parameter Group (BASE Data Type: Word) A service may have a number of parameters, who can be used to configure it. The BASE protocol assigns every service parameter to one or more parameter groups. There are existing five different service parameter groups. C: Configurable, parameter is used for the configuration of the agent A parameter used to configure the service of the agent is flagged as "C" (configurable), thus making system policies possible. These parameters influence the agent’s behavior. Note, that "C"-flagged parameters do not configure the source system. The source system can be changed exclusively with ACCOUNT* messages. K: Key, parameter is key member of the service A parameter is flagged as "K" (key), if it is part of the service’s primary key. With K-parameters the agent identifies the object on which it executes the service. When the BE wants to book a service, it must specify "K"-flagged parameters. I: Informational, parameter carries additional information Parameters flagged as "I" (informational), can be used to provide additional, billing-irrelevant, information, to the BE or the source system. They also can be used to configure parameters on a source system not necessary for its operation. I-parameters are not part of the primary key. L: Load, parameter defines load data "L"-flagged parameters indicate that this parameter will be used in LIFDATA BASE Messages for transferring load data from the Billing Agent to the Billing Engine. The data is used for billing of the subscribed services. Z: Zone, parameter is member of zone info "Z"-flagged parameters are used by the BA to indicate that the load has been collected in a different time zone than the BA is running. Dickel et al. Expires November 2003 [Page 28] Internet Draft BASE Protocol May 2003 The parameter group flags C, K, I, L, Z are positioned in a Word (BASE Data Type) as shown below: 1 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Z L - I K C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter ID (BASE Data Type: Word) The Parameter ID is used to identify the parameter in the list of parameters. It is set by the agent and is sequentially numbered, starting with "1". Parameter Name (Base Data Type: String) Parameter Name is a string containing the name of the parameter. Parameter Data Type ID (BASE Data Type: Byte) Parameter Data Type ID is a BASE Data Type ID (see 7.1) and indicates the type of the parameter’s value, when the parameter is used for future POLICY*, ACCOUNT* or LIFDATA BASE Messages. Parameter Domain (BASE Data Type: String) Parameter Domain defines the range of values that are allowed for the registered parameter. The value range is defined as a string containing a regular BASE expression. When the parameter is used afterwards the value must be within the range defined through Parameter Domain. The sender is responsible to send values within the correct domain only. Structure of a Service Parameter Element: +----------------------------------------------------------------------+ | Param. Group | Param. ID | Param. Name | DataTypeID | Param. Domain | +----------------------------------------------------------------------+ 2 Bytes 2 Bytes variable 1 Byte variable (String) (String) Comments: The use of "L"-flagged parameters changes with the BASE message type. A typical simplified sequence of messages would be the following: the agent registers with a REGISTERRES message the service with it’s parameters. Then the BE subscribes to the service Dickel et al. Expires November 2003 [Page 29] Internet Draft BASE Protocol May 2003 with a POLICYADDREQ message and activates collecting and sending of data with a POLICYSTARTREQ message. After this the agent may send LIFDATA messages. In the REGISTERRES message "L"-flagged parameters are defined: The BASE Load Type of the parameter is defined in the "ParameterDomain" field which is a string. When the BE subscribes to load data with a POLICYADDREQ message it specifies the "L"- parameters. The registered BASE Load Type is implicitly booked. When the agent sends load data in a LIFDATA message the parameter contains the actual value of the load data. The BASE Load Type of the "L"- flagged parameter corresponds to the one disclosed to the BE in the REGISTERRES message. 5.3 Booking Message Element A Booking Message Element is used to book and configure a service offered by a Billing Agent. Booking Message Elements are used by the BASE Messages ACCOUNTADDREQ, ACCOUNTDELREQ, ACCOUNTCHANGEREQ, ACCOUNTSUSPENDREQ, ACCOUNTUNSUSPENDREQ, POLICYADDREQ, POLICYDELETEREQ, POLICYCHANGEREQ. A Booking Message Element consists of a service identifier, the number of specified parameters and the according Parameter Value Elements. Service ID (BASE Data Type: WORD) is the unique identifier of a service offered by the Billing Agent. This identifier corresponds to the service identifier published to the Billing Engine via a Register Base Transaction and specifies that special service. Parameter Count (BASE Data Type: WORD) is the number of Parameter Value Elements that are following. Structure of a Booking Message Element: +------------------------------------------------------------------+ | Service ID | Param. Count | Parameter Value Elements | +------------------------------------------------------------------+ 2 Bytes 2 Bytes variable Dickel et al. Expires November 2003 [Page 30] Internet Draft BASE Protocol May 2003 5.4 Parameter Value Element A Booking Parameter Element consists of a parameter identifier, the parameter data type specification and the parameter value. Parameter ID (BASE Data Type: WORD) is the unique identifier of a service parameter. This identifier corresponds to the parameter identifier published to the Billing Engine via a Register Base Transaction and specifies a special parameter of a service. Parameter Data Type ID (BASE Data Type: Byte) specifies the BASE Data Type ID of the parameter value (see 7.1). Parameter Value contains the parameter value. Structure of a Parameter Value Element: +-------------------------------------------------------+ | Parameter ID | Data Type ID | Parameter Value | +-------------------------------------------------------+ 2 Bytes 1 Byte variable 5.5 LIFDATA Message Element A LIFDATA Message Element contains gathered load data and consists of a policy identifier, a service identifier, timestamps of the beginning and the end of the data collection, the number of transmitted parameter values and the according Parameter Value Elements. Policy ID (BASE Data Type: WORD) is the Transaction Identifier of the POLICYADDREQ BASE Message that caused this load data. Service ID (BASE Data Type: Word) is the Service ID of the requested service. Begin (BASE Data Type: Time) marks the starting point of data collection. Dickel et al. Expires November 2003 [Page 31] Internet Draft BASE Protocol May 2003 End (BASE Data Type: Time) marks the ending point of data collection. Parameter Count (BASE Data Type: Word) is the number of Parameter Value Elements that are following. Structure of a LIFDATA Message Element: +----------------------------------------------------------------------+ | P.ID | S.ID | Begin | End | P.Count | Param. Value Elements| +----------------------------------------------------------------------+ 2 Bytes 2 Bytes 10 Bytes 10 Bytes 2 Bytes variable Comments: Depending on the policy, the agent may collect data from an interval. In this case Begin specifies the begin and End the end of the collection interval. If the agent collects data to a point in time, then both parameters are set to the same value. This is the time when the agent took the measurement. LIFDATA BASE Messages only transmit parameters of types K/I/L/Z. Any parameter flagged differently will be ignored. K-, I-, L- and Z- parameters are always transmitted atomic (without regular expressions). L-parameter are transmitted according to their registered Load Type. 5.6 Identification Message Element A CHECKINREQ Base Message contains an Identification Message Element. It consists of the peer state information, a type identifier, a version number, a type name and a type description. Peer State (BASE Data Type: Byte) The Peer State Byte contains 4 Flags to indicate the current state of the peer. R: (Reconnect) Is set, if the BASE Agent is reconnecting to the BASE Engine. D: (Disconnect) Is set, if the R-Flag is set and the former connection was closed with a DISCONNECT BASE Message. Dickel et al. Expires November 2003 [Page 32] Internet Draft BASE Protocol May 2003 P: (Policies) Is set, if the BASE Agent is currently configured by policies. A: (Active) Is set, if the BASE Agent is active. Structure of the Peer State Byte 7 6 5 4 3 2 1 0 +-------------------------------+ | | | | | A | P | D | R | +-------------------------------+ Peer Type ID (BASE Data Type: Word) identifies the type of the Billing Agent. Peer Version (BASE Data Type: Word) is the version number of the Billing Agent. Peer Type Name (BASE Data Type: String) is the name of the Billing Agent type. Peer Type Description (BASE Data Type: String) describes textually the Billing Agent type. Structure of an Identification Message Element: +----------------------------------------------------------------------+ | State | P.Type ID | P.Version | P.Type Name | Peer Type Description | +----------------------------------------------------------------------+ 1 Byte 2 Bytes 2 Bytes variable variable (String) (String) 5.7 Policy Message Element Policy Message Elements are transmitted by a POLICIESRES Base Message and contain the booked policies by POLICYADDREQ Base Messages that are stored on the Billing Agent. A Policy Message Element consists of a Policy ID and the according Booking Message Element of the POLICYADDREQ or POLICYCHANGEREQ BASE Message that caused this policy. Policy ID (BASE Data Type: Word) is the Transaction ID of the POLICYADDREQ or POLICYCHANGEREQ Base Dickel et al. Expires November 2003 [Page 33] Internet Draft BASE Protocol May 2003 Message that caused this policy. Structure of a Policy Message Element: +-------------------------------------------------+ | Policy ID | Booking Message Element | +-------------------------------------------------+ 2 Bytes variable 5.8 Notification Message Element A Notification Base Message contains a Notification Message Element. It consists of a Policy ID and 2 Strings. Policy ID (BASE Data Type: Word) is the Transaction ID of the POLICYADDREQ or POLICYCHANGEREQ Base Message that caused this notification message. String 1 (BASE Data Type: String) is intended to be the short version of the notice. String 2 (BASE Data Type: String) is intended to be the detailed version of the notice. 6. Error Handling Errors that occur by the interpretation or processing of the request part of a two message BASE Transaction are signaled within the Message State field of the appropriate response message from the BASE Peer. In the BASE protocol all BASE Messages (except DISCONNECT) are acknowledged by an ACK Byte (%xFF). If a BASE Message Layer timeout occurs without reception of an expected ACK Byte, the BASE Peer is assuming that the TCP connection is broken. In this case, a Billing Agent attempts periodically to establish a new TCP connection to the Billing Engine. If a new TCP connection is established, the Billing Agent signals the former connection abort by setting the appropriate Peer State within the Identification Message Element (see 5.6) within the CHECKINREQ BASE Message. Dickel et al. Expires November 2003 [Page 34] Internet Draft BASE Protocol May 2003 7. Definitions 7.1 BASE Data Types Within the BASE protocol the following data types are defined: Data Type ID Name Length in byte Signed %x01 BYTE 1 no %x02 WORD 2 no %x03 DWORD 4 no %x04 DOUBLE 8 no %x05 STRING variable - %x06 - - - %x07 TIME 10 - %x08 INTEGER16 2 yes %x09 INTEGER32 4 yes WORD, DWORD, DOUBLE, INTEGER16, INTEGER32 are transferred in network byte order. The first two bytes of data type STRING indicates the length of the following string in octets (most significant byte first). The string format is UTF-8. The data type TIME uses the format YYYYMMDDhhmmssZ+hhmm or YYYYMMDDhhmmssZ-hhmm. Y,M,D,h,m,s are decimal digits in the packed BCD format. 7 Bytes for YYYYMMDDhhmmss, 1 Byte for + or - and 2 Bytes for hhmm. 7.2 BASE Load Types BASE Load Types indicate the interpretation and measurement unit of load data. A BASE Load Type is composed from a measurement unit, a computing operation and an interpretation. Time Unit The following section lists the predefined time units. %x00 Millisecond %x01 Second %x02 Minute %x03 Hour %x04 Day %x05 Week %x06 Month %x07 Year Dickel et al. Expires November 2003 [Page 35] Internet Draft BASE Protocol May 2003 Basic Unit %x08 1 (without unit) %x09 BIT %x0A KILO BIT %x0B BYTE %x0C KILO BYTE // 1024 BIT = 2**10 BIT %x0D MEGA BYTE // 1048576 BIT = 2**20 BIT %x0E GIGA BYTE // 1073741824 BIT = 2**30 BIT %x0F 250 MEGA BYTE // 262144000 BIT = 250* 2**20 BIT Computing Operation The following section lists the predefined measurement. %x01 average %x02 absolute value %x03 adding values %x04 delta to previous value %x05 percentage of the total available value %x06 percentage of the used value %x07 maximum %x08 minimum Interpretation The following section lists the predefined interpretations. %x01 transmitted amount of data %x02 duration of usage %x03 used transmission capacity %x04 consumed amount %x05 number of mails sent %x06 number of mails received %x07 total number of mails %x08 used processing time %x09 used disk space %x0A memory usage %x0B number of sessions %x0C number of transactions %x0D number of read accesses %x0E number of write accesses %x0F number of I/O accesses Dickel et al. Expires November 2003 [Page 36] Internet Draft BASE Protocol May 2003 7.3 Compose a BASE Load Type Syntax of a BASE Load Type: load-type = interpretation computing-operation measurement-unit measurement-unit = time-unit / basic-unit / basic-unit time-unit / time-unit time-unit interpretation = %x01-0F computing-operation = %x01-08 time-unit = %x00-07 basic-unit = %x08-0F allows to specify a basic unit per time unit, for example bits per second. The composed BASE Load Type uses three bytes if the rule for is or . Otherwise it uses four bytes. allows to specify that the measured time value refers to a measurement period. For example if the CPU-time in milliseconds shall be measured every week, the BASE Load Type could be %x08 %x02 %x00 %x05. Example Interpretation composed LoadType max 4[Byte] -------------------------------------------------------------- total used general %x04 %x02 %x08 delta used general %x04 %x04 %x08 average used general %x04 %x09 %x08 percent of usage %x04 %x05 %x08 total used traffic in octets %x01 %x02 %x0B delta used traffic in octets %x01 %x04 %x0B total resource usage in octets %x04 %x02 %x0B delta resource usage in octets %x04 %x04 %x0B average resource usage in octets %x04 %x09 %x0B number used per second %x04 %x02 %x08 %x01 average used bandwidth in bits per second %x03 %x09 %x09 %x01 maximum used bandwidth in bits per second %x03 %x07 %x09 %x01 minimum used bandwidth in bits per second %x03 %x08 %x09 %x01 total used time in seconds %x02 %x02 %x01 or %x02 %x03 %x01 Please note that "percent of usage" here has been defined to use the Dickel et al. Expires November 2003 [Page 37] Internet Draft BASE Protocol May 2003 computing operation "percentage of the total available value". The composed BASE Load Type of "total used time in seconds" depends on the agent’s service. 7.4 Regular BASE Expressions To allow not just fixed strings of characters, variable patterns of words may be used. These patterns are referred to as "regular expressions". They are made up by combining literal characters with a number of special characters called metacharacters. BASE lets you use regular expressions instead of fixed strings for the domains of a parameter. Regular BASE expressions have to follow the rules below. They come in two different variants: 1. Character sets, matching a character at a single position 2. Modifiers, specifying how many times the previous expression has to be repeated BASE expects that it is always the longest match that will be taken, if more than one match is found. The syntax of regular BASE expressions is as follows: base-expression = 1*expression / base-expression *WSP "|" *WSP base-expression expression = term / term "?" / term "+" / term "*" / term "{" *DIGIT "," *DIGIT "}" / "!" term term = label / "(" base-expression ")" label = symbol / "[" 1*range "]" range = symbol / character "-" character symbol = "." / character / "\" special character = %d32-39 / %d44 / %d47-62 / %d64-90 / %d94-122 / %d126 special = "\" / "|" / "(" / ")" / "[" / "]" / "{" / "}" / "-" / "+" / "?" / "*" / "." / "d" / "D" / "s" / "S" / "a" / "A" / %d116 / %d110 / %d114 / ; t,n,r %d119 4HEXDIG / %d98 2HEXDIG ; wnnmm / bnn Dickel et al. Expires November 2003 [Page 38] Internet Draft BASE Protocol May 2003 Explanation: Any character except \ | ( ) [ ] { } - + * ? . matches itself \ | ( ) [ ] { } - + * ? . are metacharacters and can be escaped with a leading backslash ("\"), i. e. "\?" matches "?" and "\\" matches "\" . matches any single character abc matches abc [abc] matches any one of the characters enclosed between the brackets [a-d] matches any character in the enclosed range. Ranges can be combined, i. e. "a-d0-8YZ" ! negates the match of the following term {n,m} match the preceding regular expression a minimum number of n times and a maximum of m times. n and m can be omitted. Omitting n is interpreted as n=0, omitting m is interpreted as m=65535 + match one or more of the preceding expression. Same as {1,} ? match zero or one of the preceding expression. Same as {,1} * match zero or more of the preceding expression. Same as {,} | Separator; match either the preceding or the following expression () group, regular expressions enclosed in parentheses are treated as a single element \ treat the next character literally. This is normally used to escape the meaning of special characters such as "." and "*". \d matches any decimal digit; this is equivalent to the class [0-9] Dickel et al. Expires November 2003 [Page 39] Internet Draft BASE Protocol May 2003 \D matches any non-digit character; this is equivalent to the class ![0-9] \s matches any whitespace character; this is equivalent to the class [\t\n\r] \S matches any non-whitespace character; this is equivalent to the class ![\t\n\r] \a matches any alphanumeric character; this is equivalent to the class [a-zA-Z0-9_] \A matches any non-alphanumeric character; this is equivalent to the class ![a-zA-Z0-9_] \bnn matches the hex-code %xnn with n in [0-9a-f]. \b matches one byte with ASCII-code nn \wnnmm matches the hex-code %xnnmm with n in [0-9a-f]; this is equivalent to \bnn\bmm \t matches the tab-character \n matches the newline-character \r matches the return-character 8. Security Considerations Billing information typically is confidential information. In order to prevent unpermitted access to confidential billing data, all data should be encrypted. This is even a leading point in corporate networks. Therefore it is recommended to use TLS [RFC2246] or IPsec [RFC2407] to secure an implementation of the BASE protocol. 9. References Normative [RFC793] Postel, J. "Transmission Control Protocol", RFC 793, January 1981. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997 Dickel et al. Expires November 2003 [Page 40] Internet Draft BASE Protocol May 2003 [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. 10. Acknowledgements The authors would like to thank the ascertech AG software-development team for the careful specification and design, test and implementation of the BASE protocol software. As this implementation had to be adjusted and redesigned in order to meet all the requirements of various customers, the team developed a convincing model for the BASE protocol. As a large variety of very different resources had to be equipped with a Billing Agent, the protocol design showed sufficient openness and flexibility. Finally, Odo Maletzki would like to thank Jochen Koerner from IBM for the comprehensive dialog on requirement specifications for the BASE-protocol. 11. Authors' Addresses Questions about this memo can be directed to: Harald Dickel University of Koblenz Postfach 201 602 D-56016 Koblenz Germany Phone: +49 261 2763 Fax: +49 261 2731 E-mail: dickel@uni-koblenz.de Christoph Steigner University of Koblenz Postfach 201 602 D-56016 Koblenz Germany Phone: +49 261 2726 Fax: +49 261 2731 E-mail: steigner@uni-koblenz.de Dickel et al. Expires November 2003 [Page 41] Internet Draft BASE Protocol May 2003 Odo Maletzki ascertech AG KoelnTurm Im Mediapark 8 D-50670 Koeln Phone: +49 / 221 / 2766-250 Fax: +49 / 221 / 2766-100 E-mail: odo.maletzki@ascertech.com Thilo Dieckmann ascertech AG KoelnTurm Im Mediapark 8 D-50670 Koeln Phone: +49 / 221 / 2766-222 Fax: +49 / 221 / 2766-100 E-mail: thilo.dieckmann@ascertech.com Martin Grundmann ascertech AG KoelnTurm Im Mediapark 8 D-50670 Koeln Phone: +49 / 221 / 2766-205 Fax: +49 / 221 / 2766-100 E-mail: martin.grundmann@ascertech.com Sascha Busse ascertech AG KoelnTurm Im Mediapark 8 D-50670 Koeln Phone: +49 / 221 / 2766-240 Fax: +49 / 221 / 2766-100 E-mail: sascha.busse@ascertech.com 12. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are Dickel et al. Expires November 2003 [Page 42] Internet Draft BASE Protocol May 2003 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Expiration Date This memo is filed as and expires November 2003. Dickel et al. Expires November 2003 [Page 43]