Individual-Submissions Odo Maletzki Internet Draft INTERNET ONLINE AG Document: 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 ::= { } | '|' ::= | '?' | '+' | '*' | '{' { } ',' { } '}' | '!' | '^' | '$' ::=