[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments draft-amini-cdi-distribution-reqs-00
Comments and questions inline
>>>>>>>>>>>>
thusly deliniated.
>>>>>>>>>>>>
Kobus
Network Working Group L. Amini
Internet-Draft IBM Research
Expires: August 20, 2001 S. Thomas
TransNexus, Inc
O. Spatscheck
AT&T Labs
February 19, 2001
Distribution Peering Requirements for Content Distribution
Internetworking
draft-amini-cdi-distribution-reqs-00
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 20, 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 Distribution Networks
(CDN). Distribution peering requires advertising the capabilities of
a CDN offering distribution services, moving content from one CDN 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 20, 2001 [Page 1]
Internet-Draft Distribution Peering Requirements February 2001
1. Introduction
Content Distribution Internetworking (CDI) assumes an architecture
wherein the resources of multiple CDNs are combined so as to achieve
a larger scale, or reach, than any of the component CDNs could
individually [3]. At the core of CDI are three principal
architectural elements. These elements are the Request Routing
System, the Distribution Peering System and the Accounting Peering
System. The focus of this document, the Distribution Peering System,
is responsible for moving content from one Distribution CDN to
another Distribution CDN. Note that the original content provider
is considered a degenerate case of a Distribution CDN.
In any Distribution Peering arrangement, the relationships between
Distribution CDNs can always be decomposed into one or more pairs of
CDNs. Each CDN pair comprises one CDN which has, or has access to,
content, and another CDN which has, or has access to, systems
capable of providing distribution and/or delivery functions for
content. The former CDN 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 Distribution Peering System. It also defines
the protocol requirements for interconnecting two or more
Distribution CDNs via their respective Content Peering Gateways
(CPG). Specifically, it defines the requirements for:
Distribution Advertising: announcing the distribution
capabilities of a Content Destination to potential Content
Sources.
Content Signaling: enabling consistent storage and delivery of
content to user agents.
>>>>>>>>>>>>
Not clear what is meant with content signaling from this sentence.
Discription on page 10 (talking about meta-data) is better.
>>>>>>>>>>>>
Content Replication: moving content from a Content Source to a
Content Destination.
Although this document does not specifically address requirements
for communicating within a CDN, it is plausible that protocols
developed to meet inter-CDN requirements may also be well-suited for
intra-CDN communications.
Requirements for the remaining CDI 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 20, 2001 [Page 2]
Internet-Draft Distribution Peering Requirements February 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].
Amini, et. al. Expires August 20, 2001 [Page 3]
Internet-Draft Distribution Peering Requirements February 2001
2. Overview of Distribution Peering System
In the Distribution Peering System architecture, 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. CDN A operates a network
of SURROGATES, and "CDN D" (actually the original content provider,
or ORIGIN) has content to be distributed. CDN A communicates with
CDN B, who communications with CDN C, who, in turn, communicates
with CDN D.
+------------+ +-----------+ +-----------+ +------------+
| CDN A | | CDN B | | CDN C | | "CDN D" |
|(SURROGATES)|<->| (agent |<->| (agent |<->| (ORIGIN) |
| | | for A) | | for D) | | |
+------------+ +-----------+ +-----------+ +------------+
CONTENT DST <-> CONTENT SRC
CONTENT DST <-> CONTENT SRC
CONTENT DST <-> CONTENT SRC
Figure 1: Distribution Peering System Components
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 CDN's role may change, depending on the party
with whom it is communicating. CDN B, for example, is a Content
Source when communicating with CDN A, but a Content Destination when
communicating with CDN 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 CDNs peered in
series, a Distribution CDN may serve as the Content Source for
multiple Content Destinations. Likewise, a Distribution CDN may
serve as the Content Destination for multiple Content Sources.
Additionally, it is possible for the peering relationship between a
single Source-Destination pair to be reciprocal for different
content sets. That is, CDN A may request distribution services from
CDN B for Content Set A, while CDN B requests distribution services
from CDN A for Content Set B.
>>>>>>>>>>>>>>>>
In a distribution peering relationship as shown in figure 1, does it
necessarily mean that the "data flow" has to follow the peering hierarchy,
i.e. CDN A gets content from CDN B, which gets content from CDN C which
gets content from CDN D. In a pull model, the information exchanged by
the distribution peering system might simply be signalling, i.e. no
data is transfered in the distribution phase and while the peering
relationship remains A<>B<>C<>D, all CDNs register D as the content
source and fetch content from there on-demand as needed.
>>>>>>>>>>>>>>>>
Amini, et. al. Expires August 20, 2001 [Page 4]
Internet-Draft Distribution Peering Requirements February 2001
2.1 Relationship with other CDI components
Figure 1 showed only the relationships among peered distribution
systems, it did not show the relationship between these distribution
systems and the other two CDI components. The purpose of this
section is to place the Distribution Peering System into the overall
CDI context.
2.1.1 CDI Full Peering
Figure 2 provides a simple example with each of three CDNs peering
at each CDI layer.
[Editor's note: I don't like the term "Full Peering," seeking
suggestions ...Like-Component Peering, Layered Peering,...]
CDN A CDN B CDN C
+---------------+ +---------------+ +---------------+
|Request Routing|<--->|Request Routing|<--->|Request Routing|
|...............| |...............| |...............|
| Distribution |<--->| Distribution |<--->| Distribution |
|...............| |...............| |...............|
| Accounting |<--->| Accounting |<--->| Accounting |
+---------------+ +---------------+ +---------------+
Figure 2: CDI Full Peering Example
As illustrated, the information exchanged between CDI components of
the same type (denoted by arrows) are inter-CDN exchanges, and
therefore, are specified by CDI. However, all information that
flows between the various CDI components within a given CDN is
intra-CDN communication; its format is not specified by CDI. For
example, the format of information exchanged between the
Distribution System and the Request Routing System of CDN A is not
specified by CDI.
An example of CDI Full Peering occurs when proxies [4] are
configured to be in the communications path between ORIGIN servers
and their CLIENTs. Systems which follow this model are said to be
"in-line" between the ORIGIN and their CLIENTs. The purpose of the
proxy may be to cache content closer to the CLIENT (i.e., caching
proxies) or dynamically export content to a preconfigured CDN. The
"dynamic exporter," because it recognizes content which is likely to
benefit from the services of a CDN, initiates the export of that
content to a CDN, and then rewrites references to that content so
Amini, et. al. Expires August 20, 2001 [Page 5]
Internet-Draft Distribution Peering Requirements February 2001
clients will be directed to the CDN, is often referred to as a "URI
rewriter."
This example is a special, or limited, case because there are no
Request Routing exchanges per se. Instead, Request Routing is
generally configured at the CLIENT and intermediate proxies.
>>>>>>>>>>>>
This is probably not the right example for the Full Peering case.
As it says above it is a special case. Might be more useful to
describe a full interaction involving all three component here
and move the special case example somewhere else.
>>>>>>>>>>>>
Further, accounting information may not be exchanged. It is
provided as an example because it is a well-known, relatively simple
model of best-effort, implicit mechanisms for distribution
"peering." This is in spite of the fact there are currently no
standardized protocols for the Content Destination to explicitly
advertise distribution capabilities, for the Content Source to
explicitly request replication, nor for the Content Source to
explicitly signal content meta-data.
In this example, an HTTP proxy identifies itself by inserting the
"Via" general header into proxied requests [5]. However, this is
for the purpose of for tracking message forwards, avoiding request
loops, and identifying the protocol capabilities of senders along
the request/response chain. It does not identify the distribution
capabilities of the intermediary. HTTP replication is also implicit
in that content may, or may not, be cached at an intermediary as it
flows from ORIGIN to CLIENT. HTTP also provides limited content
signaling via expiration and cache control headers.
2.1.2 CDI Component Peering
Now consider a peering relationship in which ORG A is providing
Accounting and Request Routing functions, but has no Distribution
capabilities. Distribution functions are provided by peered
Distribution CDNs, CDN A and CDN B. Within this Distribution Peering
arrangement, CDN A is a Content Source and CDN B is a Content
Destination. This relationship is illustrated in Figure 3.
>>>>>>>>>>>>
Cosmetic comments:
Using A for both the origin and for one of the CDNs is confusing.
Especially since earlier on the argument is made that an origin
is a degenerate CDN.
The layout of figure 3 with ORG A in two places is confusing.
>>>>>>>>>>>>
Amini, et. al. Expires August 20, 2001 [Page 6]
Internet-Draft Distribution Peering Requirements February 2001
+-----------------------------+
Request Routing System | ORG A |
+-----------------------------+
^ ^
| | (Content Advertisements)
| |
+ - - - - - - - - - - - - - - +
+-----+ +-----+
Peered Distribution | |CDN A|<----->|CDN B| |
System +-----+ +-----+
+ - - - - - - - - - - - - - - +
| |
| | (Access Information)
v v
+-----------------------------+
Accounting System | ORG A |
+-----------------------------+
Figure 3: CDI Component Peering Example
As in the previous example, CDN A and CDN B exchange Distribution
Peering information (i.e., Distribution Advertisements, Content
Signals and Content Replication) as defined by CDI. Additionally,
the CDN A and CDN B send information to the Request Routing and
Accounting systems. Unlike the previous example, the information
sent to the Request Routing and Accounting Systems in Figure 3 is
inter-CDN communication. Content Advertisements are sent to the
>>>>>>>>>>>>
Not sure what the "Unlike" refers to, but I think the exchange of
information is the same in both full peering and component peering.
The exchange of information this document is concerned with is
between CPGs, within a CPG there is information flow between
different components which does not concern us.
So for this example, if ORG A has content and wants to do accounting
and request routing, then I think that implies that the CPG for
ORG A will exchange peering information with the CPGs of CDN A
and B for request routing, distribution and accounting. I.e.
ORG A's CPG will exchange distribution peering information with
CPGs of CDN A and B even though ORG A has no distribution
capabilities. (Unless the distribution is handled in an offline
way, but the point is that because ORG has no distribution
capabilities it does not necessarily mean its CPG is not taking
part in distribution peering).
>>>>>>>>>>>>
Request Routing System to indicate the content for which a
particular Distribution CDN will accept requests. Distribution CDNs
send Access Information to the Accounting System to report usage and
accounting events.
An example of Component Peering occurs when a Content Provider
relies on an RRS CDN using Layer-7 or DNS [6] redirection to direct
CLIENTS to SURROGATES which are not in the same administrative
domain. Current systems generally use proprietary extensions to
existing protocols to implement CDI Component Peering.
2.2 CDN Peering Gateways for Distribution CDNs
A Distribution CDN may be peered with other CDNs for Distribution,
Request Routing (RR) and/or Accounting services. Communications
between any two CDNs will occur via their respective CPGs.
For example, Figure 4 illustrates the same relationships described
for Figure 3, but adds the CPGs for clarity. This three-way peering
Amini, et. al. Expires August 20, 2001 [Page 7]
Internet-Draft Distribution Peering Requirements February 2001
relationship is also detailed in [9].
In Figure 4, only those links marked by an "*" carry inter-CDN
exchanges. Further, the inter-CDN information exchanged with ORG A
(by the CPG of either CDN A or CDN B) is Request Routing and
Accounting information, and is not covered by this document. Only
the inter-CDN flow between the CPGs of CDN A and CDN B is a
Distribution Peering System exchange. The protocol requirements for
this flow of Distribution Peering information is addressed in this
document.
>>>>>>>>>>>>>
As per above I think ORG A's CPG will also exchange distribution peering
information with the other CPGs. Furthermore, it is not clear to me why the
CPGs of CDN A and CDN B will be exchanging distribution peering information.
>>>>>>>>>>>>>
+---------------+
| ORG A |
|...............| +--------------+
|REQUEST ROUTING|<===>| |
|...............| | CDN |
| ACCOUNTING |<===>| PEERING |
+---------------+ | GATEWAY |
| |
+--------------+
^| ^| ^| ^|
// // \\ \\
*// //* *\\ \\*
+---------------+ // // \\ \\ +---------------+
| CDN A | |v |v |v |v | CDN B |
|...............| +---------+ +---------+ |...............|
|REQUEST ROUTING|<=>| | | |<=>|REQUEST ROUTING|
|...............| | CDN | * | CDN | |...............|
| DISTRIBUTION |<=>| PEERING |<==>| PEERING |<=>| DISTRIBUTION |
|...............| | GATEWAY | | GATEWAY | |...............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
|---------------| +---------+ +---------+ +---------------+
| ^ | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
^ \ ^ /
\ \ +---------+ / /
\ \------->| CLIENTS |--------/ /
\---------| |<--------/
+---------+
Figure 4: Accounting and Request Direction Across Multiple CDNs
Amini, et. al. Expires August 20, 2001 [Page 8]
Internet-Draft Distribution Peering Requirements February 2001
3. Replication Models
Replication of content may take place using a push model, or a pull
model, or a combination of both.
o Use-initiated replication, where SURROGATEs, upon getting a cache
miss, retrieve CONTENT from the DISTRIBUTION SYSTEM, represents
the pull model. This model is 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 between the administrative domains of different
Distribution CDNs will occur via CPGs. Replication within a single
Distribution CDN is an intra-CDN communication and therefore, need
not flow through CPGs. Further, the replication model used within a
single Distribution CDN need not be the same as the model used to
replicate CONTENT between CDNs.
>>>>>>>>>>>>>>>
What does it mean that replication occur through the CPG? Does it mean
the CPG actually touch all data or is it orchestrating (or signaling)
the transfer of data, or both (or either) depending on use?
May be it depends on whether the CPG is a box or a function (which might
be realized by one or many boxes).
>>>>>>>>>>>>>>>
For both ORIGIN- and use- 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 may 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 CDN
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 CDN which
has no internal SURROGATES. For example, a Distribution CDN may
have servers at key exchange points within the network which only
serve content to other distribution systems, and peer with other
CDNs which provide SURROGATES which deliver content to CLIENTS.
Amini, et. al. Expires August 20, 2001 [Page 9]
Internet-Draft Distribution Peering Requirements February 2001
4. Distribution Peering Requirements
This section details general requirements for exchange of
inter-domain distribution information.
4.1 General Requirements
The goal of the Distribution Peering System is to interconnect the
Distribution Systems of multiple CDNs. 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 CDN and some between Distribution CDNs, the
Distribution Peering System is concerned only with those
communications between Distribution CDNs.
The three main components of the Distribution Peering System are
advertising, replication, and signaling.
Advertising: Distribution CDNs SHOULD advertise their capabilities
to potential Content Source CDNs.
Replication: Distribution CDNs MUST be able to move content from a
Content Source to a Content Destination.
Content signaling: Distribution CDNs MUST be able to propagate
content meta-data. This meta-data includes information such as
the immediate expiration of content or a change in the expiration
time of CONTENT.
Note that these requirements do not necessarily translate directly
into three distinct Distribution Peering 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 20, 2001 [Page 10]
Internet-Draft Distribution Peering Requirements February 2001
4.3 Replication Requirements
The following list specifies requirements to enable content
replication.
1. A common protocol for the replication of content.
>>>>>>>>>>>>
Is this saying there will be one protocol (as part of the distribution
peering protocol(s)) which will handle the actual transfer of content?
I would think we want to allow different protocols to perform this
transfer function and that the purpose of the distribution protocol
is (mainly) to signal what content needs to be transfered with what
protocol. For example in some cases (think large media files in a push
environment) the transfer of content might simply be done using ftp
between the participating CPGs, while in other cases some (existing or
new) application level multicast might be used to perform the distribution.
>>>>>>>>>>>>
2. A common format for the actual content data in the protocol.
3. A common format for the content meta-data in the protocol.
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. Signals for at least "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 20, 2001 [Page 11]
Internet-Draft Distribution Peering Requirements February 2001
5. Distribution Peering System Protocol Requirements
This section defines protocol requirements for each of the
advertising, replication and content signaling components of the
Distribution Peering System. Note that these requirements do not
necessarily translate directly into either one converged or three
distinct Distribution Peering protocols.
5.1 Overview of Distribution Peering Flow
In a Distribution Peering arrangement, the following sequence of
events is expected:
1. The Content Source will make a decision to request content
distribution services from a Content Destination. This decision
may have been preceded by one or more Content Destinations
sending distribution capabilities advertisements to the Content
Source, negotiation of an off-line contractual agreement, or
some combination.
2. The Content Source will send a content signal requesting
distribution services.
3. 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:
+ retrieving a copy of the object(s),
>>>>>>>>>>>>>>>>
Is retrieving the object(s) optional (in a pull model)?
>>>>>>>>>>>>>>>>
+ joining the content update channel, 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.
4. Once the Content Destination is prepared, it will notify the
Request Routing System of the content's availability.
>>>>>>>>>>>>
Nit:
In a pull model it might not actually have the content, but might
have the ability (be ready) to serve it.
>>>>>>>>>>>>
5. The Content Destination will terminate service on first
Amini, et. al. Expires August 20, 2001 [Page 12]
Internet-Draft Distribution Peering Requirements February 2001
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 Peering Protocol Requirements
Protocols must be scalable, i.e., support Distribution Peering
Systems 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 Peering protocols MUST enable a Content Destination
to advertise the capabilities of its distribution service in a
common format.
2. The advertisement protocol must be extensible with the
restriction that implementation-specific capabilities may be
safely ignored by Content Source.
3. Distribution Peering protocols MUST provide low-overhead,
in-line advertising mechanism to support distribution
advertising by in-line elements (e.g., proxies).
>>>>>>>>>>>>>
The distribution peering protocols run between CPGs (and treat CDNs
as black boxes). Where do inline elements get into the picture?
>>>>>>>>>>>>>
4. The CPG of a Content Destination MAY support Distribution
Advertising. That is, a Content Source may not require
real-time advertisement of distribution capabilities in order
to establish a Distribution Peering arrangement. Distribution
capabilities may be communicated via Advertisements or some
other agreed upon mechanism such as an off-line contract
negotiated between the parties.
>>>>>>>>>>>>>>>
Is this a *protocol* requirement?
>>>>>>>>>>>>>>
5. 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.
Amini, et. al. Expires August 20, 2001 [Page 13]
Internet-Draft Distribution Peering Requirements February 2001
6. A Content Destination MUST be able to advertise multiple service
profiles. Each 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).
7. A Content Destination MUST be able to advertise multiple
services profiles to the same or different potential Content
Sources.
8. 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.
9. By default, advertisements are advisory. A Content Destination
SHOULD be able to specify whether the capabilities are advisory
or binding.
10. The protocol MUST provide the ability to specify distribution
capabilities in terms of one or more of the following
attributes:
Profile ID: Profile Identifier for this advertisement 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 CDNs, and may be used
in advertisements to multiple Content Sources.
FootPrint: The areas served by the CDN. 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 CDN is able to distribute.
Capacity: The storage capacity that the CDN can provide.
Bandwidth: Maximum outbound bandwidth available from the CDN.
Object Bandwidth: Maximum outbound bandwidth supported for a
single object.
Distribution Method: The distribution methods that the CDN
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
Amini, et. al. Expires August 20, 2001 [Page 14]
Internet-Draft Distribution Peering Requirements February 2001
specified.
[ Editor's Note: Specifying support for splitting
requires refinement. ]
Request Routing Type: Type(s) of Component Peering supported
for CDI Request Routing Systems.
Accounting System Format: Supported protocol(s) and format(s)
for sending accounting and access feedback to a specified
CDI Accounting System.
Time Frame: Time frame for which this advertisement is valid.
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.
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 CPGs, for any content type which can be used to
transport meta-data and a full replica of content data.
2. In-line replication MUST be supported. I.e., it must be possible
for a Content Source to send a Content Signal which includes the
data to be distributed. This mechanism is expected to be used
only for small objects.
>>>>>>>>>>>>
May be want to limit the actual data transfer capabilities of this protocol
to the inline case, and for the rest only use it to signal (initiate) the
transfer.
>>>>>>>>>>>>
3. 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
Amini, et. al. Expires August 20, 2001 [Page 15]
Internet-Draft Distribution Peering Requirements February 2001
additional info required to establish a connection. E.g.
wcips://invalidation.com/content_set for signaling; will
provide clarification later ]
4. 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.
5. A Content Source SHOULD be able to specify an authoritative
source for content as well alternative distribution points.
6. The protocol MUST enable replication that is secured (encrypted)
across the communications channel, as well as content which has
been source encrypted.
>>>>>>>>>>>>
I think the first deals with securely moving content within the CDN.
Does the second mean digital rights management is becoming part of
what we do?
>>>>>>>>>>>>
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
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:
Amini, et. al. Expires August 20, 2001 [Page 16]
Internet-Draft Distribution Peering Requirements February 2001
Content ID: A unique identifier for this specific content, 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 ID MUST be
global and unique, i.e., a given content set MUST have the
same Content ID across all distribution CDNs in a
Distribution Peering System, and this ID MUST be unique
across *all* Distribution Peering Systems.
URI: The uniform resource identifier for the content. It
identifies how CLIENTS will request delivery services from
the Distribution CDN. 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.
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.
Amini, et. al. Expires August 20, 2001 [Page 17]
Internet-Draft Distribution Peering Requirements February 2001
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
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.
Subscription Fee: Specifies the fee charged by the Content
Source for providing content to the Distribution CDN.
[ Editor's Note: Subscription Fee was proposed in the
context of a Distributor model, i.e., the Content Source
'sells' the content to the Distributor and the Distributor
is responsible for clients relationship. My concern is
Amini, et. al. Expires August 20, 2001 [Page 18]
Internet-Draft Distribution Peering Requirements February 2001
whether this single attribute is enough to help with this
syndication model -- seeking comments. ]
[ Editor's Note: Next Hop has also been proposed as an
attribute, but the editor lacks sufficient understanding to
describe it; clue injections are solicited. ]
9. The following table specifies the relationship between content
signal types and the defined attributes.
Attribute Add Update Withdrawal
--------------------- -------- --------- -----------
Content 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
Subscription Fee optional optional unsupported
5.5.1 Content Signaling Examples
To be provided.
Amini, et. al. Expires August 20, 2001 [Page 19]
Internet-Draft Distribution Peering Requirements February 2001
6. Security Considerations
To be provided.
Amini, et. al. Expires August 20, 2001 [Page 20]
Internet-Draft Distribution Peering Requirements February 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, "CDN 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.
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 20, 2001 [Page 21]
Internet-Draft Distribution Peering Requirements February 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 20, 2001 [Page 22]
Internet-Draft Distribution Peering Requirements February 2001
Appendix A. Acknowledgements
To be provided.
Amini, et. al. Expires August 20, 2001 [Page 23]
Internet-Draft Distribution Peering Requirements February 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 20, 2001 [Page 24]