draft-ietf-cdi-scenarios-01.txt   rfc3570.txt 
Network Working Group P. Rzewski Network Working Group P. Rzewski
Internet-Draft Inktomi Request for Comments: 3570 Media Publisher, Inc.
Expires: October 24, 2002 M. Day Category: Informational M. Day
Cisco Cisco
D. Gilletti D. Gilletti
CacheFlow
April 24, 2002
Content Internetworking (CDI) Scenarios Content Internetworking (CDI) Scenarios
draft-ietf-cdi-scenarios-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 October 24, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
In describing content internetworking as a technology targeted for In describing content internetworking as a technology targeted for
use in production networks, it's useful to provide examples of the use in production networks, it is useful to provide examples of the
sequence of events that may occur when two content networks decide sequence of events that may occur when two content networks decide to
to interconnect. The scenarios presented here seek to provide some interconnect. The scenarios presented here seek to provide some
concrete examples of what content internetworking is, and also to concrete examples of what content internetworking is, and also to
provide a basis for evaluating content internetworking proposals. provide a basis for evaluating content internetworking proposals.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................2
1.1 Terminology....................................................3 1.1. Terminology..............................................3
2. Special Cases of Content Networks..............................3 2. Special Cases of Content Networks..............................3
2.1 Publishing Content Network.....................................4 2.1. Publishing Content Network...............................3
2.2 Brokering Content Network......................................4 2.2. Brokering Content Network................................3
2.3 Local Request-Routing Content Network..........................4 2.3. Local Request-Routing Content Network....................4
3. Content Internetworking Arrangements...........................5 3. Content Internetworking Arrangements...........................5
4. Content Internetworking Scenarios..............................6 4. Content Internetworking Scenarios..............................5
4.1 General Content Internetworking................................6 4.1. General Content Internetworking..........................6
4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING 4.2. BCN providing ACCOUNTING INTERNETWORKING and
INTERNETWORKING................................................9 REQUEST-ROUTING INTERNETWORKING..........................9
4.3 BCN providing ACCOUNTING INTERNETWORKING......................11 4.3. BCN providing ACCOUNTING INTERNETWORKING................11
4.4 PCN ENLISTS multiple CNs......................................12 4.4. PCN ENLISTS multiple CNs................................12
4.5 Multiple CNs ENLIST LCN.......................................13 4.5. Multiple CNs ENLIST LCN.................................13
5. Security Considerations.......................................15 5. Security Considerations.......................................15
6. Acknowledgements..............................................15 5.1. Threats to Content Internetworking......................15
References....................................................15 5.1.1. Threats to the CLIENT.............................15
Authors' Addresses............................................16 5.1.2. Threats to the PUBLISHER..........................17
Full Copyright Statement......................................16 5.1.3. Threats to a CN...................................17
6. Acknowledgements..............................................18
7. References....................................................18
8. Authors' Addresses............................................19
9. Full Copyright Statement......................................20
1. Introduction 1. Introduction
In [1], the concept of a "content network" is introduced and In [1], the concept of a "content network" is introduced and
described. In addition to describing some general types of content described. In addition to describing some general types of content
networks, it also describes motivations for allowing content networks, it also describes motivations for allowing content networks
networks to interconnect (defined as "content internetworking"). to interconnect (defined as "content internetworking").
In describing content internetworking as a technology targeted for In describing content internetworking as a technology targeted for
use in production networks, it's useful to provide examples of the use in production networks, it's useful to provide examples of the
sequence of events that may occur when two content networks decide sequence of events that may occur when two content networks decide to
to interconnect. Naturally, different types of content networks may interconnect. Naturally, different types of content networks may be
be created due to different business motivations, and so many created due to different business motivations, and so many
combinations are likely. combinations are likely.
This document first provides detailed examples of special cases of This document first provides detailed examples of special cases of
content networks that are specifically designed to participate in content networks that are specifically designed to participate in
content internetworking (Section 2). We then discuss the steps that content internetworking (Section 2). We then discuss the steps that
would be taken in order to "bring up" or "tear down" a content would be taken in order to "bring up" or "tear down" a content
internetworking arrangement (Section 3). Next we provide some internetworking arrangement (Section 3). Next we provide some
detailed examples of how content networks (such as those from detailed examples of how content networks (such as those from Section
Section 2) could interconnect (Section 4). Finally, we describe any 2) could interconnect (Section 4). Finally, we describe any security
security considerations that arise specifically from the examples considerations that arise specifically from the examples presented
presented here (Section 5). here (Section 5).
The scenarios presented here answer two distinct needs: The scenarios presented here answer two distinct needs:
1. To provide some concrete examples of what content 1. To provide some concrete examples of what content internetworking
internetworking is, and is, and
2. To provide a basis for evaluating content internetworking 2. To provide a basis for evaluating content internetworking
proposals. proposals.
For details on the architectural framework used in the development A number of content internetworking systems have been implemented,
of actual content internetworking protocols and interfaces, refer to but there are few published descriptions. One such description is
[2]. For specific examples of systems where content internetworking [2].
has been implemented, refer to [5].
1.1 Terminology 1.1. Terminology
Terms in ALL CAPS are defined in [1]. Terms in ALL CAPS are defined in [1] except for the following terms
defined below in this document: PCN, BCN, and LCN. Additionally, the
term SLA is used as an abbreviation for Service Level Agreement.
2. Special Cases of Content Networks 2. Special Cases of Content Networks
A CN is defined in [2] as having REQUEST-ROUTING, DISTRIBUTION, and A CN may have REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING
ACCOUNTING interfaces. However, some participating networks may interfaces. However, some participating networks may gravitate
gravitate toward particular subsets of the CONTENT INTERNETWORKING toward particular subsets of the CONTENT INTERNETWORKING interfaces.
interfaces. Others may be seen differently in terms of how they Others may be seen differently in terms of how they relate to their
relate to their CLIENT bases. This section describes these refined CLIENT bases. This section describes these refined cases of the
cases of the general CN case so they may be available for easier general CN case so they may be available for easier reference in the
reference in the further development of CONTENT INTERNETWORKING further development of CONTENT INTERNETWORKING scenarios. The
scenarios. The special cases described are the Publishing Content special cases described are the Publishing Content Network, the
Network, the Brokering Content Network, and the Local Request- Brokering Content Network, and the Local Request-Routing Content
Routing Content Network. Network.
2.1 Publishing Content Network 2.1. Publishing Content Network
A Publishing Content Network (PCN), maintained by a PUBLISHER, A Publishing Content Network (PCN), maintained by a PUBLISHER,
contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or more
more CNs. A PCN may contain SURROGATES for the benefit of serving CNs. A PCN may contain SURROGATES for the benefit of serving some
some CONTENT REQUESTS locally, but does not intend to allow its CONTENT REQUESTS locally, but does not intend to allow its SURROGATES
SURROGATES to serve CONTENT on behalf of other PUBLISHERS. to serve CONTENT on behalf of other PUBLISHERS.
Several implications follow from knowing that a particular CN is a Several implications follow from knowing that a particular CN is a
PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING
SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the
PUBLISHER to determine the distribution of CONTENT REQUESTS among PUBLISHER to determine the distribution of CONTENT REQUESTS among
ENLISTED CNs. Second, it implies that the PCN need only participate ENLISTED CNs. Second, it implies that the PCN need only participate
in a subset of CONTENT INTERNETWORKING. For example, a PCN's in a subset of CONTENT INTERNETWORKING. For example, a PCN's
DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive
DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a
PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send
AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING
SYSTEM need only be able to receive ACCOUNTING data, it need not SYSTEM need only be able to receive ACCOUNTING data, it need not send
send it. it.
2.2 Brokering Content Network 2.2. Brokering Content Network
A Brokering Content Network (BCN) is a network that does not operate A Brokering Content Network (BCN) is a network that does not operate
its own SURROGATES. Instead, a BCN operates only CIGs as a service its own SURROGATES. Instead, a BCN operates only CIGs as a service
on behalf other CNs. A BCN may therefore be regarded as a on behalf other CNs. A BCN may therefore be regarded as a
"clearinghouse" for CONTENT INTERNETWORKING information. "clearinghouse" for CONTENT INTERNETWORKING information.
For example, a BCN may choose to participate in DISTRIBUTION For example, a BCN may choose to participate in DISTRIBUTION
INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to
aggregate ADVERTISEMENTS from one set of CNs into a single update aggregate ADVERTISEMENTS from one set of CNs into a single update
stream for the benefit of other CNs. To name a single specific stream for the benefit of other CNs. To name a single specific
example, a BCN could aggregate CONTENT SIGNALS from CNs that example, a BCN could aggregate CONTENT SIGNALS from CNs that
represent PUBLISHERS into a single update stream for the benefit of represent PUBLISHERS into a single update stream for the benefit of
CNs that contain SURROGATES. A BCN may also choose to participate in CNs that contain SURROGATES. A BCN may also choose to participate in
ACCOUNTING INTERNETWORKING in order to aggregate utilization data ACCOUNTING INTERNETWORKING in order to aggregate utilization data
from several CNs into combined reports for CNs that represent from several CNs into combined reports for CNs that represent
PUBLISHERS. PUBLISHERS.
This definition of a BCN implies that a BCN's CIGs would implement This definition of a BCN implies that a BCN's CIGs would implement
the sending and/or receiving of any combination of ADVERTISEMENTS the sending and/or receiving of any combination of ADVERTISEMENTS and
and ACCOUNTING data as is necessary to provide desired services to ACCOUNTING data as is necessary to provide desired services to other
other CONTENT NETWORKS. For example, if a BCN is only interested in CONTENT NETWORKS. For example, if a BCN is only interested in
aggregating ACCOUNTING data on behalf of other CNs, it would only aggregating ACCOUNTING data on behalf of other CNs, it would only
need to have an ACCOUNTING INTERNETWORKING interface on its CIGs. need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.
2.3 Local Request-Routing Content Network 2.3. Local Request-Routing Content Network
Another type of CN is the Local Request-Routing CONTENT NETWORK Another type of CN is the Local Request-Routing CONTENT NETWORK
(LCN). An LCN is defined as a type of network where CLIENTS' CONTENT (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT
REQUESTS are always handled by some local SERVER (such as a caching REQUESTS are always handled by some local SERVER (such as a caching
proxy [1]). In this context, "local" is taken to mean that both the proxy [1]). In this context, "local" is taken to mean that both the
CLIENT and SERVER are within the same administrative domain, and CLIENT and SERVER are within the same administrative domain, and
there is an administrative motivation for forcing the local mapping. there is an administrative motivation for forcing the local mapping.
This type of arrangement is common in enterprises where all CONTENT This type of arrangement is common in enterprises where all CONTENT
REQUESTS must be directed through a local SERVER for access control REQUESTS must be directed through a local SERVER for access control
purposes. purposes.
As implied by the name, the LCN creates an exception to the rule As implied by the name, the LCN creates an exception to the rule that
that there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a
particular item of CONTENT. By directing CONTENT REQUESTS through particular item of CONTENT. By directing CONTENT REQUESTS through
the local SERVER, CONTENT RESPONSES may be given to CLIENTS without the local SERVER, CONTENT RESPONSES may be given to CLIENTS without
first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing
this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an
an LCN in order to perform DISTRIBUTION into the LCN and receive LCN in order to perform DISTRIBUTION into the LCN and receive
ACCOUNTING data from it. Note that once SERVERS participate in ACCOUNTING data from it. Note that once SERVERS participate in
DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they
effectively take on the role of SURROGATES. However, an LCN would effectively take on the role of SURROGATES. However, an LCN would
not intend to allow its SURROGATES to be accessed by non-local not intend to allow its SURROGATES to be accessed by non-local
CLIENTS. CLIENTS.
This set of assumptions implies multiple things about the LCN's This set of assumptions implies multiple things about the LCN's
CONTENT INTERNETWORKING relationships. First, it is implied that the CONTENT INTERNETWORKING relationships. First, it is implied that the
LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send
DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is
implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be
able to send ACCOUNTING data, it need not receive it. Finally, due able to send ACCOUNTING data, it need not receive it. Finally, due
to the locally defined REQUEST-ROUTING, the LCN would not to the locally defined REQUEST-ROUTING, the LCN would not participate
participate in REQUEST-ROUTING INTERNETWORKING. in REQUEST-ROUTING INTERNETWORKING.
3. Content Internetworking Arrangements 3. Content Internetworking Arrangements
When the controlling interests of two CNs decide to interconnect When the controlling interests of two CNs decide to interconnect
their respective networks (such as for business reasons), it is their respective networks (such as for business reasons), it is
expected that multiple steps would need to occur. expected that multiple steps would need to occur.
The first step would be the creation of a NEGOTIATED RELATIONSHIP. The first step would be the creation of a NEGOTIATED RELATIONSHIP.
This relationship would most likely take the form of a legal This relationship would most likely take the form of a legal document
document that describes the services to be provided, cost of that describes the services to be provided, cost of services, SLAs,
services, SLAs, and other stipulations. For example, if an and other stipulations. For example, if an ORIGINATING CN wished to
ORIGINATING CN wished to leverage another CN's reach into a leverage another CN's reach into a particular country, this would be
particular country, this would be laid out in the NEGOTIATED laid out in the NEGOTIATED RELATIONSHIP.
RELATIONSHIP.
The next step would be to configure CONTENT INTERNETWORKING The next step would be to configure CONTENT INTERNETWORKING protocols
protocols on the CIGs of the respective CNs in order to technically on the CIGs of the respective CNs in order to technically support the
support the terms of the NEGOTIATED RELATIONSHIP. To follow our terms of the NEGOTIATED RELATIONSHIP. To follow our previous
previous example, this could include the configuration of the example, this could include the configuration of the ENLISTED CN's
ENLISTED CN's CIGs in a particular country to send DISTRIBUTION CIGs in a particular country to send DISTRIBUTION ADVERTISEMENTS to
ADVERTISEMENTS to the CIGs of the ORIGINATING CN. In order to the CIGs of the ORIGINATING CN. In order to configure these
configure these protocols, technical details (such as CIG protocols, technical details (such as CIG addresses/hostnames and
addresses/hostnames and authentication information) would be authentication information) would be exchanged by administrators of
exchanged by administrators of the respective CNs. the respective CNs.
Note also that some terms of the NEGOTIATED RELATIONSHIP would be Note also that some terms of the NEGOTIATED RELATIONSHIP would be
upheld through means outside the scope of CDI protocols. These could upheld through means outside the scope of CDI protocols. These could
include non-technical terms (such as financial settlement) or other include non-technical terms (such as financial settlement) or other
technical terms (such as SLAs). technical terms (such as SLAs).
In the event that the controlling interests of two CNs no longer In the event that the controlling interests of two CNs no longer wish
wish to have their networks interconnected, it is expected that to have their networks interconnected, it is expected that these
these tasks would be undone. That is, the protocol configurations tasks would be undone. That is, the protocol configurations would be
would be changed to cease the movement of ADVERTISEMENTS and/or changed to cease the movement of ADVERTISEMENTS and/or ACCOUNTING
ACCOUNTING data between the networks, and the NEGOTIATED data between the networks, and the NEGOTIATED RELATIONSHIP would be
RELATIONSHIP would be legally terminated. legally terminated.
4. Content Internetworking Scenarios 4. Content Internetworking Scenarios
This section provides several scenarios that may arise in CONTENT This section provides several scenarios that may arise in CONTENT
INTERNETWORKING implementations. INTERNETWORKING implementations.
Note that we obviously cannot examine every single permutation. Note that we obviously cannot examine every single permutation.
Specifically, it should be noted that: Specifically, it should be noted that:
o Any one of the interconnected CNs may have other CONTENT o Any one of the interconnected CNs may have other CONTENT
INTERNETWORKING arrangements that may or may not be transitive to INTERNETWORKING arrangements that may or may not be transitive to
the relationships being described in the diagram. the relationships being described in the diagram.
o The graphical figures do not illustrate the CONTENT REQUEST o The graphical figures do not illustrate the CONTENT REQUEST paths.
paths. It is assumed that the direction of CONTENT REQUESTS It is assumed that a REQUEST-ROUTING SYSTEM eventually returns to
follow the methodology given in [2] and that the end result is the CLIENT the IP address of the SURROGATE deemed appropriate to
that a REQUEST-ROUTING SYSTEM eventually returns to the CLIENT honor the CLIENT's CONTENT REQUEST.
the IP address of the SURROGATE deemed appropriate to honor the
CLIENT's CONTENT REQUEST.
The scenarios described include a general case, two cases in which The scenarios described include a general case, two cases in which
BCNs provide limited interfaces, a case in which a PCN enlists the BCNs provide limited interfaces, a case in which a PCN enlists the
services of multiple CNs, and a case in which multiple CNs enlist services of multiple CNs, and a case in which multiple CNs enlist the
the services of an LCN. services of an LCN.
4.1 General Content Internetworking 4.1. General Content Internetworking
This scenario considers the general case where two or more existing This scenario considers the general case where two or more existing
CNs wish to establish a CONTENT INTERNETWORKING relationship in CNs wish to establish a CONTENT INTERNETWORKING relationship in order
order to provide increased scale and reach for their existing to provide increased scale and reach for their existing customers.
customers. It assumes that all of these CNs already provide REQUEST- It assumes that all of these CNs already provide REQUEST-ROUTING,
ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will DISTRIBUTION, and ACCOUNTING services and that they will continue to
continue to provide these services to existing customers as well as provide these services to existing customers as well as offering them
offering them to other CNs. to other CNs.
In this scenario, these CIs would interconnect with others via a CIG In this scenario, these CNs would interconnect with others via a CIG
that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a
DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING
INTERNETWORKING SYSTEM. The net result of this interconnection would INTERNETWORKING SYSTEM. The net result of this interconnection would
be that a larger set of SURROGATES will now be available to the be that a larger set of SURROGATES will now be available to the
CLIENTS. CLIENTS.
FIGURE 1 shows three CNs which have interconnected to provide Figure 1 shows three CNs which have interconnected to provide greater
greater scale and reach to their existing customers. They are all scale and reach to their existing customers. They are all
participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING
INTERNETWORKING, and ACCOUNTING INTERNETWORKING. INTERNETWORKING, and ACCOUNTING INTERNETWORKING.
As a result of the NEGOTIATED RELATIONSHIPS it is assumed that: As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:
1. CONTENT that has been INJECTED into any one of these ORIGINATING 1. CONTENT that has been INJECTED into any one of these ORIGINATING
CNs may be distributed into any other ENLISTED CN. CNs may be distributed into any other ENLISTED CN.
2. Commands affecting the DISTRIBUTION of CONTENT may be issued 2. Commands affecting the DISTRIBUTION of CONTENT may be issued
within the ORIGINATING CN, or may also be issued within the within the ORIGINATING CN, or may also be issued within the
ENLISTED CN. The latter case allows local decisions to be made ENLISTED CN. The latter case allows local decisions to be made
about DISTRIBUTION within the ENLISTED CN, but such commands about DISTRIBUTION within the ENLISTED CN, but such commands would
would not control DISTRIBUTION within the ORIGINATING CN. not control DISTRIBUTION within the ORIGINATING CN.
3. ACCOUNTING information regarding CLIENT access and/or 3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION
DISTRIBUTION actions will be made available to the ORIGINATING actions will be made available to the ORIGINATING CN by the
CN by the ENLISTED CN. ENLISTED CN.
4. The ORIGINATING CN would provide this ACCOUNTING information to 4. The ORIGINATING CN would provide this ACCOUNTING information to
the PUBLISHER based on existing Service Level Agreements (SLAs). the PUBLISHER based on existing Service Level Agreements (SLAs).
5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within 5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within
any of the ENLISTED CNs. any of the ENLISTED CNs.
The decision of where to direct an individual CONTENT REQUEST may be The decision of where to direct an individual CONTENT REQUEST may be
dependent upon the DISTRIBUTION and REQUEST-ROUTING policies dependent upon the DISTRIBUTION and REQUEST-ROUTING policies
associated with the CONTENT being requested as well as the specific associated with the CONTENT being requested as well as the specific
algorithms and methods used for directing these requests. For algorithms and methods used for directing these requests. For
example, a REQUEST-ROUTING policy for a piece of CONTENT may example, a REQUEST-ROUTING policy for a piece of CONTENT may indicate
indicate multiple versions exist based on the spoken language of a multiple versions exist based on the spoken language of a CLIENT.
CLIENT. Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN would likely
would likely direct a CONTENT REQUEST to a SURROGATE known to be direct a CONTENT REQUEST to a SURROGATE known to be holding a version
holding a version of CONTENT of a language that matches that of a of CONTENT of a language that matches that of a CLIENT.
CLIENT.
FIGURE 1 - General CONTENT INTERNETWORKING Figure 1 - General CONTENT INTERNETWORKING
+--------------+ +--------------+ +--------------+ +--------------+
| CN A | | CN B | | CN A | | CN B |
|..............| +---------+ +---------+ |..............+ |..............| +---------+ +---------+ |..............+
| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............| |..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............| |..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+ +--------------+ +---------+ +---------+ +--------------+
| ^ \^ \^ \^ ^/ ^/ ^/ | ^ | ^ \^ \ \ ^/ ^/ ^/ | ^
v | \\ \\ \\ // // // v | v | \\ \\ \\ // // // v |
+--------------+ \\ \\ \\ // // // +--------------+ +--------------+ \\ \\ \\ // // // +--------------+
| SURROGATES | \\ v\ v\ /v /v // | SURROGATES | | SURROGATES | \\ v\ v\ /v /v // | SURROGATES |
+--------------+ \\+---------+// +--------------+ +--------------+ \\+---------+// +--------------+
^ | v| |v ^ | ^ | v| |v ^ |
| | | CONTENT | | | | | | CONTENT | | |
| | |INTWRKING| | | | | |INTWRKING| | |
| | | GATEWAY | | | | | | GATEWAY | | |
| | | | | | | | | | | |
| | +---------+ | | | | +---------+ | |
skipping to change at page 9, line 5 skipping to change at page 9, line 5
\ \ | SURROGATES | / / \ \ | SURROGATES | / /
\ \ +--------------+ / / \ \ +--------------+ / /
\ \ | ^ / / \ \ | ^ / /
\ \ | | / / \ \ | | / /
\ \ v | / / \ \ v | / /
\ \ +---------+ / / \ \ +---------+ / /
\ \-->| CLIENTS |---/ / \ \-->| CLIENTS |---/ /
\----| |<---/ \----| |<---/
+---------+ +---------+
4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING 4.2. BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
INTERNETWORKING INTERNETWORKING
This scenario describes the case where a single entity (BCN A) This scenario describes the case where a single entity (BCN A)
performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
INTERNETWORKING functions, but has no inherent DISTRIBUTION or INTERNETWORKING functions, but has no inherent DISTRIBUTION or
DELIVERY capabilities. A potential configuration which illustrates DELIVERY capabilities. A potential configuration which illustrates
this concept is given in FIGURE 2. this concept is given in Figure 2.
In the scenario shown in FIGURE 2, BCN A is responsible for In the scenario shown in Figure 2, BCN A is responsible for
collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN
A and CN B) to provide a clearinghouse/settlement function, as well A and CN B) to provide a clearinghouse/settlement function, as well
as providing a REQUEST-ROUTING service for CN A and CN B. as providing a REQUEST-ROUTING service for CN A and CN B.
In this scenario, CONTENT is injected into either CN A or CN B and In this scenario, CONTENT is injected into either CN A or CN B and
its DISTRIBUTION between these CNs is controlled via the its DISTRIBUTION between these CNs is controlled via the DISTRIBUTION
DISTRIBUTION INTERNETWORKING SYSTEMS within the CIGs. The REQUEST- INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-ROUTING SYSTEM
ROUTING SYSTEM provided by BCN A is informed of the ability to serve provided by BCN A is informed of the ability to serve a piece of
a piece of CONTENT from a particular CONTENT NETWORK by the REQUEST- CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING
ROUTING SYSTEMS within the interconnected CIGs. SYSTEMS within the interconnected CIGs.
BCN A collects statistics and usage information via the ACCOUNTING BCN A collects statistics and usage information via the ACCOUNTING
INTERNETWORKING SYSTEM and disseminates that information to CN A and INTERNETWORKING SYSTEM and disseminates that information to CN A and
CN B as appropriate. CN B as appropriate.
As illustrated in FIGURE 2, there are separate REQUEST-ROUTING As illustrated in Figure 2, there are separate REQUEST-ROUTING
SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM
provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a
given piece of CONTENT this is not a problem. However, each given piece of CONTENT this is not a problem. However, each
individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING
SYSTEM for some portion of its PUBLISHER customers. In this case SYSTEM for some portion of its PUBLISHER customers. In this case
care must be taken to ensure that the there is one and only one care must be taken to ensure that the there is one and only one
AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given
CONTENT object. CONTENT object.
FIGURE 2 - BCN providing ACCOUNTING INTERNETWORKING and Figure 2 - BCN providing ACCOUNTING INTERNETWORKING and
REQUEST-ROUTING INTERNETWORKING REQUEST-ROUTING INTERNETWORKING
+--------------+ +--------------+
| BCN A | | BCN A |
|..............| +-----------+ |..............| +-----------+
| REQ-ROUTING |<===>| | | REQ-ROUTING |<===>| |
|..............| | CONTENT | |..............| | CONTENT |
| ACCOUNTING |<===>| INTWRKING | | ACCOUNTING |<===>| INTWRKING |
+--------------+ | GATEWAY | +--------------+ | GATEWAY |
| | | |
skipping to change at page 11, line 5 skipping to change at page 11, line 5
+--------------+ +--------------+ +--------------+ +--------------+
^ \ ^ / ^ \ ^ /
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \ +---------+ / / \ \ +---------+ / /
\ \---->| CLIENTS |-----/ / \ \---->| CLIENTS |-----/ /
\------| |<-----/ \------| |<-----/
+---------+ +---------+
4.3 BCN providing ACCOUNTING INTERNETWORKING 4.3. BCN providing ACCOUNTING INTERNETWORKING
This scenario describes the case where a single entity (BCN A) This scenario describes the case where a single entity (BCN A)
performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/ performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/
settlement function only. In this scenario, BCN A would enter into settlement function only. In this scenario, BCN A would enter into
NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their
own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING
as shown in FIGURE 3. as shown in FIGURE 3.
FIGURE 3 - BCN providing ACCOUNTING INTERNETWORKING Figure 3 - BCN providing ACCOUNTING INTERNETWORKING
+--------------+ +--------------+
| BCN A | | BCN A |
|..............| +-----------+ |..............| +-----------+
| ACCOUNTING |<===>| | | ACCOUNTING |<===>| |
+--------------+ | CONTENT | +--------------+ | CONTENT |
| INTWRKING | | INTWRKING |
| GATEWAY | | GATEWAY |
| | | |
+-----------+ +-----------+
skipping to change at page 12, line 5 skipping to change at page 12, line 5
+--------------+ +--------------+ +--------------+ +--------------+
^ \ ^ / ^ \ ^ /
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \ +---------+ / / \ \ +---------+ / /
\ \---->| CLIENTS |-----/ / \ \---->| CLIENTS |-----/ /
\------| |<-----/ \------| |<-----/
+---------+ +---------+
4.4 PCN ENLISTS multiple CNs 4.4. PCN ENLISTS multiple CNs
In the previously enumerated scenarios, PUBLISHERS have not been In the previously enumerated scenarios, PUBLISHERS have not been
discussed. Much of the time, it is assumed that the PUBLISHERS will discussed. Much of the time, it is assumed that the PUBLISHERS will
allow CNs to act on their behalf. For example, a PUBLISHER may allow CNs to act on their behalf. For example, a PUBLISHER may
designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING
SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a
particular CN to aggregate all its ACCOUNTING data, even though that particular CN to aggregate all its ACCOUNTING data, even though that
data may originate at SURROGATES in multiple distant CNs. Finally, a data may originate at SURROGATES in multiple distant CNs. Finally, a
PUBLISHER may INJECT content only into a single CN and rely on that PUBLISHER may INJECT content only into a single CN and rely on that
CN to ENLIST other CNs to obtain scale and reach. CN to ENLIST other CNs to obtain scale and reach.
However, a PUBLISHER may wish to maintain more control and take on However, a PUBLISHER may wish to maintain more control and take on
the task of ENLISTING CNs itself, therefore acting as a PCN (Section the task of ENLISTING CNs itself, therefore acting as a PCN (Section
2.1). This scenario, shown in FIGURE 4, describes the case where a 2.1). This scenario, shown in Figure 4, describes the case where a
PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with
multiple CNs. In this scenario, the PCN would operate its own CIG multiple CNs. In this scenario, the PCN would operate its own CIG
and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING
INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships
with two or more CNs. with two or more CNs.
FIGURE 4 - PCN ENLISTS multiple CNs Figure 4 - PCN ENLISTS multiple CNs
+--------------+ +--------------+
| PCN | | PCN |
|..............| +-----------+ |..............| +-----------+
| REQ-ROUTING |<=>| |<---\ | REQ-ROUTING |<=>| |<---\
|..............| | CONTENT |----\\ |..............| | CONTENT |----\\
| DISTRIBUTION |<=>| INTWRKING | \\ | DISTRIBUTION |<=>| INTWRKING | \\
|..............| | GATEWAY |--\ \\ |..............| | GATEWAY |--\ \\
| ACCOUNTING |<=>| |<-\\ \\ | ACCOUNTING |<=>| |<-\\ \\
+--------------+ +-----------+ \\ \\ +--------------+ +-----------+ \\ \\
skipping to change at page 13, line 40 skipping to change at page 13, line 40
+--------------+ +--------------+ +--------------+ +--------------+
^ \ ^ / ^ \ ^ /
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \ +---------+ / / \ \ +---------+ / /
\ \---->| CLIENTS |-----/ / \ \---->| CLIENTS |-----/ /
\------| |<-----/ \------| |<-----/
+---------+ +---------+
4.5 Multiple CNs ENLIST LCN 4.5. Multiple CNs ENLIST LCN
A type of CN described in Section 2.3 is the LCN. In this scenario, A type of CN described in Section 2.3 is the LCN. In this scenario,
we imagine a tightly administered CN (such as within an enterprise) we imagine a tightly administered CN (such as within an enterprise)
has determined that all CONTENT REQUESTS from CLIENTS must be has determined that all CONTENT REQUESTS from CLIENTS must be
serviced locally. Likely due to a large CLIENT base in the LCN, serviced locally. Likely due to a large CLIENT base in the LCN,
multiple CNs determine they would like to engage in DISTRIBUTION multiple CNs determine they would like to engage in DISTRIBUTION
INTERNETWORKING with the LCN in order to extend control over CONTENT INTERNETWORKING with the LCN in order to extend control over CONTENT
objects held in the LCN's SURROGATES. Similarly, the CNs would like objects held in the LCN's SURROGATES. Similarly, the CNs would like
to engage in ACCOUNTING INTERNETWORKING with the LCN in order to to engage in ACCOUNTING INTERNETWORKING with the LCN in order to
receive ACCOUTING data regarding the usage of the content in the receive ACCOUNTING data regarding the usage of the content in the
local SURROGATES. This scenario is shown in FIGURE 5. local SURROGATES. This scenario is shown in Figure 5. Although this
diagram shows a DISTRIBUTION INTERNETWORKING connection between CN A
and CN B, it should be recognized that this connection is optional
and not a requirement in this scenario.
FIGURE 5 - Multiple CNs ENLIST LCN Figure 5 - Multiple CNs ENLIST LCN
+--------------+ +--------------+ +--------------+ +--------------+
| CN A | | CN B | | CN A | | CN B |
|..............| +---------+ +---------+ |..............+ +..............| +---------+ +---------+ |..............+
| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............| |..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............| |..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+ +--------------+ +---------+ +---------+ +--------------+
| ^ \^ \^ ^/ ^/ | ^ | ^ \^ \^ ^/ ^/ | ^
v | \\ \\ // // v | v | \\ \\ // // v |
+--------------+ \\ \\ // // +--------------+ +--------------+ \\ \\ // // +--------------+
| SURROGATES | v\ v\ /v /v | SURROGATES | | SURROGATES | v\ v\ /v /v | SURROGATES |
skipping to change at page 15, line 7 skipping to change at page 15, line 7
| ^ | ^
| | | |
v | v |
+---------+ +---------+
| CLIENTS | | CLIENTS |
| | | |
+---------+ +---------+
5. Security Considerations 5. Security Considerations
This section contains security considerations that arise Security concerns with respect to Content Internetworking can be
specifically from the examples presented here. For a more general generally categorized into trust within the system and protection of
discussion of security in the CDI protocols, see [2]. the system from threats. The trust model utilized with Content
Internetworking is predicated largely on transitive trust between the
ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION
INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORING SYSTEM, and
SURROGATES. Network elements within the Content Internetworking
system are considered to be "insiders" and therefore trusted.
Due to the likely reliance on ACCOUNTING data as the basis of 5.1. Threats to Content Internetworking
payment for services, the likelihood of fraud may be a concern of
parties that participate in CONTENT INTERNETWORKING. Indeed, it's The following sections document key threats to CLIENTs, PUBLISHERs,
easy to imagine fabricating log entries or increasing throughput and CNs. The threats are classified according to the party that they
numbers to increase revenue. While this is a difficult problem to most directly harm, but, of course, a threat to any party is
solve, there are some approaches to be explored. A useful tool would ultimately a threat to all. (For example, having a credit card
be a "fraud detection" analysis tool that is capable of modeling number stolen may most directly affect a CLIENT; however, the
human usage patterns and detecting anomalies. It may be logical for resulting dissatisfaction and publicity will almost certainly cause
such a tool to be run by a BCN that is acting as an "impartial third some harm to the PUBLISHER and CN, even if the harm is only to those
party", ENLISTED only to ensure fairness among participants. organizations' reputations.)
Additionally, a BCN may be ENLISTED to perform random audits of
ACCOUNTING data. 5.1.1. Threats to the CLIENT
5.1.1.1. Defeat of CLIENT's Security Settings
Because the SURROGATE's location may differ from that of the ORIGIN,
the use of a SURROGATE may inadvertently or maliciously defeat any
location-based security settings employed by the CLIENT. And since
the SURROGATE's location is generally transparent to the CLIENT, the
CLIENT may be unaware that its protections are no longer in force.
For example, a CN may relocate CONTENT from a Internet Explorer
user's "Internet Web Content Zone" to that user's "Local Intranet Web
Content Zone". If the relocation is visible to the Internet Explorer
browser but otherwise invisible to the user, the browser may be
employing less stringent security protections than the user is
expecting for that CONTENT. (Note that this threat differs, at least
in degree, from the substitution of security parameters threat below,
as Web Content Zones can control whether or not, for example, the
browser executes unsigned active content.)
5.1.1.2. Delivery of Bad Accounting Information
In the case of CONTENT with value, CLIENTs may be inappropriately
charged for viewing content that they did not successfully access.
Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
CONTENT (e.g., programs that "pay" users to surf the Web). Should a
CN fail to deliver appropriate accounting information, the CLIENT may
not receive appropriate credit for viewing the required CONTENT.
5.1.1.3. Delivery of Bad CONTENT
A CN that does not deliver the appropriate CONTENT may provide the
user misleading information (either maliciously or inadvertently).
This threat can be manifested as a failure of either the DISTRIBUTION
SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or
REQUEST-ROUTING SYSTEM (request routing to inappropriate SURROGATEs,
even though they may have appropriate CONTENT), or both. A REQUEST-
ROUTING SYSTEM may also fail by forwarding the CLIENT request when no
forwarding is appropriate, or by failing to forward the CLIENT
request when forwarding is appropriate.
5.1.1.4. Denial of Service
A CN that does not forward the CLIENT appropriately may deny the
CLIENT access to CONTENT.
5.1.1.5. Exposure of Private Information
CNs may inadvertently or maliciously expose private information
(passwords, buying patterns, page views, credit card numbers) as it
transmits from SURROGATEs to ORIGINs and/or PUBLISHERs.
5.1.1.6. Substitution of Security Parameters
If a SURROGATE does not duplicate completely the security facilities
of the ORIGIN (e.g., encryption algorithms, key lengths, certificate
authorities) CONTENT delivered through the SURROGATE may be less
secure than the CLIENT expects.
5.1.1.7. Substitution of Security Policies
If a SURROGATE does not employ the same security policies and
procedures as the ORIGIN, the CLIENT's private information may be
treated with less care than the CLIENT expects. For example, the
operator of a SURROGATE may not have as rigorous protection for the
CLIENT's password as does the operator of the ORIGIN server. This
threat may also manifest itself if the legal jurisdiction of the
SURROGATE differs from that of the ORIGIN, should, for example, legal
differences between the jurisdictions require or permit different
treatment of the CLIENT's private information.
5.1.2. Threats to the PUBLISHER
5.1.2.1. Delivery of Bad Accounting Information
If a CN does not deliver accurate accounting information, the
PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it
may reward CLIENTs inappropriately. Inaccurate accounting
information may also cause a PUBLISHER to pay for services (e.g.,
content distribution) that were not actually rendered. Invalid
accounting information may also effect PUBLISHERs indirectly by, for
example, undercounting the number of site visitors (and, thus,
reducing the PUBLISHER's advertising revenue).
5.1.2.2. Denial of Service
A CN that does not distribute CONTENT appropriately may deny CLIENTs
access to CONTENT.
5.1.2.3. Substitution of Security Parameters
If a SURROGATE does not duplicate completely the security services of
the ORIGIN (e.g., encryption algorithms, key lengths, certificate
authorities, client authentication) CONTENT stored on the SURROGATE
may be less secure than the PUBLISHER prefers.
5.1.2.4. Substitution of Security Policies
If a SURROGATE does not employ the same security policies and
procedures as the ORIGIN, the CONTENT may be treated with less care
than the PUBLISHER expects. This threat may also manifest itself if
the legal jurisdiction of the SURROGATE differs from that of the
ORIGIN, should, for example, legal differences between the
jurisdictions require or permit different treatment of the CONTENT.
5.1.3. Threats to a CN
5.1.3.1. Bad Accounting Information
If a CN is unable to collect or receive accurate accounting
information, it may be unable to collect compensation for its
services from PUBLISHERs.
5.1.3.2. Denial of Service
Misuse of a CN may make that CN's facilities unavailable, or
available only at reduced functionality, to legitimate customers or
the CN provider itself. Denial of service attacks can be targeted at
a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING
SYSTEM.
5.1.3.3. Transitive Threats
To the extent that a CN acts as either a CLIENT or a PUBLISHER (such
as, for example, in transitive implementations) such a CN may be
exposed to any or all of the threats described above for both roles.
6. Acknowledgements 6. Acknowledgements
The authors acknowledge the contributions and comments of Fred The authors acknowledge the contributions and comments of Fred
Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John
Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT), Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT),
Christian Hoertnagl (IBM), Christian Langkamp (Oxford University), Christian Hoertnagl (IBM), Christian Langkamp (Oxford University),
and Don Estberg (Activate). and Don Estberg (Activate).
References 7. References
[1] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for
Content Internetworking (CDI)", draft-ietf-cdi-model-01.txt
(work in progress), February 2002,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-cdi-model-
01.txt>.
[2] Green, M., Cain, B., Tomlinson, G., Thomas, S., and P. Rzewski,
"Content Internetworking Architectural Overview", draft-ietf-
cdi-architecture-00.txt (work in progress), February 2002,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-cdi-
architecture-00.txt>.
[3] Gilletti, D., Nair, R., Scharber, J., and J. Guha, "CDN-I
Internetworking Authentication, Authorization, and Accounting
Requirements", draft-ietf-cdi-aaa-reqs-00.txt (work in
progress), February 2002,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-cdi-aaa-
reqs-00.txt>.
[4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to [1] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
Accounting Management", RFC 2975, October 2000, Content Internetworking (CDI)", RFC 3466, February 2003.
<URL:ftp://ftp.isi.edu/in-notes/rfc2975.txt>.
[5] Douglis, F., Chaudhri, I. and P. Rzewski, "Known Mechanisms for [2] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal, S.,
Content Internetworking", draft-douglis-cdi-known-mech-00.txt, Spatscheck, O. and W. Sturm, "CDN Brokering", Proceedings of the
November 2001, 6th International Workshop on Web Caching and Content
<URL:http://www.ietf.org/internet-drafts/draft-douglis-cdi- Distribution, Boston, MA, June 2001.
known-mech-00.txt>.
Authors' Addresses 8. Authors' Addresses
Mark S. Day Mark S. Day
Cisco Systems Cisco Systems
135 Beaver Street 1414 Massachusetts Avenue
Waltham, MA 02452 Boxborough, MA 01719
US US
Phone: +1 781 663 8310 Phone: +1 978 936 1089
EMail: markday@cisco.com EMail: mday@alum.mit.edu
Don Gilletti Don Gilletti
CacheFlow, Inc. 21 22nd Ave.
441 Moffett Park Drive San Mateo, CA 94403
Sunnyvale, CA 94089 USA
US US
Phone: +1 408 543 0437 Phone +1 408 569 6813
EMail: don@cacheflow.com EMail: dgilletti@yahoo.com
Phil Rzewski Phil Rzewski
Inktomi 30 Jennifer Place
4100 East Third Avenue San Francisco, CA 94107
MS FC2-4
Foster City, CA 94404
US US
Phone +1 650 653 2487 Phone: +1 650 303 3790
Email: philr@inktomi.com EMail: philrz@yahoo.com
Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 73 change blocks. 
228 lines changed or deleted 317 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/