draft-ietf-cdi-distribution-reqs-00.txt   draft-ietf-cdi-distribution-reqs-01.txt 
Network Working Group L. Amini Network Working Group L. Amini
Internet-Draft IBM Research Internet-Draft IBM Research
Expires: August 22, 2002 S. Thomas Expires: June 23, 2003 S. Thomas
TransNexus, Inc TransNexus, Inc
O. Spatscheck O. Spatscheck
AT&T Labs AT&T Labs
February 2002 December 2002
Distribution Requirements for Content Internetworking Distribution Requirements for Content Internetworking
draft-ietf-cdi-distribution-reqs-00 draft-ietf-cdi-distribution-reqs-01
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-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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://www.ietf.org/ietf/1id-abstracts.txt. http://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 June 23, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document specifies requirements for interconnecting, or This document specifies requirements for interconnecting, or
peering, the distribution systems of Content Networks (CN). peering, the distribution systems of Content Networks (CN).
Distribution internetworking requires advertising the capabilities Distribution internetworking requires advertising the capabilities
skipping to change at page 16, line 30 skipping to change at line 614
Content Set ID: A unique identifier for this specific content Content Set ID: A unique identifier for this specific content
set, so that future references (e.g. to modify the content or set, so that future references (e.g. to modify the content or
to withdraw it from distribution) may be resolved. This value to withdraw it from distribution) may be resolved. This value
can also be used to avoid loops. The Content Set ID MUST be 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 global and unique, i.e., a given content set MUST have the
same ID across all Distribution Systems, and this ID MUST be same ID across all Distribution Systems, and this ID MUST be
unique across *all* Distribution Systems. unique across *all* Distribution Systems.
URI: The uniform resource identifier for the content. It URI: The uniform resource identifier for the content. It
identifies how CLIENTS will request delivery services from identifies how CLIENTS will request delivery services from
the Distribution CN. This attribute can support an atomic the Distribution CN. This attr
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.
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.
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
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
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.
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
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
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.
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.
 End of changes. 6 change blocks. 
5 lines changed or deleted 4 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/