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,
<ftp://ftp.isi.edu/in-notes/rfc2904.txt>.
[2] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000,
<ftp://ftp.isi.edu/in-notes/rfc2975.txt>.
[3] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements",
RFC 2977, October 2000,
<ftp://ftp.isi.edu/in-notes/rfc2977.txt>.
[4] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
draft-day-cdnp-model-03.txt, (work in progress), November 2000,
<http://www.ietf.org/internet-drafts/draft-day-cdnp-model-03.txt>
.
[5] Day, M. and D. Gilletti, "CDN Peering Scenarios",
draft-day-cdnp-scenarios-02.txt, (work in progress), November
2000,
<http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt>
.
[6] Green, M., Cain, B. and G. Tomlinson, "CDN Peering
Architectural Overview", draft-green-cdnp-framework-00.txt,
(work in progress), September 2000,
<http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-02.txt>
.
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]