Accounting Server

Accounting and performance software share a number of similarities. The Accounting Server faces into the network and receives data records periodically generated by NEs. Often, the data records are emitted based on a preconfigured time. It is also possible for an Accounting Server to poll MIBs for specific data. Ultimately, accounting data is concerned with billing users for network resource consumption. As usual, our discussion concerns connection-oriented resources, such as:

• ATM/FR virtual circuits

• LSPs

Billing for connection-oriented networks can present a number of difficulties, such as when a connection is rerouted because of a path failure. The original connection is automatically torn down, and a new one is created to replace it (hopefully not losing any data). The Accounting Server must recognize that a new connection is in place and ensure that the billing details for both connections are aggregated. Similar issues affect multicast connections, such as a point-to-multipoint video transmission network ”a multiparty connection with billed clients potentially at each endpoint.

There is no reason why users can't be billed for the use of other objects such as:

• CPE routers

• Traffic landed on SP router ingress interfaces

Nodes from some vendors generate call detail records (CDR), as illustrated in Figure 6-6.

Figure 6-6. Accounting Server components .

Figure 6-6 illustrates a managed network with one LSP. Let's assume that the LSP traverses five NEs, each of which generates associated CDRs that pass into mediation. Typical details contained in CDRs are:

• Correlation ID: unique large integer for tying together the connection segments

• Originating date and time

• Call type: signaled LSP, ATM/FR PVC

• Call state: starting, in progress, terminated

• Ingress node

• Ingress interface

• Egress node

• Egress interface

• Cells /packets/ frames received, transported, and dropped

• Class of service

The purpose of this data is to characterize the network resource consumption made by the underlying connections. If the nodes do not generate such accounting data automatically, then the Accounting Server may have to poll the network for the requisite details.

We assume that CDRs are available and that they are presented to mediation in a proprietary format containing some or all of the above fields.

Mediation

Mediation is the process of analyzing the raw data generated by NEs to produce standard format billing details for downstream use by third-party applications (from organizations such as ACE*COMM). It is not necessary to use standard formats if the billing application is proprietary. However, standard formats have the merit of allowing different third-party applications to be swapped in as required. Mediation may contain two additional steps: aggregation and correlation (described next ).

Aggregation

This is the process by which separate CDRs are combined. An example is an ATM PVC that spans a number of NEs (or the rerouted connection example described above). A given virtual circuit has certain performance parameters of interest:

• Number of IP packets transported (if the circuit is an LSP)

• Number of cells transported per second (if the circuit is an ATM connection)

• Number of cells dropped due to excessive input traffic

• Average bandwidth used by the cell traffic

• Number of SLA contract violations

Aggregation merges related data records so that they are tied to one billing entity, such as an LSP or an ATM connection.

Correlation

Correlation is the process of combining multiple units of aggregated data with the details of the ultimate bill recipient, that is, one customer. Let's take an example of an enterprise that has a 5Mbps ATM link to a service provider with one virtual circuit joining the enterprise's CPE to the SP network. Aggregate data on this circuit is collected across the network and then correlated with the associated enterprise user for billing. This can support usage-based billing rather than a flat-rate model. In the usage-based model, the committed traffic dictates the price.

Clearly, aggregation and correlation may be performed in a single step, but we separate them here for clarity. The billing elements can be details such as:

• Number of cells sent to or received from the SP network

• Bandwidth used in transporting the data across the ATM link

These reflect a pay-as-you-go billing model. Correlated data can be saved into the database in readiness for reporting and bill generation.

Reports

Reports are the means by which end users can view the billing details. Examples of reports are:

• Utilization of objects, such as LSPs

• The average and peak numbers of IP packets transported by the LSP

• The bandwidth consumed

Reports may be viewed by the network operator and may be accessible to customers via the Web. Actual bills can be based on report content.