--- 1/draft-ietf-cdi-distribution-reqs-00.txt 2007-12-18 18:42:16.000000000 +0100 +++ 2/draft-ietf-cdi-distribution-reqs-01.txt 2007-12-18 18:42:16.000000000 +0100 @@ -1,21 +1,20 @@ - Network Working Group L. Amini Internet-Draft IBM Research -Expires: August 22, 2002 S. Thomas +Expires: June 23, 2003 S. Thomas TransNexus, Inc O. Spatscheck AT&T Labs - February 2002 + December 2002 Distribution Requirements for Content Internetworking - draft-ietf-cdi-distribution-reqs-00 + draft-ietf-cdi-distribution-reqs-01 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. @@ -24,21 +23,21 @@ 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 22, 2002. + This Internet-Draft will expire on June 23, 2003. 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 @@ -605,291 +604,11 @@ 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. - - 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. + the Distribution CN. This attr