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]