Internet DRAFT - draft-ioag-base
draft-ioag-base
Individual-Submissions Odo Maletzki
Internet Draft INTERNET ONLINE AG
Document: <draft-ioag-base-00.txt> Thilo Dieckmann
Category: Informational INTERNET ONLINE AG
24 April 2000 Martin Grundmann
INTERNET ONLINE AG
BASE (Billing- and Accounting-System Exchange-Protocol)
Protocol Specification
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It expires October 31,
2000.
Please send comments to the authors.
2. Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
3. Abstract
The Billing and Accounting System Exchange (BASE) protocol is
intended for use for the data transfer between the subsystems of a
distributed billing and accounting system. It defines the
communication between central billing engines (BEs) and one or more
locally or remotely installed billing agents (BAs). BAs are used to
supply the BEs with load data used for billing and accounting
purposes. BEs are responsible for the process of billing and
accounting as well as for the configuration of the BAs and their
connected source systems. This document defines and describes the
BASE protocol
Maletzki e.a. Informational - October 31, 2000 1
INTERNET DRAFT BASE Protocol Specification April 2000
4. Table of Contents
1. Status of this Memo.............................................1
2. Copyright Notice................................................1
3. Abstract........................................................1
4. Table of Contents...............................................2
5. Introduction....................................................3
5.1. Why a new protocol ?..........................................4
6. General Structure of BASE.......................................5
6.1. BASE Networking Topology......................................5
6.1.1. Entry-level Configuration...................................5
6.1.2. Configuration with a single full-functional Mex Node........5
6.1.3. Configuration with multiple full-functional Mex Nodes.......5
6.2. BASE Protocol Object..........................................6
6.3. BASE vs OSI...................................................7
6.4. Addressing....................................................7
6.5. Time Synchronization..........................................7
6.6. General Error Handling........................................8
6.7. Content Encryption............................................8
7. BASE Specifications.............................................8
7.1. BASE Link Management..........................................9
7.1.1. Finite State Machine (Peer).................................9
7.1.2. Finite State Machine (Mex).................................12
7.2. Mex Functionality............................................14
7.3. BASE Flow Management.........................................14
7.3.1. Finite State Machine.......................................15
7.4. Transactions.................................................21
7.4.1. Single-message transaction.................................21
7.4.2. Two-message transaction....................................21
7.4.3. Table of transactions......................................22
7.5. Messages.....................................................22
7.5.1. Message Format.............................................22
7.5.2. Message Header.............................................22
7.5.3. Message element container..................................25
7.5.4. Message Fragmentation and Re-assembly......................26
7.6. BASE link-level Messages.....................................26
7.6.1. OPENLNKREQ Message.........................................26
7.6.2. OPENLNKRES Message.........................................27
7.6.3. CLOSELNK Message...........................................28
7.6.4. SYNCREQ Message............................................28
7.6.5. SYNCDATA Message...........................................29
7.7. BASE flow-level Messages.....................................30
7.7.1. OPENREQ message............................................31
7.7.2. OPENRES Message............................................31
7.7.3. CLOSE Message..............................................32
7.7.4. REGISTERREQ Message........................................32
7.7.5. REGISTERRES Message........................................33
7.7.6. ACCOUNTADDREQ Message......................................36
7.7.7. ACCOUNTADDRES Message......................................37
7.7.8. ACCOUNTDELREQ Message......................................38
7.7.9. ACCOUNTDELRES Message......................................39
7.7.10. ACCOUNTCHANGEREQ Message..................................39
7.7.11. ACCOUNTCHANGERES Message..................................40
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 2
INTERNET DRAFT BASE Protocol Specification April 2000
7.7.12. ACCOUNTSUSPENDREQ Message.................................41
7.7.13. ACCOUNTSUSPENDRES Message.................................42
7.7.14. ACCOUNTUNSUSPENDREQ Message...............................42
7.7.15. ACCOUNTUNSUSPENDRES Message...............................43
7.7.16. ACCOUNTREQ Message........................................43
7.7.17. ACCOUNTRES Message........................................44
7.7.18. POLICYADDREQ Message......................................45
7.7.19. POLICYADDRES Message......................................46
7.7.20. POLICYDELETEREQ Message...................................47
7.7.21. POLICYDELETERES Message...................................48
7.7.22. POLICYCHANGEREQ Message...................................48
7.7.23. POLICYCHANGERES Message...................................49
7.7.24. POLICYSTARTREQ Message....................................49
7.7.25. POLICYSTARTRES Message....................................50
7.7.26. POLICYSTOPREQ Message.....................................50
7.7.27. POLICYSTOPRES Message.....................................51
7.7.28. POLICYRESETREQ Message....................................51
7.7.29. POLICYRESETRES Message....................................52
7.7.30. LIFSTARTREQ Message.......................................52
7.7.31. LIFSTARTRES Message.......................................53
7.7.32. LIFSTOPREQ Message........................................53
7.7.33. LIFSTOPRES Message........................................54
7.7.34. LIFDATA Message...........................................54
8. BASE Flow Example..............................................55
8.1. Communication table..........................................56
8.2. Remarks to the communication table...........................57
9. BASE Definitions...............................................62
9.1. Data Types...................................................62
9.2. Load Types...................................................62
9.3. Peer Types...................................................63
9.4. Message Types................................................64
9.5. Error codes..................................................64
9.5.1. BASE protocol errors:......................................64
9.5.2. Application errors:........................................64
9.6. Regular BASE Expressions.....................................64
9.6.1. Grammar....................................................65
9.6.2. Explanation:...............................................65
10. Security Considerations.......................................67
11. References....................................................67
12. Acknowledgments...............................................68
13. Author's Addresses............................................68
14. Full Copyright Statement......................................68
15. Expiration Date...............................................69
5. Introduction
The Billing and Accounting System Exchange (BASE) protocol is
intended for use for the data transfer between the subsystems of a
distributed billing and accounting system. It defines the
communication between central billing engines (BEs) and one or more
locally or remotely operated billing agents (BAs). BAs are used to
supply the BEs with load data needed for billing and accounting
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 3
INTERNET DRAFT BASE Protocol Specification April 2000
purposes. BEs are responsible for the process of billing and
accounting as well as for the configuration of the BAs and their
connected source systems.
The load data that is transferred from a BA to the BE is generated
by these source systems (e. g. Radius servers) that are
communicating with the BA. They actively or passively provide
information to the BA about the use of their services. The pay load
enables the BE to relate load data to users accordingly, thus
permitting proper billing of products and services. The data
transmitted from the BE to the BA is used for the configuration of
the BA and their connected source systems, and to control the flow
of the load data. A single BE serves and receives data from multiple
- locally or remotely - installed BAs, which in turn control one or
more source systems and process their data.
BASE was defined by INTERNET ONLINE AG (IOAG) as a part of the
development of their BillingWare product. It is, however, not
restricted to a specific product, but allows a standardized
communication within a distributed system of load data generators
and load data analyzers.
This document describes the functionality of the BASE protocol, its
elements and everything needed to provide an implementation.
5.1. Why a new protocol ?
The architecture of a distributed billing and accounting system
requires an underlying transport mechanism which fulfills the
following requirements:
- The registration of BA services with the BE need to be processed
in a simple way.
- Effective mechanisms to control license keys are required by the
manufacturers of components of a distributed billing and
accounting system.
- It should only allocate a minimum of bandwidth for the
transmission of the measured load information.
- Transmission of account and load information should be independent
of the source systems.
Currently, none of the existing protocols fulfills all of the
requirements listed above, leading to the design of the BASE
protocol. The BASE implementation of the INTERNET ONLINE AG
demonstrates, that performance and reliability meet the
requirements of a large, highly distributed system with high
transaction frequency.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 4
INTERNET DRAFT BASE Protocol Specification April 2000
Furthermore, the standardization of the communication within a
network of billing and accounting components helps manufacturers and
vendors to create and implement scalable and integrative products.
6. General Structure of BASE
This chapter introduces the main features and functions of the BASE
protocol. It gives an overview of the BASE network components and
its layout, relates the protocol layers to OSI, and discusses the
aspects of addressing, time synchronization and error handling.
6.1. BASE Networking Topology
The BASE network consists of three types of network nodes: peer
nodes, message exchange (mex) nodes and peer nodes with an
integrated mex node.
A peer node is either a billing engine (BE) or a billing agent (BA)
and can only connect to a mex node. A mex node is either full-
functional or low-entry. In contrast to full-functional mex nodes
which can be interconnected, low-entry mex nodes are integrated in a
BE peer node.
The BASE protocol defines the communication between peer and mex
nodes as well as the communication among mex nodes.
There are basically three possibilities to design a BASE network
which are illustrated below. Note that BASE version 1 only supports
the entry-level configuration. The full-functional mex nodes will be
introduced in version 2.
6.1.1. Entry-level Configuration
The billing engine (BE) integrates a low-entry mex node that
communicates with directly connected billing agents (BAs). In this
configuration there is only one BE serving multiple BAs.
6.1.2. Configuration with a single full-functional Mex Node
This is a configuration with a single full-functional mex node that
is responsible to route the BASE data according to the BASE
destination address of the transmitted data. All peer nodes (BEs as
well as BAs) are connected to this mex. BAs are able to
simultaneously communicate with multiple BEs.
This configuration is not supported in BASE version 1.
6.1.3. Configuration with multiple full-functional Mex Nodes
This is a configuration with multiple interconnected full-functional
mex nodes. They are responsible to route the BASE data according to
the BASE destination address of the transmitted data. All peer nodes
(BEs as well as BAs) are each connected to one of the mex nodes. BAs
are able to simultaneously communicate with multiple BEs.
This configuration is not supported in BASE version 1.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 5
INTERNET DRAFT BASE Protocol Specification April 2000
6.2. BASE Protocol Object
Every node of a BASE network needs a BASE protocol object to be able
to communicate. The BASE protocol object is a software
implementation of the BASE protocol as it is described in this
document. The following diagram illustrates the general structure
and the interfaces of the protocol object.
The BASE protocol object interfaces to the BASE application by means
of an Application Programming Interface (API). Both, the structure
and the nature of this API are implementation-specific and are not
covered within this document. The function names used in above
diagram are only meant to be examples.
There are three major services provided for the application. The
BASE flow management is used to open and close connections between
two peer nodes. Transaction processing is done via the general
message interface. Additionally access to the currently valid BASE
time is offered.
The BASE protocol object tracks the state of all BASE flows it
participates in. To achieve this, it creates a state machine for
each flow. Currently, mexes do not participate in BASE flows.
Whenever a request message is sent by the application, it is the
BASE protocol object's responsibility to generate a flow-unique
transaction ID. When responding to a request message, the
application must preserve the transaction ID as used in the
corresponding request. Passing the transaction ID between the
application and the protocol object is implementation-dependent.
From the application's point of view messages are not limited in
length but may carry any number of elements, however,
implementation-specific restrictions may still apply. Since the data
units that are transmitted over the network are limited in their
length as well as in the number of elements they carry, the protocol
object needs to provide a service to fragment the original message
before transmission and to re-assemble it upon receipt. The
fragments are called message parts throughout this document.
A key factor to the BASE application is the availability of a
network-wide synchronous BASE time. The BASE protocol object
provides access to it and participates in the BASE synchronization
process.
In case of a mex, a routing engine needs to be implemented to
forward message parts according to their destination address over
the appropriate link.
The BASE protocol defines the use of TCP sessions to connect
adjacent BASE nodes. The state of these BASE links is controlled by
the BASE link management.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 6
INTERNET DRAFT BASE Protocol Specification April 2000
6.3. BASE vs OSI
Communication between directly connected BASE nodes will be called
BASE links or simply links throughout this document. Links can be
established between a BE and a mex respectively a BA and a mex as
well as among mexes.
Since the BASE link is a point-to-point link, no additional
encapsulation of the higher level data units is done. The BASE link
is used to transport data in units of message parts.
Message parts are transmitted from peer node to peer node traversing
one or more message exchanges (mexes).
If the size of the original message exceeded the maximum allowed
message size and was therefore spread across multiple message parts,
it is re-assembled before being passed to the application layer
above.
The messages used to exchange information between two peer nodes are
transmitted via a BASE flow or simply flow. BAs communicate with BEs
via this flow by means of transactions. A transaction structures the
message flow. The communication between two peers is full-duplex.
If TCP is used as the underlying protocol, all BASE communication is
encapsulated in that OSI layer 4 protocol (currently only TCP is
supported). Under such circumstances all BASE protocol functionality
must be refer to as OSI layer 7 (application layer).
6.4. Addressing
Each peer node has a world-wide unique BASE network address
consisting of a 32-bit administrator-defined network number and a
32-bit license key. License keys are given out by the BASE
registration office of the INTERNET ONLINE AG. They will be
generated for all products that adhere to the BASE protocol
definitions given within this document. The license keys have to be
used by the product manufacturer, one key per installation. The
license key generation is free of charge (refer to
http://base.ioag.com).
Every mex uses the license key number "0".
The network number is only configured within mexes. The peer nodes
receive their network number during the opening of the BASE link.
6.5. Time Synchronization
BASE provides a common system time. Synchronization of this time
base across all nodes of the BASE network is done via link-level
messages. Each BASE protocol implementation provides a mechanism to
access the current BASE time from the application layer (i. e. for
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 7
INTERNET DRAFT BASE Protocol Specification April 2000
billing engines (BE) and billing agents (BA)). The mechanism is
implementation-defined and not part of this document.
Mex nodes synchronize the time amongst themselves. Each mex node is
given a certain priority for the time synchronization process.
Usually, one or two mex nodes (equipped with access to a high-
quality clock device) are given a high priority, whereas all nodes
without such devices are given a common, low priority. After a mex
has been initialized, it sends a SYNC message to each neighbor mex
to check its own time parameters against those of the other mexes.
If there is one or more neighbor mexes with a higher priority, the
local mex takes over the time stamp from the neighbor mex with the
highest priority. It additionally keeps the information about this
specific neighbor mex for future synchronization requests that will
only be addressed to this mex. In case the own priority is higher
than those of the neighbors, no further action will be taken. If the
two neighbor mexes have the same priority higher than the requesting
mex, it will store the time stamp and information of the first
neighbor mex.
In addition to the initial processing (as described above), time
synchronization is done periodically.
Peer nodes receive SYNCDATA messages from their adjacent mex
periodically. In addition, they may request a current BASE time-
stamp by sending a SYNCREQ message to the mex. A SYNCREQ message is
answered with a SYNCDATA message, which in that specific case
permits measuring the network-added delay, too. This allows the peer
node to compensate network delays by adding an offset to any future
BASE time-stamp received by unsolicited SYNCDATA messages.
6.6. General Error Handling
Link layer error handling is done by the TCP layer used to transfer
messages between nodes.
Errors that occur during preparation of messages by the BASE
protocol object are announced to the partner node by means of a
state field in the message header.
Since the current protocol definition only supports low-entry mexes,
no end-to-end transmission control is defined.
Application layer errors are announced to the partner peer by means
of a state field in the message header.
6.7. Content Encryption
BASE version 1 does not define any data encryption.
7. BASE Specifications
This chapter provides the details needed to understand and implement
the BASE protocol.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 8
INTERNET DRAFT BASE Protocol Specification April 2000
7.1. BASE Link Management
This chapter describes the process of establishing and releasing a
BASE link.
A BASE link is a direct connection between two BASE nodes (between a
peer and a mex node, or between two mexes), initiated by the peer
node (in case of a peer-to-mex link) or either mex (in case of a
mex-to-mex link). As soon as the peer has been started, it tries to
establish a TCP session. Once established, it requests the opening
of the link by sending an "open link request" to the mex. The "open
link request" message carries the unique license key of the peer.
This gives the mex the possibility to store the address to TCP
session handle relation for the later identification of the link. In
the normal case the mex returns an "open link response" message as
an acknowledgment and the BASE link is then open. The response
carries the network number of the mex, which is used by the peer as
its own network number in all future messages.
From the mex's point of view, the opening process differs in that it
immediately opens a predefined TCP socket and waits for incoming TCP
sessions. Once a session has been established, it switches into the
"waiting for an open link request" state. Having received an "open
link request" from the peer, it normally returns a response to open
the link, thus enabling the peer to open one or more flows via this
link.
A link can orderly be closed by either side by issuing a "close"
message, or uncontrolled if the underlying TCP session breaks down.
BASE network nodes (mexes) use TCP port 5429, which has officially
been assigned for this purpose by the Internet Assigned Numbers
Authority (IANA). BASE peer nodes use a dynamically assigned TCP
port.
7.1.1. Finite State Machine (Peer)
How BASE links are established and released from the peer's point of
view is shown in the following diagram. To simplify the diagram only
the normal case is considered here, assuming that only legal events
happen. The handling of possible error situations is discussed in
the finite state machine table. The states and possible events used
within this picture are listed below.
The following states are defined:
1.) INIT
Initial state, there is no active link between the peer
and its corresponding mex
2.) WAITING FOR OPENLNKRES
The peer has sent an open link request to the mex and
is now waiting for an open link response
3.) BASE LINK OPEN
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 9
INTERNET DRAFT BASE Protocol Specification April 2000
The peer has received an open link response from the
mex and the link is established
4.) SHUTDOWN
The peer has shut down
The following events may occur:
1.) The peer receives an open link response from its corresponding
mex
2.) The peer receives a message part transmission request from
layer above
3.) The peer receives message parts from the mex
4.) The peer receives a close link request from layer above
(the last BASE flow was closed)
5.) The TCP session went down
6.) A timeout occurred
7.) The peer receives a shutdown request from layer above
8.) INIT state reached
The BASE link state diagram from the peer's point of view:
Finite state machine table:
-----------------------------------------------------------------
State Event Action Target state
-----------------------------------------------------------------
INIT 1 N/a INIT
2 Return error to above layer
(link not open) INIT
3 N/a INIT
4 No action INIT
5 N/a INIT
6 N/a INIT
7 Shut down SHUTDOWN
8 Send OPENLNKREQ WAITING FOR
OPENLNKRES
-----------------------------------------------------------------
WAITING FOR
OPENLNKRES 1 No action BASE LINK OPEN
2 Return error to layer above
(open in progress) WAITING FOR
OPENLNKRES
3 Close TCP session INIT
4 Close TCP session INIT
5 No action INIT
6 Close TCP session INIT
7 Close TCP session SHUTDOWN
8 N/a WAITING FOR
OPENLNKRES
-----------------------------------------------------------------
BASE LINK
OPEN 1 No action if parameter matches
else close TCP session -> INIT BASE LINK OPEN
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 10
INTERNET DRAFT BASE Protocol Specification April 2000
2 Send message part to remote mex BASE LINK OPEN
3 Pass message parts to
layer above BASE LINK OPEN
4 Close TCP session INIT
5 No action INIT
6 N/a BASE LINK OPEN
7 Close TCP session SHUTDOWN
N/a BASE LINK OPEN
-----------------------------------------------------------------
SHUTDOWN 1 N/a SHUTDOWN
2 Return error to layer above
(shutdown state) SHUTDOWN
3 N/a SHUTDOWN
4 Return error to layer above
(shutdown state) SHUTDOWN
5 N/a SHUTDOWN
6 N/a SHUTDOWN
7 No action SHUTDOWN
8 N/a SHUTDOWN
-----------------------------------------------------------------
-----------------------------------------------------------------
The INIT state is the initial state of a peer in the BASE link. In
this state there is actually no external event that causes a state
change except a shutdown request from the layer above, which causes
a state transition to SHUTDOWN. Once the INIT state has been
reached, the peer immediately and repeatedly tries to establish a
TCP session to its adjacent mex. It then sends an "open link"
request to this mex and switches to the WAITING FOR OPENLNKRES
state. A message part transmission request received while being in
the INIT state from the layer above will be answered with an error,
indicating that the link is not open.
The WAITING FOR OPENLNKRES state is only reached from the INIT state
by sending an OPENLNKREQ message. Assuming a normal open process,
the expected event in this state is the receipt of an OPENLNKRES
message from the mex, which requires no further action but changes
the state to BASE LINK OPEN. In case of a message part transmission
request from the layer above the peer returns an "open in progress"
error and remains in its current state. If the peer receives either
a message part from the mex or a "close link" request from the layer
above, or a time-out occurs while being in this state, it closes the
TCP session and returns to the INIT state. The peer also reacts with
a state change to INIT, if the TCP session breaks while waiting for
an "open link" request. In this case no further action will be
taken. In case of a "shutdown" request from the layer above the TCP
session has to be closed by the peer before going to the SHUTDOWN
state.
The peer must wait for an incoming OPENLNKRES message for at least
ten seconds.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 11
INTERNET DRAFT BASE Protocol Specification April 2000
Having reached the BASE LINK OPEN state from the WAITING FOR
OPENLNKRES state by getting an "open link" response, there are three
events that cause a state change. A "shutdown" request from the
layer above will cause the peer to close the TCP session and switch
into the SHUTDOWN state. In case the peer receives a "close link"
request from the layer above or the TCP session goes down, it
changes its state to INIT. In the first case it is necessary to
orderly close the TCP session before. A peer is allowed to accept an
"open link" response while being in the BASE LINK OPEN state,
provided that the connection parameters match. No action is
required, the state remains unchanged. Otherwise, if the connection
parameters do not match, the TCP session has to be closed and the
peer switches to the INIT state. While being in the BASE LINK OPEN
state, the peer will perform any message part transmission request
from the layer above as well as pass any received message part to
the layer above. A time-out cannot occur.
The SHUTDOWN state can be reached from any other state by receiving
a shutdown request from the layer above. The only way to get out of
this state is by destroying the BASE protocol object.
7.1.2. Finite State Machine (Mex)
How BASE links are established and released from the mex's point of
view is shown in the following diagram. To simplify the diagram only
the normal case is considered here, assuming that only legal events
happen. The handling of possible error situations is discussed in
the finite state machine table. The states and possible events used
within this picture are listed below.
The following states are defined:
1.) INIT
Initial state, there is no active link between the peer
and its corresponding mex
2.) WAITING FOR OPENLNKREQ
The peer has sent an open link request to the mex and
is now waiting for an open link response
3.) BASE LINK OPEN
The peer has received an open link response from the
mex and the link is established
The following events may occur:
1.) The mex receives an open link request from a peer
2.) The mex receives a message part transmission request from
routing layer
3.) The mex receives message parts
4.) The mex receives a close link request from a BE
(applies to low-entry mex only)
5.) The TCP session went down
6.) A time-out occurred
7.) TCP session established
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 12
INTERNET DRAFT BASE Protocol Specification April 2000
Finite state machine table:
-----------------------------------------------------------------
State Event Action Target state
-----------------------------------------------------------------
INIT 1 N/a INIT
2 Return error to above/
routing layer (link not open) INIT
3 N/a INIT
4 No action INIT
5 N/a INIT
6 N/a INIT
7 No action WAITING FOR
OPENLNKREQ
-----------------------------------------------------------------
WAITING FOR
OPENLNKREQ 1 Send open link response to
remote peer,
notify routing layer BASE LINK OPEN
2 Return error to above layer
(open in progress) WAITING FOR
OPENLNKREQ
3 Close TCP session INIT
4 Close TCP session INIT
5 No action INIT
6 Close TCP session INIT
7 N/a WAITING FOR
OPENLNKREQ
-----------------------------------------------------------------
BASE LINK
OPEN 1 Send open link response
if parameters match
else close TCP session -> INIT BASE LINK OPEN
2 Send message part BASE LINK OPEN
3 Pass message parts to
layer above BASE LINK OPEN
4 Close TCP session INIT
5 Notify routing layer INIT
6 N/a BASE LINK OPEN
7 N/a BASE LINK OPEN
-----------------------------------------------------------------
-----------------------------------------------------------------
The INIT state is the initial state of a mex. In this state the only
event that causes a state change is the successful establishment of
a TCP session, inducing the mex to switch into the OPENLNKREQ state.
Any other event will neither cause a state change nor any further
action, except a transmission request from the route layer is
returned a "link not open" error.
The WAITING FOR OPENLNKREQ state is reached from the INIT state as
soon as a TCP session, that was initiated by the adjacent peer, has
been established. Normally the mex sends an "open link" response to
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 13
INTERNET DRAFT BASE Protocol Specification April 2000
the peer to open the link and switches into the BASE LINK OPEN
state. In case of incoming message parts, a "close link" request
from the BE, a TCP session break down or a time-out, the mex returns
to the INIT state. The TCP session has to be closed before if
necessary. Message part transmission requests from the above/routing
layer will be answered with an "open in progress" error. The state
remains unchanged.
The mex must wait for an OPENLNKREQ message for at least ten seconds
after the establishment of a TCP session.
The BASE LINK OPEN state is reached from the WAITING FOR OPENLNKREQ
state after having received an "open link" request from the local
peer and having returned an "open link" response. In the normal case
the mex performs transmission requests and forwards received
messages accordingly while being in this state. It is also allowed
to accept another "open link" request from the peer as long as the
connection parameters match. It will then return an "open link"
response and resume its activities. Otherwise, if the connection
parameters of an incoming "open link" request do not match, the TCP
session is closed and the mex's state becomes INIT. In case of a
"close link" request from the BE, the mex complies and closes the
TCP session before going into the INIT state. In case the TCP
session goes down, the routing layer has to be notified and the
state has to be changed to INIT.
7.2. Mex Functionality
A mex is a combined BASE message switch and message router. Every
peer node has to connect to a mex which provides a message switching
function for all directly connected peer nodes. When connecting
multiple mexes, each mex is treated as a sub-network and message are
routed between the mexes.
However, in the current BASE version 1, only entry-level mexes are
defined. These provide only a subset of the mex functionality in
that they may not link to other mexes. Therefore the current BASE
definition only provides for distinct islands of BASE peer nodes,
where one of these nodes acts both as a peer and a low-entry mex
node.
7.3. BASE Flow Management
This chapter describes the process of opening and closing a BASE
flow.
The opening of a BASE flow between a BE and a BA requires an initial
two-way handshake process of "open" messages. It can be initiated by
either side but the full transaction must be completed to
successfully open the flow. In the normal case the BA sends a
regular open request to the BE just after the BASE link has been
established. The BE replies by means of a regular open response
message to acknowledge the opening of the flow. The "open"
transaction has to be executed synchronously, which means that a
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 14
INTERNET DRAFT BASE Protocol Specification April 2000
peer must wait for a response to a preceding open request before
being allowed to send any other kind of message.
In case the BE rejects the open request, the BA will continue
sending open requests until a positive response is returned.
A flow that was previously interrupted by means of a "close" message
may be resumed at a later point in time. To do so, either side has
to initiate an "open" transaction with the appropriate message
parameter set to "reopen". The remote peer may reject the "reopen"
mode in which case the transaction is treated by both peers as if it
was a regular "open" transaction. Switching to the "regular open"
mode leads to the same transaction overhead (configuration of the BA
by the BE) as the initial open, and therefore should be seen as a
measure of last resort.
It may also occur that both peers request the opening of the flow at
the same time. In this case each peer receives an "open" request
just after having send one. In case the "reopen" modes are
compatible, the incoming "open" request is answered by returning an
"open" response and the flow is immediately opened. The outstanding
"open" response will be ignored since only one flow per peer-to-peer
couple can be opened at the same time.
A flow may be terminated by either side of the communication by
issuing a "close" message. No response is expected. The termination
of the last flow of a peer also terminates its link to the mex.
7.3.1. Finite State Machine
How BASE flows are opened and closed is graphically presented in the
following state diagram. To simplify the diagram only the normal
case is considered here, assuming that only legal events happen. The
handling of possible error situations is discussed in the finite
state machine table. The states and possible events used within this
picture are listed below.
The following states are defined:
1.) INIT
Initial state, there is no active or pending flow
between two peers
2.) OPEN SENT
This peer sent an open request to the remote peer
3.) WAITING FOR APPL RESP
This peer has received an open request from the remote
peer and is waiting for a response from the application
4.) OPEN
The BASE flow is open
5.) CLOSED
The flow is closed
6.) REOPEN SENT
This peer sent a reopen request to the remote peer
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 15
INTERNET DRAFT BASE Protocol Specification April 2000
The following events may occur:
1.) The application requests the regular opening of the flow
2.) The application requests the re-opening of the flow
3.) The application requests the transmission of a message other
than OPEN* or CLOSE
4.) The application requests the closing of the flow or the BASE
protocol object is destructed
5.) An OPENREQ (regular) message was received from the remote peer
6.) An OPENRES (regular) message was received from the remote peer
7.) An OPENREQ (reopen) message was received from the remote peer
8.) An OPENRES (reopen) message was received from the remote peer
9.) A CLOSE message was received from the remote peer
10.) A message other than OPEN* or CLOSE was received from the
remote peer
11.) A semi-permanent transmission error was detected by the BASE
link layer
12.) The application confirmed the "open" request
The state machine is partly left ambiguous. If the peer is for
instance in the OPEN SENT state and receives a close message from
the remote peer, its state should return to its previous one. It is
not apparent from the diagram whether this was the INIT or the
CLOSED state. For the sake of simplicity the INIT and the CLOSED
state are here treated as only one.
Finite state machine table:
-----------------------------------------------------------------
State Event Action Target state
-----------------------------------------------------------------
INIT 1 Send OPENREQ (regular)
to remote peer OPEN SENT
2 Return error to application
(regular open required) INIT
3 Return error to application
(flow not open) INIT
4 No action INIT
5 Notify application WAITING FOR
APPL RESP
6 No action INIT
7 Notify application of
regular OPENREQ WAITING FOR
APPL RESP
8 No action INIT
9 No action INIT
10 Send CLOSE to remote peer INIT
11 No action INIT
12 N/a INIT
-----------------------------------------------------------------
OPEN SENT 1 Return error to application
(open in progress) OPEN SENT
2 Return error to application
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 16
INTERNET DRAFT BASE Protocol Specification April 2000
(open in progress) OPEN SENT
3 Return error to application
(open in progress) OPEN SENT
4 Send CLOSE message to
remote peer INIT/CLOSED
5 Send OPENRES (regular) OPEN
6 No action OPEN
7 Notify application WAITING FOR
APPL RESP
8 Send CLOSE message to
remote peer
(Protocol violation) INIT/CLOSED
9 No action INIT/CLOSED
10 Notify application,
send CLOSE to remote peer INIT/CLOSED
11 Notify application
(open failed) INIT/CLOSED
12 N/a OPEN SENT
-----------------------------------------------------------------
REOPEN SENT 1 Return error to application
(open in progress) REOPEN SENT
2 Return error to application
(open in progress) REOPEN SENT
3 Return error to application
(open in progress) REOPEN SENT
4 Send CLOSE message to
remote peer CLOSED
5 Send error to remote peer
(open in progress) REOPEN SENT
6 Notify application OPEN
7 Send OPENRES (reopen)
to remote peer OPEN
8 No action OPEN
9 Notify application
(flow is closed) CLOSED
10 Notify application,
send CLOSE to remote peer CLOSED
11 Notify application
(reopen failed) CLOSED
12 N/a REOPEN SENT
-----------------------------------------------------------------
WAITING FOR
APPL RESP 1 Return error to application
(open in progress) WAITING FOR
APPL RESP
2 Return error to application
(open in progress) WAITING FOR
APPL RESP
3 Return error to application
(open in progress) WAITING FOR
APPL RESP
4 Send CLOSE message to
remote peer INIT/CLOSED
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 17
INTERNET DRAFT BASE Protocol Specification April 2000
5 No action WAITING FOR
APPL RESP
6 No action WAITING FOR
APPL RESP
7 Return error to
remote peer (open in progress) WAITING FOR
APPL RESP
8 Send CLOSE message to remote
peer (protocol violation) CLOSED
9 Notify application INIT/CLOSED
10 Notify application,
send CLOSE to remote peer INIT/CLOSED
11 Notify application
(open failed) INIT/CLOSED
12 Send OPENRES to remote peer OPEN
-----------------------------------------------------------------
OPEN 1 Notify application
(flow already open) OPEN
2 Notify application
(flow already open) OPEN
3 Transmit message OPEN
4 Send CLOSE message to
remote peer CLOSED
5 Notify application
(flow closed) Notify
application (OPENREQ regular) WAITING FOR
APPL RESP
6 No action OPEN
7 Send OPENRES (reopen) OPEN
8 No action OPEN
9 Notify application
(flow is closed) CLOSED
10 Notify application OPEN
11 Notify application
(transmission failed) OPEN
12 N/a OPEN
-----------------------------------------------------------------
CLOSED 1 Send OPENREQ (regular)
to remote peer OPEN SENT
2 Send OPENREQ (reopen)
to remote peer REOPEN SENT
3 Return error to application
(flow is closed) CLOSED
4 No action CLOSED
5 Notify application WAITING FOR
APPL RESP
6 Send CLOSE to remote peer CLOSED
7 Notify application WAITING FOR
APPL RESP
8 Send CLOSE to remote peer CLOSED
9 No action CLOSED
10 Send CLOSE to remote peer CLOSED
11 No action CLOSED
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 18
INTERNET DRAFT BASE Protocol Specification April 2000
12 N/a CLOSED
-----------------------------------------------------------------
-----------------------------------------------------------------
The INIT state is the initial state of a flow. In this state there
are only three events that can cause a state change. If the
application requests the regular opening of the flow, the peer sends
an OPENREQ (regular) message to the remote peer and switches into
the OPEN SENT state. If the peer receives either an OPENREQ
(regular) or an OPENREQ (reopen) message, it - in both cases -
notifies the application of a regular open request. The state then
is changed to WAITING FOR APPL RESP. In case of the application
requesting the re-opening of the flow or the transmission of a
message other than OPEN* or CLOSE, an error will be returned to the
application. If any other message other than OPEN* or CLOSE is
received from the remote peer, the local peer re-synchronizes the
flow state by sending a CLOSE message to the remote peer, assuming
that a previously sent CLOSE message was probably lost. Any other
event will have no effect, neither an action will be taken nor a
state change will occur.
The OPEN SENT state is either reached from the INIT or from the
CLOSED state by sending an OPENREQ (regular) message. If in this
state the application requests either the opening of the flow - no
matter whether regular or reopen - or the transmission of a message
other than OPEN* or CLOSE, an OPEN_IN_PROGRESS error will be
returned and no state transition is made. If either the application
requests the closing of the flow or a CLOSE message was received
from the remote peer, the state returns to the previous state which
is either INIT or CLOSED. In case the close request came from the
application, the local peer sends a CLOSE message to the remote peer
before closing the flow. A received OPENREQ (regular) message will
be answered by returning an OPENRES (regular) message and the state
becomes OPEN. The outstanding OPENRES (regular) message will be
ignored upon receipt (refer to OPEN state). If the expected OPENRES
(regular) message is received from the remote peer no further action
will be taken and the state is changed to OPEN. An OPENREQ (reopen)
message from the remote peer causes the notification of the
application and the state is changed to WAITING FOR RES. An OPENRES
(reopen) at this time means a protocol violation. The local peer
reacts by sending a CLOSE message to the remote peer and returns to
either INIT or CLOSED state depending on what the previous one was.
If any message but OPEN* or CLOSE arrives at this time, the flow
will be closed by means of a CLOSE message being sent to the remote
peer. The application will be notified and a transition is made to
the state INIT or CLOSED. In case of an open failure caused for
instance by a broken BASE link, the application will be notified and
the state is set back to INIT or CLOSED.
The REOPEN SENT state is either reached from the INIT or from the
CLOSED state by sending an OPENREQ (reopen) message. If the
application requests either the opening of the flow - no matter
whether regular or reopen - or the transmission of a message other
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 19
INTERNET DRAFT BASE Protocol Specification April 2000
than OPEN* or CLOSE, an OPEN_IN_PROGRESS error will be returned and
no state change will occur. If either the application requests the
closing of the flow or a CLOSE message was received from the remote
peer, the state becomes CLOSED. In the first case the local peer
sends a CLOSE message to the remote peer before closing the flow. If
the expected OPENRES (reopen) message is received from the remote
peer no further action will be taken and the state is changed to
OPEN. The same applies to an OPENRES (regular) message, which may be
sent from the remote peer in case a reopen of the flow is not
possible but a regular open would be acceptable. In case of an
OPENREQ (regular) message received from the remote peer, an
OPEN_IN_PROGRESS error will be returned, the state remains
unchanged. If an OPENREQ (reopen) message was received, the local
peer replies by means of an OPENRES (reopen) and goes to the OPEN
state. The outstanding OPENRES (reopen) will be ignored upon
receipt. If any message except OPEN* or CLOSE arrives at this time,
the flow will be closed by means of a CLOSE message being sent to
the remote peer. The application will be notified and the state is
changed to CLOSED. In case of a reopen failure caused for instance
by a broken BASE link, the application will be notified and the
state is set back to CLOSED.
The peer is in the WAITING FOR APPL RESP state after having received
an OPENREQ (regular or reopen) message and having notified the
application. In case the application requests either the regular
respectively re-opening of the flow or the transmission of a message
other than OPEN* or CLOSE, an OPEN_IN_PROGRESS error is returned and
no state transition is made. If the closing of the flow is requested
from either side, application or remote peer, the state is changed
to INIT respectively CLOSED. In case of an application initiated
close the remote peer has to be notified by means of a CLOSE
message, whereas in the other case the application has to be
notified of the closed flow. An OPENREQ (regular) and an OPENRES
(regular) message received from the remote peer will neither have
any effect on the state nor cause any further action. If an OPENREQ
(reopen) message was received, the OPEN_IN_PROGRESS error will be
returned to the remote peer. The state remains unchanged. An OPENRES
(reopen) message means a protocol violation and must not occur. The
flow will be closed by means of a CLOSE message to the remote peer
and its state will be adjusted accordingly. Any other message but
OPEN* or CLOSE is a protocol violation and causes the closing of the
flow. A CLOSE message will be returned and the application will be
notified accordingly. The state is changed to INIT respectively
CLOSED. An open failure due to a broken link will close the flow.
The application will be notified of the open failure and the state
becomes INIT resp. CLOSED. As soon as the application confirms the
"open" request, an appropriate "open" response is sent to the remote
peer and the state is changed to OPEN.
The OPEN state indicates a successfully opened flow and is reached
from the REOPEN SENT, OPEN SENT or WAITING FOR APPL RESP state. In
this state there are only three events that cause a state change. A
close request from either application or remote peer, or the receipt
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 20
INTERNET DRAFT BASE Protocol Specification April 2000
of an OPENREQ (regular) message from the remote peer. In case of a
close request from the application, the local peer sends a CLOSE
message to the remote peer for notification, in case of a CLOSE
message received from the remote peer, the application will be
notified. In both cases a transition is made to state CLOSED. If an
OPENREQ (regular) message was received from the remote peer, it is
assumed that a previous CLOSE message had been lost, and the flow
will be closed. The application will be informed of the close and
the following regular open request and the state is immediately
changed to WAITING FOR APPL RESP. No other event will have any
effect on the state, however different actions will be required. If
the application requests the opening or re-opening of the flow, a
"flow-already-open" error will be returned. Any application
transmission request will be executed. An OPENREQ (reopen) message
will be replied by means of an OPENRES (reopen) message. The
application needs to be notified of incoming messages other than
OPEN* or CLOSE, or transmission failures. OPENRES messages will be
ignored. If this state is reached from the OPEN SENT or REOPEN SENT
state, this peer is the initiator of the flow. If this state is
reached from the WAITING FOR APPL RESPONSE state, this peer is the
acceptor of the flow.
The CLOSED state can be reached from any other but the INIT state.
The state will be changed only if either the application or the
remote peer requests the opening of the flow. In the first case an
OPENREQ (regular or reopen) will be sent to the remote peer and the
state is changed to OPEN SENT respectively REOPEN SENT. If the open
request was received from the remote peer, the application will be
notified and the state becomes WAITING FOR APPL RESP. In any other
case the state remains unchanged, however different actions are
required. If the application requests transmission of messages, an
error will be returned. In case of an OPENRES message or any other
message except OPEN* or CLOSE, a CLOSE message will be sent to the
remote peer. Any close request from either side will be ignored. A
broken BASE link will have no effect.
7.4. Transactions
Although transactions are not actually part of the BASE protocol,
they are briefly considered here. There are two types of
transactions:
7.4.1. Single-message transaction
Transaction consists of a single message
BA---message--->BE or BE---message--->BA
7.4.2. Two-message transaction
Transaction consists of two messages, a request message and a
response message
BE----request---->BA
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 21
INTERNET DRAFT BASE Protocol Specification April 2000
BE<---response---BA
7.4.3. Table of transactions
Within BASE 17 transactions are defined:
----------------------------------------------------------------
Transaction Initiated by Type of message
BA BE Single message Two message
----------------------------------------------------------------
Open X X X
Register X X
Account Add X X
Account Delete X X
Account Suspend X X
Account Unsuspend X X
Account Change X X
Account X X
Policy Add X X
Policy Delete X X
Policy CHANGE X X
Policy Start X X
Policy Stop X X
Policy Reset X X
LIF Start X X
LIF Stop X X
LIF Data X X
----------------------------------------------------------------
----------------------------------------------------------------
7.5. Messages
There are two types of messages defined in the BASE protocol. The
first type of messages are used to exchange information between BA
and BE as elements of a transaction. The second type of messages are
used to exchange information between the two adjacent nodes of a
link. Currently the only messages that are specified for the latter
category are the time synchronization and link management messages.
7.5.1. Message Format
Messages generally consist of a fixed-length header and a variable-
length element container:
+------------------+--------------------------------------------+
| Message (header) | Message element container (variable length)|
+------------------+--------------------------------------------+
7.5.2. Message Header
The message header has the following structure:
+---------------+---------------+---------------+---------------+
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 22
INTERNET DRAFT BASE Protocol Specification April 2000
|7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| Version 8 bit | Destination address (license key) 32 bit |
+---------------+---------------+---------------+---------------+
| | Destination address (network number) 32 bit |
+---------------+---------------+---------------+---------------+
| | Source address (license key) 32 bit |
+---------------+---------------+---------------+---------------+
| | Source address (network number)32 bit |
+---------------+---------------+---------------+---------------+
| | Msg type |F|E|r|r|M-state|Transaction ID |
+---------------+---------------+---------------+---------------+
| | Msg element count |MEContainerlen |
+---------------+---------------+---------------+---------------+
| |
+---------------+---------------+---------------+
Version: 8 bit, indicates the BASE version and currently has a fixed
value of 0x01
Destination address (license key): 32-bit BASE License key (refer to
"Addressing")
Destination address (network number): 32-bit administrator defined
network number
Source address (license key): 32-bit BASE License key (refer to
"Addressing")
Source address (network number): 32-bit administrator defined
network number
Msg type: (8 bits):
--------------------------------+---------------------------
Message Type | Message Type
--------------------------------+---------------------------
OPENREQ 0x01 | POLICYDELETERES 0x15
OPENRES 0x02 | POLICYCHANGEREQ 0x16
CLOSE 0x03 | POLICYCHANGERES 0x17
REGISTERREQ 0x04 | POLICYSTARTREQ 0x18
REGISTERRES 0x05 | POLICYSTARTRES 0x19
ACCOUNTADDREQ 0x06 | POLICYSTOPREQ 0x1A
ACCOUNTADDRES 0x07 | POLICYSTOPRES 0x1B
ACCOUNTDELREQ 0x08 | POLICYRESETREQ 0x1C
ACCOUNTDELRES 0x09 | POLICYRESETRES 0x1D
ACCOUNTCHANGEREQ 0x0A | LIFSTARTREQ 0x1E
ACCOUNTCHANGERES 0x0B | LIFSTARTRES 0x1F
ACCOUNTSUSPENDREQ 0x0C | LIFSTOPREQ 0x20
ACCOUNTSUSPENDRES 0x0D | LIFSTOPRES 0x21
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 23
INTERNET DRAFT BASE Protocol Specification April 2000
ACCOUNTUNSUSPENDREQ 0x0E | LIFDATA 0x22
ACCOUNTUNSUSPENDRES 0x0F | SYNCREQ 0x23
ACCOUNTREQ 0x10 | (not used) 0x24
ACCOUNTRES 0x11 | SYNCDATA 0x25
POLICYADDREQ 0x12 | OPENLNKREQ 0x26
POLICYADDRES 0x13 | OPENLNKRES 0x27
POLICYDELETEREQ 0x14 | CLOSELNK 0x28
------------------------------+---------------------------
F: flag, 1 bit
"0" means intermediate message part
"1" means final message part
If message transmission requests by the application specifies more
message elements than feasible in a single message (due to either
the 65535 limit of message elements in the message header or message
size limitations in the BASE protocol stack), multiple message parts
have to be generated by the BASE protocol object. All but the last
of these message parts have the "F" flag set to "0". The last
message has this flag set to "1", thus enabling the receiving BASE
protocol object to re-assemble the complete message.
E: flag, 1 bit (since encryption is not supported in BASE version 1,
this flag has to be set to "0")
"0" means message element container is not encrypted
"1" means message element container is encrypted
r: 1 bit reserved for future use, must be set to "0"
r: 1 bit reserved for future use, must be set to "0"
Msg state:
This 4 bit long field serves two purposes:
If the "final" bit is set to "0"(intermediate message part), the
"msg state" resemble an error code of the BASE protocol stack.
Currently the following errors are defined:
0 No error occurred
1 Open in progress
2 License key already in use
14 Protocol violation
15 An internal error occurred
Others undefined
If the "final" bit is set to "1" (final message part), the "msg
state" reflect an application-defined error code. The value range is
from 0 to 15. Currently the following errors are defined:
0 SUCCESS
1 ERROR
2 SHUTDOWN
Even if the message is marked as a final message by the fragmenter,
the BASE protocol object may decide to set the final bit to "0" in
case of an error.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 24
INTERNET DRAFT BASE Protocol Specification April 2000
Transaction ID: every application-level transaction is tagged with a
per-flow unique transaction ID. This 16 bit long ID has a value
range from 1 to 32767 for the initiator of the flow and 32768 to
65535 for the acceptor of the flow. For messages that are not part
of application-level transactions (i. e. OPENLNKREQ, OPENLNKRES,
OPENREQ, CLOSE) the transaction ID is set to "0".
Msg element count: this 16 bit field indicates the number of
messages in the message element container and has a value range from
0 to 65535.
Msg element container length: this 32-bit field denotes the length
of the message element container in octets.
7.5.3. Message element container
The message element container has the following structure:
+--------+--------+--------+-------------------+--------+--------+
| octet | octet | octet | ... | octet | octet |
+--------+--------+--------+-------------------+--------+--------+
The message element container is a byte stream consisting of message
elements. A message element consists of a structure of data elements
that depends on the message type. The data elements are declared
within this documentation. The following BASE data types are used:
Data Type Data Type ID Length in bit
BYTE 0x01 8
WORD 0x02 16
DWORD 0x03 32
DOUBLE 0x04 64
STRING 0x05 variable
LOADTYPE 0x06 0
During network transmissions the high byte will be transmitted
before the low byte and within a byte the most significant bit
first.
Parameters of type string are transmitted in the following way:
Len(MSB),Len(LSB),Char,Char,...
The type "LOADTYPE" is never used as a parameter type in the byte
stream.
Throughout the message description, the element declaration contains
a data type tParameterTupel{}. It contains a variably typed
parameter value. To detect the proper parameter type the BASE
protocol object would have to monitor the registration of all
parameters, therefore mapping the ParameterID (contained in the
parameter tupel) to the proper BASE type. To simplify the
implementation of the BASE protocol object, the parameter type is
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 25
INTERNET DRAFT BASE Protocol Specification April 2000
transmitted in the byte stream leading to the following transmitted
byte order:
ParameterID,Data Type ID,data,...
The API needs to reflect the structure, so that the parameter type
can be communicated from the application to the BASE protocol object
and vice versa.
7.5.4. Message Fragmentation and Re-assembly
From a BASE application's perspective, transactions consist of one
or two messages. These messages have structured elements with a
(theoretically) unlimited number of elements.
On the other hand, the BASE protocol can only transmit data units of
a limited size. Therefore it may be required to split up the
application's messages into multiple message parts.
Every message part carries the complete header information,
including transaction ID and message type. Additionally, messages
must be split up in such a way that no elements are broken up across
multiple parts.
If a message needs to be transmitted as a sequence of multiple
parts, all but the last part are flagged as intermediate parts,
whereas the last part is marked as the final one. The message state
that is given by the application is only included in the final
message part, all intermediate parts carry a message state of "0"
unless the BASE protocol object has detected an error. This case is
signaled to the remote peer by setting the message state to an
according error value, but leaving the "intermediate part" flag of
that message. Although this specific message part is flagged as an
intermediate part (with error) no subsequent parts will be sent, and
the receiver must drop all parts received so far.
If the complete message fits in one part, that part is marked as
final. In case the BASE protocol object detects an error during
processing this part, it will again mark the part as "intermediate"
and set the message state to an according error value.
On the receiving side, message parts are re-assembled before being
handed to the application as a complete message.
7.6. BASE link-level Messages
Certain messages are used only in the communication of adjacent
nodes. These link-level messages are not forwarded by the mex to
other nodes.
Link-level messages are used to open and close the link, as well as
to perform link-level services. In BASE protocol version 1, BASE
time synchronization is the only service currently defined.
7.6.1. OPENLNKREQ Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 26
INTERNET DRAFT BASE Protocol Specification April 2000
The OPENLNKREQ message is sent from a peer to its adjacent mex node
just after the TCP session has been established. It is used to make
its BASE address (license key and network number) known to the mex
so that it can be addressed properly in the BASE flow.
7.6.1.1. Message Field Values:
Destination address (license key) 0
Destination address (network number) 0
Source address (license key) License key of local peer
Source address (network number) 0
Msg type OPENLNKREQ
Final Flag 1
Msg state 0
Transaction ID 0
Msg element count 0
Msg element container length 0
Msg element container -
7.6.1.2. Message Element Declaration
N/a
7.6.1.3. Comments
The destination address fields are both set to "0" since the network
number of the mex is unknown.
The "source address (network number)" is set to "0" since it is not
known to the peer at this time. The corresponding OPENLNKRES message
will contain the valid network number in the "destination address
(network number)" field.
7.6.2. OPENLNKRES Message
The OPENLNKRES message is sent from a mex to a peer node in reply to
an OPENLNKREQ message to indicate that the BASE link is opened.
7.6.2.1. Message Field Values:
Destination address (license key) License key of local peer
Destination address (network number) Network number of adjacent mex
Source address (license key) 0
Source address (network number) Network number of adjacent mex
Msg type OPENLNKRES
Final Flag 0 or 1
Msg state 0, 2 or 15
Transaction ID 0
Msg element count 0
Msg element container length 0
Msg element container -
7.6.2.2. Message Element Declaration
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 27
INTERNET DRAFT BASE Protocol Specification April 2000
N/a
7.6.2.3. Comments
The mex fills in the local peer's license key and its own network
number into the corresponding destination address fields The local
peer uses both as its fully qualified address for all following
messages.
7.6.3. CLOSELNK Message
The CLOSELNK message is sent from either side to orderly close a
BASE link.
7.6.3.1. Message Field Values:
Destination address (license key) Destination license key
Destination address (network number) Local network number
Source address (license key) Source license key
Source address (network number) Local Network number
Msg type CLOSELNK
Final Flag 1
Msg state 0
Transaction ID 0
Msg element count 0
Msg element container length 0
Msg element container -
7.6.3.2. Message Element Declaration
N/a
7.6.3.3. Comments
No comments
7.6.4. SYNCREQ Message
By means of a SYNCREQ message, any node may query the current BASE
time from an adjacent mex. Additionally this message allows to
determine the current network-added delay.
7.6.4.1. Message Field Values:
Destination address (license key) 0
Destination address (network number) Local network number
Source address (license key) Source license key
Source address (network number) Local network number
Msg type SYNCREQ
Final Flag 1
Msg state 0
Transaction ID 0
Msg element count 1
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 28
INTERNET DRAFT BASE Protocol Specification April 2000
Msg element container length 5
7.6.4.2. Message Element Declaration
{
DWORD RefTime;
}
By setting the "RefTime" field to the current time stamp of the
requesting node, the network-added delay between the requesting node
and the answering mex can be estimated. To achieve this the round-
trip time of the SYNCREQ/SYNCDATA message is measured by comparing
the original reference time stamp (returned in the corresponding
field of the SYNCDATA message) to the node's time when receiving the
SYNCDATA message. Half of the round-trip time should be added to
each new BASE time stamp (as received in the "CurrentTime" field of
the SYNCDATA message to gain a more precise value). This adjustment
should be used for all further SYNCDATA messages.
7.6.4.3. Comments
SYNCREQ messages should be used sparsely. A cycle of i. e. three
SYNCREQ messages every six to twelve hours should be sufficient to
get a proper estimate on the round-trip time. Using more than one
message per cycle allows to rule out single-message delays.
7.6.5. SYNCDATA Message
Every mex sends SYNCDATA messages either periodically every thirty
seconds to all adjacent nodes or in response to a SYNCREQ message to
the specific node from which the request was received.
7.6.5.1. Message Field Values:
Destination address (license key) Destination license key
Destination address (network number) Destination network number
Source address (license key) 0
Source address (network number) Local network number
Msg type SYNCREQ
Final Flag 1
Msg state 0
Transaction ID 0
Msg element count 1
Msg element container length 12
7.6.5.2. Message Element Declaration
{
DWORD CurrentTime;
DWORD RefTime;
BYTE Priority;
}
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 29
INTERNET DRAFT BASE Protocol Specification April 2000
The SYNCDATA message always carries the current valid BASE time, as
available on the mex, and the priority value of the mex. The
priority value is set by the administrator of the mex and is usually
used to distinguish mexes into classes of quality of their external
time sources. In case of a low-entry mex the highest priority value
"255" is used regardless of the external time source used. A mex
without any external time source uses a priority value of "0".
In case of a periodically send SYNCDATA message the "RefTime" field
is set to "0". If the SYNCDATA message is sent in response to a
SYNCREQ message the mex fills this field with the content of the
corresponding field of the request message.
7.6.5.3. Comments
No comments
7.7. BASE flow-level Messages
This section discusses the messages that are used to open and close
a BASE flow and to perform transactions via such flows.
Since the following fields of the message header are common for all
these messages, they are described only in this introduction:
- The source address (license key and network number) always
reflects the address of the sending system
- The destination address (license key and network number) always
references the system the message is sent to.
- A final flag of only "1" indicates that the corresponding message
will always fit into a single message part. This is usually true
for messages without message elements.
This section lists the messages from an application's point of view,
it may of course happen that the BASE protocol object alters this
flag to indicate an error state within the protocol layer.
The flow-level messages are divided into five categories.:
1.) Flow-management messages
The OPEN* and CLOSE messages are used to open and close the
BASE flow.
2.) Registration of BA capabilities
The REGISTER* messages are needed to supply the BE with the
BA's registration information, thus enabling the BE to properly
configure and interpret the BA.
3.) Configuration of source systems
ACCOUNT* messages serve the purpose of configuring the source
systems that are connected to the BAs.
4.) Configuration of billing agents
By using POLICY* messages BAs are configured by the BE.
5.) Transmission of load information
Load information transmission is controlled by LIFSTART* and
LIFSTOP* messages, whereas the actual transfer of load
information is done using LIFDATA messages.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 30
INTERNET DRAFT BASE Protocol Specification April 2000
Please note that except for OPENREQ, OPENRES, REGISTERRES, and those
messages without any message elements, all messages use the same
message element layout.
7.7.1. OPENREQ message
The OPENREQ message is sent from either a BE or a BA to request the
opening or the re-opening of a BASE flow.
7.7.1.1. Message Field Values:
Msg type OPENREQ
Final Flag 1
Msg state 0
Transaction ID 0
Msg element count 1
Msg element container length 5
Msg element container Message element
7.7.1.2. Message Element Declaration
{
WORD PeerTypeID;
WORD PeerVersion;
BYTE OpenMode
}
For a list of "PeerTypeID" values refer to chapter 5.3 "Peer Types".
"PeerVersion" is an application-defined value reflecting its program
version.
The "OpenMode" field is either set to "0" or to "1", where "0"
indicates a "regular open" request with full synchronization of the
peers, and "1" indicates a "reopen" request with minimal processing.
7.7.1.3. Comments
This message is generated inside of the BASE protocol object in
response to an according API call.
7.7.2. OPENRES Message
The OPENRES message is sent from either the BE or the BA in reply to
the OPENREQ message to acknowledge the opening of the flow.
7.7.2.1. Message Field Values:
Msg type OPENRES
Final Flag 0 or 1
Msg state 0, 1, 15
Transaction ID 0
Msg element count 1
Msg element container 5
length
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 31
INTERNET DRAFT BASE Protocol Specification April 2000
Msg element container Message element
7.7.2.2. Message Element Declaration
{
WORD PeerTypeID;
WORD PeerVersion;
BYTE OpenMode
}
For a list of "PeerTypeID" values refer to chapter 5.3 "Peer Types".
"PeerVersion" is an application-defined value reflecting its program
version.
The "OpenMode" field is either set to "0" or to "1", where "0"
indicates a "regular open" request with full synchronization of the
peers and "1" indicates a "reopen" request with minimal processing.
7.7.2.3. Comments
By setting the "OpenMode" to "0", the responding peer may reject the
re-opening of the flow. It is not permitted to change a "regular
open" request into a "reopen" request.
This message is automatically generated inside of the BASE protocol
object in response to an OPENREQ message. However, the "OpenMode"
value is determined by the application.
7.7.3. CLOSE Message
The CLOSE message is sent from either peer to close the BASE flow.
7.7.3.1. Message Field Values:
Msg type CLOSE
Final Flag 0 or 1
Msg state 0, 14, 15
Transaction ID 0
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.3.2. Message Element Declaration
N/a
7.7.3.3. Comments
This message is generated inside of the BASE protocol object in
response to an according API call.
7.7.4. REGISTERREQ Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 32
INTERNET DRAFT BASE Protocol Specification April 2000
The BE sends a REGISTERREQ message to the BA to indicate that type
and functionality of the BA are unknown and therefore registration
information is required.
7.7.4.1. Message Field Values:
Msg type REGISTERREQ
Final Flag 1
Msg state 0
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.4.2. Message Element Declaration
N/a
7.7.4.3. Comments
No comments
7.7.5. REGISTERRES Message
REGISTERRES messages are sent from a BA to the BE in reply to the
REGISTERREQ message. They contain BA registration information,
needed by the BE for the configuration and interpretation of the BA.
7.7.5.1. Message Field Values:
Msg type REGISTERRES
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.5.2. Message Element Declaration
{
BYTE MessageType;
// message type for which registration is to be performed
WORD ServiceID;
// service ID announced for the first time at this point by BA
STRING ServiceName;
// service for which registration is to be performed
WORD nRegisterTupels;
// number of registry tuples
tRegisterTupel RegisterTupel[ ];
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 33
INTERNET DRAFT BASE Protocol Specification April 2000
// 0-65535 registry tuples
}
tRegisterTupel {
BYTE ParameterTupelTypeID;
// type of parameter
WORD ParameterID;
// parameter ID stated by the BA at this point
// for the first time
STRING ParameterName;
// name of parameter
BYTE ParameterDataTypeID;
// type of the value range of parameter
STRING ParameterDomain;
// valid value range of parameter
}
"MessageType" is one of POLICYADDREQ, POLICYDELETEREQ,
POLICYCHANGEREQ, POLICYSTARTREQ, POLICYSTOPREQ, ACCOUNTADDREQ,
ACCOUNTDELREQ, ACCOUNTSUSPENDREQ, ACCOUNTUNSUSPENDREQ,
ACCOUNTCHANGEREQ, ACCOUNTREQ or ACCOUNTADDRES.
"MessageType" and "ServiceName" of the message element determine
which BA service has to be registered for which command. This
registration process informs the BE about how to build POLICY* and
ACCOUNT* messages for this BA.
The service to which the operation refers is indicated in the
"ServiceName" field. The corresponding service ID is at this point
stated for the first time by the BA. Solely this ID is used with
future POLICY* and ACCOUNT* messages to identify the requested
service.
The number of registry tuples (RegisterTupel) is stored in
"nRegisterTupels".
7.7.5.3. Comments
The following is a list of parameter types that have been defined
for the configuration of a service.
Type Value Description
-------------------------------------------------------------------
C 0x01 Configurable, parameter is used for the configuration
of the BA
K 0x02 Key, parameter is key member of the service
I 0x04 Informational, parameter carries additional
information, e. g. LIF messages
T 0x08 LoadType, parameter defines a new load type
L 0x10 Load, parameter defines load data
Z 0x20 Zone, parameter is member of zone info
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 34
INTERNET DRAFT BASE Protocol Specification April 2000
Depending on the MessageType and the service type, different
parameters have to be used. The value of ParameterTupelTypeID is a
result of multiple bit-wise ORed parameters. Each parameter type is
described below.
A parameter that is used for the configuration of a BA is flagged as
"C" (configurable), thus making system policies possible. System
policies influence the BA's behavior (e. g. aggregation). This
parameter does not reflect the configuration of the source system
which is, according to the definition, done exclusively through
ACCOUNT* messages.
A parameter is flagged as "K" (key), if it is part of the service's
primary key. "K"- flagged parameters within the registered
MessageType-ServiceName combination are mandatory when used by the
BE, so that the BA is able to execute the required command.
Parameters flagged as "I" (informational), are not part of the
primary key. They are used for the configuration of parameters on a
source system not necessary for its operation, or for the transfer
of billing-irrelevant information to the BE.
The load type of the load data, flagged as "L" (load), is registered
to the BE using "T"-flagged parameters, unless it is already defined
as a standard load type.
"L"-flagged parameters define load data used by the BE for the
billing of the subscribed services.
"Z"-flagged parameters are used by the BE for the identification of
tariff zones.
The "ParameterID" for each combination of "MessageType" and
"ServiceName" to be registered is set by the BA. It is sequentially
numbered, starting with the value "1".
"ParameterName" is a string, containing the name of the parameter.
"ParameterDataTypeID" is a BASE "DataTypeID" (refer to chapter 5.1
"Data Types") and indicates the type of the parameter's value, when
the parameter is used for future POLICY*, ACCOUNT* or LIFDATA
messages. The exception being "T"-flagged parameters which define
new load types. In this case "ParameterDataTypeID" has to be set to
"LOADTYPE" (0x06).
"ParameterDomain" 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 (refer to 5.6 "Regular BASE
Expressions"); the exception being "T"-flagged parameters in which
case the "ParameterDomain" field contains the load type ID of the
newly registered load type as a hexadecimal value ("T"-flag, e. g.
"\w0A02"). When the parameter is used afterwards, its value must be
within the range defined through "ParameterDomain". The sender tries
to validate the value to the utmost of its ability.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 35
INTERNET DRAFT BASE Protocol Specification April 2000
The use of "L"-flagged parameters depends on the BASE message type.
During the registration process the possible load types are defined
within a string as constants of type WORD, e. g. "\w0005\w1111". The
BE subscribes to load data in the required measurement unit based on
these values using the POLICYADDREQ message. When the load data is
actually sent in a LIFDATA message, the type of the "L"-flagged
parameter corresponds to the one defined through "LoadType". For a
complete list of predefined load types refer to chapter 5.2 "Load
Types". Load types, which are added during the registration process,
are defined through the "T"-flagged parameter.
The registration of specific ACCOUNTREQ messages enables the BE to
request the value range from the source system via the BA. This
requires the preceding registration of the corresponding services
and parameters, e. g. by means of the ACCOUNTADDREQ message.
"MessageType", "ServiceID" and "ServiceName" of the ACCOUNTREQ
message become superfluous, since the parameter is identified
through the previously registered "ParameterID". The other
attributes are set as follows:
ParameterTupelTypeID is set to "C"
ParameterName is either "used" or "free"
ParameterDataTypeID ID of this query, that is registered for use
via ACCOUNT messages
ParameterDomain filter to reduce the number of values that can
be queried
7.7.6. ACCOUNTADDREQ Message
By means of an ACCOUNTADDREQ message, the BE instructs a BA to
configure a service for a new user on the source system.
7.7.6.1. Message Field Values:
Msg type ACCOUNTADDREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.6.2. Message Element Declaration
{
WORD ServiceID;
// service ID of the requested service
DWORD TimeStamp;
// based on January 1, 2000
WORD nParameters;
// number of parameter tuples
tParameterTupel Parameter[];
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 36
INTERNET DRAFT BASE Protocol Specification April 2000
// 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.6.3. Comments
ACCOUNTADDREQ messages only transmit parameters of types K/I/Z. Any
parameter flagged differently will not be transmitted.
K-, I- and Z-parameters must not contain regular expressions, they
must be declared atomic.
7.7.7. ACCOUNTADDRES Message
The ACCOUNTADDRES message is sent from the BA to the BE in reply to
an ACCOUNTADDREQ message to acknowledge the successful completion of
the requested operation. Additional response information may be
passed via parameters.
7.7.7.1. Message Field Values:
Msg type ACCOUNTADDRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0-65535
Msg element container variable
length
Msg element container Message elements
7.7.7.2. Message Element Declaration
{
WORD ServiceID;
// service ID of the requested service
DWORD TimeStamp;
// based on January 1, 2000
WORD nParameters;
// number of parameter tuples
tParameterTupel Parameter[];
// 0-65535 Parameter
}
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 37
INTERNET DRAFT BASE Protocol Specification April 2000
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.7.3. Comments
ACCOUNTADDRES messages only transmit parameters of types K/I/Z. Any
parameter flagged differently will not be transmitted.
K-, I- and Z-parameters must not contain regular expressions, they
must be declared atomic.
7.7.8. ACCOUNTDELREQ Message
By means of an ACCOUNTDELREQ message, the BE instructs the BA to
remove a service for an existing user from the source system. The
user is referenced by the complete key that was used within the
corresponding ACCOUNTADDREQ message.
7.7.8.1. Message Field Values:
Msg type ACCOUNTDELREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.8.2. Message Element Declaration
{
WORD ServiceID;
// service ID of the requested service
DWORD TimeStamp;
// based on January 1, 2000
WORD nParameters;
// number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 38
INTERNET DRAFT BASE Protocol Specification April 2000
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.8.3. Comments
ACCOUNTDELREQ messages only transmit parameters of type K. Any
parameter flagged differently will not be transmitted.
7.7.9. ACCOUNTDELRES Message
The ACCOUNTDELRES message is sent from the BA to the BE in reply to
an ACCOUNTDELREQ message to acknowledge the successful completion of
the requested operation.
7.7.9.1. Message Field Values:
Msg type ACCOUNTDELRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.9.2. Message Element Declaration
N/a
7.7.9.3. Comments
No comments
7.7.10. ACCOUNTCHANGEREQ Message
By means of an ACCOUNTCHANGEREQ message, the BE instructs the BA to
change the configuration of an existing service for a user on the
source system. The user is referenced by the complete key that was
used within the corresponding ACCOUNTADDREQ message.
7.7.10.1. Message Field Values:
Msg type ACCOUNTCHANGEREQ
Final Flag 0 or 1
Msg state Application-defined
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 39
INTERNET DRAFT BASE Protocol Specification April 2000
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.10.2. Message Element Declaration
{
WORD ServiceID;
// service ID of the requested service
DWORD TimeStamp;
// based on January 1, 2000
WORD nParameters;
// number of parameter tuples
tParameterTupel Parameter[];
// 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.10.3. Comments
ACCOUNTCHANGEREQ messages only transmit parameters of types K/I/Z.
Any parameter flagged differently will not be transmitted.
I- and Z-parameters must not contain regular expressions, they must
be declared atomic, whereas K-parameter may contain regular
expressions.
7.7.11. ACCOUNTCHANGERES Message
The ACCOUNTCHANGERES message is sent from the BA to the BE in reply
to an ACCOUNTCHANGEREQ message to acknowledge the successful
completion of the requested operation.
7.7.11.1. Message Field Values:
Msg type ACCOUNTCHANGERES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 40
INTERNET DRAFT BASE Protocol Specification April 2000
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.11.2. Message Element Declaration
N/a
7.7.11.3. Comments
No comments
7.7.12. ACCOUNTSUSPENDREQ Message
By means of an ACCOUNTSUSPENDREQ message, the BE instructs the BA to
temporarily lock a service for a user on the source system. The user
is referenced by the complete key that was used within the
corresponding ACCOUNTADDREQ message.
7.7.12.1. Message Field Values:
Msg type ACCOUNTSUSPENDREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.12.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 41
INTERNET DRAFT BASE Protocol Specification April 2000
7.7.12.3. Comments
ACCOUNTSUSPENDREQ messages only transmit parameters of type K. Any
parameter flagged differently will not be transmitted.
7.7.13. ACCOUNTSUSPENDRES Message
The ACCOUNTSUSPENDRES message is sent from the BA to the BE in reply
to an ACCOUNTSUSPENDREQ message to acknowledge the successful
completion of the requested operation.
7.7.13.1. Message Field Values:
Msg type ACCOUNTSUSPENDRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.13.2. Message Element Declaration
N/a
7.7.13.3. Comments
No comments
7.7.14. ACCOUNTUNSUSPENDREQ Message
By means of an ACCOUNTUNSUSPENDREQ message, the BE instructs the BA
to unlock a service previously locked for a user on the source
system. The user is referenced by the complete key that was used
within the corresponding ACCOUNTADDREQ message.
7.7.14.1. Message Field Values:
Msg type ACCOUNTUNSUSPENDREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.14.2. Message Element Declaration
{
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 42
INTERNET DRAFT BASE Protocol Specification April 2000
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.14.3. Comments
ACCOUNTUNSUSPENDREQ messages only transmit parameters of type K. Any
parameter flagged differently will not be transmitted.
7.7.15. ACCOUNTUNSUSPENDRES Message
The ACCOUNTUNSUSPENDRES message is sent from the BA to the BE in
reply to an ACCOUNTUNSUSPENDREQ message to acknowledge the
successful completion of the requested operation.
7.7.15.1. Message Field Values:
Msg type ACCOUNTUNSUSPENDRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.15.2. Message Element Declaration
N/a
7.7.15.3. Comments
No comments
7.7.16. ACCOUNTREQ Message
ACCOUNTREQ messages are sent from the BE to the BA to query the
values of a service parameter, either used or free, thus making it
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 43
INTERNET DRAFT BASE Protocol Specification April 2000
possible to automatically integrate source systems, started prior to
the BE, into the billing system.
7.7.16.1. Message Field Values:
Msg type ACCOUNTREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.16.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.16.3. Comments
By means of ACCOUNTREQ messages, the BA registers with the BE the
possibility to query the source system for value ranges for the
required services or parameters.
The ParameterID of a parameter tuple corresponds to the registered
ID of a possible query of the value range of a service-parameter
combination. The parameter is a filter string.
7.7.17. ACCOUNTRES Message
The ACCOUNTRES message is sent from the BA to the BE in reply to an
ACCOUNTREQ message to provide the requested information.
7.7.17.1. Message Field Values:
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 44
INTERNET DRAFT BASE Protocol Specification April 2000
Msg type ACCOUNTRES
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.17.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.17.3. Comments
The parameter ID of a parameter tuple corresponds to the one used
within the ACCOUNTREQ message. The parameter is a value within the
allowed value range.
7.7.18. POLICYADDREQ Message
POLICYADDREQ messages are sent from the BE to the BA to control the
BAs' load information flow. They are used to subscribe to load
information provided by the BA.
7.7.18.1. Message Field Values:
Msg type POLICYADDREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 45
INTERNET DRAFT BASE Protocol Specification April 2000
Msg element container variable
length
Msg element container Message elements
7.7.18.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.18.3. Comments
POLICYADDREQ messages only transmit parameters of types C/K/L/I/Z.
Any parameter flagged differently will not be transmitted.
C-, L-, I- and Z-parameters must not contain regular expressions,
they must be declared atomic, whereas K-parameters may contain
regular expressions.
7.7.19. POLICYADDRES Message
The POLICYADDRES message is sent from the BA to the BE in reply to a
POLICYADDREQ message to acknowledge the successful completion of the
requested operation.
7.7.19.1. Message Field Values:
Msg type POLICYADDRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.19.2. Message Element Declaration
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 46
INTERNET DRAFT BASE Protocol Specification April 2000
N/a
7.7.19.3. Comments
No comments
7.7.20. POLICYDELETEREQ Message
POLICYDELETEREQ messages are sent from the BE to the BA to control
the BA's load information flow. They are used to cancel the
subscription to load information that has previously been added
through POLICYADDREQ. Keys have to be specified exactly as with the
corresponding POLICYADDREQ message.
7.7.20.1. Message Field Values:
Msg type POLICYDELETEREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.20.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.20.3. Comments
POLICYDELETEREQ messages only transmit parameters of type K. Any
parameter flagged differently will not be transmitted.
K-parameters may contain regular expressions.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 47
INTERNET DRAFT BASE Protocol Specification April 2000
7.7.21. POLICYDELETERES Message
The POLICYDELETERES message is sent from the BA to the BE in reply
to a POLICYDELETEREQ message to acknowledge the successful
completion of the requested operation.
7.7.21.1. Message Field Values:
Msg type POLICYDELETERES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.21.2. Message Element Declaration
N/a
7.7.21.3. Comments
No comments
7.7.22. POLICYCHANGEREQ Message
POLICYCHANGEREQ messages are sent from the BE to the BA to change
the parameters of a subscription to load information that has
previously been added through POLICYADDREQ. Keys have to be
specified exactly as with the corresponding POLICYADDREQ message.
This is for example useful to restrict a currently active load
information flow using filters without the need to delete it
completely and add a new one afterwards.
K-parameters cannot be changed.
7.7.22.1. Message Field Values:
Msg type POLICYCHANGEREQ
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.22.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 48
INTERNET DRAFT BASE Protocol Specification April 2000
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.22.3. Comments
POLICYCHANGEREQ messages only transmit parameters of types C/K/L.
Any parameter flagged differently will not be transmitted.
C- and L-parameters must not contain regular expressions, they must
be declared atomic, whereas K-parameters may contain regular
expressions.
7.7.23. POLICYCHANGERES Message
The POLICYCHANGERES message is sent from the BA to the BE in reply
to a POLICYCHANGEREQ message to acknowledge the successful
completion of the requested operation.
7.7.23.1. Message Field Values:
Msg type POLICYCHANGERES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.23.2. Message Element Declaration
N/a
7.7.23.3. Comments
No comments
7.7.24. POLICYSTARTREQ Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 49
INTERNET DRAFT BASE Protocol Specification April 2000
The POLICYSTARTREQ message is sent from the BE to the BA to activate
all policies that have previously been added to this BA. It causes
the BA to start collecting information accordingly. There is no data
transfer from the BA to the BE at this point, which would require a
LIFSTARTREQ message.
7.7.24.1. Message Field Values:
Msg type POLICYSTARTREQ
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.24.2. Message Element Declaration
N/a
7.7.24.3. Comments
No comments
7.7.25. POLICYSTARTRES Message
The POLICYSTARTRES message is sent from the BA to the BE in reply to
a POLICYSTARTREQ message to acknowledge the successful activation of
all policies.
7.7.25.1. Message Field Values:
Msg type POLICYSTARTRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.25.2. Message Element Declaration
N/a
7.7.25.3. Comments
No comments
7.7.26. POLICYSTOPREQ Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 50
INTERNET DRAFT BASE Protocol Specification April 2000
The POLICYSTOPREQ message is sent from the BE to the BA to
deactivate all policies on this BA and thus stop the data
collection. The policies will not be deleted through this command
and can be re-activated at any time using POLICYSTARTREQ.
7.7.26.1. Message Field Values:
Msg type POLICYSTOPREQ
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.26.2. Message Element Declaration
N/a
7.7.26.3. Comments
No comments
7.7.27. POLICYSTOPRES Message
The POLICYSTOPRES message is sent from the BA to the BE in reply to
a POLICYSTOPREQ message to acknowledge the successful deactivation
of all policies.
7.7.27.1. Message Field Values:
Msg type POLICYSTOPRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.27.2. Message Element Declaration
N/a
7.7.27.3. Comments
No comments
7.7.28. POLICYRESETREQ Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 51
INTERNET DRAFT BASE Protocol Specification April 2000
The POLICYRESETREQ message is sent from the BE to the BA to reset
all subscriptions and thus restore the initial state of the BA,
prior to the first POLICYADDREQ message.
7.7.28.1. Message Field Values:
Msg type POLICYRESETREQ
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.28.2. Message Element Declaration
N/a
7.7.28.3. Comments
No comments
7.7.29. POLICYRESETRES Message
The POLICYRESETRES message is sent from the BA to the BE in reply to
a POLICYRESETREQ message to acknowledge that all subscriptions have
successfully been reset.
7.7.29.1. Message Field Values:
Msg type POLICYRESETRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.29.2. Message Element Declaration
N/a
7.7.29.3. Comments
No comments
7.7.30. LIFSTARTREQ Message
After having subscribed to the load information provided by a BA
using POLICY* messages, the BE is now able to control the load
information flow from the BA to itself using LIFSTARTREQ and
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 52
INTERNET DRAFT BASE Protocol Specification April 2000
LIFSTOPREQ messages. By means of a LIFSTARTREQ message, the BE
instructs the BA to start sending load data to the BE via the BASE
flow.
7.7.30.1. Message Field Values:
Msg type LIFSTARTREQ
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.30.2. Message Element Declaration
N/a
7.7.30.3. Comments
The LIFSTARTREQ message affects all subscribed load information at
the same time.
7.7.31. LIFSTARTRES Message
The LIFSTARTRES message is sent from the BA to the BE in reply to a
LIFSTARTREQ message to acknowledge that it has received the request
to start sending load information to the BE.
7.7.31.1. Message Field Values:
Msg type LIFSTARTRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.31.2. Message Element Declaration
N/a
7.7.31.3. Comments
No comments
7.7.32. LIFSTOPREQ Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 53
INTERNET DRAFT BASE Protocol Specification April 2000
By means of a LIFSTOPREQ message, the BE instructs the BA to stop
sending load data to the BE via the BASE flow. The BA does not stop
gathering information from the source systems.
7.7.32.1. Message Field Values:
Msg type LIFSTOPREQ
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.32.2. Message Element Declaration
N/a
7.7.32.3. Comments
The LIFSTOPREQ message affects all load information at the same time
which means that the load data flow from the BA to the BE is
stopped.
7.7.33. LIFSTOPRES Message
The LIFSTOPRES message is sent from the BA to the BE in reply to a
LIFSTOPREQ message to acknowledge that it has received the request
to stop sending load information to the BE.
7.7.33.1. Message Field Values:
Msg type LIFSTOPRES
Final Flag 1
Msg state Application-defined
Transaction ID 1-65535
Msg element count 0
Msg element container 0
length
Msg element container -
7.7.33.2. Message Element Declaration
N/a
7.7.33.3. Comments
No comments
7.7.34. LIFDATA Message
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 54
INTERNET DRAFT BASE Protocol Specification April 2000
LIFDATA messages are sent from the BA to the BE upon request. They
contain subscribed load information of the source systems that has
been gathered by the BA.
7.7.34.1. Message Field Values:
Msg type LIFDATA
Final Flag 0 or 1
Msg state Application-defined
if final flag = "1"
Transaction ID 1-65535
Msg element count 1-65535
Msg element container variable
length
Msg element container Message elements
7.7.34.2. Message Element Declaration
{
WORD ServiceID; // service ID of the requested service
DWORD TimeStamp; // based on January 1, 2000
WORD nParameters; // number of parameter tuples
tParameterTupel Parameter[]; // 0-65535 Parameter
}
tParameterTupel {
WORD ParameterID;
BASE-Type Parameter;
}
"ServiceID" and "ParameterID" have been made known through the
registration process. The parameter has a defined type for the range
of values according to the parameter ID and thus an implicitly
defined length. The number of bytes that are transmitted for each
parameter is therefore not explicitly specified; the exception being
parameters of type "STRING" which carry explicit length information
in their first two bytes.
7.7.34.3. Comments
LIFDATA messages only transmit parameters of types K/I/L/Z. Any
parameter flagged differently will not be transmitted.
K-, I-, L- and Z-parameters are always transmitted atomic (without
regular expressions). L-parameter are transmitted according to their
registered load type.
8. BASE Flow Example
Typically, products adhering to BASE version 1 are deployed in a
scenario similar the following:
A central billing engine is coded to function as a low-entry mex. No
other BEs are present, but a number of peer nodes with billing
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 55
INTERNET DRAFT BASE Protocol Specification April 2000
agents connect to the BE. This example covers only a single BA for
the sake of simplicity.
The billing engine requires no knowledge of the BA(s), whereas the
BA(s) need to know both the IP address (or DNS name) of the low-
entry mex and the network number and license key of the BE to be
able to connect. (If the BA only had the IP address of the mex, the
BE would need to know the license key of the BA in order to open the
flow as soon as the BA peer node establishes the link to the mex.
This would have to be done by polling since the low-entry mex design
does not provide for a notification of the "link up" event. The BE
does explicitly need to know the network number since it runs the
single mex of this BASE network, and so fixes the network number.)
In this example the BE starts the low-entry mex with a network
number of "1" and has a license key of "0x00010000". The BA has a
license key of "0x00020000". The IP addresses are not explicitly
mentioned, especially since none of the underlying TCP details are
given.
To be able to offer as much details as required, the example layout
distinguishes between the BE and the low-entry mex as well as
between the BASE application (BE or BA) and the BASE protocol object
(bpo) of the corresponding peer. Usually, these are integrated in
one piece of software per peer.
8.1. Communication table
+------------+------------+-------------+------------+------------+
| BE | Bpo |Low-entry-mex| Bpo | BA |
+------------+------------+-------------+------------+------------+
| | | | | |
| | | | <------- 1 |
| | | | 2 | |
| | | | | |
| | | <------- | |
| | | TCP open fail | |
| | | | | |
| | | <------- | |
| | | TCP open fail | |
| | | | | |
| 3 ----------------------> 4 | | |
| | | | | |
| | | <------- | |
| | | TCP open | |
| | | success | |
| | | | | |
| 5 | | 6 | | |
| | | | | |
| | | <--------- 7 | |
| | | OPENLNKREQ | |
| | | 8 | | |
| | | | | |
| | | 9 ----------> | |
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 56
INTERNET DRAFT BASE Protocol Specification April 2000
| | | OPENLNKRES | |
| | | | 10 | |
| | | | | 11 |
| | | | | |
| | | | <-------- |
| | | | API Open() |
| | | | | |
| | <------------------------12 | |
| | OPENREQ | | |
| | 13 | | | |
| | | | | |
| <---------- | | | |
| API call | | | |
| | | | | |
| 14 | | | | |
| | | | | |
| ----------> | | | |
| accept via | | | |
| API call | | | |
| | 15 | | | |
| | | | | |
| | 16 -----------------------> | |
| | OPENRES | 17 | |
| | | | --------> |
| | | | API Open() |
| | | | returns |
| | | | | |
| 18 | | | | |
| 19-------------------------------------------------> |
| REGISTERREQ | | | 20 |
| | | | | |
| <------------------------------------------------- 21 |
| REGISTERRES | | | |
| | | | | |
| After the initial processing has been done, the flow can be |
| used for the transfer of load- or account information |
| ... |
| In this example, the flow is closed on part of the BE |
| | | | | |
| 22 | | | | |
| ----------> | | | |
| API close() | | | |
| | 23 ------------------------> | |
| | CLOSE | -----------> |
| | | | API close |
| | | | notification |
| | | | | |
+------------+------------+-------------+------------+------------+
8.2. Remarks to the communication table
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 57
INTERNET DRAFT BASE Protocol Specification April 2000
1) Upon startup, the BA initializes the bpo with an indicator to run
as a peer node, the TCP/IP address of the mex, the BA's license key,
its type and version.
2) The bpo repeatedly tries to connect to the mex.
3) Upon startup, the BE initializes the low-entry mex by
constructing the bpo with an indicator to run as a low-entry mex,
the network number to use, the BE's license key, its type and
version.
4) The Low-entry mex initializes the TCP socket.
5) The BE then waits for incoming BASE flows.
6) The Low-entry mex opens the TCP session and waits for an "open
link" request.
7) The BA bpo sent an OPENLNKREQ message to the mex:
Destination address (license key) 0x00000000
Destination address (network number) 0x00000000
Source address (license key) 0x00020000
Source address (network number) 0x00000000
Msg type 0x26
F-flag 1
Msg state 0x0
Transaction ID 0x0000
Msg element count 0x0000
Msg element container length 0x00000000
Byte stream of message(all in hex):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|00|00|00|00|00|00|00|00|00|02|00|00|00|00|00|
|00|26|80|00|00|00|00|00|00|00|00| | | | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8) The Low-entry mex generates an entry in its switching table to
link the peer's license key to the corresponding TCP session, then
sends an "open link" response.
9) The mex sent an OPENLNKRES message to the BA bpo:
Destination address (license key) 0x00020000
Destination address (network number) 0x00000001
Source address (license key) 0x00000000
Source address (network number) 0x00000001
Msg type 0x27
F-flag 1
Msg state 0x0
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 58
INTERNET DRAFT BASE Protocol Specification April 2000
Transaction ID 0x0000
Msg element count 0x0000
Msg element container length 0x00000000
Byte stream of message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|00|02|00|00|00|00|00|01|00|00|00|00|00|00|00|
|01|27|80|00|00|00|00|00|00|00|00| | | | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10) Now the link is open, and the bpo accepts calls to its Open()
method without immediately returning an error
11) The BA has tried to Open() the flow since bpo has been created.
12) The BA bpo sent an OPENREQ message to the BE bpo:
Destination address (license key) 0x00010000
Destination address (network number) 0x00000001
Source address (license key) 0x00020000
Source address (network number) 0x00000001
Msg type 0x01
F-flag 1
Msg state 0x0
Transaction ID 0x0000
Msg element count 0x0001
Msg element container length 0x00000008
Message element:
{
0x0001; // BA type is ASCII
0x1234; // BA version
0x00 // OpenMode is "regular"
}
Byte stream of message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|00|01|00|00|00|00|00|01|00|02|00|00|00|00|00|
|01|01|80|00|00|00|01|00|00|00|08|00|01|12|34|00|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
13) The bpo asks the BE to confirm the open request.
14) The BE checks the mode of the open request (usually there should
be no reason to deny a "regular" open).
15) The bpo sends an appropriate response.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 59
INTERNET DRAFT BASE Protocol Specification April 2000
16) The BE bpo sent an OPENRES message to the BA bpo:
Destination address (license key) 0x00020000
Destination address (network number) 0x00000001
Source address (license key) 0x00010000
Source address (network number) 0x00000001
Msg type 0x02
F-flag 1
Msg state 0x0
Transaction ID 0x0000
Msg element count 0x0001
Msg element container length 0x00000008
Message element:
{
0x0000; // BE type is BE
0x5678; // BE version
0x00 // OpenMode is "regular"
}
Byte stream of message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|00|02|00|00|00|00|00|01|00|01|00|00|00|00|00|
|01|02|80|00|00|00|01|00|00|00|08|00|00|56|78|00|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
17) The flow is open now
18) Assuming, this was the first time the BA type connected to the
BE, its capabilities has to be determined.
19) The BE sent a REGISTERREQ message to the BA
Destination address (license key) 0x00020000
Destination address (network number) 0x00000001
Source address (license key) 0x00010000
Source address (network number) 0x00000001
Msg type 0x04
F-flag 1
Msg state 0x0
Transaction ID 0x8000
Msg element count 0x0000
Msg element container length 0x00000000
Byte stream of message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 60
INTERNET DRAFT BASE Protocol Specification April 2000
|01|00|02|00|00|00|00|00|01|00|01|00|00|00|00|00|
|01|04|80|80|00|00|00|00|00|00|00| | | | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20) The BA lists all its capabilities.
21) The BA sent a REGISTERRES to the BE
Destination address (license key) 0x00010000
Destination address (network number) 0x00000001
Source address (license key) 0x00020000
Source address (network number) 0x00000001
Msg type 0x05
F-flag 1
Msg state 0x0
Transaction ID 0x8000
Msg element count 0x????
Msg element container length 0x????????
Messages elements:
{
0x??; // MessageType
0x????; // ServiceID
"?"; // ServiceName
0x????; // nRegisterTupels
}
{
0x??; // ParameterTupelTypeID
0x????; // ParameterID
"?"; // ParameterName
0x??; // ParameterDataTypeID
"?"; // ParameterDomain
}
Byte stream of message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|00|01|00|00|00|00|00|01|00|02|00|00|00|00|00|
|01|05|80|80|00|??|??|??|??|??|??| | | | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22) The BE instructs the bpo to close the flow.
23) The BE bpo sent a CLOSE message to the BA bpo
Destination address (license key) 0x00020000
Destination address (network number) 0x00000001
Source address (license key) 0x00010000
Source address (network number) 0x00000001
Msg type 0x03
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 61
INTERNET DRAFT BASE Protocol Specification April 2000
F-flag 1
Msg state 0x0
Transaction ID 0x0000
Msg element count 0x0000
Msg element container length 0x00000000
Byte stream of message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| A| B| C| D| E| F|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|00|02|00|00|00|00|00|01|00|01|00|00|00|00|00|
|01|03|80|00|00|00|00|00|00|00|00| | | | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9. BASE Definitions
This section summarizes the various definitions found in this
documentation.
9.1. Data Types
The following data types are defined in the BASE protocol:
Data type DataTypeID Length in bit
BYTE 0x01 8
WORD 0x02 16
DWORD 0x03 32
DOUBLE 0x04 64
STRING 0x05 variable
LOADTYPE 0x06 0
The data types indicate the type of parameters that are transmitted
according to the BASE protocol. Due to the data type definition,
there is no need to indicate the number of bytes transmitted for a
parameter, with the exception of the data type "STRING". The first
two bytes of a string indicate the string length in octets (most
significant byte first).
The data type "LOADTYPE" is used only to announce new load types.
In a BASE communication all transmitted data is treated as unsigned
integers. Only the BE may interpret signs.
9.2. Load Types
Load types indicate the measurement units of load data. It is the
responsibility of the BE to interpret the load types. The BASE
protocol defines a number of load types. Additional load types can
be announced to the BE by the BA. This is done during the BA
registration process, which is described in chapter 3.5.4.5
"REGISTERRES message".
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 62
INTERNET DRAFT BASE Protocol Specification April 2000
To guarantee that load types are unique world-wide, they have to be
announced to the BASE registration office of the IOAG before being
used. The new load type is then given a load type identifier
("LoadTypeID") that has to be used in the BASE communication. Load
type IDs are of type "WORD". The following is a list of all load
types that have been released by the BASE registration office as of
January 1, 2000. For the latest information, refer to
http://base.ioag.com.
Load type LoadTypeID corresponding
data type
------------------------------------------------------------------
total used general 0x0001 DWORD
delta used general 0x0002 DWORD
average used general 0x0003 DWORD
percent of usage 0x0004 DWORD
total used traffic in octets 0x0005 DWORD
delta used traffic in octets 0x0006 DWORD
total resource usage in octets 0x0007 DWORD
delta resource usage in octets 0x0008 DWORD
average resource usage in octets 0x0009 DWORD
number used per second 0x000A DWORD
average used bandwidth in
bits per second 0x000B DWORD
maximum used bandwidth in
bits per second 0x000C DWORD
minimum used bandwidth in
bits per second 0x000D DWORD
total used time in seconds 0x000E DWORD
9.3. Peer Types
Peer Type PeerTypeID Peer Type PeerTypeID
---------------------------------------------------------------
Billing engine 0x0000 Lotus Notes
Application
Monitor 0x000F
ASCII 0x0001 Time-Management 0x0010
Cisco IP-Accounting 0x0002 OS/390 SMS 0x0011
Cisco Net-Flow 0x0003 VSE PAR 0x0012
Teles CDR 0x0004 DNS 0x0013
Siemens Hicom CDR 0x0005 DHCP 0x0014
Windows
System Monitor 0x0006 Radius 0x0015
Linux System Monitor 0x0007 SNMP 0x0016
AIX System Monitor 0x0008 WINS 0x0017
SunOS System Monitor 0x0009 Microsoft IIS 4 0x0018
HPUX System Monitor 0x000A Microsoft IIS 5 0x0019
Oracle
Application Monitor 0x000B Apache 0x001A
Microsoft SQL
Application Monitor 0x000C Cisco Pix 0x001B
DB2 Application
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 63
INTERNET DRAFT BASE Protocol Specification April 2000
Monitor 0x000D Borderware
FireWall 1 0x001C
SAP
Application Monitor 0x000E
9.4. Message Types
Message Type Message Type
---------------------------------------------------------
OPENREQ 0x01 POLICYDELETERES 0x15
OPENRES 0x02 POLICYUPDATEREQ 0x16
CLOSE 0x03 POLICYUPDATERES 0x17
REGISTERREQ 0x04 POLICYSTARTREQ 0x18
REGISTERRES 0x05 POLICYSTARTRES 0x19
ACCOUNTADDREQ 0x06 POLICYSTOPREQ 0x1A
ACCOUNTADDRES 0x07 POLICYSTOPRES 0x1B
ACCOUNTDELREQ 0x08 POLICYRESETREQ 0x1C
ACCOUNTDELRES 0x09 POLICYRESETRES 0x1D
ACCOUNTCHANGEREQ 0x0A LIFSTARTREQ 0x1E
ACCOUNTCHANGERES 0x0B LIFSTARTRES 0x1F
ACCOUNTSUSPENDREQ 0x0C LIFSTOPREQ 0x20
ACCOUNTSUSPENDRES 0x0D LIFSTOPRES 0x21
ACCOUNTUNSUSPENDREQ 0x0E LIFDATA 0x22
ACCOUNTUNSUSPENDRES 0x0F SYNCREQ 0x23
ACCOUNTREQ 0x10 (not used) 0x24
ACCOUNTRES 0x11 SYNCDATA 0x25
POLICYADDREQ 0x12 OPENLNKREQ 0x26
POLICYADDRES 0x13 OPENLNKRES 0x27
POLICYDELETEREQ 0x14 CLOSELNK 0x28
9.5. Error codes
9.5.1. BASE protocol errors:
0 No error occurred
1 Open in progress
2 License key already in use
14 Protocol violation
15 An internal error occurred
Others Undefined
9.5.2. Application errors:
0 SUCCESS
1 ERROR
2 SHUTDOWN
9.6. Regular BASE Expressions
To allow not just for 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.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 64
INTERNET DRAFT BASE Protocol Specification April 2000
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:
9.6.1. Grammar
<base_re> ::= <expression> { <expression> }
| <base_re> '|' <base_re>
<expression> ::= <term>
| <term> '?'
| <term> '+'
| <term> '*'
| <term> '{' { <number> } ',' { <number> } '}'
| '!' <term>
| '^' <term>
| '$' <term>
<term> ::= <label>
| '(' <base_re> ')'
<number> ::= 0..65535
<label> ::= <symbol>
| '[' <range> { <range> } ']'
<range> ::= <symbol>
| <character> '-' <character>
<symbol> ::= '.'
| <character>
| '\' <metachar>
<character> ::= Any character except \|()[]{}-+*?.^$
<metachar> ::= '\' | '|' | '(' | ')' | '[' | ']' | '{' | '}'
| '-' | '+' | '?' | '*' | '.' | '^' | '$'
| 'd' | 'D' | 's' | 'S' | 'a' | 'A'
| 'w' <hexdigit> <hexdigit> <hexdigit> <hexdigit>
| 'b' <hexdigit> <hexdigit>
| 't' | 'n' | 'r'
<hexdigit> ::= 0..f
9.6.2. 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
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 65
INTERNET DRAFT BASE Protocol Specification April 2000
[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
^ requires the following term to be at the beginning of
the string
$ requires the following term to be at the end of the
string
{n,m} match the preceding regular expression a minimum number
of n times and a maximum of m times (0 through 65535
are allowed for n and m). 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 the regular expressions within and apply the
match to the set
\ 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]
\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_]
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 66
INTERNET DRAFT BASE Protocol Specification April 2000
\A matches any non-alphanumeric character; this is
equivalent to the class ![a-zA-Z0-9_]
\bnn matches the hex-code 0xnn with n in [0-9a-f]. \b
matches one byte with ASCII-code nn
\wnnmm matches the hex-code 0xnnmm 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
10. Security Considerations
Authentication and crypting will be part of the next version of
BASE.
11. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Mills, C., Hirsch G. and Ruth, G. "Internet Accounting
Background", RFC 1272, November 1991.
3. Reynolds, J., Postel, C., "Assigned Numbers", RFC 1700, October
1994.
4 Braden, R., Clark, D. Shenker, S., ½ Integrated Services in the
Internet Architecture: an Overview", RFC 1633, June 1994.
5 Mills, D.L., "Network Time Protocol (NTP)", RFC 958, September
1985.
6 Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
7 Aboba, B. and Lidyard, D., "The Accounting Data Interchange
Fofrmat (ADIF)", Internet Draft (Work in progress), draft-ietf-
roamops-actng ..
8 Brownlee, N., Mills, C., Ruth, G., "Traffic Flow Measurement:
Architecture", RFC 2722, October 1999.
9 Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720,
October 1999.
10 Handelman, S., Brownlee, N., Ruth, G., Stibler, S., "New
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 67
INTERNET DRAFT BASE Protocol Specification April 2000
Atribuites for Traffic Flow Measurement", RFC 2724, October 1999.
11 Case, J., Fedor, M., Schoffstall, M., Davin, J., "A simple
Network Management Protocol (SNMP)", RFC 1157, May 1990.
12 McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting
Information for ATM Networks", RFC 2512, February 1999.
12. Acknowledgments
The authors would like to thank Prof. Dr. Steigner (University of
Koblenz) and his team for many useful discussions. Furthermore we
would like to thank Angelika Modzden for the review and translation
of the original german BASE-Document and Jens Mozdzen for the
discussions about the protocol details.
Finally the authors would like to thank the BillingWare-team of
INTERNET ONLINE AG for the technical support and the fast
development of the BASE implementations.
13. Author's Addresses
Odo Maletzki
INTERNET ONLINE AG
Eupener Strasse 148
50933 Koeln
Germany
Phone: +49 (221) 2766-0
Email: Odo.Maletzki@ioag.com
Thilo Dieckmann
INTERNET ONLINE AG
Eupener Strasse 148
50933 Koeln
Germany
Phone: +49 (221) 2766-0
Email: Thilo.Dieckmann@ioag.com
Martin Grundmann
INTERNET ONLINE AG
Eupener Strasse 148
50933 Koeln
Germany
Phone: +49 (221) 2766-0
Email: Martin.Grundmann@ioag.com
14. Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 68
INTERNET DRAFT BASE Protocol Specification April 2000
are 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 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 as an "AS
IS" basis.
15. Expiration Date
This memo is filed as <draft-ioag-base-00.txt> and expires October
31, 2000.
Maletzki, Dieckmann, Grundmann Informational - October 31, 2000 69
