Network Working Group M. Day
Internet-Draft Cisco
Expires: May 9, 2001 D. Gilletti
Entera
November 8, 2000
Content Distribution Network Peering Scenarios
draft-day-cdnp-scenarios-02.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 May 9, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document sets forth several logical and detailed scenarios to
be considered when evaluating systems and protocols for CDN peering.
Discussion List Information
This document and related documents are discussed on the cdn mailing
list. To join the list, send mail to cdn-request@ops.ietf.org. To
contribute to the discussion, send mail to cdn@ops.ietf.org. The
archives are at ftp://ops.ietf.org/pub/lists/cdn.*.
Day & Gilletti Expires May 9, 2001 [Page 1]
Internet-Draft CDNPS November 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Logical Peering Scenarios . . . . . . . . . . . . . . . . . 5
2.1 Expanding Existing CDN Footprint . . . . . . . . . . . . . . 5
2.2 ACCOUNTING and REQUEST DIRECTION Across Multiple
DISTIBUTING CDNs . . . . . . . . . . . . . . . . . . . . . . 7
2.3 ACCOUNTING PEERING Across Multiple DISTRIBUTING CDNs . . . . 9
2.4 PUBLISHER peers w/multiple DISTRIBUTING CDNs . . . . . . . . 10
3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Key Assumptions . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Content Has Value . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Distribution Has Value . . . . . . . . . . . . . . . . . . . 12
3.2 Accounting Scenarios . . . . . . . . . . . . . . . . . . . . 13
3.2.1 The Cable Scenario . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 The Telco Scenario . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 The Ticket Scenario . . . . . . . . . . . . . . . . . . . . 14
3.2.4 The Calling Card Scenario . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 15
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
Day & Gilletti Expires May 9, 2001 [Page 2]
Internet-Draft CDNPS November 2000
1. Introduction
This document presents several logical scenarios which are intended
to describe the potential configurations that can be realized when
peering CDNs. These logical scenarios describe how various entities
may combine to provide a complete CDN solution. These scenarios
answer two distinct needs:
1. To provide some concrete examples of what CDN peering is, and
2. To provide a basis for evaluating CDN peering proposals.
Each of the logical peering scenarios gives an indication of how the
various CDN peering systems can be combined. From [2] these peering
systems are:
1. DIRECTION PEERING SYSTEM
2. DISTRIBUTION PEERING SYSTEM
3. ACCOUNTING PEERING SYSTEM
The peering scenarios presented in this document are also framed by
the following concepts:
1. CONTENT Has Value
2. DISTRIBUTION Has Value
3. CLIENTS Have Value
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].
Day & Gilletti Expires May 9, 2001 [Page 3]
Internet-Draft CDNPS November 2000
2. Logical Peering Scenarios
This section provides several logical peering scenarios that may
arise in peered CDN implementations.
2.1 Expanding Existing CDN Footprint
This scenario considers the case where two or more existing CDNs
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 CDNs already provide REDIRECTION, 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 CDNs would be interconnected via a CDN
PEERING GATEWAY which provides a DIRECTION 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 CDNs which have peered to provide greater scale
and reach to their existing customers. They are all participating
in; DISTRIBUTION PEERING, DIRECTION 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 CDNs
(ORIGIN CDN) MAY be distributed into any peered DISTRIBUTING CDN
2. Commands affecting the distribution of CONTENT MAY originate
within the ORIGIN CDN or MAY be issued within the DISTRIBUTING
CDN
3. Accounting information regarding CLIENT access and/or
DISTRIBUTION actions will be made available to the ORIGIN CDN by
the DISTRIBUTING CDN
4. The ORIGIN CDN 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 CDNs
The decision of where to direct an individual CLIENT request MAY be
dependent upon the DISTRIBUTION and DIRECTION 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 CDNs
Day & Gilletti Expires May 9, 2001 [Page 4]
Internet-Draft CDNPS November 2000
may also have other peering arrangements which may or may not be
transitive to peering relationships created for the above purpose.
FIGURE 1 - Peering Existing CDNs
+--------------+ +--------------+
| CDN A | | CDN B |
|..............| +---------+ +---------+ |..............+
| DIRECTION |<=>| |<=>| |<=>| DIRECTION |
|..............| | CDN | | CDN | |..............|
| DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
|--------------| +---------+ +---------+ +--------------+
| ^ \^ \^ \^ ^/ ^/ ^/ | ^
v | \\ \\ \\ // // // v |
+--------------+ \\ \\ \\ // // // +--------------+
| SURROGATES | \\ v\ v\ /v /v // | SURROGATES |
+--------------+ \\+---------+// +--------------+
^ | v| |v ^ |
| | | CDN | | |
| | | PEERING | | |
| | | GATEWAY | | |
| | | | | |
| | +---------+ | |
| | ^| ^| ^| | |
| | || || || | |
| | |v |v |v | |
| | +--------------+ | |
| | | CDN C | | |
| | |..............| | |
| | | DIRECTION | | |
| | |..............| | |
\ \ | DISTRIBUTION | / /
\ \ |..............| / /
\ \ | ACCOUNTING | / /
\ \ |--------------| / /
\ \ | ^ / /
\ \ v | / /
\ \ +--------------+ / /
\ \ | SURROGATES | / /
\ \ +--------------+ / /
\ \ | ^ / /
\ \ | | / /
\ \ v | / /
\ \ +---------+ / /
\ \-->| CLIENTS |---/ /
\----| |<---/
+---------+
Day & Gilletti Expires May 9, 2001 [Page 5]
Internet-Draft CDNPS November 2000
NOTE:
The above FIGURE 1 does not illustrate the CLIENT REQUEST path. It
is assumed that the DIRECTION of CLIENT requests follows the
methodology given in [2] and that the end result is that the peered
DIRECTION SYSTEMs return the IP address of the SURROGATE deemed
appropriate to honor the CLIENT's REQUEST.
2.2 ACCOUNTING and REQUEST DIRECTION Across Multiple DISTIBUTING CDNs
This scenario describes the case where a single entity (ORG
A)performs ACCOUNTING and DIRECTION functions but has no inherent
DISTRIBUTION capabilities. This entity must therefore peer with one
or more DISTRIBUTING CDNs 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 CDNs (CDN A, and CDN
B) and providing a "clearing house"/reconciliation function as well
as providing a REQUEST DIRECTION service across the peered CDNs.
In this scenario, CONTENT is injected into one of the peered CDNs
and its DISTRIBUTION between these peered CDNs is controlled via the
DISTRIBUTION PEERING SYSTEMs within the peered CPGs. The REQUEST
DIRECTION system provided by ORG A is informed of the ability to
serve a piece of CONTENT from a particular CDN by the DIRECTION
PEERING 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 DIRECTION systems
employed within the peered CDNs. If the DIRECTION SYSTEM provided by
ORG A is the AUTHORITATIVE DIRECTION 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 insure that
the tree structure remains intact (i.e. there is one and only one
DIRECTION tree for a given CONTENT object).
Also, it should be noted that FIGURE 2 does not illustrate the fact
that ACCOUNTING PEERING and DIRECTION PEERING MAY also exist between
CDN A and CDN B.
ORG A could also play an active role in managing the DISTRIBUTION.
In this case an additional DISTRIBUTION PEERING relationships are
required.
Day & Gilletti Expires May 9, 2001 [Page 6]
Internet-Draft CDNPS November 2000
FIGURE 2 - Accounting and Request Direction Across Multiple CDNs
+--------------+
| ORG A |
|..............| +-----------+
| DIRECTION |<===>| |
|..............| | CDN |
| ACCOUNTING |<===>| PEERING |
+--------------+ | GATEWAY |
| |
+-----------+
^| ^| ^| ^|
+--------------+ // // \\ \\ +--------------+
| CDN A | |v |v |v |v | CDN B |
|..............| +---------+ +---------+ |..............|
| DIRECTION |<=>| | | |<=>| DIRECTION |
|..............| | CDN | | CDN | |..............|
| 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 DIRECTION 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 CDNs.
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 & Gilletti Expires May 9, 2001 [Page 7]
Internet-Draft CDNPS November 2000
2.3 ACCOUNTING PEERING Across Multiple DISTRIBUTING CDNs
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 DIRECTION
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 CDNs
+--------------+
| ORG A |
|..............| +-----------+
| ACCOUNTING |<===>| |
+--------------+ | CDN |
| PEERING |
| GATEWAY |
| |
+-----------+
^| ^|
+--------------+ // \\ +--------------+
| CDN A | |v |v | CDN B |
|..............| +---------+ +---------+ |..............|
| DIRECTION |<=>| |<=>| |<=>| DIRECTION |
|..............| | CDN | | CDN | |..............|
| DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
|--------------| +---------+ +---------+ +--------------+
| ^ | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
^ \ ^ /
\ \ / /
\ \ / /
\ \ / /
\ \ +---------+ / /
\ \---->| CLIENTS |-----/ /
\------| |<-----/
+---------+
Day & Gilletti Expires May 9, 2001 [Page 8]
Internet-Draft CDNPS November 2000
In this scenario, the DISTRIBUTION of CONTENT and the DIRECTION of
CLIENT REQUESTs are controlled via the DISTRIBUTION PEERING SYSTEMs
and REQUEST DIRECTION PEERING SYSTEMs within the peered CPGs. These
systems MAY be decoupled from the ACCOUNTING or they may use
information obtained via an optional ACCOUNTING PEERING relationship
between CDN A and CDN B.
As in the previous diagrams, the communication path(s) between the
CLIENT and the REQUEST DIRECTION 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.
2.4 PUBLISHER peers w/multiple DISTRIBUTING CDNs
This scenario, shown in FIGURE 4 describes the case where a
PUBLISHER wishes to directly enter into peering relationships
w/multiple DISTRIBUTING CDNs.
In this scenario the PUBLISHER would operate its own CPG and enter
into; DISTRIBUTION PEERING, ACCOUNTING PEERING, and REDIRECTION
peering with one or more DISTRIBUTING CDNs.
FIGURE 4 assumes that the PUBLISHER operates as the
FIRST-REDIRECTION SYSTEM for its CONTENT although it is possible
that this function may be designated to one of the DISTRIBUTING
CDNs. If this delegation occurs then it is not necessary for the
PUBLISHER to have an REQUEST DIRECTION PEERING relationship to the
DISTRIBUTING CDNs.
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 CDNs.
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
CDNs would be a DISTRIBUTION PEERING relationship.
As in the previous diagrams, the communication path(s) between the
CLIENT and the REQUEST DIRECTION SYSTEM have been omitted in order
to better illustrate the peering connections.
It is also worthwhile to consider that any one of these peered
Day & Gilletti Expires May 9, 2001 [Page 9]
Internet-Draft CDNPS November 2000
entities may also have other peering arrangements which may or may
not be transitive to peering relationships created for the above
purpose.
FIGURE 4 - PUBLISHER Peers w/Multiple DISTRIBUTING CDNs
+--------------+
| PUBLISHER |
|..............| +-----------+
| DIRECTION |<=>| |<---\
|..............| | CDN |----\\
| DISTRIBUTION |<=>| PEERING | \\
|..............| | GATEWAY |--\ \\
| ACCOUNTING |<=>| |<-\\ \\
+--------------+ +-----------+ \\ \\
^| ^| ^| ^| \\ ||
+--------------+ || || || \\ || || +--------------+
| CDN A | |v |v |v \v |v |v | CDN B |
|..............| +---------+ +---------+ |..............|
| DIRECTION |<=>| | | |<=>| DIRECTION |
|..............| | CDN | | CDN | |..............|
| DISTRIBUTION |<=>| PEERING | | PEERING |<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
|--------------| +---------+ +---------+ +--------------+
| ^ | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
^ \ ^ /
\ \ / /
\ \ / /
\ \ / /
\ \ +---------+ / /
\ \---->| CLIENTS |-----/ /
\------| |<-----/
+---------+
Day & Gilletti Expires May 9, 2001 [Page 10]
Internet-Draft CDNPS November 2000
3. Accounting
There are several concepts that are helpful to consider when
attempting to model the various accounting scenarios that can be
realized when peering CDNs. 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 CDNs and flows
towards the BILLING/ACCOUNTING organizations. However it is entirely
appropriate to consider that this data may flow through one 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.
3.1 Key Assumptions
The distribution of accounting information, like the distribution of
content, is greatly affected by the following concepts.
3.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 CONTENT PROVIDER. 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).
3.1.2 Distribution Has Value
This concept describes the situation where the value is located
Day & Gilletti Expires May 9, 2001 [Page 11]
Internet-Draft CDNPS November 2000
within the CDN service being provided. In this case the revenue as
well as the statistical and access information flow toward the CDN
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 the CDN service provider'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.
3.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.
3.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 CONTENT
PROVIDER 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
Day & Gilletti Expires May 9, 2001 [Page 12]
Internet-Draft CDNPS November 2000
CDN enters into a redistribution agreement with a CONTENT PROVIDER.
In this scenario, the scope of the transaction is between the
CONTENT PROVIDER and the specific DISTRIBUTION CDN. Once the
transaction is successful, the DISTRIBUTION CDN 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.
3.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.
3.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.
3.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 CDN service. The amount of the decrement
will be specific to the CONTENT or CDN service being accessed. The
CLIENT is able to continue accessing or consuming the CONTENT or CDN
service until the entitlement is fully depleted.
Day & Gilletti Expires May 9, 2001 [Page 13]
Internet-Draft CDNPS November 2000
4. Security Considerations
This document describes scenarios for use in evaluating CDN peering
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 the context of Content Alliance effort will be compliant with
the trust model given in [4].
Day & Gilletti Expires May 9, 2001 [Page 14]
Internet-Draft CDNPS November 2000
5. Conclusion
The set of scenarios contained within this document illustrate the
complete set of requirements which should be met in the design of
CDN peering system(s).
Day & Gilletti Expires May 9, 2001 [Page 15]
Internet-Draft CDNPS November 2000
6. Acknowledgements
The authors acknowledge the contributions and comments of Fred
Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (Entera), and John
Scharber (Entera).
Day & Gilletti Expires May 9, 2001 [Page 16]
Internet-Draft CDNPS November 2000
References
[1] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
draft-day-cdnp-model-02.txt (work in progress), November 2000,
<http://www.ietf.org/internet-drafts/draft-day-cdnp-model-02.txt>
.
[2] Green, M., Cain, B. and G. Tomlinson, "CDN Peering
Architectural Overview", draft-green-cdnp-gen-arch-02.txt (work
in progress), November 2000,
<http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-02.txt>
.
[3] Gilletti, D., Nair, R. and J. Scharber, "CDN Peering
Authentication, Authorization, and Accounting Requirements",
draft-gilletti-cdnp-aaa-reqs-00.txt (work in progress),
November 2000,
<http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aaa-reqs-00.txt>
.
[4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000,
<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
Entera, Inc.
40971 Encyclopedia Circle
Fremont, CA 94538
US
Phone: +1 510 770 5281
EMail: don@entera.com
Day & Gilletti Expires May 9, 2001 [Page 17]
Internet-Draft CDNPS November 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.
Day & Gilletti Expires May 9, 2001 [Page 18]