Billing with X.25 over TCP

bill for TCP/IP traffic since that is what is crossing your network - pretty easy if all the traffic is XoT......

if the traffic appears at an application server, then measure it there.

if it just transits your network mixed with "other stuff", then you could try to pick out the XoT traffic, say by TCP protocol ID.

in that case you have to wonder why you think you have a justification to charge a premium for it......

the classic Cisco tool for picking out particular flows is to use netflow on the transit routers, then export the metadata to a server and process it there.

this has 2 basic problems

1. protocol IDs are just a convention - a customer can alter the socket used fairly easily to avoid your billing assumptions.
2. your billing might pick out traffic using the same socket which is not XoT.

more generally the billing will not be exact - the average packet size will alter the ratio of payload to application traffic and adjusting for that is not trivial.

so you need to have a way to resolve billing inaccuracies.

seriously though - 1 reason people move from X.25 to XoT is to avoid billing by traffic volume, and once you are moving IP, where is the reason to charge for the volume of 1 type of traffic?

vivian had written this in response to

: Thank you for your suggestions. You must be right it's not worth it and i suppose netflow is CPU intensive. Nevertheless there is a command like x25 charge where you can generate CDRs on a serial i/f with x25 encapsulation. I will investigate what i can do with its outcome and i will return on this topic. Kind regards!

Stephen wrote:

------------------------------------- Hello to you all! Can you suggest me a way of preserving volume-based charging for X.25 customers that migrate to a TCP/IP network over XOT tunnels. Thank you a lot, Vivian.

no - fairly painless on a software router (say a 28xx / 29xx / 38xx and so on).

the high end stuff implements netflow in hardware so effective no real overhead.

it can generate a lot of info to the servers though - an Internet feed with lots of users (so lots of flows) through a router can generate a few % of the overall traffic in telemetry info.

Doesnt sound much until you work out what that means to the servers with lots of 1G and 10G links in the netflow system....

NetFlow switching and reporting was carefully designed to avoid excessive CPU load on the router.

For sure the switching part succeeded. I expect that the repoting part did too.