Billing with X.25 over TCP

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View



-------------------------------------
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.



--
+----------------------------------------------------------+
|            http://forums.cabling-design.com/             |
|              *** a better way to USENET ***              |
| no-spam Web and RSS interface to your favorite newsgroup |
|    comp.dcom.sys.cisco - 46248 messages and counting!    |
+----------------------------------------------------------+



Re: Billing with X.25 over TCP


On Fri, 10 Sep 2010 08:40:38 +0000, velia100_at_yahoo_dot_com@foo.com
(Vivian) wrote:

Quoted text here. Click to load it

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.
www.cisco.com/go/netflow

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?

--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Re: Billing with X.25 over TCP


vivian had written this in response to
http://forums.cabling-design.com/cisco/Re-Billing-with-X-25-over-TCP-47552-.htm
 :
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:

Quoted text here. Click to load it












-------------------------------------
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.



--
+----------------------------------------------------------+
|            http://forums.cabling-design.com/             |
|              *** a better way to USENET ***              |
| no-spam Web and RSS interface to your favorite newsgroup |
|    comp.dcom.sys.cisco - 46254 messages and counting!    |
+----------------------------------------------------------+



Re: Billing with X.25 over TCP


On Sun, 12 Sep 2010 20:04:59 +0000, velia100_at_yahoo_dot_com@foo.com
(vivian) wrote:

Quoted text here. Click to load it

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....

Quoted text here. Click to load it
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Re: Billing with X.25 over TCP


Quoted text here. Click to load it

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.


Site Timeline