draft-ietf-cdi-architecture-00.txt   draft-ietf-cdi-architecture-01.txt 
Network Working Group M. Green CDI M. Green
Internet-Draft CacheFlow Internet-Draft No Affiliation
Expires: August 22, 2002 B. Cain Expires: November 30, 2002 B. Cain
Cereva Networks Storigen Systems
G. Tomlinson G. Tomlinson
CacheFlow No Affiliation
S. Thomas M. Speer
TransNexus Sun Microsystems
P. Rzewski P. Rzewski
Inktomi Inktomi
February 22, 2002 S. Thomas
TransNexus
Content Internetworking Architectural Overview Content Internetworking Architectural Overview
draft-ietf-cdi-architecture-00.txt draft-ietf-cdi-architecture-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2002. This Internet-Draft will expire on November 30, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
There is wide interest in the technology for interconnecting Content There is wide interest in the technology for interconnecting Content
Networks, variously called "Content Peering" or "Content Networks, variously called "Content Peering" or "Content
Internetworking". We present the general architecture and core Internetworking". We present the general architecture and core
building blocks used in the internetworking of Content Networks. building blocks used in the internetworking of Content Networks. The
The scope of this work is limited to external interconnections with scope of this work is limited to external interconnections with
Content Networks and does not address internal mechanisms used Content Networks and does not address internal mechanisms used within
within Content Networks, which for the purpose of the document are Content Networks, which for the purpose of the document are
considered to be black boxes. This work establishes an abstract considered to be black boxes. This work establishes an abstract
architectural framework to be used in the development of protocols, architectural framework to be used in the development of protocols,
interfaces, and system models for standardized Content interfaces, and system models for standardized Content
Internetworking. Internetworking.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Content Internetworking System Architecture . . . . . . . 5 1.1 Change Log . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Conceptual View of Peered Content Networks . . . . . . . . 5 1.2 Outstanding Issues . . . . . . . . . . . . . . . . . . . . 5
2.2 Content Internetworking Architectural Elements . . . . . . 7 2. Content Internetworking System Architecture . . . . . . . 6
3. Request-Routing Peering System . . . . . . . . . . . . . . 11 2.1 Conceptual View of Peered Content Networks . . . . . . . . 6
3.1 Request-Routing Overview . . . . . . . . . . . . . . . . . 11 2.2 Content Internetworking Architectural Elements . . . . . . 8
3.2 Request Routing . . . . . . . . . . . . . . . . . . . . . 13 3. Request-Routing Internetworking System . . . . . . . . . . 12
3.3 System Requirements . . . . . . . . . . . . . . . . . . . 13 3.1 Request-Routing Overview . . . . . . . . . . . . . . . . . 12
3.4 Protocol Requirements . . . . . . . . . . . . . . . . . . 14 3.2 Request-Routing . . . . . . . . . . . . . . . . . . . . . 14
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 System Requirements . . . . . . . . . . . . . . . . . . . 14
3.6 Request-Routing Problems to Solve . . . . . . . . . . . . 15 3.4 Protocol Requirements . . . . . . . . . . . . . . . . . . 15
4. Distribution Peering System . . . . . . . . . . . . . . . 17 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 17 3.6 Request-Routing Problems to Solve . . . . . . . . . . . . 16
4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 19 4. Distribution Internetworking System . . . . . . . . . . . 18
4.3 Distribution Components . . . . . . . . . . . . . . . . . 20 4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 18
4.4 Distribution System Requirements . . . . . . . . . . . . . 20 4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 20
4.3 Distribution Components . . . . . . . . . . . . . . . . . 21
4.4 Distribution System Requirements . . . . . . . . . . . . . 21
4.4.1 Replication Requirements . . . . . . . . . . . . . . . . . 21 4.4.1 Replication Requirements . . . . . . . . . . . . . . . . . 21
4.4.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 21 4.4.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 22
4.4.3 Advertising Requirements . . . . . . . . . . . . . . . . . 21 4.4.3 Advertising Requirements . . . . . . . . . . . . . . . . . 22
4.5 Protocol Requirements . . . . . . . . . . . . . . . . . . 22 4.5 Protocol Requirements . . . . . . . . . . . . . . . . . . 23
4.6 Distribution Problems to Solve . . . . . . . . . . . . . . 22 4.6 Distribution Problems to Solve . . . . . . . . . . . . . . 23
4.6.1 General Problems . . . . . . . . . . . . . . . . . . . . . 22 4.6.1 General Problems . . . . . . . . . . . . . . . . . . . . . 23
4.6.2 Replication Problems . . . . . . . . . . . . . . . . . . . 23 4.6.2 Replication Problems . . . . . . . . . . . . . . . . . . . 23
4.6.3 Signaling Problems . . . . . . . . . . . . . . . . . . . . 23 4.6.3 Signaling Problems . . . . . . . . . . . . . . . . . . . . 24
4.6.4 Advertising Problems . . . . . . . . . . . . . . . . . . . 23 4.6.4 Advertising Problems . . . . . . . . . . . . . . . . . . . 24
5. Accounting Peering System . . . . . . . . . . . . . . . . 25 5. Accounting Internetworking System . . . . . . . . . . . . 25
5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 25 5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 25
5.2 Accounting System Requirements . . . . . . . . . . . . . . 27 5.2 Accounting System Requirements . . . . . . . . . . . . . . 27
5.3 Protocol Requirements . . . . . . . . . . . . . . . . . . 27 5.3 Protocol Requirements . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . 28
6.1 Threats to Content Internetworking . . . . . . . . . . . . 28 6.1 Threats to Content Networking . . . . . . . . . . . . . . 28
6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 28 6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 28
6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 28 6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 28
6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 28 6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 28
6.1.1.3 Delivery of Bad CONTENT . . . . . . . . . . . . . . . . . 29 6.1.1.3 Delivery of Bad Content . . . . . . . . . . . . . . . . . 29
6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 29 6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 29
6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 29 6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 29
6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 29 6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 29
6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 29 6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 29
6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 29 6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 29
6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 29 6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 30
6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30 6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30
6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 30 6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 30
6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 30 6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 30
6.1.3 Threats to a CN . . . . . . . . . . . . . . . . . . . . . 30 6.1.3 Threats to a CN . . . . . . . . . . . . . . . . . . . . . 30
6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 30 6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 30
6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30 6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30
6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 31 6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . 33 References . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . 36 Full Copyright Statement . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Terms in ALL CAPS, except those qualified with explicit citations Terms in ALL CAPS, except those qualified with explicit citations are
are defined in [13]. defined in [13].
This memo describes the overall architectural structure and the This memo describes the overall architectural structure and the
fundamental building blocks used in the composition of Content fundamental building blocks used in the composition of Content
Internetworking. Consult [13] for the system model, and vocabulary Internetworking. Consult [13] for the system model, and vocabulary
used in, this application domain. A key requirement of the used in, this application domain. A key requirement of the
architecture itself is that it be able to address each of the architecture itself is that it be able to address each of the Content
Content Internetworking scenarios enumerated in [14]. The scope of Internetworking scenarios enumerated in [14] . The scope of this
this work is limited to external interconnections between Content work is limited to external interconnections between Content Networks
Networks (CN) (i.e. INTER-CN) and does not address internal (CN) (i.e. INTER-CN) and does not address internal mechanisms used
mechanisms used within Content Networks (i.e. INTRA-CN), which for within Content Networks (i.e. INTRA-CN), which for the purposes of
the purposes of the document are considered to be black boxes. This the document are considered to be black boxes. This work is intended
work is intended to establish an abstract architectural framework to to establish an abstract architectural framework to be used in the
be used in the development of protocols, interfaces and system development of protocols, interfaces and system models for
models for standardized, interoperable peering among Content standardized, interoperable peering among Content Networks.
Networks.
We first present the architecture as an abstract system. Then we We first present the architecture as an abstract system. Then we
develop a more concrete system architecture. For each core develop a more concrete system architecture. For each core
architectural element, we first present the structure of the element architectural element, we first present the structure of the element
followed by system requirements. Protocol requirements for followed by system requirements. Protocol requirements for
individual core elements are presented in accompanying works individual core elements are presented in accompanying works
[17][18][15]. The assumptions and scenarios constraining the [17][18][15]. The assumptions and scenarios constraining the
architecture is explained in [14]. We intend that the architecture architecture is explained in [13] . We intend that the architecture
should support a wide variety of business models. should support a wide variety of business models.
At the core of Content Internetworking are three principal At the core of Content Internetworking are three principal
architectural elements that constitute the building blocks of the architectural elements that constitute the building blocks of the
Content Internetworking system. These elements are the Content Internetworking system. These elements are the REQUEST-
REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM, and ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION INTERNETWORKING SYSTEM,
ACCOUNTING PEERING SYSTEM. Collectively, they control selection of and ACCOUNTING INTERNETWORKING SYSTEM. Collectively, they control
the delivery Content Network, content distribution between peering selection of the delivery Content Network, content distribution
Content Networks, and usage accounting, including billing settlement between peering Content Networks, and usage accounting, including
among the peering Content Networks. billing settlement among the peering Content Networks.
This work takes into consideration relevant IETF RFCs and IETF This work takes into consideration relevant IETF RFCs and IETF works-
works-in-progress. In particular, it is mindful of the end-to-end in-progress. In particular, it is mindful of the end-to-end nature
nature [6][10] of the Internet, the current taxonomy of web [6][10] of the Internet, and the taxonomy of web replication and
replication and caching [11], and the accounting, authorization and caching [11].
authentication framework [12].
1.1 Change Log
1. First pass at integration of the terms from the latest models
draft [13].
2. New Editor of document -- Michael Speer (Sun Microsystems).
1.2 Outstanding Issues
1. Need to complete integration of [13], and [17], [18], and [15].
2. Need to address the open and outstanding questions.
2. Content Internetworking System Architecture 2. Content Internetworking System Architecture
2.1 Conceptual View of Peered Content Networks 2.1 Conceptual View of Peered Content Networks
Before developing the system architecture, a conceptual view of Before developing the system architecture, a conceptual view of
peered CNs is presented to frame the problem space. CNs are peered CNs is presented to frame the problem space. CNs are
comprised principally of four core system elements [13], the comprised principally of four core system elements [13], the REQUEST-
REQUEST-ROUTING SYSTEM, the DISTRIBUTION SYSTEM, the ACCOUNTING ROUTING SYSTEM, the DISTRIBUTION SYSTEM, the ACCOUNTING SYSTEM, and
SYSTEM, and SURROGATES. In order for CNs to peer with one another, SURROGATES. In order for CNs to peer with one another, it is
it is necessary to interconnect several of the core system elements necessary to interconnect several of the core system elements of
of individual CNs. The interconnection of CN core system elements individual CNs. The interconnection of CN core system elements
occurs through network elements called Content Peering Gateways occurs through network elements called Content Internetworking
(CPG). Namely, the CN core system elements that need to be Gateways (CIG). Namely, the CN core system elements that need to be
interconnected are the REQUEST-ROUTING SYSTEM, the DISTRIBUTION interconnected are the REQUEST-ROUTING SYSTEM, the DISTRIBUTION
SYSTEM, and the ACCOUNTING SYSTEM. SYSTEM, and the ACCOUNTING SYSTEM.
Figure 1 contains a conceptual peered Content Networks diagram. Figure 1 contains a conceptual peered Content Networks diagram.
+---------------+ +---------------+ +---------------+ +---------------+
| CN A | | CN B | | CN A | | CN B |
|...............| +---------+ +---------+ |.......... ....+ |...............| +---------+ +---------+ |.......... ....+
|REQUEST-ROUTING|<=>| |<=>| |<=>|REQUEST-ROUTING| |REQUEST-ROUTING|<=>| |<=>| |<=>|REQUEST-ROUTING|
|...............| | CONTENT | | CONTENT | |...............| |...............| | | | | |...............|
| DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | | DISTRIBUTION |<=>| CIG |<=>| CIG |<=>| DISTRIBUTION |
|...............| | 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 | | | | | | | | |
| | | PEERING | | | | | | CIG | | |
| | | GATEWAY | | | | | | | | |
| | | | | | | | | | | |
| | +---------+ | | | | +---------+ | |
| | ^| ^| ^| | | | | ^| ^| ^| | |
| | || || || | | | | || || || | |
| | |v |v |v | | | | |v |v |v | |
| | +------------- -+ | | | | +------------- -+ | |
| | | CN C | | | | | | CN C | | |
| | |...............| | | | | |...............| | |
| | |REQUEST-ROUTING| | | | | |REQUEST-ROUTING| | |
| | |...............| | | | | |...............| | |
skipping to change at page 6, line 50 skipping to change at page 7, line 50
\ \ | SURROGATEs | / / \ \ | SURROGATEs | / /
\ \ +---------------+ / / \ \ +---------------+ / /
\ \ | ^ / / \ \ | ^ / /
\ \ | | / / \ \ | | / /
\ \ v | / / \ \ v | / /
\ \ +---------+ / / \ \ +---------+ / /
\ \--->| CLIENTs |---/ / \ \--->| CLIENTs |---/ /
\-----| |<---/ \-----| |<---/
+---------+ +---------+
CIG = Content Internetworking Gateway
Figure 1 Conceptual View of Peered Content Networks Figure 1 Conceptual View of Peered Content Networks
This conceptual view illustrates the peering of three Content This conceptual view illustrates the peering of three Content
Networks; CN A, CN B, and CN C. The CNs are peered through Networks; CN A, CN B, and CN C. The CNs are peered through
interconnection at Content Peering Gateways. The result is interconnection at Content Internetworking Gateways. The result is
presented as a virtual CN to CLIENTs for the DELIVERY of CONTENT by presented as a virtual CN to CLIENTs for the DELIVERY of CONTENT by
the aggregated set of SURROGATES. the aggregated set of SURROGATES.
Note: Note:
Not all Content Networks contain the complete set of core Not all Content Networks contain the complete set of core
elements. For these Content Networks, peering will be done with elements. For these Content Networks, peering will be done with
only the core elements they do contain. only the core elements they do contain.
2.2 Content Internetworking Architectural Elements 2.2 Content Internetworking Architectural Elements
skipping to change at page 7, line 38 skipping to change at page 8, line 40
interconnection of the individual CN administrative domains through interconnection of the individual CN administrative domains through
gateway protocols and mechanisms loosely modeled after BGP [5]. gateway protocols and mechanisms loosely modeled after BGP [5].
The system architecture depends on the following assumptions: The system architecture depends on the following assumptions:
1. The URI [8] name space is the basis of PUBLISHER object 1. The URI [8] name space is the basis of PUBLISHER object
identifiers. identifiers.
2. PUBLISHERs delegate authority of their object URI name space 2. PUBLISHERs delegate authority of their object URI name space
being distributed by peering CNs to the REQUEST-ROUTING being distributed by peering CNs to the REQUEST-ROUTING
PEERING SYSTEM. INTERNETWORKING SYSTEM.
3. Peering CNs use a common convention for encoding CN metadata 3. Peering CNs use a common convention for encoding CN metadata into
into the URI name space. the URI name space.
Figure 2 contains a system architecture diagram of the core elements Figure 2 contains a system architecture diagram of the core elements
involved in Content Internetworking. involved in Content Internetworking.
+---------------+ 1 +---------------+ 1
/-------------|REQUEST-ROUTING|<----\ /-------------|REQUEST-ROUTING|<----\
/ 4 | PEERING | 7 | / 4 |INTERNETWORKING| 7 |
/ /------------->| SYSTEM* |<-\ | / /------------->| SYSTEM* |<-\ |
/ / +---------------+ | | / / +---------------+ | |
/ / ^ | | / / ^ | |
/ / |3 | | / / |3 | |
/ / | | | / / | | |
/ / +--------------+ | | / / +---------------+ | |
5| | | DISTRIBUTION | 2| | 5| | | DISTRIBUTION | 2| |
V | __| PEERING |<-\ | V | __|INTERNETWORKING|<-\ |
+--------+ 6 +-----------+ 3 / | SYSTEM* | |\ | +---------+ +--------+ 6 +-----------+ 3 / | SYSTEM* |\ | +--------+
| |<---| |<-/ +--------------+ | \ \_| | | |<---| |<-/ +---------------+ | \\_| |
| CLIENT | | SURROGATE | | \__| ORIGIN | | CLIENT | | SURROGATE | | \_ | ORIGIN |
| |--->| |-\ +--------------+ | /-->| | | |--->| |-\ +---------------+ | /-->| |
+--------+ +-----------+ \ 7 | ACCOUNTING |--// 7 +---------+ +--------+ +-----------+ \ 7 | ACCOUNTING |--// 7 +--------+
\->| PEERING |--/ \->|INTERNETWORKING|--/
| SYSTEM* |--\ +---------+ | SYSTEM* |--\ +--------+
+--------------+ \ 7 | BILLING | +---------------+ \ 7| BILLING|
\-->| ORG. | \->| ORG. |
| | | |
+---------+ +--------+
Note: * represents core elements of Content Internetworking Note: * represents core elements of Content Internetworking
Figure 2 System Architecture Elements of a Content Internetworking Figure 2 System Architecture Elements of a Content Internetworking
System System
The System Architecture is comprised of 7 major elements, 3 of which The System Architecture is comprised of 7 major elements, 3 of which
constitute the Content Internetworking system itself. The peering constitute the Content Internetworking system itself. The peering
elements are REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING elements are REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION
SYSTEM, and ACCOUNTING PEERING SYSTEM. Correspondingly, the system INTERNETWORKING SYSTEM, and ACCOUNTING INTERNETWORKING SYSTEM.
architecture is a system of systems: Correspondingly, the system architecture is a system of systems:
1. The ORIGIN delegates its URI name space for objects to be 1. The ORIGIN delegates its URI name space for objects to be
distributed and delivered by the peering CNs to the distributed and delivered by the peering CNs to the REQUEST-
REQUEST-ROUTING PEERING SYSTEM. ROUTING INTERNETWORKING SYSTEM.
2. The ORIGIN INJECTS CONTENT that is to be distributed and 2. The ORIGIN INJECTS CONTENT that is to be distributed and
delivered by the peering CNs into the DISTRIBUTION PEERING delivered by the peering CNs into the DISTRIBUTION
SYSTEM. INTERNETWORKING SYSTEM.
Note: Note:
CONTENT which is to be pre-populated (pushed) within the CONTENT which is to be pre-populated (pushed) within the
peering CNs is pro-actively injected, while CONTENT which peering CNs is pro-actively injected, while CONTENT which is
is to be pulled on demand is injected at the time the to be pulled on demand is injected at the time the object is
object is being requested for DELIVERY. being requested for DELIVERY.
3. The DISTRIBUTION PEERING SYSTEM moves content between CN 3. The DISTRIBUTION INTERNETWORKING SYSTEM moves content between CN
DISTRIBUTION SYSTEMs. Additionally this system interacts with DISTRIBUTION SYSTEMs. Additionally this system interacts with
the REQUEST-ROUTING PEERING SYSTEM via feedback the REQUEST-ROUTING INTERNETWORKING SYSTEM via feedback
ADVERTISEMENTs to assist in the peered CN selection process ADVERTISEMENTs to assist in the peered CN selection process for
for CLIENT requests. CLIENT requests.
4. The CLIENT requests CONTENT from what it perceives to be the 4. The CLIENT requests CONTENT from what it perceives to be the
ORIGIN, however due to URI name space delegation, the request ORIGIN, however due to URI name space delegation, the request is
is actually made to the REQUEST-ROUTING PEERING SYSTEM. actually made to the REQUEST-ROUTING INTERNETWORKING SYSTEM.
Note: Note:
The request routing function may be implied by an in-path The request routing function may be implied by an in-path
network element such as caching proxy, which is typical network element such as caching proxy, which is typical for a
for a Access Content Network. In this case, request Access Content Network. In this case, request routing is
routing is optimized to a null function, since the CLIENT optimized to a null function, since the CLIENT is a priori
is a priori mapped to the SURROGATE. mapped to the SURROGATE.
5. The REQUEST-ROUTING PEERING SYSTEM routes the request to a 5. The REQUEST-ROUTING INTERNETWORKING SYSTEM routes the request to
suitable SURROGATE in a peering CN. REQUEST-ROUTING PEERING a suitable SURROGATE in a peering CN. REQUEST-ROUTING
SYSTEMs interact with one another via feedback ADVERTISEMENTs INTERNETWORKING SYSTEMs interact with one another via feedback
in order to keep request-routing tables current. ADVERTISEMENTs in order to keep request-routing tables current.
6. The selected SURROGATE delivers the requested content to the 6. The selected SURROGATE delivers the requested content to the
CLIENT. Additionally, the SURROGATE sends accounting CLIENT. Additionally, the SURROGATE sends accounting information
information for delivered content to the ACCOUNTING PEERING for delivered content to the ACCOUNTING INTERNETWORKING SYSTEM.
SYSTEM.
7. The ACCOUNTING PEERING SYSTEM aggregates and distills the 7. The ACCOUNTING INTERNETWORKING SYSTEM aggregates and distills the
accounting information into statistics and content detail accounting information into statistics and content detail records
records for use by the ORIGIN and BILLING ORGANIZATION. for use by the ORIGIN and BILLING ORGANIZATION. Statistics are
Statistics are also used as feedback to the REQUEST-ROUTING also used as feedback to the REQUEST-ROUTING INTERNETWORKING
PEERING SYSTEM. SYSTEM.
8. The BILLING ORGANIZATION uses the content detail records to 8. The BILLING ORGANIZATION uses the content detail records to
settle with each of the parties involved in the content settle with each of the parties involved in the content
distribution and delivery process. distribution and delivery process.
This process has been described in its simplest form in order to This process has been described in its simplest form in order to
present the Content Internetworking architecture in the most present the Content Internetworking architecture in the most abstract
abstract way possible. In practice, this process is more complex way possible. In practice, this process is more complex when applied
when applied to policies, business models and service level to policies, business models and service level agreements that span
agreements that span multiple peering Content Networks. The multiple peering Content Networks. The orthogonal core peering
orthogonal core peering systems are discussed in greater depth in systems are discussed in greater depth in Section 3, Section 4 and
Section 3, Section 4 and Section 5 respectively. Section 5 respectively.
Note: Note:
Figure 2 simplifies the presentation of the core Content Figure 2 simplifies the presentation of the core Content
Internetworking elements as single boxes, when in fact they Internetworking elements as single boxes, when in fact they
represent a collection of CPGs and interconnected individual CN represent a collection of CIGs and interconnected individual CN
core system elements. This has been done to introduce the system core system elements. This has been done to introduce the system
architecture at its meta level. architecture at its meta level.
The system architecture does not impose any administrative domain The system architecture does not impose any administrative domain [3]
[3] restrictions on the core peering elements (REQUEST-ROUTING restrictions on the core peering elements (REQUEST-ROUTING
PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM and ACCOUNTING PEERING INTERNETWORKING SYSTEM, DISTRIBUTION INTERNETWORKING SYSTEM and
SYSTEM). The only requirement is that they be authorized by the ACCOUNTING INTERNETWORKING SYSTEM). The only requirement is that
principal parties (ORIGIN and peering CNs) to act in their behalf. they be authorized by the principal parties (ORIGIN and peering CNs)
Thus, it is possible for each of the core elements to be provided by to act in their behalf. Thus, it is possible for each of the core
a different organization. elements to be provided by a different organization.
3. Request-Routing Peering System 3. Request-Routing Internetworking System
The REQUEST-ROUTING PEERING SYSTEM represents the request-routing The REQUEST-ROUTING INTERNETWORKING SYSTEM represents the request-
function of the Content Internetworking system. It is responsible routing function of the Content Internetworking system. It is
for routing CLIENT requests to an appropriate peered CN for the responsible for routing CLIENT requests to an appropriate peered CN
delivery of content. for the delivery of content.
Note: Note:
When the DISTRIBUTION PEERING SYSTEM and/or the ACCOUNTING When the DISTRIBUTION INTERNETWORKING SYSTEM and/or the ACCOUNTING
PEERING SYSTEM is present, it is highly desirable to utilize INTERNETWORKING SYSTEM is present, it is highly desirable to
content location information within the peered CNs and/or system utilize content location information within the peered CNs and/or
load information in the selection of appropriate peered CNs in system load information in the selection of appropriate peered CNs
the routing of requests. in the routing of requests.
3.1 Request-Routing Overview 3.1 Request-Routing Overview
REQUEST-ROUTING SYSTEMs route CLIENT requests to a suitable REQUEST-ROUTING SYSTEMs route CLIENT requests to a suitable
SURROGATE, which is able to service a client request. Many SURROGATE, which is able to service a client request. Many request-
request-routing systems route users to the surrogate that is routing systems route users to the surrogate that is "closest" to the
"closest" to the requesting user, or to the "least loaded" requesting user, or to the "least loaded" surrogate. However, the
surrogate. However, the only requirement of the request-routing only requirement of the request-routing system is that it route users
system is that it route users to a surrogate that can serve the to a surrogate that can serve the requested content.
requested content.
REQUEST-ROUTING PEERING is the interconnection of two or more REQUEST-ROUTING INTERNETWORKING is the interconnection of two or more
REQUEST-ROUTING SYSTEMs so as to increase the number of REACHABLE REQUEST-ROUTING SYSTEMs so as to increase the number of REACHABLE
SURROGATEs for at least one of the interconnected systems. SURROGATEs for at least one of the interconnected systems.
In order for a PUBLISHER's CONTENT to be delivered by multiple In order for a PUBLISHER's CONTENT to be delivered by multiple
peering CNs, it is necessary to federate each Content Network peering CNs, it is necessary to federate each Content Network
REQUEST-ROUTING SYSTEM under the URI name space of the PUBLISHER REQUEST-ROUTING SYSTEM under the URI name space of the PUBLISHER
object. This federation is accomplished by first delegating object. This federation is accomplished by first delegating
authority of the PUBLISHER URI name space to an AUTHORITATIVE authority of the PUBLISHER URI name space to an AUTHORITATIVE
REQUEST-ROUTING SYSTEM. The AUTHORITATIVE REQUEST-ROUTING SYSTEM REQUEST-ROUTING SYSTEM. The AUTHORITATIVE REQUEST-ROUTING SYSTEM
subsequently splices each peering Content Network REQUEST-ROUTING subsequently splices each peering Content Network REQUEST-ROUTING
SYSTEM into this URI name space and transitively delegates URI name SYSTEM into this URI name space and transitively delegates URI name
space authority to them for their participation in request-routing. space authority to them for their participation in request-routing.
Figure 3 is a diagram of the entities involved in the Figure 3 is a diagram of the entities involved in the REQUEST-ROUTING
REQUEST-ROUTING PEERING SYSTEM. INTERNETWORKING SYSTEM.
Note: Note:
For the null request routing case (in path caching proxy For the null request routing case (in path caching proxy present),
present), the caching proxy acts as the SURROGATE. In this case, the caching proxy acts as the SURROGATE. In this case, the
the SURROGATE performs the request routing via its SURROGATE performs the request routing via its pre-established
pre-established proxy relationship with the CLIENT and is proxy relationship with the CLIENT and is implicitly the
implicitly the terminating level of request routing. In essence, terminating level of request routing. In essence, the SURROGATE
the SURROGATE is federated into the URI namespace without the is federated into the URI namespace without the need to
need to communicate with the AUTHORITATIVE REQUEST-ROUTING SYSTEM. communicate with the AUTHORITATIVE REQUEST-ROUTING SYSTEM.
+---------------+ +---------------+
| CLIENT | | CLIENT |
+---------------+ +---------------+
| |
(Request-Routing Tree Root) +---------------+ (Request-Routing Tree Root) +---------------+
| AUTHORITATIVE | | AUTHORITATIVE |
|REQUEST-ROUTING| |REQUEST-ROUTING|
| SYSTEM | | SYSTEM |
+---------------+ +---------------+
| | INTER-CN Request-Routing | | INTER-CN Request-Routing
/----------------/ \-----------------\ /----------------/ \-----------------\
| | | |
(1st Level) +---------------+ +---------------+ (1st Level) +---------------+ +---------------+
.........|REQUEST-ROUTING|.......... .........|REQUEST-ROUTING|......... .........|REQUEST-ROUTING|.......... .........|REQUEST-ROUTING|........
. CN A | CPG | . . CN B | CPG | . . CN A | CIG | . . CN B | CIG | .
. +---------------+ . . +---------------+ . . +---------------+ . . +---------------+ .
. | . . | . . | . . | .
. +---------------+ . . +---------------+ . . +---------------+ . . +---------------+ .
. |REQUEST-ROUTING| . . |REQUEST-ROUTING| . . |REQUEST-ROUTING| . . |REQUEST-ROUTING| .
. | SYSTEM | . . | SYSTEM | . . | SYSTEM | . . | SYSTEM | .
. +---------------+ . . +---------------+ . . +---------------+ . . +---------------+ .
. | | . . | | . . | | . . | | .
. /---/ \-------\ . . /-----/ \----\ . . /---/ \-------\ . . /-----/ \----\ .
. | | . . | | . . | | . . | | .
. +---------------+ | . . | | . . +---------------+ | . . | | .
. |REQUEST-ROUTING| +------------+ . . +-----------+ +------------+ . . |REQUEST-ROUTING| +------------+ . . +-----------+ +-----------+ .
..| CPG |.| SURROGATEs |.. ..| SURROGATE |....| SURROGATES |.. ..| CIG |.| SURROGATEs |.. ..| SURROGATE |....| SURROGATES| .
+---------------+ +------------+ +-----------+ +------------+ +---------------+ +------------+ +-----------+ +-----------+
| INTER-CN Recursive Request-Routing | INTER-CN Recursive Request-Routing
\------\ \------\
| |
(2nd Level) +---------------+ (2nd Level) +---------------+
.........|REQUEST-ROUTING|.......... .........|REQUEST-ROUTING|..........
. CN C | CPG | . . CN C | CIG | .
. +---------------+ . . +---------------+ .
, | . . | .
. +---------------+ . . +---------------+ .
. |REQUEST-ROUTING| . . |REQUEST-ROUTING| .
. | SYSTEM | . . | SYSTEM | .
. +---------------+ . . +---------------+ .
. | | . . | | .
. /----/ \-----\ . . /----/ \-----\ .
. | | . . | | .
. +-----------+ +------------+ . . +-----------+ +------------+ .
..| SURROGATE |....| SURROGATEs |... ..| SURROGATE |....| SURROGATEs |...
+-----------+ +------------+ +-----------+ +------------+
Figure 3 REQUEST-ROUTING INTERNETWORKING SYSTEM Architecture
Figure 3 REQUEST-ROUTING PEERING SYSTEM Architecture The REQUEST-ROUTING INTERNETWORKING SYSTEM is hierarchical in nature.
The REQUEST-ROUTING PEERING SYSTEM is hierarchical in nature. There There exists exactly one request-routing tree for each PUBLISHER URI.
exists exactly one request-routing tree for each PUBLISHER URI. The The AUTHORITATIVE REQUEST-ROUTING SYSTEM is the root of the request-
AUTHORITATIVE REQUEST-ROUTING SYSTEM is the root of the routing tree. There may be only one AUTHORITATIVE REQUEST-ROUTING
request-routing tree. There may be only one AUTHORITATIVE SYSTEM for a URI request-routing tree. Subordinate to the
REQUEST-ROUTING SYSTEM for a URI request-routing tree. Subordinate AUTHORITATIVE REQUEST-ROUTING SYSTEM are the REQUEST-ROUTING SYSTEMs
to the AUTHORITATIVE REQUEST-ROUTING SYSTEM are the REQUEST-ROUTING of the first level peering CNs. There may exist recursive
SYSTEMs of the first level peering CNs. There may exist recursive
subordinate REQUEST-ROUTING SYSTEMs of additional level peering CNs. subordinate REQUEST-ROUTING SYSTEMs of additional level peering CNs.
Note: Note:
A PUBLISHER object may have more than one URI associated with it A PUBLISHER object may have more than one URI associated with it
and therefore be present in more than one request-routing tree. and therefore be present in more than one request-routing tree.
3.2 Request Routing 3.2 Request-Routing
The actual "routing" of a client request is through REQUEST-ROUTING The actual "routing" of a client request is through REQUEST-ROUTING
CPGs. The AUTHORITATIVE REQUEST-ROUTING CPG receives the CLIENT CIGs. The AUTHORITATIVE REQUEST-ROUTING CIG receives the CLIENT
request and forwards the REQUEST to an appropriate DISTRIBUTING CN. request and forwards the REQUEST to an appropriate DISTRIBUTING CN.
This process of INTER-CN request-routing may occur multiple times in This process of INTER-CN request-routing may occur multiple times in
a recursive manner between REQUEST-ROUTING CPGs until the a recursive manner between REQUEST-ROUTING CIGs until the REQUEST-
REQUEST-ROUTING SYSTEM arrives at an appropriate DISTRIBUTING CN to ROUTING SYSTEM arrives at an appropriate DISTRIBUTING CN to deliver
deliver the content. the content.
Note: Note:
The Client request may be for resolution of a URI component and The Client request may be for resolution of a URI component and
not the content of the URI itself. This is the case when DNS is not the content of the URI itself. This is the case when DNS is
being utilized in the request-routing process to resolve the URI being utilized in the request-routing process to resolve the URI
server component. server component.
Request-Routing systems explicitly peer but do not have "interior" Request-Routing systems explicitly peer but do not have "interior"
knowledge of surrogates from other CNs. Each CN operates its knowledge of surrogates from other CNs. Each CN operates its
internal request-routing system. In this manner, request-routing internal request-routing system. In this manner, request-routing
systems peer very much like IP network layer peering. systems peer very much like IP network layer peering.
3.3 System Requirements 3.3 System Requirements
We assume that there is a peering relationship between We assume that there is a peering relationship between REQUEST-
REQUEST-ROUTING CPGs. This peering relationship at a minimum must ROUTING CIGs. This peering relationship at a minimum must exchange a
exchange a set of CLIENT IP addresses that can be serviced, and a set of CLIENT IP addresses that can be serviced, and a set of
set of information about the DISTRIBUTION SYSTEMs, for which they information about the DISTRIBUTION SYSTEMs, for which they are
are performing request-routing. performing request-routing.
Request-Routing Requirements Request-Routing Requirements
1. Use of a URI name space based request-routing mechanism. The 1. Use of a URI name space based request-routing mechanism. The
request-routing mechanism is allowed to use as much of the URI request-routing mechanism is allowed to use as much of the URI
name space as it needs to select the proper SURROGATE. For name space as it needs to select the proper SURROGATE. For
example, DNS based mechanisms utilize only the host example, DNS based mechanisms utilize only the host subcomponent,
subcomponent, while content aware mechanisms utilize use while content aware mechanisms utilize use multiple components.
multiple components.
2. Normalized canonical URI name space structure for peered CN 2. Normalized canonical URI name space structure for peered CN
distribution of PUBLISHER objects. The default in the absence distribution of PUBLISHER objects. The default in the absence of
of encoded meta data is the standard components as defined by encoded meta data is the standard components as defined by [8].
[8]. Encoded meta data must conform to the syntactical grammar Encoded meta data must conform to the syntactical grammar defined
defined in [7]. in [7] .
3. Single AUTHORITATIVE REQUEST-ROUTING SYSTEM for PUBLISHER object 3. Single AUTHORITATIVE REQUEST-ROUTING SYSTEM for PUBLISHER object
URI name space. URI name space.
4. Assure that the request-routing tree remains a tree -- i.e., has 4. Assure that the request-routing tree remains a tree -- i.e., has
no cycles. no cycles.
5. Assure that adjacent request-routing systems from different 5. Assure that adjacent request-routing systems from different
administrative domains (different CNs) use a compatible administrative domains (different CNs) use a compatible request-
request-routing mechanism. routing mechanism.
6. Assure that adjacent request-routing systems from different 6. Assure that adjacent request-routing systems from different
administrative domains (different CNs) agree to forward requests administrative domains (different CNs) agree to forward requests
for the CONTENT in question. for the CONTENT in question.
7. Editor Note:
[Editor Note:
System requirements being generated in the request-routing System requirements being generated in the request-routing
peering protocol design team have not yet been reconciled and peering protocol design team have not yet been reconciled and
integrated into this document.] integrated into this document.]
3.4 Protocol Requirements 3.4 Protocol Requirements
Consult [17] for request-routing peering protocol requirements. The REQUEST-ROUTING INTERNETWORKING system's protocol has a complete
set of requirements that it must implement to solve a variety of
internetworking problems to enable REQUEST-ROUTING systems to peer
each other.
Some of the internetworking problems that the protocol must address
include:
1. Satisfying the need to interconnect a variety of request-routing
system types.
2. Satisfying the need to exchange content and associated meta-data.
3. Satisfying the need to exchange attributes and policies
assoicated with given pieces of content.
For a complete of set of requirements that the Request-Routing
Internetworking protocol needs to satisfy, consult [17].
3.5 Examples 3.5 Examples
Consult [16] for in-depth information on known request-routing Consult [16] for in-depth information on known request-routing
systems. systems.
3.6 Request-Routing Problems to Solve 3.6 Request-Routing Problems to Solve
[Editor Note: Editor Note:
This section is being preserved until it has been determined that This section is being preserved until it has been determined that
these issues have been addressed in the request-routing peering these issues have been addressed in the request-routing peering
protocol requirements draft.] protocol requirements draft.]
Specific problems in request-routing needing further investigation Specific problems in request-routing needing further investigation
include: include:
1. What is the aggregated granularity of CLIENT IP address being 1. What is the aggregated granularity of CLIENT IP address being
serviced by a peering CN's DISTRIBUTION SYSTEM? serviced by a peering CN's DISTRIBUTION SYSTEM?
2. How do DNS request-routing systems forward a request? If a 2. How do DNS request-routing systems forward a request? If a given
given CN is peered with many other CNs, what are the criteria CN is peered with many other CNs, what are the criteria that
that forwards a request to another CN? forwards a request to another CN?
3. How do content-aware request-routing systems forward a request? 3. How do content-aware request-routing systems forward a request?
If a given CN is peered with many other CNs, what are the If a given CN is peered with many other CNs, what are the
criteria that forwards a request to another CN? criteria that forwards a request to another CN?
4. What are the merits of designing a generalized content routing 4. What are the merits of designing a generalized content routing
protocol, rather than relying on request-routing mechanisms. protocol, rather than relying on request-routing mechanisms.
5. What is the normalized canonical URI name space for 5. What is the normalized canonical URI name space for request-
request-routing? Because request-routing is federated across routing? Because request-routing is federated across multiple
multiple CNs, it is necessary to have agreed upon standards for CNs, it is necessary to have agreed upon standards for the
the encoding of meta data in URIs. There are many potential encoding of meta data in URIs. There are many potential
elements, which may be encoded. Some of these elements are: elements, which may be encoded. Some of these elements are:
authoritative agent domain, publisher domain, content type, authoritative agent domain, publisher domain, content type,
content length, etc. content length, etc.
6. How are policies communicated between the REQUEST-ROUTING SYSTEM 6. How are policies communicated between the REQUEST-ROUTING SYSTEM
and the DISTRIBUTION ADVERTISEMENT SYSTEM? A given CN may wish and the DISTRIBUTION ADVERTISEMENT SYSTEM? A given CN may wish
to serve only a given content type or a particular set of users. to serve only a given content type or a particular set of users.
These types of policies must be communicated between CNs. These types of policies must be communicated between CNs.
7. What are the request-routing protocols in DNS? When a request is 7. What are the request-routing protocols in DNS? When a request is
routed to a particular REQUEST-ROUTING CPG, a clear set of DNS routed to a particular REQUEST-ROUTING CIG, a clear set of DNS
rules and policies must be followed in order to have a workable rules and policies must be followed in order to have a workable
and predictable system. and predictable system.
8. How do we protect the REQUEST-ROUTING SYSTEM against denial of 8. How do we protect the REQUEST-ROUTING SYSTEM against denial of
service attacks? service attacks?
9. How do we select the appropriate peering CN for DELIVERY? 9. How do we select the appropriate peering CN for DELIVERY?
Note:
The selection process must to consider the distribution The selection process must to consider the distribution
policies involved in Section 4. Investigation into other policies involved in Section 4. Investigation into other
policy "work in progress" within the IETF is needed to policy "work in progress" within the IETF is needed to
understand the relationship of policies developed within understand the relationship of policies developed within
Content Internetworking. Content Internetworking.
4. Distribution Peering System 4. Distribution Internetworking System
The DISTRIBUTION PEERING SYSTEM represents the content distribution The DISTRIBUTION INTERNETWORKING SYSTEM represents the content
function of the CN peering system. It is responsible for moving distribution function of the CN peering system. It is responsible
content from one DISTRIBUTION CPG to another DISTRIBUTION CPG and for moving content from one DISTRIBUTION CIG to another DISTRIBUTION
for supplying content location information to the REQUEST-ROUTING CIG and for supplying content location information to the REQUEST-
PEERING SYSTEM. ROUTING INTERNETWORKING SYSTEM.
4.1 Distribution Overview 4.1 Distribution Overview
One goal of the Content Internetworking system is to move content One goal of the Content Internetworking system is to move content
closer to the CLIENT. Typically this is accomplished by copying closer to the CLIENT. Typically this is accomplished by copying
content from its ORIGIN to SURROGATEs. The SURROGATEs then have the content from its ORIGIN to SURROGATEs. The SURROGATEs then have the
CONTENT available when it is requested by a CLIENT. Even with a CONTENT available when it is requested by a CLIENT. Even with a
single PUBLISHER and single CN, the copying of CONTENT to a single PUBLISHER and single CN, the copying of CONTENT to a SURROGATE
SURROGATE may traverse a number of links, some in the PUBLISHER's may traverse a number of links, some in the PUBLISHER's network, some
network, some in the CN's network, and some between those two in the CN's network, and some between those two networks. For
networks. For DISTRIBUTION PEERING, we consider only the DISTRIBUTION INTERNETWORKING, we consider only the communication
communication "between" two networks, and ignore the mechanisms for "between" two networks, and ignore the mechanisms for copying CONTENT
copying CONTENT within a network. within a network.
In the above example the last server on the content provider's In the above example the last server on the content provider's
network in the path, and the first server on the CN's network in the network in the path, and the first server on the CN's network in the
path, must contain DISTRIBUTION CPGs which communicate directly with path, must contain DISTRIBUTION CIGs which communicate directly with
each other. The DISTRIBUTION CPGs could be located in the ORIGIN each other. The DISTRIBUTION CIGs could be located in the ORIGIN
server and the SURROGATE server. Thus in the simplest form the server and the SURROGATE server. Thus in the simplest form the
ORIGIN server is in direct contact with the SURROGATE. However the ORIGIN server is in direct contact with the SURROGATE. However the
DISTRIBUTION CPG in the content provider's network could aggregate DISTRIBUTION CIG in the content provider's network could aggregate
content from multiple ORIGIN servers and the DISTRIBUTION CPG in the content from multiple ORIGIN servers and the DISTRIBUTION CIG in the
CN's network could represent multiple SURROGATEs. These DISTRIBUTION CN's network could represent multiple SURROGATEs. These DISTRIBUTION
CPGs could then be co-located in an exchange facility. In fact, CIGs could then be co-located in an exchange facility. In fact,
given the common practice of independently managed IP peering given the common practice of independently managed IP peering co-
co-location exchange facilities for layer 3, there exists the location exchange facilities for layer 3, there exists the distinct
distinct opportunity to create similar exchanges for CPGs. opportunity to create similar exchanges for CIGs.
Figure 4 is a diagram of the entities involved in the DISTRIBUTION Figure 4 is a diagram of the entities involved in the DISTRIBUTION
PEERING SYSTEM. INTERNETWORKING SYSTEM.
+--------+ +--------+
| ORIGIN | | ORIGIN |
+--------+ +--------+
| | INJECTION | | INJECTION
/------------------/ \----------------\ /------------------/ \----------------\
| | | |
+--------------+ +--------------+ +--------------+ +--------------+
.........| DISTRIBUTION |........... ...........| DISTRIBUTION |........ .........| DISTRIBUTION |........... ...........| DISTRIBUTION |......
. CN A | CPG | . . CN B | CPG | . . CN A | CIG | . . CN B | CIG | .
. +--------------+ . . +--------------+ . . +--------------+ . . +--------------+ .
. | . . | . . | . . | .
. +--------------+ . . +--------------+ . . +--------------+ . . +--------------+ .
. | DISTRIBUTION | . . | DISTRIBUTION | . . | DISTRIBUTION | . . | DISTRIBUTION | .
. | SYSTEM | . . | SYSTEM | . . | SYSTEM | . . | SYSTEM | .
. +--------------+ . . +--------------+ . . +--------------+ . . +--------------+ .
. | | . . | | . . | | . . | | .
. /-----/ \-------\ . . /-----/ \----\ . . /-----/ \-------\ . . /-----/ \----\ .
. | | . . | | . . | | . . | | .
. | +--------------+ . . +--------------+ | . . | +--------------+ . . +--------------+ | .
. +------------+ | DISTRIBUTION | . . | DISTRIBUTION | +------------+ . . +------------+ | DISTRIBUTION | . . | DISTRIBUTION | +----------+ .
..| SURROGATEs |.| CPG |... ..| CPG |.| SURROGATEs |.. ..| SURROGATEs |.| CIG |... ..| CIG |.|SURROGATEs|..
+------------+ +--------------+ +--------------+ +------------+ +------------+ +--------------+ +--------------+ +----------+
| | | | | | | |
| \-----------------/ | | \-----------------/ |
\----------\ /-----------/ \----------\ /-----------/
| | INTER-CN DISTRIBUTION PEERING | | INTER-CN DISTRIBUTION INTERNETWORKING
| | | |
+--------------+ +--------------+
.........| DISTRIBUTION |........... .........| DISTRIBUTION |...........
. CN C | CPG | . . CN C | CIG | .
. +--------------+ . . +--------------+ .
. | . . | .
. +--------------+ . . +--------------+ .
. | DISTRIBUTION | . . | DISTRIBUTION | .
. | SYSTEM | . . | SYSTEM | .
. +--------------+ . . +--------------+ .
. | | . . | | .
. /-----/ \-------\ . . /-----/ \-------\ .
. | | . . | | .
. | | . . | | .
. +-----------+ +------------+ . . +-----------+ +------------+ .
..| SURROGATE |.....| SURROGATEs |.. ..| SURROGATE |.....| SURROGATEs |..
+-----------+ +------------+ +-----------+ +------------+
Figure 4 DISTRIBUTION PEERING SYSTEM Architecture Figure 4 DISTRIBUTION INTERNETWORKING SYSTEM Architecture
While Content Internetworking in general relates to interfacing with While Content Internetworking in general relates to interfacing with
CNs, there are two CN distribution peering relationships we expect CNs, there are two CN distribution peering relationships we expect to
to be common; INTER-CN distribution peering and INJECTION peering. be common; INTER-CN distribution peering and INJECTION peering.
INTER-CN distribution peering involves distributing CONTENT between INTER-CN distribution peering involves distributing CONTENT between
individual CNs in a inter-network of peered CNs. INJECTION peering individual CNs in a inter-network of peered CNs. INJECTION peering
involves the publishing of CONTENT directly into CNs by ORIGINs. involves the publishing of CONTENT directly into CNs by ORIGINs.
4.2 Distribution Models 4.2 Distribution Models
Replication ADVERTISEMENTs may take place in a model similar to the Replication ADVERTISEMENTs may take place in a model similar to the
way IP routing table updates are done between BGP routers. way IP routing table updates are done between BGP routers.
DISTRIBUTION CPGs could take care of exterior content replication DISTRIBUTION CIGs could take care of exterior content replication
between content providers and CNs, while at the same time performing between content providers and CNs, while at the same time performing
content replication interior to their networks in an independent content replication interior to their networks in an independent
manner. If this model is used then the internal structure of the manner. If this model is used then the internal structure of the
networks is hidden and the only knowledge of other networks is the networks is hidden and the only knowledge of other networks is the
locations of DISTRIBUTION CPGs. locations of DISTRIBUTION CIGs.
Replication of content may take place using a push model, or a pull Replication of content may take place using a push model, or a pull
model, or a combination of both. Use initiated replication, where model, or a combination of both. Use initiated replication, where
SURROGATEs, upon getting a cache miss, retrieve CONTENT from the SURROGATEs, upon getting a cache miss, retrieve CONTENT from the
DISTRIBUTION SYSTEM, represents the pull model. ORIGIN initiated DISTRIBUTION SYSTEM, represents the pull model. ORIGIN initiated
replication of CONTENT to SURROGATEs represents the push model. replication of CONTENT to SURROGATEs represents the push model.
DISTRIBUTION CPGs may be located at various points in these models DISTRIBUTION CIGs may be located at various points in these models
depending on the topologies of the networks involved. depending on the topologies of the networks involved.
With Content Internetworking it may be desirable to replicate With Content Internetworking it may be desirable to replicate content
content through a network, which has no internal SURROGATEs. For through a network, which has no internal SURROGATEs. For example add
example add a exchange network between the content provider network a exchange network between the content provider network and the CN
and the CN network to the example above. The exchange network could network to the example above. The exchange network could have a
have a DISTRIBUTION CPG co-located with the content provider's DISTRIBUTION CIG co-located with the content provider's DISTRIBUTION
DISTRIBUTION CPG, which acts as a proxy for the CN. The exchange CIG, which acts as a proxy for the CN. The exchange network could
network could also have a DISTRIBUTION CPG co-located with the CN's also have a DISTRIBUTION CIG co-located with the CN's DISTRIBUTION
DISTRIBUTION CPG, which acts as a proxy for the content provider. In CIG, which acts as a proxy for the content provider. In a
a consolidated example, the exchange network could have a single consolidated example, the exchange network could have a single
DISTRIBUTION CPG that acts as a proxy for both the content provider DISTRIBUTION CIG that acts as a proxy for both the content provider
and the CN. and the CN.
Replication of CONTINUOUS MEDIA that is not to be cached on Replication of CONTINUOUS MEDIA that is not to be cached on
SURROGATEs, such as live streaming broadcasts, takes place in a SURROGATEs, such as live streaming broadcasts, takes place in a
different model from content that is to be persistently stored. different model from content that is to be persistently stored.
Replication in this case, typically takes the form of splitting the Replication in this case, typically takes the form of splitting the
live streaming data at various points in the network. In Content live streaming data at various points in the network. In Content
Internetworking, DISTRIBUTION CPGs may support CONTINUOUS MEDIA Internetworking, DISTRIBUTION CIGs may support CONTINUOUS MEDIA
splitting replication, as they likely provide ideal network splitting replication, as they likely provide ideal network topologic
topologic points for application layer multicasting. points for application layer multicasting.
4.3 Distribution Components 4.3 Distribution Components
The three main components of DISTRIBUTION PEERING are replication, The three main components of DISTRIBUTION INTERNETWORKING are
signaling and advertising. replication, signaling and advertising.
The first component of content distribution is replication. The first component of content distribution is replication.
Replication involves moving the content from an ORIGIN server to Replication involves moving the content from an ORIGIN server to
SURROGATE servers. The immediate goal in CN peering is moving the SURROGATE servers. The immediate goal in CN peering is moving the
content between DISTRIBUTION CPGs. content between DISTRIBUTION CIGs.
The second component of content distribution is content signaling. The second component of content distribution is content signaling.
Content signaling is the propagation of content meta-data. This Content signaling is the propagation of content meta-data. This
meta-data may include such information such as the immediate meta-data may include such information such as the immediate
expiration of content or a change in the expiration time of CONTENT. expiration of content or a change in the expiration time of CONTENT.
The immediate goal in signaling is exchanging signals between The immediate goal in signaling is exchanging signals between
DISTRIBUTION CPGs. DISTRIBUTION CIGs.
The third component of content distribution is content advertising. The third component of content distribution is content advertising.
Content providers must be able to advertise content that can be Content providers must be able to advertise content that can be
distributed by CNs and its associated terms. It is important that distributed by CNs and its associated terms. It is important that
the advertising of content must be able to aggregate content the advertising of content must be able to aggregate content
information. The immediate goal in advertising is exchanging information. The immediate goal in advertising is exchanging
advertisements between DISTRIBUTION CPGs. advertisements between DISTRIBUTION CIGs.
4.4 Distribution System Requirements 4.4 Distribution System Requirements
Replication systems must have a peering relationship. This peering Replication systems must have a peering relationship. This peering
relationship must exchange sets of aggregated content and its relationship must exchange sets of aggregated content and its meta-
meta-data. Meta-data may change over time independently of the data. Meta-data may change over time independently of the content
content data and must be exchanged independently as well. data and must be exchanged independently as well.
4.4.1 Replication Requirements 4.4.1 Replication Requirements
The specific requirements in content replication are: The specific requirements in content replication are:
1. A common protocol for the replication of content. 1. A common protocol for the replication of content.
2. A common format for the actual content data in the protocol. 2. A common format for the actual content data in the protocol.
3. A common format for the content meta-data in the protocol. 3. A common format for the content meta-data in the protocol.
skipping to change at page 21, line 36 skipping to change at page 22, line 22
3. Scalable distribution of the signals on a large scale. 3. Scalable distribution of the signals on a large scale.
Editor Note: Editor Note:
We have to start being quantitative about what we mean by We have to start being quantitative about what we mean by
"large scale". Are we thinking in terms of the number of "large scale". Are we thinking in terms of the number of
content items, the number of networks, or the number of content items, the number of networks, or the number of
signals? For each of those, how big is "large scale"? signals? For each of those, how big is "large scale"?
4. Content location and serviced CLIENT IP aggregate address 4. Content location and serviced CLIENT IP aggregate address
exchanges with REQUEST-ROUTING CPGs. exchanges with REQUEST-ROUTING CIGs.
4.4.3 Advertising Requirements 4.4.3 Advertising Requirements
The specific requirements in CONTENT ADVERTISEMENT are: The specific requirements in CONTENT ADVERTISEMENT are:
1. A common protocol for the ADVERTISEMENT of CONTENT. 1. A common protocol for the ADVERTISEMENT of CONTENT.
2. A common format for the actual ADVERTISEMENTs in the protocol. 2. A common format for the actual ADVERTISEMENTs in the protocol.
Editor Note: Editor Note:
The following requirements need further discussion. As it The following requirements need further discussion. As it
stands now, there isn't sufficient information to stands now, there isn't sufficient information to substantiate
substantiate them. them.
3. A well-known state machine. 3. A well-known state machine.
4. Use of TCP or SCTP (because soft-state protocols will not scale). 4. Use of TCP or SCTP (because soft-state protocols will not scale).
5. Well-known error codes to diagnose protocols between different 5. Well-known error codes to diagnose protocols between different
networks. networks.
6. Capability negotiation. 6. Capability negotiation.
7. Ability to represent policy. 7. Ability to represent policy.
[Editor Note: Editor Note:
System requirements being generated in the distribution peering System requirements being generated in the distribution
protocol design team have not yet been reconciled and integrated peering protocol design team have not yet been reconciled and
into this document.] integrated into this document.]
4.5 Protocol Requirements 4.5 Protocol Requirements
Consult [18] for distribution peering protocol requirements. Consult [18] for distribution internetworking protocol requirements.
4.6 Distribution Problems to Solve 4.6 Distribution Problems to Solve
[Editor Note: [Editor Note:
This section is being preserved until it has been determined that This section is being preserved until it has been determined that
these issues have been addressed in the distribution peering these issues have been addressed in the distribution peering
protocol requirements draft.] protocol requirements draft.]
Some of the problems in distribution revolve around supporting both Some of the problems in distribution revolve around supporting both a
a push model and a pull model for replication of content in that push model and a pull model for replication of content in that they
they are not symmetric. The push model is used for pre-loading of are not symmetric. The push model is used for pre-loading of content
content and the pull model is used for on-demand fetching and and the pull model is used for on-demand fetching and pre-fetching of
pre-fetching of content. These models are not symmetric in that the content. These models are not symmetric in that the amount of
amount of available resources in which to place the content on the available resources in which to place the content on the target
target server must be known. In the fetching cases the server that server must be known. In the fetching cases the server that pulls
pulls the content knows the available resources on the target the content knows the available resources on the target server,
server, itself. In the pre-loading case the server that pushes the itself. In the pre-loading case the server that pushes the content
content must find out the available resources from the target server must find out the available resources from the target server before
before pushing the data. pushing the data.
4.6.1 General Problems 4.6.1 General Problems
General problems in distribution peering needing further General problems in distribution peering needing further
investigation include: investigation include:
1. How would a single distribution peering protocol adequately 1. How would a single distribution peering protocol adequately
support replication, signaling and advertising? support replication, signaling and advertising?
2. Should a single distribution peering protocol be considered, 2. Should a single distribution peering protocol be considered,
rather than separate protocols for each component? rather than separate protocols for each component?
3. How do we prevent looping of distribution updates? That is to 3. How do we prevent looping of distribution updates? That is to
say, detect and stop propagating replication, signaling and say, detect and stop propagating replication, signaling and
advertisement of events a DISTRIBUTION CPG has already issued. advertisement of events a DISTRIBUTION CIG has already issued.
Looping here has the possibility of becoming infinite, if not Looping here has the possibility of becoming infinite, if not
bounded by the protocol(s). IP route updating and forwarding bounded by the protocol(s). IP route updating and forwarding has
has faced similar issues and has solved them. faced similar issues and has solved them.
4.6.2 Replication Problems 4.6.2 Replication Problems
Specific problems in replication needing further investigation Specific problems in replication needing further investigation
include: include:
1. How do replication systems forward a request? 1. How do replication systems forward a request?
2. How do we keep pull based replication serviced within the 2. How do we keep pull based replication serviced within the
DISTRIBUTION CPGs in order to prevent it from inadvertently DISTRIBUTION CIGs in order to prevent it from inadvertently
bleeding out into REQUEST-ROUTING SYSTEM and potentially getting bleeding out into REQUEST-ROUTING SYSTEM and potentially getting
into a recursive loop? into a recursive loop?
3. How are policies communicated between the replication systems? 3. How are policies communicated between the replication systems?
4. What are the replication protocols? 4. What are the replication protocols?
5. Does replication only take place between CPGs? 5. Does replication only take place between CIGs?
4.6.3 Signaling Problems 4.6.3 Signaling Problems
Specific problems in content signaling needing further investigation Specific problems in content signaling needing further investigation
include: include:
1. How do we represent a content signal? 1. How do we represent a content signal?
2. What content meta-data needs to be signaled? 2. What content meta-data needs to be signaled?
skipping to change at page 24, line 4 skipping to change at page 24, line 41
6. Do content signals need a virtual distribution system of their 6. Do content signals need a virtual distribution system of their
own? own?
4.6.4 Advertising Problems 4.6.4 Advertising Problems
Specific problems in CONTENT ADVERTISEMENT needing further Specific problems in CONTENT ADVERTISEMENT needing further
investigation include: investigation include:
1. How do we represent aggregates of content to be distributed in a 1. How do we represent aggregates of content to be distributed in a
concise and compressed manner? concise and compressed manner?
2. What protocol(s) should be used for the aggregation of this data? 2. What protocol(s) should be used for the aggregation of this data?
3. What are the issues involved in the creation of CPG exchanges? 3. What are the issues involved in the creation of CIG exchanges?
This is actually a broader question than just for distribution, This is actually a broader question than just for distribution,
but needs to be considered for all forms of CPGs but needs to be considered for all forms of CIGs {REQUEST-
{REQUEST-ROUTING, DISTRIBUTION, ACCOUNTING}. ROUTING, DISTRIBUTION, ACCOUNTING}.
5. Accounting Peering System 5. Accounting Internetworking System
The ACCOUNTING PEERING SYSTEM represents the accounting data The ACCOUNTING INTERNETWORKING SYSTEM represents the accounting data
collection function of the Content Internetworking system. It is collection function of the Content Internetworking system. It is
responsible for moving accounting data from one ACCOUNTING CPG to responsible for moving accounting data from one ACCOUNTING CIG to
another ACCOUNTING CPG. another ACCOUNTING CIG.
5.1 Accounting Overview 5.1 Accounting Overview
Content Internetworking must provide the ability for the content Content Internetworking must provide the ability for the content
provider to collect data regarding the delivery of their CONTENT by provider to collect data regarding the delivery of their CONTENT by
the peered CNs. ACCOUNTING CPGs exchange the data collected by the the peered CNs. ACCOUNTING CIGs exchange the data collected by the
interior ACCOUNTING SYSTEMS. This interior data may be collected interior ACCOUNTING SYSTEMS. This interior data may be collected
from the SURROGATEs by ACCOUNTING CPGs using SNMP or FTP, for from the SURROGATEs by ACCOUNTING CIGs using SNMP or FTP, for
example. ACCOUNTING CPGs may transfer the data to exterior example. ACCOUNTING CIGs may transfer the data to exterior
neighboring ACCOUNTING CPGs on request (push), in an asynchronous neighboring ACCOUNTING CIGs on request (push), in an asynchronous
manner (push), or a combination of both. Accounting data may also be manner (push), or a combination of both. Accounting data may also be
aggregated before it is transferred. aggregated before it is transferred.
Figure 5 is a diagram of the entities involved in the ACCOUNTING Figure 5 is a diagram of the entities involved in the ACCOUNTING
PEERING SYSTEM. INTERNETWORKING SYSTEM.
+---------+ +---------+
| BILLING | +--------+ | BILLING | +--------+
| ORG. | | ORIGIN | | ORG. | | ORIGIN |
+---------+ +--------+ +---------+ +--------+
BILLING | | ACCOUNTING PEERING | | ORIGIN ACCOUNTING PEERING BILLING | | ACCOUNTING INTERNETWORKING | | ORIGIN ACCOUNTING INTERNETWORKING
/-----/ \-----------------------|-|----\ /-----/ \-----------------------|-|----\
| /-----------------------------/ \----|-\ | /-----------------------------/ \----|-\
| | | | | | | |
+--------------+ +--------------+ +--------------+ +--------------+
.........| ACCOUNTING |........... ...........| ACCOUNTING |........ .........| ACCOUNTING |........... ...........| ACCOUNTING |......
. CN A | CPG | . . CN B | CPG | . . CN A | CIG | . . CN B | CIG | .
. +--------------+ . . +--------------+ . . +--------------+ . . +--------------+ .
. | . . | . . | . . | .
. +--------------+ . . +--------------+ . . +--------------+ . . +--------------+ .
. | ACCOUNTING | . . | ACCOUNTING | . . | ACCOUNTING | . . | ACCOUNTING | .
. | SYSTEM | . . | SYSTEM | . . | SYSTEM | . . | SYSTEM | .
. +--------------+ . . +--------------+ . . +--------------+ . . +--------------+ .
. | | . . | | . . | | . . | | .
. /-----/ \-------\ . . /-----/ \----\ . . /-----/ \-------\ . . /-----/ \----\ .
. | | . . | | . . | | . . | | .
. | +--------------+ . . +--------------+ | . . | +--------------+ . . +--------------+ | .
. +------------+ | ACCOUNTING | . . | ACCOUNTING | +------------+ . . +------------+ | ACCOUNTING | . . | ACCOUNTING | +----------+ .
..| SURROGATEs |.| CPG |... ..| CPG |.| SURROGATEs |.. ..| SURROGATEs |.| CIG |... ..| CIG |.|SURROGATEs|..
+------------+ +--------------+ +--------------+ +------------+ +------------+ +--------------+ +--------------+ +----------+
| | | | | | | |
| \-----------------/ | | \-----------------/ |
\----------\ /-----------/ \----------\ /-----------/
| | INTER-CN ACCOUNTING PEERING | | INTER-CN ACCOUNTING INTERNETWORKING
| | | |
+--------------+ +--------------+
.........| ACCOUNTING |........... .........| ACCOUNTING |...........
. CN C | CPG | . . CN C | CIG | .
. +--------------+ . . +--------------+ .
. | . . | .
. +--------------+ . . +--------------+ .
. | ACCOUNTING | . . | ACCOUNTING | .
. | SYSTEM | . . | SYSTEM | .
. +--------------+ . . +--------------+ .
. | | . . | | .
. /-----/ \-------\ . . /-----/ \-------\ .
. | | . . | | .
. | | . . | | .
. +-----------+ +------------+ . . +-----------+ +------------+ .
..| SURROGATE |.....| SURROGATEs |.. ..| SURROGATE |.....| SURROGATEs |..
+-----------+ +------------+ +-----------+ +------------+
Figure 5 ACCOUNTING Internetworking Ssystem Architecture
Figure 5 ACCOUNTING Peering system Architecture
There are three CN accounting peering relationships we expect to be There are three CN accounting peering relationships we expect to be
common; INTER-CN accounting peering, BILLING ORGANIZATION accounting common; INTER-CN accounting peering, BILLING ORGANIZATION accounting
peering and ORIGIN accounting peering. INTER-CN accounting peering peering and ORIGIN accounting peering. INTER-CN accounting peering
involves exchanging accounting information between individual CNs in involves exchanging accounting information between individual CNs in
a inter-network of peered CNs. BILLING ORGANIZATION peering involves a inter-network of peered CNs. BILLING ORGANIZATION peering involves
exchanging to accounting information between CNs and a billing exchanging to accounting information between CNs and a billing
organization. ORIGIN accounting peering involves the exchanging of organization. ORIGIN accounting peering involves the exchanging of
accounting information between CNs and ORIGINs. accounting information between CNs and ORIGINs.
Note: Note:
It is not necessary for an ORIGIN to peer directly with multiple It is not necessary for an ORIGIN to peer directly with multiple
CNs in order to participate in Content Internetworking. ORIGINs CNs in order to participate in Content Internetworking. ORIGINs
participating in a single home CN will be indirectly peered by participating in a single home CN will be indirectly peered by
their home CN with the inter-network of CNs the home CN is a their home CN with the inter-network of CNs the home CN is a
member of. Nor is it necessary to have a BILLING ORGANIZATION member of. Nor is it necessary to have a BILLING ORGANIZATION
peer, since this function may also be provided by the home CN. peer, since this function may also be provided by the home CN.
However, ORIGINs that directly peer for ACCOUNTING may have However, ORIGINs that directly peer for ACCOUNTING may have access
access to greater accounting detail. Also, through the use of to greater accounting detail. Also, through the use of ACCOUNTING
ACCOUNTING peering, 3rd party billing can be provided. peering, 3rd party billing can be provided.
5.2 Accounting System Requirements 5.2 Accounting System Requirements
[Editor Note: [Editor Note:
System requirements being generated in the accounting peering System requirements being generated in the accounting peering
protocol design team have not yet been reconciled and integrated protocol design team have not yet been reconciled and integrated
into this document.] into this document.]
5.3 Protocol Requirements 5.3 Protocol Requirements
Consult [15] for accounting peering protocol requirements. Consult [15] for accounting internetworking protocol requirements.
6. Security Considerations 6. Security Considerations
Security concerns with respect to Content Internetworking can be Security concerns with respect to Content Internetworking can be
generally categorized into trust within the system and protection of generally categorized into trust within the system and protection of
the system from threats. The trust model utilized with Content the system from threats. The trust model utilized with Content
Internetworking is predicated largely on transitive trust between Internetworking is predicated largely on transitive trust between the
the ORIGIN, REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION
SYSTEM, ACCOUNTING PEERING SYSTEM and SURROGATES. Network elements INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORKING SYSTEM and
within the Content Internetworking system are considered to be SURROGATES. Network elements within the Content Internetworking
"insiders" and therefore trusted. system are considered to be "insiders" and therefore trusted.
6.1 Threats to Content Internetworking 6.1 Threats to Content Networking
The following sections document key threats to CLIENTs, PUBLISHERs, The following sections document key threats to CLIENTs, PUBLISHERs,
and CNs. The threats are classified according to the party that they and CNs. The threats are classified according to the party that they
most directly harm, but, of course, a threat to any party is most directly harm, but, of course, a threat to any party is
ultimately a threat to all. (For example, having a credit card ultimately a threat to all. (For example, having a credit card
number stolen may most directly affect a CLIENT; however, the number stolen may most directly affect a CLIENT; however, the
resulting dissatisfaction and publicity will almost certainly cause resulting dissatisfaction and publicity will almost certainly cause
some harm to the PUBLISHER and CN, even if the harm is only to those some harm to the PUBLISHER and CN, even if the harm is only to those
organizations' reputations.) organizations' reputations.)
skipping to change at page 28, line 39 skipping to change at page 28, line 39
6.1.1.1 Defeat of CLIENT's Security Settings 6.1.1.1 Defeat of CLIENT's Security Settings
Because the SURROGATE's location may differ from that of the ORIGIN, Because the SURROGATE's location may differ from that of the ORIGIN,
the use of a SURROGATE may inadvertently or maliciously defeat any the use of a SURROGATE may inadvertently or maliciously defeat any
location-based security settings employed by the CLIENT. And since location-based security settings employed by the CLIENT. And since
the SURROGATE's location is generally transparent to the CLIENT, the the SURROGATE's location is generally transparent to the CLIENT, the
CLIENT may be unaware that its protections are no longer in force. CLIENT may be unaware that its protections are no longer in force.
For example, a CN may relocate CONTENT from a Internet Explorer For example, a CN may relocate CONTENT from a Internet Explorer
user's "Internet Web Content Zone" to that user's "Local Intranet user's "Internet Web Content Zone" to that user's "Local Intranet
Web Content Zone." If the relocation is visible to the Internet Web Content Zone." If the relocation is visible to the Internet
Explorer browser but otherwise invisible to the user, the browser Explorer browser but otherwise invisible to the user, the browser may
may be employing less stringent security protections than the user be employing less stringent security protections than the user is
is expecting for that CONTENT. (Note that this threat differs, at expecting for that CONTENT. (Note that this threat differs, at least
least in degree, from the substitution of security parameters threat in degree, from the substitution of security parameters threat below,
below, as Web Content Zones can control whether or not, for example, as Web Content Zones can control whether or not, for example, the
the browser executes unsigned active content.) browser executes unsigned active content.)
6.1.1.2 Delivery of Bad Accounting Information 6.1.1.2 Delivery of Bad Accounting Information
In the case of CONTENT with value, CLIENTs may be inappropriately In the case of CONTENT with value, CLIENTs may be inappropriately
charged for viewing content that they did not successfully access. charged for viewing content that they did not successfully access.
Conversely, some PUBLISHERs may reward CLIENTs for viewing certain Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
CONTENT (e.g. programs that "pay" users to surf the Web). Should a CONTENT (e.g. programs that "pay" users to surf the Web). Should a
CN fail to deliver appropriate accounting information, the CLIENT CN fail to deliver appropriate accounting information, the CLIENT may
may not receive appropriate credit for viewing the required CONTENT. not receive appropriate credit for viewing the required CONTENT.
6.1.1.3 Delivery of Bad CONTENT 6.1.1.3 Delivery of Bad Content
A CN that does not deliver the appropriate CONTENT may provide the A CN that does not deliver the appropriate CONTENT may provide the
user misleading information (either maliciously or inadvertently). user misleading information (either maliciously or inadvertently).
This threat can be manifested as a failure of either the This threat can be manifested as a failure of either the DISTRIBUTION
DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or
SURROGATEs) or REQUEST-ROUTING SYSTEM (request routing to REQUEST-ROUTING SYSTEM (request routing to inappropriate SURROGATEs,
inappropriate SURROGATEs, even though they may have appropriate even though they may have appropriate CONTENT), or both. A REQUEST-
CONTENT), or both. A REQUEST-ROUTING SYSTEM may also fail by ROUTING SYSTEM may also fail by forwarding the CLIENT request when no
forwarding the CLIENT request when no forwarding is appropriate, or forwarding is appropriate, or by failing to forward the CLIENT
by failing to forward the CLIENT request when forwarding is request when forwarding is appropriate.
appropriate.
6.1.1.4 Denial of Service 6.1.1.4 Denial of Service
A CN that does not forward the CLIENT appropriately may deny the A CN that does not forward the CLIENT appropriately may deny the
CLIENT access to CONTENT. CLIENT access to CONTENT.
6.1.1.5 Exposure of Private Information 6.1.1.5 Exposure of Private Information
CNs may inadvertently or maliciously expose private information CNs may inadvertently or maliciously expose private information
(passwords, buying patterns, page views, credit card numbers) as it (passwords, buying patterns, page views, credit card numbers) as it
skipping to change at page 29, line 44 skipping to change at page 29, line 44
secure than the CLIENT expects. secure than the CLIENT expects.
6.1.1.7 Substitution of Security Policies 6.1.1.7 Substitution of Security Policies
If a SURROGATE does not employ the same security policies and If a SURROGATE does not employ the same security policies and
procedures as the ORIGIN, the CLIENT's private information may be procedures as the ORIGIN, the CLIENT's private information may be
treated with less care than the CLIENT expects. For example, the treated with less care than the CLIENT expects. For example, the
operator of a SURROGATE may not have as rigorous protection for 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 CLIENT's password as does the operator of the ORIGIN server. This
threat may also manifest itself if the legal jurisdiction of the threat may also manifest itself if the legal jurisdiction of the
SURROGATE differs from that of the ORIGIN, should, for example, SURROGATE differs from that of the ORIGIN, should, for example, legal
legal differences between the jurisdictions require or permit differences between the jurisdictions require or permit different
different treatment of the CLIENT's private information. treatment of the CLIENT's private information.
6.1.2 Threats to the PUBLISHER 6.1.2 Threats to the PUBLISHER
6.1.2.1 Delivery of Bad Accounting Information 6.1.2.1 Delivery of Bad Accounting Information
If a CN does not deliver accurate accounting information, the If a CN does not deliver accurate accounting information, the
PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it
it may reward CLIENTs inappropriately. Inaccurate accounting may reward CLIENTs inappropriately. Inaccurate accounting
information may also cause a PUBLISHER to pay for services (e.g. information may also cause a PUBLISHER to pay for services (e.g.
content distribution) that were not actually rendered.) Invalid content distribution) that were not actually rendered.) Invalid
accounting information may also effect PUBLISHERs indirectly by, for accounting information may also effect PUBLISHERs indirectly by, for
example, undercounting the number of site visitors (and, thus, example, undercounting the number of site visitors (and, thus,
reducing the PUBLISHER's advertising revenue). reducing the PUBLISHER's advertising revenue).
6.1.2.2 Denial of Service 6.1.2.2 Denial of Service
A CN that does not distribute CONTENT appropriately may deny CLIENTs A CN that does not distribute CONTENT appropriately may deny CLIENTs
access to CONTENT. access to CONTENT.
6.1.2.3 Substitution of Security Parameters 6.1.2.3 Substitution of Security Parameters
If a SURROGATE does not duplicate completely the security services If a SURROGATE does not duplicate completely the security services of
of the ORIGIN (e.g. encryption algorithms, key lengths, certificate the ORIGIN (e.g. encryption algorithms, key lengths, certificate
authorities, client authentication) CONTENT stored on the SURROGATE authorities, client authentication) CONTENT stored on the SURROGATE
may be less secure than the PUBLISHER prefers. may be less secure than the PUBLISHER prefers.
6.1.2.4 Substitution of Security Policies 6.1.2.4 Substitution of Security Policies
If a SURROGATE does not employ the same security policies and If a SURROGATE does not employ the same security policies and
procedures as the ORIGIN, the CONTENT may be treated with less care procedures as the ORIGIN, the CONTENT may be treated with less care
than the PUBLISHER expects. This threat may also manifest itself if than the PUBLISHER expects. This threat may also manifest itself if
the legal jurisdiction of the SURROGATE differs from that of the the legal jurisdiction of the SURROGATE differs from that of the
ORIGIN, should, for example, legal differences between the ORIGIN, should, for example, legal differences between the
skipping to change at page 32, line 11 skipping to change at page 32, line 11
To the extent that a CN acts as either a CLIENT or a PUBLISHER (such 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 as, for example, in transitive implementations) such a CN may be
exposed to any or all of the threats described above for both roles. exposed to any or all of the threats described above for both roles.
7. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge the contributions and comments The authors would like to acknowledge the contributions and comments
of Mark Day (Cisco), Fred Douglis (AT&T), Patrik Falstrom (Cisco), of Mark Day (Cisco), Fred Douglis (AT&T), Patrik Falstrom (Cisco),
Don Gilletti (CacheFlow), Barron Housel (Cisco) John Martin (Network Don Gilletti (CacheFlow), Barron Housel (Cisco) John Martin (Network
Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter
(Cisco), John Scharber (CacheFlow), and Oliver Spatscheck (AT&T). (Cisco), John Scharber (CacheFlow), Michael Speer (Sun), and Oliver
Spatscheck (AT&T).
References References
[1] Hawkinson, J. and T. Bates, "Guidelines for creation, [1] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", BCP selection, and registration of an Autonomous System (AS)", BCP
6, March 1996, 6, March 1996, <http://www.rfc-editor.org/rfc/bcp/bcp6.txt>.
<URL:http://www.rfc-editor.org/rfc/bcp/bcp6.txt>.
[2] Postel, J., "Internet Protocol, DARPA Internet Program [2] Postel, J., "Internet Protocol, DARPA Internet Program Protocol
Protocol Specification", RFC 791, September 1981, Specification", RFC 791, September 1981, <http://www.rfc-
<URL:http://www.rfc-editor.org/rfc/rfc791.txt>. editor.org/rfc/rfc791.txt>.
[3] Hares, S. and D. Katz, "Administrative Domains and Routing [3] Hares, S. and D. Katz, "Administrative Domains and Routing
Domains A Model for Routing in the Internet", RFC 1136, Domains A Model for Routing in the Internet", RFC 1136,
December 1989, December 1989, <http://www.rfc-editor.org/rfc/rfc1136.txt>.
<URL:http://www.rfc-editor.org/rfc/rfc1136.txt>.
[4] Postel, J., "Domain Name Structure and Delegation", RFC 1591, [4] Postel, J., "Domain Name Structure and Delegation", RFC 1591,
March 1994, March 1994, <http://www.rfc-editor.org/rfc/rfc1591.txt>.
<URL:http://www.rfc-editor.org/rfc/rfc1591.txt>.
[5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995, RFC 1771, March 1995, <http://www.rfc-editor.org/rfc/
<URL:http://www.rfc-editor.org/rfc/rfc1771.txt>. rfc1771.txt>.
[6] Carpenter, B., "Architecture Principles of the Internet", RFC [6] Carpenter, B., "Architectural Principles of the Internet", RFC
1958, June 1996, 1958, June 1996, <http://www.rfc-editor.org/rfc/rfc1958.txt>.
<URL:http://www.rfc-editor.org/rfc/rfc1958.txt>.
[7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol", RFC 2326, April 1998, Protocol (RTSP)", RFC 2326, April 1998, <http://www.rfc-
<URL:http://www.rfc-editor.org/rfc/rfc2326.txt>. editor.org/rfc/rfc2326.txt>.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998, 1998, <http://www.rfc-editor.org/rfc/rfc2396.txt>.
<URL:http://www.rfc-editor.org/rfc/rfc2396.txt>.
[9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
-- HTTP/1.1", RFC 2616, June 1999, HTTP/1.1", RFC 2616, June 1999, <http://www.rfc-editor.org/rfc/
<URL:http://www.rfc-editor.org/rfc/rfc2616.txt>. rfc2616.txt>.
[10] Carpenter, B., "Internet Transparency", RFC 2775, February [10] Carpenter, B., "Internet Transparency", RFC 2775, February
2000, 2000, <http://www.rfc-editor.org/rfc/rfc2775.txt>.
<URL:http://www.rfc-editor.org/rfc/rfc2775.txt>.
[11] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web [11] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001, Replication and Caching Taxonomy", RFC 3040, January 2001,
<URL:http://www.ietf.org/rfc/rfc3040.txt>. <http://www.rfc-editor.org/rfc/rfc3040.txt>.
[12] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, [12] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, G., de Bruijn, B., de Latt, C., Holdrege, M. and D. Spence,
"AAA Authorization Framework", "AAA Authorization Framework", RFC 2904, August 2000, <http://
draft-ietf-aaa-authz-arch-00.txt (work in progress), October www.rfc-editor.org/rfc/rfc2904.txt>.
1999,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-aaa-authz-a
rch-00.txt>.
[13] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for [13] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
Content Internetworking", draft-day-cdnp-model-05.txt (work in Content Internetworking (CDI)", draft-ietf-cdi-model-02.txt
progress), March 2001, (work in progress), May 2002, <http://www.ietf.org/internet-
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-model-0 drafts/draft-ietf-cdi-model-02.txt>.
5.txt>.
[14] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking [14] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking
Scenarios", draft-day-cdnp-scenarios-03.txt (work in Scenarios", draft-ietf-cdi-scenarios-01.txt (work in progress),
progress), March 2001, April 2002, <http://www.ietf.org/internet-drafts/draft-ietf-
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-scenari cdi-scenarios-01.txt>.
os-03.txt>.
[15] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Content [15] Gilletti, D., Nair, R., Scharber, J., Guha, J. and D. Frascone,
Internetworking Authentication, Authorization, and Accounting "Content Internetworking Authentication, Authorizaiton, and
Requirements", draft-gilletti-cdnp-aaa-reqs-01.txt (work in Accounting Requirements", draft-ietf-cdi-aaa-reqs-01.txt (work
progress), January 2001, in progress), June 2002, <http://www.ietf.org/internet-drafts/
<URL:http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aa draft-ietf-cdi-aaa-reqs-01.txt>.
a-reqs-01.txt>.
[16] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, M., [16] Douglis, F., Chaudhri, I. and P. Rzewski, "Known Mechanisms For
Nair, R., Potter, D. and O. Spatscheck, "Known CDN Content Internetworking", draft-douglis-cdi-known-mech-00.txt
Request-Routing Mechanisms", (work in progress), November 2001, <http://www.ietf.org/
draft-cain-cdnp-known-request-routing-01.txt (work in internet-drafts/draft-douglis-cdi-known-mech-00.txt>.
progress), February 2001.
[17] Cain, B., Spatscheck, O., May, M. and A. Barbir, [17] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request-
"Request-Routing Requirements for Content Internetworking", Routing Requirements for Content Internetworking", draft-ietf-
draft-ietf-cain-request-routing-req-01.txt (work in progress), cdi-request-routing-reqs-00.txt (work in progress), February
March 2001. 2002, <http://www.ietf.org/internet-drafts/draft-ietf-cdi-
request-routing-reqs-00.txt>.
[18] Amini, L., Thomas, S. and O. Spatscheck, "Distribution Peering [18] Amini, L., Thomas, S. and O. Spatscheck, "Requirements for
Requirements for Content Distribution Internetworking", Content Distribution Internetworking", draft-ietf-cdi-
draft-amini-cdi-distribution-reqs-00.txt (work in progress), distribution-reqs-00.txt (work in progress), February 2002,
February 2001. <http://www.ietf.org/internet-drafts/draft-ietf-cdi-
distribution-reqs-00.txt>.
Authors' Addresses Authors' Addresses
Mark Green Mark Green
CacheFlow Inc. No Affiliation
650 Almanor Avenue
Sunnyvale, CA 94086
US
Phone: +1 408 543 0470
EMail: markg@cacheflow.com
EMail: reserved@pacbell.net
Brad Cain Brad Cain
Cereva Networks Storigen Systems
650 Suffolk Street
Lowell, MA 01854
US
EMail: bcain@cereva.com Phone: +1 978 323 4454
EMail: bcain@storigen.com
Gary Tomlinson Gary Tomlinson
CacheFlow Inc. No Affiliation
12034 134th Ct. NE
Suite 201
Redmond, WA 98052
US
Phone: +1 425 820 3009 EMail: gary@tomlinsongroup.net
EMail: garyt@cacheflow.com
Stephen Thomas Michael F. Speer
TransNexus, Inc. Sun Microsystems, Inc.
430 Tenth Street NW 4150 Network Circle
Suite N204 UMPK17-103
Atlanta, GA 30318 Santa Clara, CA 95054
US US
Phone: +1 404 872 4887 Phone: +1 650 786 6368
EMail: stephen.thomas@transnexus.com EMail: michael.speer@sun.com
Phil Rzewski Phil Rzewski
Inktomi Inktomi
4100 East Third Avenue 4100 East Third Avenue
MS FC1-4 MS FC1-4
Foster City, CA 94404 Foster City, CA 94404
US US
Phone: +1 650 653 2487 Phone: +1 650 653 2487
EMail: philr@inktomi.com EMail: philr@intkomi.com
Stephen Thomas
TransNexus, Inc.
430 Tenth Street NW
Suite N204
Atlanta, GA 30318
US
Phone: +1 404 872 4887
EMail: stephen.thomas@transnexus.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). 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 assigns.
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. 167 change blocks. 
446 lines changed or deleted 467 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/