Network Working Group L. Amini
Internet-Draft IBM Research
Expires: August 30, 2001 S. Thomas
TransNexus, Inc
O. Spatscheck
AT&T Labs
March 2001
Distribution Requirements for Content Internetworking
draft-amini-cdi-distribution-reqs-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document specifies requirements for interconnecting, or
peering, the distribution systems of Content Networks (CN).
Distribution internetworking requires advertising the capabilities
of a CN offering distribution services, moving content from one CN
to another, and signaling requirements for consistent storage and
delivery of content. This document does not address requirements for
directing user agents to distributed content, nor for aggregating
access information for distributed content.
Amini, et. al. Expires August 30, 2001 [Page 1]
Internet-Draft CI Distribution Requirements March 2001
1. Introduction
Content Internetworking (CI) assumes an architecture wherein the
resources of multiple CNs are combined so as to achieve a larger
scale or reach than any of the component CNs could individually [3].
A Content Distribution Network (CDN) is an example of a CN.
At the core of CI are three principal architectural elements. These
elements are Request Routing, the Distribution and the Accounting.
The focus of this document, the Internetworking Distribution
Systems, is responsible for moving content from one Distribution CN
to another Distribution CN. Note that the original content provider
is considered a degenerate case of a Distribution CN.
In any Distribution Internetworking arrangement, the relationships
between Distribution CNs can always be decomposed into one or more
pairs of CNs. Each CN pair comprises one CN which has, or has access
to, content, and another CN which has, or has access to, systems
capable of providing distribution and/or delivery functions for
content. The former CN is referred to as the Content Source, while
the latter is referred to as the Content Destination.
This document describes the overall architectural structure and
building blocks of the internetworked Distribution Systems. It also
defines the protocol requirements for interconnecting two or more
Distribution CNs via their respective Content Internetworking
Gateways (CIG). Specifically, it defines the requirements for:
Distribution Advertising: announcing the distribution
capabilities of a Content Destination to potential Content
Sources.
Content Signaling: communicating content meta-data to enable
consistent storage and delivery of content to user agents.
Content Replication: moving content from a Content Source to a
Content Destination.
Although this document does not specifically address requirements
for communicating within a CN, it is plausible that protocols
developed to meet inter-CN requirements may also be well-suited for
intra-CN communications.
Requirements for the remaining CI architectural elements, the
Request Routing System, which is responsible for directing user
agents to the distributed content, and the Accounting System, which
is responsible for aggregating information related to the access of
distributed content, are detailed in [6], [7].
Amini, et. al. Expires August 30, 2001 [Page 2]
Internet-Draft CI Distribution Requirements March 2001
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
All other terms in ALL CAPS, except those qualified with explicit
citations, are defined in [8].
1.2 Change Log
1. Fixed terminology to comply with updated Models doc.
2. Intro: fixed reach or scale so not synonyms
3. Section 1: clarified definition for Content Signaling
4. Section 2: clarified that fig 1 is a logical view, need not have
this strictly hierarchical relationship.
5. Section 2.1-2.2: deleted these sections, feedback indicated they
confused more than claried; material is adequately covered in
Models doc.
6. Section 3: change Use-initiated to surrogate initiated.
7. Section 3 (para 2): cig is not necessarily a box, could be
functionality (protocol conformance) implemented in multiple
boxes.
8. Section 4.1: clarified content signalling example.
9. Section 4.3: clarified common base replication vs. content type
specific replication
10. Section 4.4: fixed "extensible model..." wording
11. Section 5.1: clarified that content pull for delivery services
preparation is optional.
12. Section 5.3 3-4: modified, added request for feedback
13. Section 5.3.5: clarified advertisements as optional
14. Section 5.4: dropped requirement for sending data with content
signal.
15. Section 5.4 6: dropped part about source encryption -- if the
object is encrypted at source and not decrypted until it
Amini, et. al. Expires August 30, 2001 [Page 3]
Internet-Draft CI Distribution Requirements March 2001
reaches the client, then it is just a (downloadable) blob as
far as the dist system is concerned.
16. Section 5.5 8: dropped subscription fee and next hop.
17. Section 5.5 8: changed content id to content set id.
18. Section 5.5: added information on relationship to WEBI/RUP.
Amini, et. al. Expires August 30, 2001 [Page 4]
Internet-Draft CI Distribution Requirements March 2001
2. Distribution System Overview
In Distribution System Internetworking, even the most complex
communication arrangements can be expressed in terms of simple
interactions between a Content Source and a Content Destination.
Figure 1, for example, shows a relationship between four different
administrative authorities. CN A operates a network of SURROGATES,
and "CN D" (actually the original content provider, or ORIGIN) has
content to be distributed. CN A communicates with CN B, which
communications with CN C, which, in turn, communicates with CN D.
+------------+ +-----------+ +-----------+ +------------+
| CN A | | CN B | | CN C | | "CN D" |
|(SURROGATES)|<->| (agent |<->| (agent |<->| (ORIGIN) |
| | | for A) | | for D) | | |
+------------+ +-----------+ +-----------+ +------------+
CONTENT DST <-> CONTENT SRC
CONTENT DST <-> CONTENT SRC
CONTENT DST <-> CONTENT SRC
Figure 1: Distribution System Interworking
In each case, one of the parties in the communications has the role
of Content Destination, while the other party is the Content Source.
Note that a particular CN's role may change, depending on the party
with whom it is communicating. CN B, for example, is a Content
Source when communicating with CN A, but a Content Destination when
communicating with CN C.
Note that a Content Destination which peers directly with the
Content ORIGIN, will interface with the ORIGIN just as it interfaces
with any other Content Source.
Although Figure 1 provides an example of multiple CNs peered in
series, a Distribution CN may serve as the Content Source for
multiple Content Destinations. Likewise, a Distribution CN may
serve as the Content Destination for multiple Content Sources.
Additionally, it is possible for the internetworking relationship
between a single Source-Destination pair to be reciprocal for
different content sets. That is, CN A may request distribution
services from CN B for Content Set A, while CN B requests
distribution services from CN A for Content Set B.
Further, note that Figure 1 is a logical view of the internetworking
relationship between several Content Source-Destination pairs;
actual communications are not restricted to this pair-wise
Amini, et. al. Expires August 30, 2001 [Page 5]
Internet-Draft CI Distribution Requirements March 2001
hierarchy. For example, CDN D may specify a single authoritative
distribution channel from which any distributing CN must retrieve
the CONTENT.
Amini, et. al. Expires August 30, 2001 [Page 6]
Internet-Draft CI Distribution Requirements March 2001
3. Replication Models
Replication of content may take place using a push model, or a pull
model, or a combination of both.
o SURROGATE-initiated replication of CONTENT, where a SURROGATE
retrieves CONTENT based on a cache miss or on a prefetching
policy specified at the SURROGATE, represents the pull model.
This is the model currently used by caching proxies.
o ORIGIN-initiated replication of CONTENT to SURROGATEs represents
the push model. This model is used to preposition CONTENT in
anticipation of demand.
Replication, when between the administrative domains of different
Distribution CNs must adhere to the CI protocol for content
replicaiton. Replication within a single Distribution CN is an
intra-CN communication and therefore, need not adhear to CI
protocols. Further, the replication model used within a single
Distribution CN need not be the same as the model used to replicate
CONTENT between CNs.
For both ORIGIN- and SURROGATE- initiated replication, the Content
Source may use replication mechanisms beyond a simple transfer. For
example, it may be desirable to have the Content Destination join a
multicast channel on which a set of content is pushed to all
SURROGATES.
Another example is for CONTINUOUS MEDIA. In the case of live
broadcasts, the data need not be cached on the SURROGATES. Instead,
replication takes the form of "splitting" the live stream at various
points in the network. Splitting is also referred to as application
layer multicast.
Replication of CONTINUOUS MEDIA streams which are not live, and
therefore may be stored on SURROGATES, also benefits from mechanisms
beyond in-line replication. For example, CONTINUOUS MEDIA is often
delivered to CLIENTS over an unreliable channel. However, a CN
distributing this content to many CLIENTS should work with a full
replica. Existing proprietary replication protocols enable
distribution of CONTINUOUS MEDIA objects in which a full or partial
replica can be propagated, the data may be encrypted and/or
authenticated, and the SURROGATE can support CONTINUOUS
MEDIA-related services such as random access and stream
insertion/splicing.
It may be desirable to replicate content to a Distribution CN which
has no internal SURROGATES. For example, a Distribution CN may have
servers at key exchange points within the network which only serve
Amini, et. al. Expires August 30, 2001 [Page 7]
Internet-Draft CI Distribution Requirements March 2001
content to other distribution systems, and peer with other CNs which
provide SURROGATES which deliver content to CLIENTS.
Amini, et. al. Expires August 30, 2001 [Page 8]
Internet-Draft CI Distribution Requirements March 2001
4. Distribution Internetworking Requirements
This section details general requirements for exchange of
inter-domain distribution information.
4.1 General Requirements
The goal of the Distribution Internetworking is to interconnect the
Distribution Systems of multiple CNs. The intent of this
interconnection is to effectively position content for fast,
reliable access by CLIENTs. Generally this is accomplished by
replicating content on SURROGATEs. While the communications path
from ORIGIN to CLIENTs may traverse a number of links, some within a
Distribution CN and some between Distribution CNs, Distribution
Internetworking is concerned only with those communications between
Distribution CNs.
The three main components of Distribution Internetworking are
advertising, replication, and signaling.
Advertising: Distribution CNs MAY advertise their capabilities to
potential Content Source CNs.
Replication: Distribution CNs MUST be able to move content from a
Content Source to a Content Destination.
Content signaling: Distribution CNs MUST be able to propagate
content meta-data. This meta-data includes information such as
the immediate invalidation of content or a change in the source
or distribution method of content.
Note that these requirements do not necessarily translate directly
into three distinct Distribution Internetworking protocols.
4.2 Advertising Requirements
The following list specifies requirements to enable advertising of
distribution capabilities.
1. A common protocol for the Advertisement of distribution
capabilities.
2. A common format for the actual distribution capabilities
Advertisements in the protocol.
3. Security mechanisms.
Amini, et. al. Expires August 30, 2001 [Page 9]
Internet-Draft CI Distribution Requirements March 2001
4.3 Replication Requirements
The following list specifies requirements to enable content
replication.
1. A common base protocol for the replication of content.
2. This common base protocol should specify:
* a common format for the actual content data in the protocol.
* A common format for the content meta-data in the protocol.
3. Alternate content-specific protocols for the replication of
content should be enabled. The replication protocol for a
particular content set is specified via content signaling.
4. Scalable distribution of the content.
5. Security mechanisms.
4.4 Content Signaling Requirements
The following list specifies requirements to enable content
signaling.
1. A common protocol for signaling content meta-data.
2. An extenisble format for communicating content metadata.
Minimally, support is required for "add," "withdraw," and
"expiration time update."
3. Scalable distribution of signals on a scale to enable
Internet-wide peering.
4. Security mechanisms.
Amini, et. al. Expires August 30, 2001 [Page 10]
Internet-Draft CI Distribution Requirements March 2001
5. Distribution Internetworking Protocol Requirements
This section defines protocol requirements for each of the
advertising, replication and content signaling components of
Distribution Internetworking. Note that these requirements do not
necessarily translate directly into either one converged or three
distinct Distribution Internetworking protocols.
5.1 Overview of Distribution Internetworking Flow
In a Distribution Internetworking arrangement, the following
sequence of events is expected:
1. A Content Source may receive distribution capabilities
advertisements from one or more Content Destinations. A Content
Source may or may not require receipt of distribution
capabilities advertisements prior to requesting services. For
example, a Content Source may request services based on a
contractual agreement negotiated off-line.
2. The Content Source will make a decision to request content
distribution services from a Content Destination.
3. The Content Source will send a content signal requesting
distribution services.
4. The Content Destination will accept or reject the request; no
partial acceptance or negotiation is defined.
* If the request is rejected, the error code SHOULD provide
enough information for the Content Source to determine if it
should send a request with modified service requirements.
* If the request is accepted, the Content Destination will
prepare for distribution services. Generally, this
preparation will entail:
+ optionally retrieving a copy of the object(s),
+ joining the content update channel (if any), and
+ preparing to provide access information to the Accounting
System
* Each of the above steps are according to the Content Source's
specification, and to the Content Destination's policies and
configuration.
5. Once the Content Destination is prepared, it will notify the
Amini, et. al. Expires August 30, 2001 [Page 11]
Internet-Draft CI Distribution Requirements March 2001
Request Routing System of the content's availability.
6. The Content Destination will terminate service on first
occurrence of either:
* the time frame specified in the Content Source's request for
distribution services expires or
* a content signal requesting withdrawal of the content is
received.
5.2 General Distribution Internetworking Protocol Requirements
Protocols must be scalable, i.e., support Distribution
Internetworking on an Internet-wide scale.
Protocols must prevent looping of advertisements, replication and
content signaling.
Protocols must support the ability to optionally conduct
authenticated and/or encrypted exchanges.
Protocols must support the ability to optionally exchange
credentials.
5.3 Advertising Protocol Requirements
1. Distribution Internetworking protocols MUST enable a Content
Destination to advertise the capabilities of its distribution
service in a common format. This common format for distribution
service capabilities will be referred to as a Service Profile
for the remainder of this draft.
2. The advertisement protocol must be extensible with the
restriction that implementation-specific capabilities may be
safely ignored by Content Source.
3. Distribution Internetworking protocols MUST provide
low-overhead, mechanism to notify in-line elements (e.g.,
proxies) of CI support.
4. [ Editor's Note: prev item can be as simple has having the
Content Source include a reference to it's CIG so that inline
systems could contact the CIG and establish an internetworking
arrangement. But the feedback has been lukewarm to bad --
drop? ]
5. Distribution Advertising by a Content Destination must be
optional. That is, a Content Source may not require real-time
Amini, et. al. Expires August 30, 2001 [Page 12]
Internet-Draft CI Distribution Requirements March 2001
advertisement of distribution capabilities in order to
establish a Distribution Internetworking arrangement.
Distribution capabilities may be communicated via
Advertisements or some other agreed upon mechanism such as an
off-line contract negotiated between the parties.
6. Advertised capabilities are those available to the peer,
potentially based on some off-line contractual agreement, and
may not necessarily reflect the total capacity of the Content
Destination.
7. The protocol MUST enable a Content Destination to advertise
multiple service profiles. Each service profile MUST be
specifiable by a profile identifier. The profile identifier
MAY encode Content Source or Content Destination specific
information, but it has local significance only (i.e., it is
strictly between the Content Source and Content Destination).
8. The protocol MUST enable a Content Destination to advertise
multiple services profiles to the same or different potential
Content Sources.
9. A Content Destination with regional capabilities SHOULD
advertise capabilities on a per region basis. A Content
Destination which advertises regional capabilities MUST
minimally be able to identify regions by network
addresses/prefixes.
10. By default, advertisements are advisory. A Content Destination
SHOULD be able to specify whether the capabilities are advisory
or binding.
11. The protocol MUST provide the ability to specify distribution
capabilities in terms of one or more of the following
attributes:
Profile ID: Identifier for the service profile being
advertised. The profile identifier is to be used by the
Content Source when requesting service. This attribute is
required for all advertisements. The value need not be
unique across Distribution CNs, and may be used in
advertisements to multiple Content Sources.
FootPrint: The areas served by the CN. Minimally, a Content
Destination should support expressing footprint according to
IP network addresses/prefixes.
Content Type: The type of content (e.g. static Web pages,
streaming media, etc.) that the CN is able to distribute.
Amini, et. al. Expires August 30, 2001 [Page 13]
Internet-Draft CI Distribution Requirements March 2001
Capacity: The storage capacity that the CN can provide.
Bandwidth: Maximum outbound bandwidth available from the CN.
Object Bandwidth: Maximum outbound bandwidth supported for a
single object.
Distribution Method: The distribution methods that the CN
supports; one or more of push, pull, and alm. "alm" refers
to application layer multicast, or splitting, of CONTINUOUS
MEDIA; if specified, supported protocols must also be
specified.
[ Editor's Note: Specifying support for splitting
requires refinement. ]
Request Routing Type: Type(s) of request routing supported for
CI Request Routing Systems.
Accounting System Format: Supported protocol(s) and format(s)
for sending accounting and access feedback to a specified CI
Accounting System.
Time Frame: Time frame for which this advertisement is valid.
Client Protocols: Indicates the client protocols supported.
Currently only HTTP and RTSP are valid. However, this field
must be further qualified than just the transport or
signalling protocol. The protocol must clearly define a
level of support implicated by a given Client Protocol
value.
Distribution Fee: Indicates the fee charged for distribution
services. The value may be expressed in Mbps
(megabits/second) or in MB (megabytes of storage).
Advertisement Type: Indicates whether the advertisement is
advisory or binding. By default, all advertisements are
advisory.
Private Extensions: Additional metrics that the communicating
parties may agree to use, but are not part of the IETF
standard. Extensions must be defined such that if not
understood by the Content Source, they can be safely
ignored.
Amini, et. al. Expires August 30, 2001 [Page 14]
Internet-Draft CI Distribution Requirements March 2001
5.3.1 Advertising Examples
To be provided.
5.4 Replication Protocol Requirements
1. A common (base) replication protocol MUST be defined which is
supported by all CIGs, for any content type which can be used to
transport meta-data and a full replica of content data.
2. Replication MUST support the ability for a Content Source to
specify a replication channel from which content may be
retrieved.
1. [ Editors Note: I am using channel as a generic term which
would provide a contact point and protocol, and any
additional info required to establish a connection. E.g.
wcips://invalidation.com/content_set for signaling; will
provide clarification later ]
3. Replication MUST enable specifying optionally supported,
alternative replication protocols which may be better suited
than the common base protocol for specific content types or
configuration scenarios.
4. A Content Source SHOULD be able to specify an authoritative
source for content as well as distribution points.
5. The protocol MUST enable replication that is secured (encrypted)
across the communications channel.
5.4.1 Replication Examples
To be provided.
5.5 Content Signaling Protocol Requirements
1. A Content Source MUST be able to request distribution services
for one or more content objects.
2. A Content Destination MUST explicitly accept or reject a request
for distribution services.
3. A Content Source MUST be able to withdraw (cancel) a request for
content services for one or multiple content objects.
4. Rejected requests for distribution services MUST include error
codes. Partial rejections or negotiations are not supported. A
Content Source may follow a rejection with a request for
Amini, et. al. Expires August 30, 2001 [Page 15]
Internet-Draft CI Distribution Requirements March 2001
distribution services under alternate service requirements.
5. A Content Source MUST be able to signal consistency meta-data.
Minimally, Content Sources SHOULD support weak consistency
mechanisms. Content Sources MAY support mechanisms for strong
consistency.
6. Content signaling SHOULD include mechanisms to aggregate content
information.
7. Content Signaling SHOULD be decoupled from the content ORIGIN.
I.e., a Content Source should be able to specify a content
signaling channel.
8. The following attributes are defined for content signals:
Content Set ID: A unique identifier for this specific content
set, so that future references (e.g. to modify the content or
to withdraw it from distribution) may be resolved. This value
can also be used to avoid loops. The Content Set ID MUST be
global and unique, i.e., a given content set MUST have the
same ID across all Distribution Systems, and this ID MUST be
unique across *all* Distribution Systems.
URI: The uniform resource identifier for the content. It
identifies how CLIENTS will request delivery services from
the Distribution CN. This attribute can support an atomic
unit of content or it can be used to generally specify a URI
path. For pull distribution, a URI path serves as pattern
(e.g. http://origin/images/*) to qualify which content should
receive the specified service. For push distribution, only
URIs which identify an atomic unit of content may be used.
[Ed: The editor would prefer further discussion on whether
this attribute must uniquely identify an atomic unit of
content or whether it can more generally specify a URI
path. Allowing paths may significantly reduce the size of
any protocol transfers, but, there are some attributes
(e.g. size, content type) that do not apply as cleanly to
paths, and some distribution methods (e.g. pull) cannot be
easily accommodate paths.]
Authoritative Source: Identifies the channel where the
authoritative copy of the content may be retrieved. In the
case of live CONTINUOUS MEDIA, this channel may represent
where the Content Destination may retrieve meta-data required
to provide application layer multicasting services.
Distribution Method: Push, pull, on-demand, alm or withdraw.
Amini, et. al. Expires August 30, 2001 [Page 16]
Internet-Draft CI Distribution Requirements March 2001
Specifies how the Content Destination should retrieve the
content. Withdraw is a special case that indicates a Content
Destination should cease distribution of previously accepted
content.
Service Profile ID: Identifies the service profile to be
associated with this request. The Service Profile ID may
have been provided by a Content Destination advertisement or
some other means (e.g. contractual agreement negotiated
off-line). The identifier MAY encode Content Source or
Content Destination specific information, but it has local
significance only (i.e., it is strictly between the Content
Source and Content Destination).
Size: Size of the content.
Time Frame: The period of time for which the Content Source
requests distribution.
Request Routing Type: Type of Request Routing requested for this
content. Depending on the Request Routing type, an RRS
channel may also be supplied.
[ Editor's Note: Request Routing Types to be defined according
to [6]. ]
Accounting Format: Format for sending accounting and access
feedback.
Accounting Type: Accounting/access feedback type desired.
Depending on the type requested, an Accounting channel may
also be supplied. The information conveyed with this
attribute should also indicate whether the Content
Destination is required to provide this feedback.
[ Editor's Note: Accounting Formats and Types to be defined
according to [7]. ]
Distribution Authority: Indicates whether the Content
Destination can serve as the Authoritative Source for this
content set or if the Authoritative Source attribute must be
treated as a global attribute. By default, the Content
Destination can serve as Authoritative Source to Content
Destinations for which it is the Content Source.
Mirrors: Alternate channels for retrieving the content.
Update Channel: Alternate channels for receiving consistency
signals. The information conveyed in this attribute should
Amini, et. al. Expires August 30, 2001 [Page 17]
Internet-Draft CI Distribution Requirements March 2001
also indicate whether the Content Destination is required to
subscribe to this channel.
Content Data: The actual content data to be distributed; this is
expected to be used for small objects only.
Expires: Indicates the date/time after which this version of the
content is considered stale.
Prefetch: If content is to be prefetched, indicates the
date/time when the prefetch should be requested.
9. The following table specifies the relationship between content
signal types and the defined attributes.
Attribute Add Update Withdrawal
--------------------- -------- --------- -----------
Content Set ID required required required
URI required optional unsupported
Service Profile ID optional optional optional
Authoritative Source required optional unsupported
Distribution Method required optional unsupported
Time Frame required optional required
Request Routing Type required optional unsupported
Accounting Format required optional unsupported
Accounting Type required optional unsupported
Mirrors optional optional unsupported
Distribution Authority optional optional unsupported
Update Channel optional optional unsupported
Content Data optional optional unsupported
Expires optional required unsupported
5.5.1 Resource Update Protocol (RUP) Relationship
The IETF Web Intermediaries (WEBI) Working Group is currently
developing requirements for a Resource Update Protocol (RUP) [10].
RUP defines requirements for a protocol enabling communication about
changes to content accessible from caching proxies and surrogates.
Operations required by RUP include cache invalidation, content
location update, content prefetch hints, removal and addition of
resources to a resource group, adjustments to cache consistency
parameters.
Several of the RUP defined operations coincide with the requirements
listed for CI Distribution Signaling (CI-DS). The intent of this
document is to specify those requirements which are specific to the
Amini, et. al. Expires August 30, 2001 [Page 18]
Internet-Draft CI Distribution Requirements March 2001
CI environment. The CI-DS requirements which would be met by a
protocol designed to meet the RUP requirements are:
Both RUP and CI-DS require transport of content metadata from a
single point of control (RUP Server) to a large number of
surrogates (RUP clients).
In the CI-DS environment, the RUP Server and RUP Clients are
expected to be in multiple administrative domains. Also, RUP
Clients are likely to be CIG responsible for propogating content
signals to downstream surrogates which are in the same
administrative domain as the CIG. It is anticipated, but not
required, the signals relayed to downstream surrogates will also
conform to the protocol designed to meet RUP requirements.
The transport defined to carry content metadata must enable
enforcing secrecy and authentication for payloads.
The transport must enable the point of control to specify
explicit acknowledgement of messages.
The following mapping of metadata fields are anticipated:
CI-DS Content Set ID field maps to RUP Resource Groups.
CI-DS URI field maps to RUP Object ID.
CI-DS Update Channel may reference a RUP server providing
cache consistency for this Content Set.
CI-DS Authoritative Source maps to a RUP Content Location.
CI-DS Expires maps to the RUP document expiration time.
CI-DS enables the ability to specify when an object should be
prefetched; RUP enables the ability to specify an object
should be prefetched.
In addition to the metadata fields which were defined for CI-DS, but
not mapped to an RUP field, CI-DS requires the following
functionality.
Ability to specifically request a Content Set be added or
withdrawn from the list of objects being serviced. This
requirement could be covered by adding the ability to dynamically
define Resource Groups to RUP.
Specifically, a master Resource Group could be defined which
would be used as the channel to communicate which Resource Groups
Amini, et. al. Expires August 30, 2001 [Page 19]
Internet-Draft CI Distribution Requirements March 2001
to be added/withdrawn from service. The CIG would then establish
channels to receive cache coherency messages for these Resource
Groups.
Ability to update metadata for an object. While it is possible
this can be covered by withdrawal and re-add of the Content Set,
due to the number and types of fields supported, inability to
update would impact efficiency.
5.5.2 Content Signaling Examples
To be provided.
Amini, et. al. Expires August 30, 2001 [Page 20]
Internet-Draft CI Distribution Requirements March 2001
References
[1] Bradner, S.O., "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[2] Bradner, S.O., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[3] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CN Peering
Architectural Overview", January 2001.
[4] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", January 2001.
[5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
January 2001.
[6] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request
Routing Requirements for Content Internetworking", January
2001.
[7] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Accounting
Requirements for CDN Internetworking", January 2001.
[8] Day, M., Cain, B. and G. Tomlinson, "A Model for Content
Distribution Internetworking", January 2001.
[9] Day, M., Cain, B. and G. Tomlinson, "Content Distribution
Network Peering Scenarios", January 2001.
[10] Hamilton, M., Cooper, I. and D. Li, "Requirements for a
Resource Update Protocol", November 2001.
Authors' Addresses
Lisa D. Amini
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532
US
Phone: +1 914 784 7366
EMail: aminil@us.ibm.com
Amini, et. al. Expires August 30, 2001 [Page 21]
Internet-Draft CI Distribution Requirements March 2001
Stephen Thomas
TransNexus, Inc
430 Tenth Street NW Suite N204
Atlanta, GA 30318
US
Phone: +1 404 872 4887
EMail: stephen.thomas@transnexus.com
Oliver Spatscheck
AT&T Labs
180 Park Ave, Bldg 103
Florham Park, NJ 07932
Phone:
EMail: spatsch@research.att.com
Amini, et. al. Expires August 30, 2001 [Page 22]
Internet-Draft CI Distribution Requirements March 2001
Appendix A. Acknowledgements
The editors would like to thank the following for their assistance:
Kobus van der Merwe, Nalin Mistry, Don Easton, Christian Hoertnagl,
John Robertson, Dan Li, Phil Rzewski, Brad Cain, Mark Day, Fred
Douglis, and Ingrid Melve.
Amini, et. al. Expires August 30, 2001 [Page 23]
Internet-Draft CI Distribution Requirements March 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Amini, et. al. Expires August 30, 2001 [Page 24]