Network Working Group D. Gilletti Internet-Draft Entera Expires: March 2, 2001 R. Nair Cisco J. Scharber Entera September 2000 CDN Peering Authentication, Authorization, and Accounting Requirements draft-gilletti-cdnp-aaa-reqs-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract In developing a solution for CDN peering it is necessary to define and accommodate requirements for Authentication, Authorization, and Accounting. Since the Authentication, Authorization, and Accounting (AAA) working group is already focused on defining these requirements, this document attempts to leverage that work. It contains the requirements that would have to be supported by a AAA service to formulate a solution for CDN peering. Gilletti, et. al. Expires March 2, 2001 [Page 1] Internet-Draft CDNP.AAA September 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. A Transaction Model . . . . . . . . . . . . . . . . . . . . . 6 4. Accounting Messaging . . . . . . . . . . . . . . . . . . . . . 8 4.1 Client Identification . . . . . . . . . . . . . . . . . . . . 8 4.2 Pricing Message . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Multiple Compensation . . . . . . . . . . . . . . . . . . . . 9 4.4 Global Naming . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Accounting Issues . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Log Collection Issues . . . . . . . . . . . . . . . . . . . . 10 5.2 Filtering Content Records . . . . . . . . . . . . . . . . . . 10 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 Gilletti, et. al. Expires March 2, 2001 [Page 2] Internet-Draft CDNP.AAA September 2000 1. Introduction The initial model for the World Wide Web (WWW) was based on clients interacting with origin servers to request and receive content or services. As the Web increased in scale this model proved unwieldy for several reasons and resulted in current industry efforts to build and operate Content Distribution Networks or CDNs. The overall purpose of these CDNs is to create a scalable service that can meet aggregate client demand while improving the performance and quality of delivery. With increased demand for CDN services a need has been generated for a mechanism for interconnecting or peering these systems. A typical CDN has relationships with publishers and provides them with accounting and access related information. This information is typically provided in the form of aggregate or detailed log files. In addition, these CDNs typically collect accounting information to aid in operation, billing and SLA verification. Since all accounting data is collected within the CDN's administrative domain there is no requirement for generalized systems or protocols. Peering or interconnecting these CDNs introduces the need to obtain similar accounting data from a foreign domain. This requirement means that customers of a peered CDN service (publishers, clients, and CDNs) must now have a generalized or standard means of obtaining accounting information to support current as well as planned business models. For example, the desire to implement business models such as "Pay Per View" may require that there exist a mechanism for authenticating and authorizing clients at a delivery point that lies in a foreign domain. This document along with [4],[5], and [6] outline requirements to be satisfied in order to develop a mechanism for interconnecting or peering CDNs. The intent of this set of documents is to provide structure and guidelines for the evaluation of proposed solutions. This document is focused on describing requirements for the Accounting Peering System as described in [6] This document frames the requirements for the Accounting Peering System against the ongoing work of the AAA working group. This was done because the authors realized that considerable effort has already been expended in identifying inter-domain trust models and accounting requirements within that working group. Therefore, a conscious decision has been made to leverage that existing body of work before making additional proposals. As such, this document relies heavily on RFC 2904[1], RFC 2975[2], and RFC 2977[3]. Gilletti, et. al. Expires March 2, 2001 [Page 3] Internet-Draft CDNP.AAA September 2000 Since the concentration of this effort is to determine the requirements for CDN peering, the accounting requirements within an individual CDN are largely ignored within this document. Gilletti, et. al. Expires March 2, 2001 [Page 4] Internet-Draft CDNP.AAA September 2000 2. Terminology This section introduces new terminology not already defined in RFC 2975[2], RFC 2977[3], or [4]. CDN Service: An action that is directly or indirectly related to the act of moving content from publisher to consumer. Customer: A billable entity (typically a publisher, client or peered CDN) that agrees to exchange compensation for a CDN Service. Entitlement: A right to access a given CDN Service or content object typically provided to a customer by a provider. Flat Rate: Indicates there is no limit on the amount of CDN Service that a customer can consume during a Period. Percentile: Indicates that a CDN Service will be billed at a rate that is based on a multiplier (Usage Rate) times the Usage during the Period. Period: The duration for which the Usage counter or Entitlement is active. Provider: An entity that offers a CDN Service in exchange for Compensation. Unit Of Measure (UOM): Indicates how Usage should be tracked (i.e. minutes, seconds, bytes, etc). Usage: A counter that measures the access or use of a CDN Service by the Customer. Usage Rate: A per-unit cost associated with the Usage of a CDN Service. Tiered: Indicates the existence of a schedule against which Usage of a given CDN Service is tracked and billed. Gilletti, et. al. Expires March 2, 2001 [Page 5] Internet-Draft CDNP.AAA September 2000 3. A Transaction Model This section describes a transaction model that SHOULD be considered when deriving the Accounting Peering System for a peered CDN model. There are four separate components required to create a flexible accounting transaction model for a Content Distribution Network (CDN); 1. Method 2. Establishment 3. Measurement 4. Payment. A Method is used to define the Unit Of Measure (UOM), algorithm and period used to calculate usage fee for a billable event. The algorithm indicates how the UOM should be applied. Primitive algorithm types include; Flat Rate, Tiered, and Percentile although more complex applications may be constructed. The period specifies the duration for which the method is valid. A method may be applied on a per unit basis or a method may also be applied over a time periods such as a day or a month. A transaction is a customer initiated action requesting access to a specific CDN service being offered by the provider. A CDN service has a specified method for accounting purposes. The Establishment system ensures that the requestor is authorized and includes the appropriate state and method to allow accurate measurement for the current request. The establishment system will communicate with the accounting system to determine the state information that is required and could include such information as entitlements. The establishment system also ensures that Digital Rights of a requestor are consistent with its entitlements. The Measurement system provides a means of tracking and reporting utilization or accounting events back to an accounting system. The measurement system may also aggregate responses to the accounting system based on the method applied to a given request and the state information returned from the establishment system. The accounting system provides for real time or offline processing of accounting events and tracks the user, state and method information that are applied to a specified transaction type. The payment system allows for the definition of user, CDN service Gilletti, et. al. Expires March 2, 2001 [Page 6] Internet-Draft CDNP.AAA September 2000 records. Gilletti, et. al. Expires March 2, 2001 [Page 7] Internet-Draft CDNP.AAA September 2000 4. Accounting Messaging An expression of consumption consists of a collection/sequence of attributes which consist of identifiers, measures, and counters. The attributes serve to answer the who, what, where, and perhaps why of these elements of usage or acts of consumption. For the CDN peering/interconnection scenario, it is important to construct the expressions/acts of consumption such that there is no dispute and ambiguity in meaning between parties producing and receiving these expressions. In each act of consumption, there is a minimum set of attributes in which an act/expression of consumption/usage is considered "complete and undisputable" and therefore able to be rated and billed. In addition, there are various "modalities of usage" - session, resource-consumption, transaction/event, and/or a combination of the above. This is not to be confused by the "modalities of billing" such as pre-paid, post-paid, flat-rate, time-of-day, tiered, etc. On a further note, it is also important to keep in the background that the cost of metering/billing for an act of consumption should not "cost" more than the value of the consumption. This will help to keep perspective on the granularity of details/attributes required to meter the usage and the associated cost/benefit ratios. 4.1 Client Identification Since the customer represented in a Content Distribution Network Transaction can represent various roles and or organizations it will need to be defined in a flexible way, that not only includes the IP address, but can also be defined in terms of Dynamic Address Identifiers like DHCP host names, or User Ids for certain services, like Yahoo! or AOL user IDs email Addresses. Since the customer may in fact be an organization (and therefore represent multiple clients) there should also be a means for identifying these groups of clients and aggregating the transactions associated with them. 4.2 Pricing Message There should be, as a part of the messaging protocols, a message that allows a client to request "pricing" information to a CDN. These messages could be used to determine how to route a particular set of content to a destination or destinations while calculating the least-expensive path. The accounting system SHOULD be capable of generating these prices on real-time when requested. Gilletti, et. al. Expires March 2, 2001 [Page 8] Internet-Draft CDNP.AAA September 2000 4.3 Multiple Compensation The Peers need to agree on the different ways to compensate the participants in an specific content transfer. For example, there can be a publisher paying a CDN to distribute certain content, and that CDN can be paying to another CDN to redistribute part of it. In that scenario, they have to negotiate between themselves so that the publisher doesn't have to worry about the second level of interaction. It is the job of the first CDN to figure the compensation of the second one. A mechanism needs to be put in place in order to specify to the billing system how everybody in the value-chain is compensated. This would be similar to the peering taking place on the Telco world: If somebody does an international phone call using Sprint, they would just pay that carrier for the whole value, and then Sprint would figure out how to compensate the foreign carriers that completed the transfer. 4.4 Global Naming In a distributed environment, a universal way of naming the customer MAY be required, so that any member or participant of the CDN federation can be identified. Likewise, it is also useful to consider a method for universally naming an specific content. For example, a specific Movie or Song might need to be named in the same way in all of the different points of the federation, independently of the domain that is serving it. This SHOULD follow a standard that can be interpreted by every member of the federation. Gilletti, et. al. Expires March 2, 2001 [Page 9] Internet-Draft CDNP.AAA September 2000 5. Accounting Issues This section lists some additional issues that SHOULD be considered in order to have a complete solution for accounting across peered CDNs. 5.1 Log Collection Issues In a Layer 3 network, the most granular entity is a flow whereas in a layer 5 network, the most granular entity is a content request. Observations have shown that many web sites will use a single TCP connection for upwards of 20 content requests. This would imply that a simple log at the content level would result in at least 20 times the log volume of a layer 3 log. Moreover, at the CDN level the problem becomes worse because we could be required to transmit logs from all the CDN nodes back to the billing organization or publisher. The issue here is not simply one of available bandwidth for transmission. Rather, it is the problem of processing large volumes of logs. Thus, it becomes important to aggregate at the granularity of billable events whose definition is perhaps left open. One way to reduce this information is to be able to aggregate the logs by Domain Names or URL-sets (i.e., wildcards or ranges) and transport these aggregates across the CDNs. It would be extremely advantageous to implement the ability for involved parties to define, via an open interface, the billable events that the CDN would like to use, (i.e., Domain Name, URL-set, etc). This interface SHOULD have an XML vocabulary that is used to describe these events. Solutions SHOULD allow the aggregation to be performed at the Content Delivery Nodes, so that the distribution system need only deal with the transport of this aggregated information among the peering CDNs. It is worth noting that there are many events which aren't easy to represent in standard log formats. These include things such as QoS delivery to consumer, content mixing, target ad insertion and other value added services. 5.2 Filtering Content Records Filtering Content Records: The Content Records should be able to be filtered by any arbitrary Content Identifier, including Time and Volume in the instrumentation source, so that the billing system can Gilletti, et. al. Expires March 2, 2001 [Page 10] Internet-Draft CDNP.AAA September 2000 deal with issues of scalability and privacy. For example, some countries forbid obtaining information about the end users. Gilletti, et. al. Expires March 2, 2001 [Page 11] Internet-Draft CDNP.AAA September 2000 6. Recommendations [Editor's Note: This section is here only to record some ideas that need to be discussed while this specification is being progressed.] One means of accommodating these types of services is to build off of the ongoing work of the IETF AAA working group [2]. At present this work is centered on the DIAMETER framework and protocol suite for both provisioning and accounting. Early observations indicate that DIAMETER has several characteristics that are desirable for consideration in fulfilling these accounting requirements. The high point characteristics are that it: Has a model that supports either direct aggregation to home provider 3rd party brokering. Has well developed security and trust relationships. Supports standardized, extensible accounting record format. Is generally extensible via object oriented techniques. The general model of extending DIAMETER is to define required extensions to the protocol much like one would do to an abstract base class in C++ via base class and subclassing. Although its a bit premature to fully assess the suitability of DIAMETER to meet these requirements, early observations indicate that it sets forth a reasonable framework from which to develop a base model for this effort. Early observations have also identified the following issues with the model that will likely create a need for the following extensions to the base framework: 1. DIAMETER works on a request-by-request basis like pay-per-view. While this model is okay for some applications, it will have to be extended to support cases where a CDN pays at a larger granularity (e.g., by a million content hits) and then resells to its users or another CDN. This would apply to cases where a CDN subscribes to a peered billing organization or pays for distribution in a peering CDN. Existing DIAMETER mechanisms could be used for pay-per-view content inside a CDN but may need a higher level protocol across CDNs for aggregate content programming. This protocol SHOULD co-exist with DIAMETER message proxying. It can borrow message routing models from DIAMETER (e.g. realm-based routing). 2. DIAMETER uses end-to-end security. This may not work well across Gilletti, et. al. Expires March 2, 2001 [Page 12] Internet-Draft CDNP.AAA September 2000 CDN boundaries. As previously discussed, it may be necessary to be flexible about the definition of the "end" to be the CDN boundary. This will be consistent with the need for CDNs to serve as a content provisioning entity and makes it possible to aggregate request traffic. 3. DIAMETER needs to be extended with AVPs specific to web-based billable events. More detailed analysis needs to be undertaken before these conclusions can be validated. Gilletti, et. al. Expires March 2, 2001 [Page 13] Internet-Draft CDNP.AAA September 2000 7. Security Considerations This document assumes that the solutions suggested within this document will be compliant with the trust model given in RFC 2904[1]. Gilletti, et. al. Expires March 2, 2001 [Page 14] Internet-Draft CDNP.AAA September 2000 8. Conclusion There is a considerable amount of work remaining in defining the accounting requirements and relationships. As such, the authors welcome additional input from interested parties. Gilletti, et. al. Expires March 2, 2001 [Page 15] Internet-Draft CDNP.AAA September 2000 9. Acknowledgements The authors acknowledge the contributions and comments of Brad Cain (Mirror Image), Mark Day (Cisco), Fred Douglis (AT&T), John Martin (Network Appliance), Doug Potter (Cisco), Oliver Spatscheck (AT&T), Gary Tomlinson (Entera), and Jay Guha (Apogee Networks). Gilletti, et. al. Expires March 2, 2001 [Page 16] Internet-Draft CDNP.AAA September 2000 References [1] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000, . [2] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000, . [3] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000, . [4] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering", draft-day-cdnp-model-03.txt, (work in progress), November 2000, . [5] Day, M. and D. Gilletti, "CDN Peering Scenarios", draft-day-cdnp-scenarios-02.txt, (work in progress), November 2000, . [6] Green, M., Cain, B. and G. Tomlinson, "CDN Peering Architectural Overview", draft-green-cdnp-framework-00.txt, (work in progress), September 2000, . Authors' Addresses Don Gilletti Entera, Inc. 40971 Encyclopedia Circle Fremont, CA 94538 US Phone: +1 510 770 5281 EMail: don@entera.com Gilletti, et. al. Expires March 2, 2001 [Page 17] Internet-Draft CDNP.AAA September 2000 Raj Nair Cisco Systems 50 Nagog Park Acton, MA 01720 US Phone: +1 978 206 3029 EMail: rnair@cisco.com John Scharber Entera, Inc. 40971 Encyclopedia Circle Fremont, CA 94538 US Phone: +1 510 770 5201 EMail: john@entera.com Gilletti, et. al. Expires March 2, 2001 [Page 18] Internet-Draft CDNP.AAA September 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Gilletti, et. al. Expires March 2, 2001 [Page 19]