Network Working Group M. Day Internet-Draft Cisco Expires: September 2, 2001 D. Gilletti CacheFlow P. Rzewski Inktomi March 2, 2001 Content Internetworking Scenarios draft-day-cdnp-scenarios-03.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 September 2, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document sets forth several logical and detailed scenarios to be considered when evaluating systems and protocols for Content Internetworking. Day et. al. Expires September 2, 2001 [Page 1] Internet-Draft CDI Scenarios March 2001 Table of Contents 1. Introduction................................................ 3 2. Logical Internetworking Interfaces.......................... 3 2.1 Access Content Network...................................... 4 2.2 Publishing Content Network.................................. 4 2.3 Brokering Content Network................................... 4 3. Logical Internetworking Scenarios........................... 4 3.1 Expanding Existing Content Network Footprint................ 5 3.2 ACCOUNTING and REQUEST-ROUTING Across Multiple DISTIBUTING CONTENT NETWORKs............................................ 7 3.3 ACCOUNTING PEERING Across Multiple DISTRIBUTING CONTENT NETWORKs.................................................... 9 3.4 PUBLISHER peers w/multiple DISTRIBUTING CONTENT NETWORKs....10 4. Accounting..................................................11 4.1 Key Assumptions.............................................12 4.1.1 Content Has Value...........................................12 4.1.2 Distribution Has Value......................................12 4.2 Accounting Scenarios........................................13 4.2.1 The Cable Scenario..........................................13 4.2.2 The Telco Scenario..........................................13 4.2.3 The Ticket Scenario.........................................14 4.2.4 The Calling Card Scenario...................................14 5. Security Considerations.....................................14 6. Acknowledgements............................................14 References..................................................14 Authors' Addresses..........................................15 Full Copyright Statement....................................15 Day et. al. Expires September 2, 2001 [Page 2] Internet-Draft CDI Scenarios March 2001 1. Introduction This document presents several logical scenarios that are intended to describe potential Content Internetworking configurations. These logical scenarios describe how various entities may combine to provide a complete end-to-end solution. These scenarios answer two distinct needs: 1. To provide some concrete examples of what Content Internetworking is, and 2. To provide a basis for evaluating Content Internetworking proposals. Each of the logical internetworking scenarios gives an indication of how the various Content Internetworking systems can be combined. From [2] these systems are: 1. REQUEST-ROUTING PEERING SYSTEM 2. DISTRIBUTION PEERING SYSTEM 3. ACCOUNTING PEERING SYSTEM Some specific types of Content Networks are described whose internetworking interfaces may include only a subset of the functionality of the three systems. The internetworking scenarios presented in this document are also framed by the following concepts: 1. CONTENT Has Value 2. DISTRIBUTION Has Value 3. CLIENTS Have Value [Ed note: This is not expanded later. To be removed?] Scenarios that reference the above concepts are given within this document in an effort to describe some of the currently known business models. These descriptions are intended to provide guidelines for developing the requirements given in [3]. Terms in ALL CAPS are defined in [1]. 2. Logical Internetworking Interfaces A CDN is defined in [2] as having REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING interfaces. However, some participating networks may gravitate toward particular subsets of the Content Internetworking interfaces. Sample Content Networks that support these particular Day et. al. Expires September 2, 2001 [Page 3] Internet-Draft CDI Scenarios March 2001 subsets are described for easier reference in the further development of internetworking scenarios. 2.1 Access Content Network An Access Content Network (ACN) is a network that utilizes forward proxy caching as described in [2]. Because an ACN's CLIENTs are bound to a particular caching proxy in the ACN's network, REQUEST- ROUTING for these CLIENTs is statically defined by the ACN and is therefore out of the control of the ORIGIN. An ACN typically does not have direct relationships with PUBLISHERs. As a result, an ACN is likely to participate in "receive-only" DISTRIBUTION PEERING and ACCOUNTING PEERING. Also note that, because the caching proxies in a peered ACN are delivering content specifically on behalf of upstream ORIGINs, these caching proxies effectively become SURROGATEs in this context. 2.2 Publishing Content Network A Publishing Content Network (PCN) is an ORIGIN that has a NEGOTIATED RELATIONSHIP with several CONTENT NETWORKs. Because a PCN is the ORIGIN for a set of CONTENT, the PCN contains the A UTHORITATIVE REQUEST-ROUTING SYSTEM for that set of CONTENT. Because a PCN is the ORIGIN for a set of CONTENT, the PCN participates in "send-only" DISTRIBUTION PEERING (aka INJECTION), ACCOUNTING PEERING, and REQUEST-ROUTING PEERING. 2.3 Brokering Content Network A Brokering Content Network (BCN) is a network that does not operate its own surrogates or REQUEST-ROUTING systems. Instead, a BCN typically operates only CPGs as a service on behalf other Content Networks. A BCN may therefore be regarded as a "clearinghouse" for Content Internetworking information. For example, a BCN may choose to participate in DISTRIBUTION PEERING in order to aggregate CONTENT SIGNALs from several upstream sources into a single update stream for the benefit of downstream peers. A BCN may also choose to participate in ACCOUNTING PEERING in order to aggregate utilization data from several downstream networks into combined reports for upstream peers. Finally, a BCN may also choose to participate in REQUEST-ROUTING PEERING in order to aggregate REQUEST-ROUTING ADVERTISEMENTS from several sources into a single update stream for the benefit of other peers. 3. Logical Internetworking Scenarios This section provides several logical peering scenarios that may arise in Content Internetworking implementations. Day et. al. Expires September 2, 2001 [Page 4] Internet-Draft CDI Scenarios March 2001 3.1 Expanding Existing Content Network Footprint This scenario considers the case where two or more existing CONTENT NETWORKs wish to peer and exchange content in order to provide an increased scale and reach for their existing customers. It assumes that all of these CONTENT NETWORKs already provide REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will continue to provide these services to existing customers as well as offering them to their peers. In this scenario these CONTENT NETWORKs would be interconnected via a CONTENT PEERING GATEWAY which provides a REQUEST-ROUTING PEERING SYSTEM, a DISTRIBUTION PEERING SYSTEM, and an ACCOUNTING PEERING SYSTEM. The net result of this peering would be that a larger set of SURROGATES will now be available to the CLIENTs. FIGURE 1 shows three CONTENT NETWORKs which have peered to provide greater scale and reach to their existing customers. They are all participating in; DISTRIBUTION PEERING, REQUEST-ROUTING PEERING, and ACCOUNTING PEERING. As a result of these peering relationships it is assumed that: 1. CONTENT that has been INJECTed into any one of these CONTENT NETWORKs (ORIGIN CONTENT NETWORK) MAY be distributed into any peered DISTRIBUTING CONTENT NETWORK 2. Commands affecting the distribution of CONTENT MAY originate within the ORIGIN CONTENT NETWORK or MAY be issued within the DISTRIBUTING CONTENT NETWORK 3. Accounting information regarding CLIENT access and/or DISTRIBUTION actions will be made available to the ORIGIN CONTENT NETWORK by the DISTRIBUTING CONTENT NETWORK 4. The ORIGIN CONTENT NETWORK would provide this accounting information to the PUBLISHER based on existing Service Level Agreements (SLAs) 5. Requests by CLIENTS MAY be directed to SURROGATES within any of the peered CONTENT NETWORKs The decision of where to direct an individual CLIENT request MAY be dependent upon the DISTRIBUTION and REQUEST-ROUTING policies associated with the CONTENT being requested as well as the specific algorithms and methods used for directing these requests. It is also worthwhile to consider that any one of these peered CONTENT NETWORKs may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. Day et. al. Expires September 2, 2001 [Page 5] Internet-Draft CDI Scenarios March 2001 FIGURE 1 - Peering Existing CONTENT NETWORKs +--------------+ +--------------+ | CN A | | CN B | |..............| +---------+ +---------+ |..............+ | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ \^ \^ \^ ^/ ^/ ^/ | ^ v | \\ \\ \\ // // // v | +--------------+ \\ \\ \\ // // // +--------------+ | SURROGATES | \\ v\ v\ /v /v // | SURROGATES | +--------------+ \\+---------+// +--------------+ ^ | v| |v ^ | | | | CONTENT | | | | | | PEERING | | | | | | GATEWAY | | | | | | | | | | | +---------+ | | | | ^| ^| ^| | | | | || || || | | | | |v |v |v | | | | +--------------+ | | | | | CN C | | | | | |..............| | | | | | REQ-ROUTING | | | | | |..............| | | \ \ | DISTRIBUTION | / / \ \ |..............| / / \ \ | ACCOUNTING | / / \ \ |--------------| / / \ \ | ^ / / \ \ v | / / \ \ +--------------+ / / \ \ | SURROGATES | / / \ \ +--------------+ / / \ \ | ^ / / \ \ | | / / \ \ v | / / \ \ +---------+ / / \ \-->| CLIENTS |---/ / \----| |<---/ +---------+ NOTE: The above FIGURE 1 does not illustrate the CLIENT REQUEST path. It is assumed that the direction of CLIENT requests follows the Day et. al. Expires September 2, 2001 [Page 6] Internet-Draft CDI Scenarios March 2001 methodology given in [2] and that the end result is that the peered REQUEST-ROUTING SYSTEMs return the IP address of the SURROGATE deemed appropriate to honor the CLIENT's REQUEST. 3.2 ACCOUNTING and REQUEST-ROUTING Across Multiple DISTIBUTING CONTENT NETWORKs This scenario describes the case where a single entity (ORG A) performs ACCOUNTING and REQUEST-ROUTING functions but has no inherent DISTRIBUTION capabilities. This entity must therefore peer with one or more DISTRIBUTING CONTENT NETWORKs in order to provide a complete solution. A potential configuration which illustrates this concept is given in FIGURE 2. In the scenario shown in FIGURE 2, ORG A is responsible for collecting ACCOUNTING information from multiple CONTENT NETWORKs (CN A, and CN B) and providing a "clearing house"/reconciliation function as well as providing a REQUEST-ROUTING service across the peered CONTENT NETWORKs. In this scenario, CONTENT is injected into one of the peered CONTENT NETWORKs and its DISTRIBUTION between these peered CONTENT NETWORKs is controlled via the DISTRIBUTION PEERING SYSTEMs within the peered CPGs. The REQUEST-ROUTING system provided by ORG A is informed of the ability to serve a piece of CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING SYSTEMs within the peered CPGs. ORG A collects statistics and usage information via the ACCOUNTING PEERING SYSTEM and disseminates that information to its peers as appropriate. As illustrated in FIGURE 2, there may be multiple REQUEST-ROUTING systems employed within the peered CONTENT NETWORKs. If the REQUEST- ROUTING SYSTEM provided by ORG A is the AUTHORITATIVE REQUEST- ROUTING SYSTEM for a given CONTENT DATA UNIT this is not a problem. However, the individual CDNs may also provide the AUTHORITATIVE DIRECTION SYSTEM for some portion of its existing customers. In this case care must be taken to ensure that the tree structure remains intact (i.e. there is one and only one REQUEST-ROUTING tree for a given CONTENT object). Also, it should be noted that FIGURE 2 does not illustrate the fact that ACCOUNTING PEERING and REQUEST-ROUTING PEERING MAY also exist between CN A and CN B. ORG A could also play an active role in managing the DISTRIBUTION. In this case an additional DISTRIBUTION PEERING relationships are required. Day et. al. Expires September 2, 2001 [Page 7] Internet-Draft CDI Scenarios March 2001 FIGURE 2 - Accounting and Request-Routing Across Multiple CONTENT NETWORKSs +--------------+ | ORG A | |..............| +-----------+ | REQ-ROUTING |<===>| | |..............| | CONTENT | | ACCOUNTING |<===>| PEERING | +--------------+ | GATEWAY | | | +-----------+ ^| ^| ^| ^| +--------------+ // // \\ \\ +--------------+ | CN A | |v |v |v |v | CN B | |..............| +---------+ +---------+ |..............| | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| CLIENTS |-----/ / \------| |<-----/ +---------+ As in the previous diagram (FIGURE 1), the communication path(s) between the CLIENT and the REQUEST-ROUTING SYSTEM have been omitted in order to better illustrate the peering connections. It should be noted that FIGURE 2 also omits the (optional) DISTRIBUTION PEERING connection which MAY be implemented between ORG A and any or all of the peered CONTENT NETWORKs. It is also worthwhile to consider that any one of these peered entities may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. Day et. al. Expires September 2, 2001 [Page 8] Internet-Draft CDI Scenarios March 2001 3.3 ACCOUNTING PEERING Across Multiple DISTRIBUTING CONTENT NETWORKs This scenario describes the case where a single ACCOUNTING SYSTEM (ORG A) provides a settlement/clearing-house function and wishes to peer w/multiple DISTRIBUTING CDNs. For the purposes of this scenario it is not necessary to consider the specifics of REQUEST-ROUTING PEERING. In this scenario the entity which operates the ACCOUNTING SYSTEM would enter into ACCOUNTING PEERING relationships w/one or more DISTRIBUTING CDNs as shown in FIGURE 3. FIGURE 3 - Accounting Across Multiple CONTENT NETWORKs +--------------+ | ORG A | |..............| +-----------+ | ACCOUNTING |<===>| | +--------------+ | CONTENT | | PEERING | | GATEWAY | | | +-----------+ ^| ^| +--------------+ // \\ +--------------+ | CN A | |v |v | CN B | |..............| +---------+ +---------+ |..............| | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| CLIENTS |-----/ / \------| |<-----/ +---------+ In this scenario, the DISTRIBUTION of CONTENT and the direction of CLIENT REQUESTs are controlled via the DISTRIBUTION PEERING SYSTEMs and REQUEST-ROUTING PEERING SYSTEMs within the peered CPGs. These Day et. al. Expires September 2, 2001 [Page 9] Internet-Draft CDI Scenarios March 2001 systems MAY be decoupled from the ACCOUNTING or they may use information obtained via an optional ACCOUNTING PEERING relationship between CN A and CN B. As in the previous diagrams, the communication path(s) between the CLIENT and the REQUEST-ROUTING SYSTEM have been omitted in order to better illustrate the peering connections. It is also worthwhile to consider that any one of these peered entities may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. 3.4 PUBLISHER peers w/multiple DISTRIBUTING CONTENT NETWORKs This scenario, shown in FIGURE 4 describes the case where a PUBLISHER wishes to directly enter into peering relationships w/multiple DISTRIBUTING CONTENT NETWORKs. In this scenario the PUBLISHER would operate its own CPG and enter into; DISTRIBUTION PEERING, ACCOUNTING PEERING, and REQUEST-ROUTING peering with one or more DISTRIBUTING CONTENT NETWORKs. FIGURE 4 assumes that the PUBLISHER operates as the AUTHORITATIVE REQUEST-ROUTING SYSTEM for its CONTENT although it is possible that this function may be designated to one of the DISTRIBUTING CONTENT NETWORKs. If this delegation occurs then it is not necessary for the PUBLISHER to have a REQUEST-ROUTING PEERING relationship to the DISTRIBUTING CONTENT NETWORKs. It likely that a PUBLISHER may also wish to use a third party to perform ACCOUNTING and BILLING. In that case there is no need for an ACCOUNTING PEERING relationship between the PUBLISHER's CPG and those of the DISTRIBUTING CONTENT NETWORKs. Likewise, it is possible that the PUBLISHER may only be interested in obtaining additional control over the DISTRIBUTION of its CONTENT. In that case, the only peering relationship that would be required between the PUBLISHER's CPG and those of the DISTRIBUTING CONTENT NETWORKs would be a DISTRIBUTION PEERING relationship. As in the previous diagrams, the communication path(s) between the CLIENT and the REQUEST-ROUTING SYSTEM have been omitted in order to better illustrate the peering connections. It is also worthwhile to consider that any one of these peered entities may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. Day et. al. Expires September 2, 2001 [Page 10] Internet-Draft CDI Scenarios March 2001 FIGURE 4 - PUBLISHER Peers w/Multiple DISTRIBUTING CONTENT NETWORKs +--------------+ | PUBLISHER | |..............| +-----------+ | REQ-ROUTING |<=>| |<---\ |..............| | CONTENT |----\\ | DISTRIBUTION |<=>| PEERING | \\ |..............| | GATEWAY |--\ \\ | ACCOUNTING |<=>| |<-\\ \\ +--------------+ +-----------+ \\ \\ ^| ^| ^| ^| \\ || +--------------+ || || || \\ || || +--------------+ | CN A | |v |v |v \v |v |v | CN B | |..............| +---------+ +---------+ |..............| | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>| PEERING | | PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| CLIENTS |-----/ / \------| |<-----/ +---------+ 4. Accounting There are several concepts that are helpful to consider when attempting to model the various accounting scenarios that can be realized when peering CONTENT NETWORKs. The most fundamental of these is the assignment of value within the distribution exchange. In any distribution system, revenue will generally flow in the direction of value. In order to insure that this revenue flows accurately, it is necessary to provide accurate statistical and access related information to one or more BILLING or ACCOUNTING organizations. In general it can be assumed that accounting information originates within the DISTRIBUTING CONTENT NETWORKs and flows towards the BILLING/ACCOUNTING organizations. However it is entirely appropriate to consider that this data may flow through one Day et. al. Expires September 2, 2001 [Page 11] Internet-Draft CDI Scenarios March 2001 or more aggregation points. In fact the ability to aggregate statistical and access related information is essential to allow for scalability within the proposed solution. It should be noted that value exists at many points in a peered DISTRIBUTION system. To fully consider this problem one should assume that, in general, any element of the DISTRIBUTION system could have an assigned value associated with its use. This raises some obvious questions about settlement that are outside the scope of this document. A more detailed description of these requirements is contained within [3]. For the purposes of this effort it is sufficient to insure that the appropriate accounting data is capable of being transferred from the measurement point to the BILLING/ACCOUNTING system. 4.1 Key Assumptions The distribution of accounting information, like the distribution of content, is greatly affected by the following concepts. 4.1.1 Content Has Value This concept assumes that the content has intrinsic value and that the revenue (and ACCOUNTING information) flows from the consumer to the PUBLISHER. A consumer, as defined in this relationship, is the entity that consumes data. Therefore the consumer may be a CLIENT or a SURROGATE. An example of this concept would include services such as Video On Demand (VOD). 4.1.2 Distribution Has Value This concept describes the situation where the value is located within the CONTENT NETWORK service being provided. In this case the revenue as well as the statistical and access information flow toward the CONTENT NETWORK that provides the service. (NOTE: There may be other ACCOUNTING flows in addition to the one described.) When considering this case, it is a reasonable assumption to consider that the majority of the statistical and access information would be produced and consumed within a single CONTENT NETWORK's domain and is therefore not important to consider. However, it is not reasonable to assume that all such information is obtained in this manner. The latter is especially true when a third-party BILLING ORGANIZATION or complex peering arrangements are in place. An example of this case is where a service provider has an aggregated CLIENT population which is of sufficient interest to one or more PUBLISHERs. In this case the PUBLISHERs are willing to pay to access the CLIENTs of the service provider and revenue flows from the PUBLISHER to the service provider. Day et. al. Expires September 2, 2001 [Page 12] Internet-Draft CDI Scenarios March 2001 4.2 Accounting Scenarios There are four basic conceptual accounting scenarios that SHOULD be considered when describing the requirements for the peering of accounting events between peered distribution entities:[Editor's Note: Other models suitable for real-time provisioning may be added to this proposal over time.] o Flat Rate Accounting Scenario - (aka "The Cable Scenario) o Metered Accounting Scenario - (aka "The Telco Scenario") o Prepay Event Accounting Scenario - (aka "The Ticket Scenario") o Prepay Metered Accounting Scenario - (aka "The Calling Card Scenario") These scenarios are described in the following sections. 4.2.1 The Cable Scenario In this scenario there is a "subscription" fee associated with the reception of CONTENT. In its primary mode it consists of a CLIENT entering into a transaction, either directly with the PUBLISHER or through some third party, for the purposes of obtaining access to one or more CONTENT objects. Once the transaction has been approved the CLIENT receives an entitlement to access the requested CONTENT for the duration of the subscription interval. An extension to this scenario is the case where a given DISTRIBUTING CONTENT NETWORK enters into a redistribution agreement with a PUBLISHER. In this scenario, the scope of the transaction is between the PUBLISHER and the specific DISTRIBUTION CONTENT NETWORK. Once the transaction is successful, the DISTRIBUTION CONTENT NETWORK obtains the right to redistribute that content in some mutually agreed upon manner. The manner of redistribution can range from unlimited to highly restricted. The resultant accounting information for this scenario consists of a single transaction which is associated with a specific consumer or CLIENT. 4.2.2 The Telco Scenario This scenario associates a finite value with the access or consumption of one or more CONTENT objects and attempts to fully control and/or account for access to this CONTENT. The resultant accounting information for this scenario is a set of detailed or summary accounting records associated with a specific CLIENT. Day et. al. Expires September 2, 2001 [Page 13] Internet-Draft CDI Scenarios March 2001 4.2.3 The Ticket Scenario In this scenario the CLIENT obtains a ticket (or entitlement) in advance of accessing the CONTENT. This is accomplished by a transaction between the CLIENT and the PUBLISHER or their agent(s). The ticket is assumed to be a one-time entitlement which expires upon use. 4.2.4 The Calling Card Scenario In this scenario a CLIENT prepays and receives an entitlement to access a set of CONTENT objects up to some pre-specified value level. The total value of the entitlement is determined at the time of purchase and its value is decremented each time the CLIENT accesses the CONTENT or CONTENT NETWORK service. The amount of the decrement will be specific to the CONTENT or CONTENT NETWORK service being accessed. The CLIENT is able to continue accessing or consuming the CONTENT or CONTENT NETWORK service until the entitlement is fully depleted. 5. Security Considerations This document describes scenarios for use in evaluating Content Internetworking proposals. As such, it does not propose any solutions which might have security concerns. This document assumes that any peering solutions which are derived within CDI will be compliant with the trust model given in [4]. 6. Acknowledgements The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John Scharber (CacheFlow), and Nalin Mistry (Nortel). References [1] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking", draft-day-cdnp-model-05.txt (work in progress), March 2001, . [2] Green, M., Cain, B., Tomlinson, G., Thomas, S., and P. Rzewski, "Content Internetworking Architectural Overview", draft-green- cdnp-gen-arch-03.txt (work in progress), March 2001, . [3] Gilletti, D., Nair, R., Scharber, J., and J. Guha, "CDN-I Internetworking Authentication, Authorization, and Accounting Day et. al. Expires September 2, 2001 [Page 14] Internet-Draft CDI Scenarios March 2001 Requirements", draft-gilletti-cdnp-aaa-reqs-01.txt (work in progress), March 2001, . [4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000, . Authors' Addresses Mark S. Day Cisco Systems 135 Beaver Street Waltham, MA 02452 US Phone: +1 781 663 8310 EMail: markday@cisco.com Don Gilletti CacheFlow Inc. EMail: don@cacheflow.com Phil Rzewski Inktomi 4100 East Third Avenue MS FC1-4 Foster City, CA 94404 US Phone +1 650 653 2487 Email: philr@inktomi.com Full Copyright Statement Copyright (C) The Internet Society (2001). 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 Day et. al. Expires September 2, 2001 [Page 15] Internet-Draft CDI Scenarios March 2001 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. Day et. al. Expires September 2, 2001 [Page 16]