barns@gateway.mitre.org (02/05/90)
Archive-name: ddn-billing/26-Jan-90 Original-posting-by: barns@gateway.mitre.org Original-subject: billing for use; report announcement Archive-site: aelred-3.ie.org [192.48.115.36] Archive-directory: pub Archive-files: billing.ps.Z Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) I wrote a sizable paper on "enhanced" billing designs for the DDN, as I mentioned the last time that the topic of network usage billing came up here. At that time it was not publicly available, but it has since been released. You can obtain it in the form of a PostScript file (details below), and I have a small number of paper copies which I can mail if someone wants it and doesn't have a PostScript printer. It is a large document (~114 pages) and many parts are very DDN specific, but there is some treatment of general design issues too. Feel free to send me any comments if you so desire. The report can be obtained by anonymous FTP from host aelred-3.ie.org [192.48.115.36]. The uncompressed file is pub/billing.ps (710899 bytes) and the compressed version is pub/billing.ps.Z (260701 bytes). There is no ASCII-only version (sorry, but the pictures and more importantly, some tables that contain essential information, do not convert readily). Here are some comments on the discussion to this point: You may or may not need special identifiers at any or all layers for billing purposes. You don't know what you need until you have defined your objectives. Also, identification of a billable entity can be explicit or implicit. A charging system levies charges on one or more types of chargeable events. To do this, it must identify the occurrence of the event, measure it in some dimension (typically but not necessarily by simply counting it), and attribute it to some billable entity. If the chargeable event is a layer N event, then you need attribution information visible at layer N that maps to a billable entity. So, if transmitting (or receiving) an IP datagram is a chargeable event, you have to make the attribution information visible to an IP entity. Whether the normal basic IP header provides the needed information depends on your notion of a billable entity. If you only care about billing IP sources or destinations, you have enough EXPLICIT information in the IP header. If you want to bill end users, you have IMPLICIT information to do the attribution if and only if all end users have separate IP addresses. If you need to bill any multi-user systems, you do not have IMPLICIT information and need EXPLICIT information such as an IP option. Billing doesn't necessarily imply authentication. It implies attribution. Authentication is a mechanism you might use to improve the chances of explicit information used for attribution being "correct" relative to some external standard. A reasonable person might want this feature. However, there is no magic here. To authenticate the identification of something still requires that the thing be identified. In the IP DG billing example, an IP router still needs to know which authenticated billable entity identity goes with which DG. This seems to involve having some kind of recognizable element of the DG that maps to a billable entity. The form may be different (authentication token or certificate of some kind) but it has to be there, and it has to map. X.25 vs. Connectionless doesn't get at the real problems of cost attribution. Transport multiplexing on a Network connection is what gets us in trouble with Network layer billing. If you multiplex TP2 on X.25 as Europe does (or talks about), the X.25 switch doesn't know Fred's TP2 traffic from Frank's (or Fritz's from Franz's). The X.25 call accounting will duly kick out its one call accounting record, but that's no help to the system that originated the X.25 link if it has to bill the users separately. This is a Network/Transport mess, not a CO/CL mess. My typing time is up, for which you can all be grateful. Bill Barns / MITRE-Washington / barns@gateway.mitre.org