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. 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. 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. 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. 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 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. +---------------+ | 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. 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. 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), + 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. 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). 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. 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. 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. 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]