ISP billing - data collection, correlation, and billing
I went back a few years in the archives and found a few odd references, but not much discussion. I'm curious what some other approaches are to usage-based billing, both the practice of generating/correlating data and the billing itself. We bill based on use/95th percentile and our system is rudimentary on its best day. We use SNMP and interface descriptions to generate data and correlate it with customers. This works for the most part, but leaves a lot to be desired. Ours is one method, and I've seen others who use NetFlow data in a similar fashion, with the assumption that the NetFlow data is correlated either via IP address or source interface. Most of the systems I've seen are full-fledged CRM, billing, and OSS, which is a little overkill for us at the moment. I think we would have issues trying to integrate such a multi-headed beast into our organization at this time. What methods do you use to collect and correlate data? What systems, if any, do you use? I'm a little in the dark as the billing/OSS side of things is outside of my normal scope and would appreciate any recommendations. Thanks!
On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Sean Pedersen Sent: Friday, July 14, 2017 1:41 PM To: nanog@nanog.org Subject: ISP billing - data collection, correlation, and billing I went back a few years in the archives and found a few odd references, but not much discussion. I'm curious what some other approaches are to usage-based billing, both the practice of generating/correlating data and the billing itself. We bill based on use/95th percentile and our system is rudimentary on its best day. We use SNMP and interface descriptions to generate data and correlate it with customers. This works for the most part, but leaves a lot to be desired. Ours is one method, and I've seen others who use NetFlow data in a similar fashion, with the assumption that the NetFlow data is correlated either via IP address or source interface. Most of the systems I've seen are full-fledged CRM, billing, and OSS, which is a little overkill for us at the moment. I think we would have issues trying to integrate such a multi-headed beast into our organization at this time. What methods do you use to collect and correlate data? What systems, if any, do you use? I'm a little in the dark as the billing/OSS side of things is outside of my normal scope and would appreciate any recommendations. Thanks!
On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" <nanog-bounces@nanog.org on behalf of lguillory@reservetele.com> wrote:
On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though.
IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose. Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience. Lee
To be honest we don't do usage billing so I've never used it. I'd like to think it is since it uses a verification between the collector and source. Sent from my iPhone On Jul 15, 2017, at 3:47 AM, Lee Howard <lee@asgard.org<mailto:lee@asgard.org>> wrote: On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" <nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org> on behalf of lguillory@reservetele.com<mailto:lguillory@reservetele.com>> wrote: On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though. IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose. Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience. Lee Luke Guillory Vice President – Technology and Innovation [cid:image3856cc.JPG@d6320433.44ae2e87] <http://www.rtconline.com> Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On Sat, Jul 15, 2017 at 4:48 AM Lee Howard <lee@asgard.org> wrote:
Depending on the capability of the exporter, you don't need to export full
flow information. With Cisco's Flexible Netflow you can define the aggregation in the flow cache you are monitoring. You are not required to use a 7-tuple. An aggregation could be something basic like this: Source interface Destination interface Octets Packets This would give you SNMP equivalent for byte accounting on interfaces without requiring full flow accounting IF you're not forced to do sampling and IF you have flexible netflow. Another much more recent method around SNMP (sorry SNMP, I'm over you) is streaming telemetry, which is part of Netconf/YANG/OpenConfig. This is more of a push method for these yang data models(the relevent one here being snmp interfaces table). It already exists on some Juniper and Cisco platforms. Mike Krygeris
On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" <nanog-bounces@nanog.org on behalf of lguillory@reservetele.com> wrote:
On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though.
IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose.
Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience.
Lee
Flexible NetFlow is the best option for us. I haven’t seen a lot of products outside of open source that work with telemetry at the moment, and nothing that has billing functions. We’re far too lean to be able to rely on open source / devops at this point. That’s been a hard lesson to teach the company. It’s definitely on our internal roadmap, though. From: Michael Krygeris [mailto:me@krygerism.com] Sent: Sunday, July 16, 2017 9:35 AM To: Lee Howard <lee@asgard.org>; Luke Guillory <lguillory@reservetele.com>; Sean Pedersen <spedersen.lists@gmail.com>; nanog@nanog.org Subject: Re: ISP billing - data collection, correlation, and billing On Sat, Jul 15, 2017 at 4:48 AM Lee Howard <lee@asgard.org <mailto:lee@asgard.org> > wrote: Depending on the capability of the exporter, you don't need to export full flow information. With Cisco's Flexible Netflow you can define the aggregation in the flow cache you are monitoring. You are not required to use a 7-tuple. An aggregation could be something basic like this: Source interface Destination interface Octets Packets This would give you SNMP equivalent for byte accounting on interfaces without requiring full flow accounting IF you're not forced to do sampling and IF you have flexible netflow. Another much more recent method around SNMP (sorry SNMP, I'm over you) is streaming telemetry, which is part of Netconf/YANG/OpenConfig. This is more of a push method for these yang data models(the relevent one here being snmp interfaces table). It already exists on some Juniper and Cisco platforms. Mike Krygeris On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" <nanog-bounces@nanog.org <mailto:nanog-bounces@nanog.org> on behalf of lguillory@reservetele.com <mailto:lguillory@reservetele.com> > wrote:
On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though.
IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose. Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience. Lee
Hi, we use the same approach as you. When provisioning services they’re identified by a label in the interface description so data is collected and delivered to our billing systems. Gerardo El 14/07/17 13:43, "NANOG en nombre de Sean Pedersen" <nanog-bounces@nanog.org en nombre de spedersen.lists@gmail.com> escribió: I went back a few years in the archives and found a few odd references, but not much discussion. I'm curious what some other approaches are to usage-based billing, both the practice of generating/correlating data and the billing itself. We bill based on use/95th percentile and our system is rudimentary on its best day. We use SNMP and interface descriptions to generate data and correlate it with customers. This works for the most part, but leaves a lot to be desired. Ours is one method, and I've seen others who use NetFlow data in a similar fashion, with the assumption that the NetFlow data is correlated either via IP address or source interface. Most of the systems I've seen are full-fledged CRM, billing, and OSS, which is a little overkill for us at the moment. I think we would have issues trying to integrate such a multi-headed beast into our organization at this time. What methods do you use to collect and correlate data? What systems, if any, do you use? I'm a little in the dark as the billing/OSS side of things is outside of my normal scope and would appreciate any recommendations. Thanks! ________________________________ NOTA: La información de este correo es de propiedad exclusiva y confidencial. Este mensaje es sólo para el destinatario señalado, si usted no lo es, destrúyalo de inmediato. Ninguna información aquí contenida debe ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es responsabilidad de quien recibe este correo de asegurarse que esté libre de virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus empleados aceptan responsabilidad alguna. NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by AXTEL, S.A.B. de C.V, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their employees accept any responsibility.
participants (5)
-
Jose Gerardo Perales Soto -
Lee Howard -
Luke Guillory -
Michael Krygeris -
Sean Pedersen