One document matched: draft-dickel-ascertech-base-01.txt
Differences from draft-dickel-ascertech-base-00.txt
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
<basic-unit> <time-unit> 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 <measurement-unit> is <time-unit> or
<basic-unit>. Otherwise it uses four bytes.
<time-unit> <time-unit> 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 <draft-dickel-ascertech-base-01.txt> and
expires November 2003.
Dickel et al. Expires November 2003 [Page 43]
| PAFTECH AB 2003-2026 | 2026-04-24 10:26:39 |