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,
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-model-
02.txt>.
[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,
<URL:http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-
arch-03.txt>.
[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,
<URL:http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-
aaa-reqs-01.txt>.
[4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000,
<URL:ftp://ftp.isi.edu/in-notes/rfc2975.txt>.
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]