Network Working Group F. Douglis Internet-Draft AT&T Labs Expires: May 9, 2002 I. Chaudhri PanteraTech, Inc. P. Rzewski Inktomi Nov 8, 2001 Known Mechanisms for Content Internetworking draft-douglis-cdi-known-mech-00.txt 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 May 9, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Content Networks provide infrastructure, at layers 4 through 7, to get content to end users in a scalable, reliable, and cost-effective fashion. Content Internetworking is the interconnection of multiple content networks. This document describes some existing technologies for content internetworking. Douglis, et al. Expires May 9, 2002 [Page 1] Internet-Draft CDI Known Mechanisms Nov 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Content Bridge . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Authentication, Authorization, and Accounting . . . . . . . . 7 2.5 Request-Routing . . . . . . . . . . . . . . . . . . . . . . . 8 2.6 Operator roles . . . . . . . . . . . . . . . . . . . . . . . . 8 2.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. CiRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 How CiRouter Works . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Content-Provisioning . . . . . . . . . . . . . . . . . . . . . 12 3.4 Content Publishing . . . . . . . . . . . . . . . . . . . . . . 13 3.5 Content-Routing . . . . . . . . . . . . . . . . . . . . . . . 13 3.6 Content-Billing . . . . . . . . . . . . . . . . . . . . . . . 13 3.7 Content-Reporting . . . . . . . . . . . . . . . . . . . . . . 14 4. IDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Request-Routing . . . . . . . . . . . . . . . . . . . . . . . 17 4.4 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5 Authentication, Authorization, and Accounting . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 B. Intellectual Property Rights . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 Douglis, et al. Expires May 9, 2002 [Page 2] Internet-Draft CDI Known Mechanisms Nov 2001 1. Introduction Content Networks provide infrastructure, at layers 4 through 7, to get content to end users in a scalable, reliable, and cost-effective fashion. Content Internetworking is the interconnection of multiple content networks [7]. For somewhat historical reasons, "Content Internetworking" is also referred to as "Content Distribution Internetworking" and abbreviated "CDI". As of this writing, CDI is under consideration as an IETF working group. There are a number of existing documents that cover various aspects of content networks and CDI. These include: o The "models" document [7] provides an overview of CDI and defines some terminology. o The "scenarios" document [8] discusses ways in which CDI might be used in general. o The "known request-routing mechanisms" document [2] covers existing techniques for request-routing in content networks (not necessarily CDI). o The "architectural overview" [10] establishes an abstract architectural framework for CDI. o Finally, there are several requirements documents relating to CDI, including "request-routing requirements" [4], "distribution requirements" [1], and "AAA requirements" [11]. This document attempts to bridge a gap between the scenarios draft and the requirements drafts, by surveying existing request-routing, distribution, and AAA mechanisms for CDI. The reader is assumed to be familiar with all aforementioned CDI-related documentation. This document encompasses three existing systems. To offer information about additional systems, contact the editor. Content Bridge. Content Bridge [5] is an arrangement for content providers to gain some control over existing, deployed HTTP caching proxies in access networks. Content providers are able to send signals of content changes to those proxies in order to keep them consistent with origin servers. The content providers may also retrieve accounting information associated with their content from those proxies. An "operator" assists in the distribution of content signals and the aggregation of accounting data. CiRouter The Content Internetworking Router, CiRouter, in conjunction Douglis, et al. Expires May 9, 2002 [Page 3] Internet-Draft CDI Known Mechanisms Nov 2001 with CiAdmin allows CDN providers to provision, publish, route, track performance and gather billing usage data from the partner CDNs. The CiRouter directs browsers to retrieve web site content from the best source, where best is defined by a combination of price, performance, specific CDN accounts, and Internet regions set by the CiAdmin. CiRouter [9] uses URL rewriting (akin to the Content Modification approach described in Section 4.2 of the "known CDN request-routing mechanisms" document [2], to direct clients to one of a set of CDNs. IDNS. AT&T has a DNS-based redirection system, called Intelligent DNS (IDNS), to direct clients to one of a set of CDNs [3]. Each CDN then does its own DNS redirection to a particular cache within its own network. IDNS has similarities to the DNS-based multi- level request-routing resolution described in Section 2.3 of the "known CDN request-routing mechanisms" document [2], but it typically redirects to a completely different CDN with its own internal request-routing system. Douglis, et al. Expires May 9, 2002 [Page 4] Internet-Draft CDI Known Mechanisms Nov 2001 2. Content Bridge [EDITOR'S NOTE: The order and content of the following subsections vary. Does this matter?] 2.1 Overview [EDITOR'S NOTE: the text in this section describes Content Bridge circa autumn, 2000. The author of this text is not employed by the company that currently operates Content Bridge, and therefore is not privy to updated knowledge of the current state of Content Bridge. However, this text has been written with the consent of a current Content Bridge spokesperson. Corrections and updates are solicited.] Content Bridge was created as a service that would allow content providers to gain some control over deployed HTTP caching proxies in access networks. These proxies were typically already deployed by the access networks in a "forward" manner, implying they were used by clients through such methods such as explicit (browser) configuration or interception [6]. Therefore, a content provider's content was already being stored in these caching proxies based on user demand. In this situation, the only way for the content provider to control freshness of objects in these proxies would be through setting HTTP expiry times or "No-Cache" headers when objects were served from an origin. Similarly, a typical way to gather accounting data in this scenario would be through setting HTTP headers to ensure If-Modified- Since requests were made to the origin each time the proxy received a client request. A primary goal of Content Bridge was to make freshness control and the gathering of accounting more efficient than this. 2.2 Architecture Because Content Bridge consisted of both distribution internetworking and accounting internetworking, there were separate architectures for each. Douglis, et al. Expires May 9, 2002 [Page 5] Internet-Draft CDI Known Mechanisms Nov 2001 The distribution architecture is shown in the following diagram: Origin CDN/Hoster Operator Access Provider ---------- --------- --------- --------- -------- |content | |content| |content| |content| |access| |injector|-->| relay |-->| relay |-->| relay |-->| cache| ---------- --------- --------- --------- -------- (many) (several) (few) (several) (many) Content signals (e.g. invalidation messages) would originate at a point of origin, controlled by a content provider. These signals would be received by a CDN or hosting company that provided Content Bridge service to the content providers. These CDNs and Hosters played the role of aggregating these content signals. Once aggregated, these signals would be passed to a central Operator, who would then relay them out to the various access networks that were contractually entitled to receive the signals. The Operator's primary role in this case was to ensure that signals were relayed between "peer" networks. Once signals were received by an access network, they would be relayed to potentially many caching proxies deployed internally. Note that, when an access cache receives and acts on content signals in this manner, it now doubles as a "surrogate", because it is now "a gateway [...] delegated the authority to operate on behalf of, and typically working in close co-operation with, one or more origin servers" [6]. The accounting architecture is shown in the following diagram: CDN/Hoster Operator Access Provider ------------ ------------ ------------ -------- |accounting| |accounting| |accounting| |access| | relay |<--| relay |<--| relay |<--| cache| ------------ ------------ ------------ -------- (several) (few) (several) (many) For each content provider affiliated with a "peer" CDN/Hoster, the caching proxies in the access networks would be responsible for maintaining a separate log per domain. Periodically, these logs would be sent up to an aggregation box controlled by the access provider that would create summary logs. The summaries of each access provider would be aggregated yet again when passed up to the Douglis, et al. Expires May 9, 2002 [Page 6] Internet-Draft CDI Known Mechanisms Nov 2001 central Operator. Once fully aggregated, these logs could be used for settlement and then made available to CDN/Hoster for eventual passing back to the content provider. An overall design goal of Content Bridge was to re-use as many existing standards (e.g. HTTP methods) and common data formats (e.g. log file layout) as possible. 2.3 Distribution The only supported content signal in Content Bridge was "invalidation", which was provided using the HTTP DELETE method. Starting with the injector (controlled by the content provider), HTTP DELETE operations would be relayed, eventually being received by the caching proxies in the access networks. When received, a caching proxy would naturally act on an HTTP DELETE by invalidating the referenced object(s) from its cache. In some access provider networks, their content relays would often contain caches as well. This gave them the option to react to an HTTP DELETE by proactively doing an HTTP GET of the referenced objects, effectively "pre-loading" the cache with a fresh copy of the object. To allow for this to be specifically addressed by Content Bridge, an additional "pre-load" header would be included when an Injector originated an HTTP DELETE request, and peer access networks would pre-load based on the presence of this header (in exchange for additional funding). Note that, once participating in Content Bridge, any requests by access provider clients for content of "peered" domains could be treated in a special manner. Specifically, the access provider could choose to ignore any HTTP expiration headers on the objects stored in its caching proxies, since the distribution system of Content Bridge ensured that an invalidation message would be sent in the event that any objects in that domain were to expire. 2.4 Authentication, Authorization, and Accounting The typical accounting mechanism provided by Content Bridge was effectively a unique summary format, but designed to be similar to SQUID. For each URL accessed via a caching proxy, a summary line would appear that included the total number of hits for the object, average client access time across all his, total number of non-hits for the object, etc. If a content provider wanted more granular data, full SQUID logs could also be made available (typically at additional cost). All logs would be kept by the access provider in separate files based on domain, allowing them to be easily divided up for eventual delivery to content providers. Douglis, et al. Expires May 9, 2002 [Page 7] Internet-Draft CDI Known Mechanisms Nov 2001 Log data would typically be stored in the access provider's caching proxies for a small time period (e.g. several minutes) before being forwarded to an accounting relay for aggregation. Each accounting relay in line toward the content provider would similarly aggregate just a few minutes of data before passing to the next party. This prevented the need for periodic, massive log file pushes, and also allowed content providers to see their utilization data with minimal delays. The method of relaying log file data was through an HTTP POST operation. There were no special provisions for Authentication and Authorization in Content Bridge. Rather, since the participating "surrogates" were actually HTTP caching proxies, normal HTTP rules applied (i.e. no caching of responses to requests that required HTTP authentication, etc.) 2.5 Request-Routing Because the access provider participants had already chosen to deploy their caching proxies in a "forward" manner, Content Bridge participants had no ability to affect the request-routing decisions for content requests. Rather, the request-routing was already statically set: The client request would go to a caching proxy of the access provider's choosing. In the event of a "miss", the request would then possibly go through a content relay that also contains a cache (acting as an HTTP parent), and then directly to an origin server. Whereas the content provider did not have any technical control over the request-routing path, the contractual nature of the peering relationship was effectively an endorsement of this request routing: The peering relationship requested that the access provider to route all its clients' content requests for the content provider's domains to the very same caching proxies that were receiving the content signals and aggregating the accounting data for the content provider's objects. 2.6 Operator roles Much like NAP operators eased peering configuration and data exchange in the early days of bandwidth peering, the central Operator had an analogous role in Content Bridge. By providing centralized content relays and accounting relays, peering between content networks could be accomplished with minimal technical configuration. For example, if a content provider decided Douglis, et al. Expires May 9, 2002 [Page 8] Internet-Draft CDI Known Mechanisms Nov 2001 it wanted its content signals distributed to several access providers, it could state this goal to the Operator, and the Operator would take the responsibility of ensuring that the messages were relayed to the correct access providers. Another benefit of providing centralized accounting is the ability to provide settlement between networks. Content Bridge was primarily used for the distribution of "ad-revenue based" content. In other words, content providers wanted to have their content distributed as widely and efficiently as possible in the interest of increasing the number of page views. As a result, these content providers would pay an amount proportional to the quantity of data served by the access providers' caching proxies, and this traffic would be reflected in the logs. As a neutral third party, the Operator had the responsibility to collect funds based on these logs and distribute payments. By acting as the central authority for settlement, the Operator could potentially play even more roles. For example, when performing accounting based on logs, there is naturally a fear of fraud (e.g. by fabricating log data). Analytical "fraud detection" tools do exist, but naturally there is a cost with owning and operating the tools. By providing this as a central service, the Operator could give peace of mind to participants without requiring each of them to operate their own instances of fraud detection software. 2.7 Security Because the control signals and accounting data were transported over standard HTTP sessions, common HTTP security methods could be used to ensure the integrity of data. This could include SSL encryption and/or certificates. Douglis, et al. Expires May 9, 2002 [Page 9] Internet-Draft CDI Known Mechanisms Nov 2001 3. CiRouter 3.1 Overview The CiRouter provides a turnkey meta-CDN solution for managing content routing through multiple content delivery networks. The CiRouter is deployed by Service Providers (SPs) who wish to become a CDN by utilizing the minimum amount of network infrastructure to form a primary network. The end-to-end meta-CDN solution includes content provisioning, content publishing, content routing, content billing and content reporting. A web based application allows network administrators to provision sites. Content publishing provides capability of dynamic translation to multiple CDNs per viewer basis. Content routing directs browsers to retrieve web site content from the best source, where best is defined by a combination of price, performance, specific CDN accounts, and Internet regions. Content billing aggregates the CDN usage per site or per customer basis. Content reporting provides different views of the CDN usage. Douglis, et al. Expires May 9, 2002 [Page 10] Internet-Draft CDI Known Mechanisms Nov 2001 The following figure shows how to enable Service Providers to become a CDN and manage the amount of traffic that is routed through each of the peered networks. ..................................................................... . . . --------------- . . +------> | Publisher's |-------- . . | |own CDN account| | . . ----+----- --------------- V . . | | ------- . . | Hosting | | | . . |CiRouter | --------------- | | . . | |->| Regional |--->| | . . ----------- | CDN | | CDN | | | . . | Publisher | |Selection | --------------- |Viewer | . . | Server |---> | Criteria | | | . . | | | | | | . . ----------- | | --------------- | | . . | |->| Specialty |--->| | . . | | | CDN | | | . . | | --------------- | | . . | | ------- . . -----+---- /\ . . | | . . v | . . ---------- | . . | Hosting |---------------------------+ . . | Caches | . . ---------- . . . ..................................................................... 3.2 How CiRouter Works ...................................................................... . . . . . 2. CiRouter dynamically translates. Douglis, et al. Expires May 9, 2002 [Page 11] Internet-Draft CDI Known Mechanisms Nov 2001 . 3. Viewer's browser content for selected source CDN. . fetches objects and inserts performance code . . from selected sources HTML . . +---------------------------------------+ . . . | | . . | | . . +-----V---+ Content +--------+ . . | |<------------------------------| | . . | | Content | | +--------+ . . | |<------------------------------| |<-| Web | . . | Viewer | |CiRouter| |Hosting | . . | | | | +--------+ . . | | Content ___ Content | | /\ . . | |<-------- / \ <--------------| | | . . | | |CDNs |__ | | +---+----+ . . +---------+ \___/ \ +-------+ |Content | . . | | | | /\ /\ |Provider| . . | | \ __ / | | +--------+ . . | +----------------------------------------+ | . . | 1. Initial Web site | . . | Request www.publisher.com +-+----------------+. . | (DNS resolution) |Populate CiRouter |. . | |proximity DB |. . +------------------------------------------->|with network |. . 4. Browser provides performance |performance data |. . feedback for each CDN |and/or business |. . |rules |. . +------------------+. ...................................................................... 3.3 Content-Provisioning The CiAdmin enables transparent content delivery network (CDN) peering, by providing the ability to provision, securely publish, report usage, and report performance of content delivery on multiple CDNs. The CiAdmin is a web-based real-time content provisioning and reporting system for CiRouters that allows business rules based acceleration of web sites giving one control over the delivery of the content. CiAdmin is also capable of providing billing system ready usage data from all partner CDNs. The CiAdmin: 1. Provisions websites through a real-time web-based administration interface Douglis, et al. Expires May 9, 2002 [Page 12] Internet-Draft CDI Known Mechanisms Nov 2001 2. Gathers and provides usage information from all partner CDNs to a billing system 3. Provides reports that analyze system performance and usage across all partner CDNs 4. Provides actual viewer performance improvement for each accelerated website 3.4 Content Publishing CiRouter determines the best CDN to deliver the content through for embedded objects. Content is cached in the CDN caches based on pull- based HTTP requests. On a cache miss, the CDN retrieves the content from the CiRouter's primary network. On a cache miss on the primary network, the primary network retrieves the content from the origin server. 3.5 Content-Routing Content Delivery with the CiRouter using internal and peered CDNs: 1. The end-user enters Web site URL to request page from Web site 2. The browser is directed to a CiRouter via DNS 3. A price/performance based algorithm determines "best" delivery method for serving the content to that particular end-user 4. The CiRouter delivers HTML content by rewriting the URLs of the embedded objects to point to the best CDN and by inserting instructions to the end-user's browser to test several delivery alternatives the service provider has included in its portfolio. The CiRouter also tags the content to allow for publisher identification from raw logs. 5. The selected node (internal CDN or peered CDN) delivers embedded objects and the full page with objects displays on the browser 6. The browser provides performance feedback to CiRouter 3.6 Content-Billing Content Billing provides the following capabilities: 1. Collects all primary network logs Douglis, et al. Expires May 9, 2002 [Page 13] Internet-Draft CDI Known Mechanisms Nov 2001 2. Collects peered network logs 3. Splits the logs based on publisher account and collates logs from all sources per publisher 4. Generates per-publisher billing-ready usage reports for internal CiRouters 5. Generates per-publisher billing ready usage reports for all networks 3.7 Content-Reporting Content reporting has the following features: 1. Service providers can use reports to understand how the content is being routed and what performance was delivered 2. Publishers can get insight into performance improvement delivered by the service provider 3. Different reporting metrics are used, e.g.: Gbytes, Hits, Mbps, top URLs 4. The browser provides performance feedback to CiRouter Douglis, et al. Expires May 9, 2002 [Page 14] Internet-Draft CDI Known Mechanisms Nov 2001 4. IDNS 4.1 Overview The "Intelligent DNS" (IDNS) system uses a DNS server to redirect, typically via the DNS CNAME response, to a DNS server within a selected CDN. The brokering DNS server monitors the load of other CDNs within a set of predefined "regions" (e.g., individual countries). Using the IP address of the DNS server making a request, IDNS maps the DNS server to a region and selects the CDN that serves that region "best" based on various metrics. IDNS uses CNAME or NS redirection to other CDNs, or it can forward the DNS request directly to a CDN that will respond to the request directly: Origin Server +-------+ -->| | ---- | | ---- +-------* ---- \ CDN H +- -------- \ | ---//---------\\-- \ ---------- | // \ \ /// +---+ \\\ | / CDN B \\\ \ || |***| || | \ \ | +++---+ | /| \ \ | oo +---+ | | | (IDNS) | \ || ++ |***| || | | +---+ ++ Brokering | \ \\\ +---+/// | | |***| oo DNS | \ ---------- | | +---+ ++ \ | \ | | | \\ ++ ++ | \ | | | \XX XX | \ | v | ++ ++ | \ | +---+ ++ | | \ | |***| oo | ^| | \ \ +---+ ++ | || / \ \ ^ . 2|| 3 / ------\--- \\ \ .. | || // /-------- \ \\\ \\ \ .. | || // ||++ +---+ \ || \--\. |-++/ |--oo |***| +---+ | ..\------+ || >+ ++ +---+ |***| | .. \ ||V -- || +---+ || . \ | NS or \\\ / /// .. \ ++ --CNAME ---//----- Douglis, et al. Expires May 9, 2002 [Page 15] Internet-Draft CDI Known Mechanisms Nov 2001 .. \\ ||<-redirect / . \ .|| / CDN G Triangular Client DNS ++\ // Redirection . \ \ / 5,6 . 5,6 1,4 / . \ \ // . \ \-- / \ / \< > | | | \ / --- Client +--------------------------------------------------+ | | | +---+ | | |***| Edge Server | | +---+ | | | | ++ | | || ++ ++ | | || oo XX DNS Servers | | ++ ++ ++ | | | | client CDN brokering | +--------------------------------------------------+ Here, a client (1) contacts its local DNS server, which (2) contacts the brokering DNS server. This server (3) returns either a CNAME or NS record redirecting to another CDN, or an A record for a server within CDN B. (The latter is called a "triangular resolution".) Eventually, (4) an IP address is returned to the client, which (5) requests and (6) receives the actual content. 4.2 Architecture Douglis, et al. Expires May 9, 2002 [Page 16] Internet-Draft CDI Known Mechanisms Nov 2001 The IDNS architecture looks like this: DNS/control agent interface interface | | .................... | ........................................... . . | . | . . . | . | ____________ . . . | . | | config | . . . | . | | | . . . | . V /| agent | . . . | . / |____________| . . . | . / . . ____________ . | . ____________ / ____________ . . | DNS | . V . | Control | <--' | management | . . | |<--------------| | <-------| | . . | Engine | . . | Component | | agent | . . |____________| . . |____________| <--- |____________| . . . . \ . . . . \ ____________ . . . . \ | load | . . . . \| | . . . . | agent | . . . . |____________| . . . . . .................... ........................................... DNS Element Control Element The "DNS Engine" is a customized DNS server, which is driven by tables that are set through the DNS/control interface. The DNS Engine maps the IP address of the requesting host, usually a local DNS server acting on behalf of a client, and maps that address into a "region". Using its tables, it selects the best CDN to which the client should be directed. This selection is probabilistic; for instance, a client in a particular region may be sent to one CDN with probability X and a second CDN with probability (1-X). These probabilities are updated by the "Control Element" based on its initial configuration (which defines such things as regions), a run- time GUI-based management agent for dynamic modification of these policies, and load agents that accept information from the brokered CDNs. 4.3 Request-Routing Known mechanisms for CDN request-routing include DNS-level redirection via "CNAME" or "NS" responses, as well as explicit "A" responses with IP addresses (see section 2.3 of [2]). IDNS supports Douglis, et al. Expires May 9, 2002 [Page 17] Internet-Draft CDI Known Mechanisms Nov 2001 each of these responses, but primarily relies on the CNAME response to redirect to a DNS server for another CDN. Domain names are mapped by explicit agreement between the brokering DNS system and any CDN providing content. For example, A.EXAMPLE.COM might be mapped by the broker B into a DNS name in the namespace of another CDN, G, as A.EXAMPLE.COM.B.G.COM. G would find anything in the domain B.G.COM as a brokered domain. The "Host" header in the HTTP request would tell G what original host was requested, and G would statically map requests for A.EXAMPLE.COM to some origin server such as ORIGIN-A.EXAMPLE.COM. 4.4 Distribution IDNS relies on the content distribution functions of individual CDNs. For static content such as images, content is not prepopulated into CDNs. Content may be invalidated using any mechanism an individual CDN provides for invalidation. On a cache miss, the CDN retrieves content from the origin server (not from the brokering CDN). 4.5 Authentication, Authorization, and Accounting IDNS relies on the AAA mechanisms of individual CDNs, and expects cooperating CDNs to bill each other as though they were customers of one another. Douglis, et al. Expires May 9, 2002 [Page 18] Internet-Draft CDI Known Mechanisms Nov 2001 5. Security Considerations There are no security-related issues related to the systems described in this document, beyond the detailed discussion of those issues in "Content Internetworking Architectural Overview" [10]. Douglis, et al. Expires May 9, 2002 [Page 19] Internet-Draft CDI Known Mechanisms Nov 2001 6. Conclusion Content Internetworking is still in its earliest stages. These three examples of known existing mechanisms that predate standardization efforts within the IETF may help to guide those efforts through their protocols, implementation experiences, and running code. Douglis, et al. Expires May 9, 2002 [Page 20] Internet-Draft CDI Known Mechanisms Nov 2001 References [1] Amini, L., Thomas, S. and O. Spatscheck, "Distribution Requirements for Content Internetworking", draft-amini-cdi- distribution-reqs-01 (work in progress), July 2001, . [2] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request- Routing Mechanisms", draft-cain-cdnp-known-request-routing- 03.txt (work in progress), Nov 2001, . [3] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal, S., Spatscheck, O. and W. Sturm, "CDN Brokering", Workshop on Web Caching and Content Distribution http://www.cs.bu.edu/pub/wcw01, June 2001, . [4] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request- Routing Requirements for Content Internetworking", draft-cain- request-routing-req-02.txt (work in progress), July 2001, . [5] "Content Bridge", September 2001, . [6] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [7] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for CDN Peering", draft-day-cdnp-model-08.txt (work in progress), Oct 2001, . [8] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking Scenarios", draft-day-cdnp-scenarios-03.txt (work in progress), March 2001, . [9] Chaudhri, I., "CiRouter Whitepaper", July 2001. [10] Green, M., Cain, B., Tomlinson, G., Thomas, S., Rzewski, P. and S. Thomas, "Content Internetworking Architectural Overview", Douglis, et al. Expires May 9, 2002 [Page 21] Internet-Draft CDI Known Mechanisms Nov 2001 draft-green-cdnp-gen-arch-03.txt (work in progress), March 2001, . [11] Nair, R., Gilletti, D., Scharber, J. and J. Guha, "Content Internetworking (CDI)Authentication,Authorization, and Accounting Requirements", draft-gilletti-cdnp-aaa-reqs-01 (work in progress), June 2001, . [12] Authors' Addresses Fred Douglis AT&T Labs 180 Park Ave, Bldg 103 Florham Park, NJ 07932 US Phone: +1 973-360-8775 EMail: douglis@research.att.com URI: http://www.research.att.com/~douglis/ Imran Chaudhri PanteraTech, Inc. 2070 Chain Bridge Road, Suite 150 Vienna, VA 22182 US Phone: EMail: imran@chaudhri.net Phil Rzewski Inktomi 4100 East Third Avenue MS FC2-4 Foster City, CA 94404 US Phone: +1 650-653-2487 EMail: philr@inktomi.com Douglis, et al. Expires May 9, 2002 [Page 22] Internet-Draft CDI Known Mechanisms Nov 2001 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of the following persons for comments on this document and/or contributions to text included herein: Alex Biliris, Chuck Cranor, Mark Day, Arthur Huston, Ken Lee, Kent Lockhart, Michael Rabinovich, Sandeep Sibal, Oliver Spatscheck, and Walter Sturm. Douglis, et al. Expires May 9, 2002 [Page 23] Internet-Draft CDI Known Mechanisms Nov 2001 Appendix B. Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights, at [12]. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Douglis, et al. Expires May 9, 2002 [Page 24] Internet-Draft CDI Known Mechanisms Nov 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. Douglis, et al. Expires May 9, 2002 [Page 25]