Network Working Group M. Green Internet-Draft Entera Expires: April 20, 2001 B. Cain Mirror Image Internet G. Tomlinson Entera October 20, 2000 CDN Peering Architectural Overview draft-green-cdnp-gen-arch-01.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 April 20, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Discussion List & Archives This document and related documents are discussed on the cdn mailing list. To join the list, send mail to cdn-request@ops.ietf.org. To contribute to the discussion, send mail to cdn@ops.ietf.org. The archives are at ftp://ops.ietf.org/pub/lists/cdn.*. Green, et. al. Expires April 20, 2001 [Page 1] Internet-Draft CDNP Architecture October 2000 Abstract This memo presents the general architecture and core building blocks used in the peering of content distribution networks (CDNs). This involves the interconnection of CDNs to create larger virtual CDNs with greater reach, while still retaining the same simple interface to both content providers and viewers. The scope of this work is limited to external interconnections between CDNs and does not address internal mechanisms used within CDNs, which for the purpose of the document are considered to be black boxes. This work is intended to establish an abstract architectural framework to be used in the development of protocols, interfaces and system models for standardized, interoperable, peering among CDNs, and peering of CDNs with content providers. The term "peering" used within this memo is defined as the coupling and interaction between CDNs in order to build internetworks of CDNs. Green, et. al. Expires April 20, 2001 [Page 2] Internet-Draft CDNP Architecture October 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 2. CDN Peering System Architecture . . . . . . . . . . . . . 7 3. Request Direction Peering System . . . . . . . . . . . . . 10 3.1 Request Direction Overview . . . . . . . . . . . . . . . . 10 3.2 Request Routing . . . . . . . . . . . . . . . . . . . . . 12 3.3 Request Direction Problems to Solve . . . . . . . . . . . 12 3.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 13 3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.1 Modified DNS Redirection Model . . . . . . . . . . . . . 14 3.5.2 DNS Redirection Model using NS records . . . . . . . . . . 14 3.5.3 DNS Redirection Model using CNAME records . . . . . . . . 15 3.5.4 Hybrid DNS & Content Aware Redirection Models . . . . . . 16 3.5.4.1 Server-side direction model . . . . . . . . . . . . . . . 16 3.5.4.2 Client-side direction model . . . . . . . . . . . . . . . 16 4. Distribution Peering System . . . . . . . . . . . . . . . 17 4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 17 4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 18 4.3 Distribution Components . . . . . . . . . . . . . . . . . 19 4.4 Distribution Problems to Solve . . . . . . . . . . . . . . 20 4.4.1 Replication Problems . . . . . . . . . . . . . . . . . . . 20 4.4.2 Signaling Problems . . . . . . . . . . . . . . . . . . . . 20 4.4.3 Advertising Problems . . . . . . . . . . . . . . . . . . . 20 4.5 Distribution Requirements . . . . . . . . . . . . . . . . 21 4.5.1 Replication Requirements . . . . . . . . . . . . . . . . . 21 4.5.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 21 4.5.3 Advertising Requirements . . . . . . . . . . . . . . . . . 22 5. Accounting Peering System . . . . . . . . . . . . . . . . 23 5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 23 5.2 Accounting Data Types . . . . . . . . . . . . . . . . . . 24 5.3 Accounting Models . . . . . . . . . . . . . . . . . . . . 25 5.4 Accounting Problems to Solve . . . . . . . . . . . . . . . 25 5.5 Accounting Requirements . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . 27 6.1 Threats to CDN Peering . . . . . . . . . . . . . . . . . . 27 6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 27 6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 27 6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 27 6.1.1.3 Delivery of Bad CONTENT . . . . . . . . . . . . . . . . . 28 6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 28 6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 28 6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 28 6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 28 6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 28 6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 28 6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 29 6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 29 6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 29 Green, et. al. Expires April 20, 2001 [Page 3] Internet-Draft CDNP Architecture October 2000 6.1.3 Threats to a CDN . . . . . . . . . . . . . . . . . . . . . 29 6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 29 6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 29 6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 29 7. Impact on the Internet Architecture . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 Full Copyright Statement . . . . . . . . . . . . . . . . . 35 Green, et. al. Expires April 20, 2001 [Page 4] Internet-Draft CDNP Architecture October 2000 1. Introduction In a typical (non-peered) CDN [12], a single service provider operates the DIRECTION SYSTEM and the DISTRIBUTION SYSTEM. In addition, that service provider has the commercial relationship with the content source (operating the origin server). Typically, the value that this CDN presents to a PUBLISHER is based on the scale and reach of its combined systems. There are practical limits to the scale and reach of any single network. Increasing either scale or reach is ultimately limited by the cost of equipment, the space available for deploying equipment, and/or the demand for that scale/reach of infrastructure. Sometimes a particular audience is tied to a single service provider or a small set of providers by constraints of technology, economics, or law. CDN peering allows different CDNs to share resources so as to provide larger scale and/or reach to participants than they could otherwise achieve. Although this peering is similar in concept to layer 3 peering between autonomous systems [1], it differs rather fundamentally in that it involves the peering of content delivery according to semantically rich application policies. The context of "peering" used within this application domain pertains to the interconnection of CDNs in order to build internetworks of CDNs, which is quite different than the traditional dictionary definition of a peer "one that is of equal standing with another" [16]. Although this definition is conceptually derived from its use in the interconnection of autonomous systems, it differs significantly in that it doesn't presume a settlement-free basis [17] business model. Through the use of CDN peering, complex distribution topologies can be composed, including both hierarchical and mesh. This memo describes the overall architectural structure and the fundamental building blocks used in the composition of CDN peering. Consult [12] for a description of, and the vocabulary used in, this application domain. A key requirement of the architecture itself, is the it be able to address each of the CDN peering scenarios enumerated in [13]. The scope of this work is limited to external interconnections between CDNs (i.e. INTER-CDN) and does not address internal mechanisms used within CDNs (i.e. INTRA-CDN), which for the purposes of the document are considered to be black boxes. INTER-CDN peering as specified in this architecture includes both CDN to CDN as well as content provider to CDN interactions. This work is intended to establish an abstract architectural framework to be used in the development of protocols, interfaces and system models for standardized, interoperable peering among CDNs. Green, et. al. Expires April 20, 2001 [Page 5] Internet-Draft CDNP Architecture October 2000 The architecture is presented first from an abstract system model in order to establish a framework comprised of the most fundamental elements. Using these architectural elements as building blocks, it subsequently transitions into a system architecture constrained by fundamental assumptions and scenario requirements. Through the use of a broad set of usage scenarios as requirements, a cognizant effort has been made to ensure the system architecture doesn't unduly constrain business models and their associated value chains. At the core of CDN peering are three principle architectural elements that constitute the building blocks of the CDN peering system. These elements are DIRECTION PEERING system, DISTRIBUTION PEERING system, and ACCOUNTING PEERING system. Collectively, they control selection of the delivery CDN, content distribution between peering CDNs, and usage accounting, including billing settlement among the peering CDNs. This work takes into consideration relevant IETF RFCs and IETF works-in-progress. In particular, it is mindful of the end-to-end nature [5][9] of the Internet, the current taxonomy of web replication and caching [10], and the accounting, authorization and authentication framework [11] Terms in ALL CAPS are defined in [12]. Green, et. al. Expires April 20, 2001 [Page 6] Internet-Draft CDNP Architecture October 2000 2. CDN Peering System Architecture The system architecture revolves around the general premise that individual CDNs are wholly contained within an administrative domain [2] that is composed of either autonomous systems [1] or overlay networks. The system architecture for CDN peering accommodates this premise by assuring that the information and controls are available for inter-domain administration. With this in mind, CDN peering involves the interconnection of these administrative domains through layer 5 exterior gateway protocols and machinery. The notion of exterior gateway protocols and machinery has precedence in the IETF in the form of the Border Gateway Protocol (BGP) [4], which serves as a reference that this architecture is loosely modeled upon. The system architecture is predicated upon the following fundamental assumptions: 1. The URI [7] name space is the basis of PUBLISHER object identifiers. 2. PUBLISHERs delegate authority of their object URI name space being distributed by peering CDNs to the DIRECTION PEERING system. 3. There is a normalized canonical name space extension for CDN meta data encapsulated within URIs being distributed by peering CDNs. Figure 1 contains a system architecture diagram of the core elements involved in CDN peering. Green, et. al. Expires April 20, 2001 [Page 7] Internet-Draft CDNP Architecture October 2000 +--------------+ /--------------| DIRECTION |<----\ / | PEERING | | / /-------------->| SYSTEM* |<-\ | / / +--------------+ | | / / ^ | | / / | | | / / | | | / / +--------------+ | | | | | DISTRIBUTION | | | V | __| PEERING |<-\ | +--------+ +-----------+ / | SYSTEM* | |\ | +---------+ | |<---| |<-/ +--------------+ | \ \_| | | CLIENT | | SURROGATE | | \__| ORIGIN | | |--->| |-\ +--------------+ | /-->| | +--------+ +-----------+ \ | ACCOUNTING |--// +---------+ \->| PEERING |--/ | SYSTEM* |--\ +---------+ +--------------+ \ | BILLING | \-->| ORG. | | | +---------+ Note: * represents core elements of CDN peering Figure 1 System Architecture Elements of a CDN Peering System The System Architecture is comprised of 7 major elements, 3 of which constitute the CDN peering system itself. The peering elements are DIRECTION PEERING system, DISTRIBUTION PEERING system, and ACCOUNTING PEERING system. Correspondingly, the system architecture is a system of systems: 1. The ORIGIN publishes content into the DISTRIBUTION SYSTEM. This process includes both the delegation of URI name space to the DIRECTION PEERING system and delegation of delivery to the DISTRIBUTION PEERING system. 2. The DISTRIBUTION PEERING system moves content between CDN DISTRIBUTION SYSTEMs. Additionally this system interacts with the DIRECTION PEERING system via feedback ADVERTISEMENTs to assist in the peered CDN selection process for CLIENT requests. 3. The CLIENT requests content from a SURROGATE. Green, et. al. Expires April 20, 2001 [Page 8] Internet-Draft CDNP Architecture October 2000 4. The DIRECTION PEERING system directs a REQUEST from a CLIENT to a suitable SURROGATE in a peering CDN. DIRECTION PEERING systems interact with one another via feedback ADVERTISEMENTs in order to keep request routing tables current. 5. The selected SURROGATE delivers the requested content to the CLIENT. Additionally, the SURROGATE sends accounting information for delivered content to the ACCOUNTING PEERING system. 6. The ACCOUNTING PEERING system aggregates and distills the accounting information into statistics and content detail records for use by the ORIGIN and BILLING ORGANIZATION. Statistics are also used as feedback to the DIRECTION PEERING system. 7. The BILLING ORGANIZATION uses the content detail records to settle with each of the parties involved in the content distribution and delivery process. This process has been described in its simplest form in order to present the CDN peering architecture in the most abstract way possible. In reality, this process is more complex when applied to policies, business models and service level agreements that span multiple peering CDNs. The orthogonal core peering systems are discussed in greater depth in Section 3, Section 4 and Section 5 respectively. It is important to note that the DIRECTION PEERING system is the only mandatory element for CDN peering to function. A DISTRIBUTION PEERING system is needed when the PUBLISHER does not have a NEGOTIATED RELATIONSHIP with every peering CDN. Additionally, an ACCOUNTING PEERING system is needed when statistical and usage information is needed in order to satisfy PUBLISHER and/or BILLING ORGANIZATION requirements. Additionally, it is important to note that the core elements can be provided by independent administrative domains [2] so long as they have authorized peering relationships (i.e. affiliations) between themselves. Green, et. al. Expires April 20, 2001 [Page 9] Internet-Draft CDNP Architecture October 2000 3. Request Direction Peering System The DIRECTION PEERING system represents the request routing function of the CDN peering system. It is responsible for binding CLIENTs to peered CDNs for the delivery of content. It has a dependency upon the DISTRIBUTION PEERING system for content location information within the peered CDNs. 3.1 Request Direction Overview DIRECTION systems direct CLIENT REQUESTs to a suitable SURROGATE, which is able to service a client request. Many request direction systems direct users to a surrogate that is "closest" to the user on the "least loaded" surrogate. The only requirement of the request direction system is that it directs users to a surrogate that can serve the requested content. Request direction is commonly performed via redirection mechanisms. Such redirection is accomplished through a variety of connection hand-off mechanisms including but not limited to DNS [3], HTTP [8], RTSP [6], etc redirection. DIRECTION PEERING is the interconnection of two or more DIRECTION SYSTEMs so as to increase the number of REACHABLE SURROGATEs for at least one of the interconnected systems. In order for a PUBLISHER's CONTENT to be delivered by multiple peering CDNs, it is necessary to federate each CDN DIRECTION system under the DNS name space of the PUBLISHER object. This federation is accomplished by first delegating the PUBLISHER DNS name space to an AUTHORITATIVE DIRECTION SYSTEM. The AUTHORITATIVE DIRECTION SYSTEM subsequently splices each peering CDN DIRECTION SYSTEM into this DNS name space. Figure 2 contains a architecture diagram of the entities involved in the DIRECTION PEERING system. Green, et. al. Expires April 20, 2001 [Page 10] Internet-Draft CDNP Architecture October 2000 +---------------+ | CLIENT | +---------------+ | | (Direction Tree Root) +---------------+ | AUTHORITATIVE | | DIRECTION | | SYSTEM | +---------------+ | | INTER-CDN Direction /----------------/ \-----------------\ | | (1st Level) +--------------+ +--------------+ .........| DIRECTION |.......... .........| ********* |.......... . | CPG | . . | **** | . . +--------------+ . . +--------------+ . . INTRA-CDN | | | Direction . . | | . . /----/ | \-----\ . . /------/ \-----\ . . | | | . . | | . . +-----------+ | +------------+ . . +------------+ +-----------+ . ..| SURROGATE |.|..| SURROGATEs |.. ..| ********** |....| ********* |.. +-----------+ | +------------+ +------------+ +-----------+ | | INTER-CDN Recursive Direction (2nd Level) +--------------+ .........| DIRECTION |.......... . | CPG | . . +--------------+ . . INTRA-CDN | | Direction . . /----/ \-----\ . . | | . . +-----------+ +------------+ . ..| SURROGATE |....| SURROGATEs |.. +-----------+ +------------+ Figure 2 DIRECTION PEERING System Architecture The DIRECTION PEERING system is hierarchical in nature. There exists exactly one direction tree for each PUBLISHER URI. The AUTHORITATIVE DIRECTION SYSTEM is the root of the direction tree. There may be only one AUTHORITATIVE DIRECTION SYSTEM for a URI direction tree. Subordinate to the AUTHORITATIVE DIRECTION SYSTEM are the DIRECTION SYSTEMs of the first level peering CDNs. There may exist recursive subordinate DIRECTION SYSTEMs of additional level peering CDNs. Green, et. al. Expires April 20, 2001 [Page 11] Internet-Draft CDNP Architecture October 2000 Note: A PUBLISHER object may have more than one URI associated with it and therefore be present in more than one direction tree. 3.2 Request Routing The actual "routing" of a client request is through DIRECTION Content Peering Gateways (CPG). The AUTHORITATIVE DIRECTION CPG receives the initial client request and redirects the request to an appropriate DISTRIBUTING CDN. This process of INTER-CDN request direction may occur multiple times in a recursive manner between DIRECTION CPGs until the DIRECTION SYSTEM arrives at an appropriate DISTRIBUTING CDN to deliver the content. Direction systems explicitly peer but do not have "interior" knowledge of surrogates from other CDNs. Each CDN operates its internal request direction system. In this manner, request direction systems peer very much like IP network layer peering. 3.3 Request Direction Problems to Solve Specific problems in request direction needing further investigation include: 1. How do DNS request direction systems redirect a request? If a given CDN is peered with many other CDNs, what are the criteria which redirects a request to another CDN? 2. How do Content-Aware direction systems redirect a request? If a given CDN is peered with many other CDNs, what are the criteria which redirects a request to another CDN? 3. What are the merits of designing a generalized content routing protocol, rather than relying on redirection mechanisms. 4. What is the normalized canonical URI name space for request direction? Because request direction is federated across multiple CDNs, it is necessary to have agreed upon standards for the encoding of URIs. There are many potential elements which may be encoded. Some of these elements are: authoritative agent domain, publisher domain, content type, content length, etc. 5. How are policies communicated between the DIRECTION SYSTEM and the DISTRIBUTION ADVERTISEMENT system? A given CDN may wish to serve only a given content type or a particular set of users. These types of policies must be communicated between CDNs. Green, et. al. Expires April 20, 2001 [Page 12] Internet-Draft CDNP Architecture October 2000 6. What are the request direction protocols in DNS? When a request is routed to a particular DIRECTION CPG, a clear set of DNS rules and policies must be followed in order to have a workable and predictable system. 7. How do we protect the DIRECTION SYSTEM against denial of service attacks? 3.4 Requirements DIRECTION SYSTEMs require some coupling to DISTRIBUTION SYSTEMs. For example, a CDN may have a DIRECTION SYSTEM that makes use of its own DISTRIBUTION SYSTEM. The DIRECTION SYSTEMs may also communicate some information about the DISTRIBUTION SYSTEMs for which they are performing redirection. We assume that there is a peering relationship between DIRECTION CPGs. This peering relationship at a minimum must exchange a set of CLIENT IP addresses that can be serviced, and a set of information about the DISTRIBUTION SYSTEMs, for which they are performing redirection. Request Direction Requirements 1. Normalized canonical URI name space structure for peered CDN distribution of PUBLISHER objects. 2. Single AUTHORITATIVE DIRECTION SYSTEM for PUBLISHER object URI name space. 3. Use of a URI name space based direction mechanism. The direction mechanism is allowed to use as much of the URI name space as it needs to select the proper SURROGATE. For example, DNS based mechanisms utilize only the host subcomponent, while content aware mechanisms utilize use multiple components. 4. Assure the request direction tree does not become a cyclic routing graph. 5. Assure that adjacent direction systems from different administrative domains (different CDNs) use a compatible request direction mechanism. 6. Assure that adjacent direction systems from different administrative domains (different CDNs) agree to direct requests for the CONTENT in question. Green, et. al. Expires April 20, 2001 [Page 13] Internet-Draft CDNP Architecture October 2000 3.5 Example In order to provide a greater understanding of the DIRECTION PEERING system, the following four examples are described. While these don't represent all implementations, they are considered to be representative of the most common implementations deployed today. It is important to remember the INTRA-CDN DIRECTION SYSTEM is opaque to the CDN peering architecture, since it is within the CDN black box. The following examples contain known INTRA-CDN implementations in order to present the reader with a complete scenario of DIRECTION PEERING. 3.5.1 Modified DNS Redirection Model This example describes a DNS redirection model that utilizes protocol extensions for proxies between peered DIRECTION CPGs. DNS is utilized exclusively by the AUTHORITATIVE DIRECTION SYSTEM for INTER-CDN redirection and exclusively by the CDN DIRECTION SYSTEM for INTRA-CDN redirection. We assume in this example that the CDN DIRECTION SYSTEM R2 has a INTER-CDN peering relationship with the AUTHORITATIVE DIRECTION SYSTEM R1 and has informed R1 via a peering protocol, similar to BGP but modified for content routing information, and that some set of addresses including the address of the CLIENT, is in the "redirection set" of R2. We also assume the URI being REQUESTED is contained within a name space authoritatively serviced by R1. When the CLIENT contacts the authoritative DNS server R1 to resolve the URI domain name, R1 determines that the peering R2 needs to perform the INTRA-CDN redirection to one of its SURROGATES for service of the forthcoming CLIENT REQUEST. Since, R2 cannot return the NS record, R1 proxies R2 with an DNS protocol extension carrying both the CLIENT address and the domain name of the URI. At this point the redirection process has been delegated to the proper peering CDN for INTRA-CDN redirection. R2 runs its request routing computation as though the CLIENT had directly contacted it, and returns the result of the selected SURROGATE to R1, which in turn passes it on to the CLIENT. At this point the CLIENT has the correct SURROGATE to connect with for DELIVERY of the CONTENT. 3.5.2 DNS Redirection Model using NS records This example describes a pure DNS redirection model. DNS is utilized exclusively by the AUTHORITATIVE DIRECTION SYSTEM for INTER-CDN redirection and exclusively by the CDN DIRECTION SYSTEM for INTRA-CDN redirection. Green, et. al. Expires April 20, 2001 [Page 14] Internet-Draft CDNP Architecture October 2000 We assume in this example that the CDN DIRECTION SYSTEM R2 has a INTER-CDN peering relationship with the AUTHORITATIVE DIRECTION SYSTEM R1. We also assume that the DNS name used by the PUBLISHER contains at least as many name levels as the INTER-CDN redirection tree is deep. In our case, for example, using only R1 and R2 the name could be foo2.foo1.com. When the CLIENT request's a URI, the DNS resolution request will contain the domain name foo2.foo1.com. To resolve this domain name the client site DNS server will first contact the DIRECTION SYSTEM of R1 since it is authoritative for the domain foo1.com. The DIRECTION SYSTEM R1 has to decide now if it wants to serve the content from one of its own SURROGATEs or if the content should be served from the CDN with DIRECTION SYSTEM R2. If R1 wants to serve the content it returns an A record with the IP address of the appropriate SURROGATE. If R1 decides R2 should serve the content, it returns a NS record to the client site DNS server, denying a recursive resolution and pointing the client site DNS server to the DIRECTION SYSTEM of R2. R2 can now decide which SURROGATE to use and returns an appropriate A record. At this point, the CLIENT has the correct SURROGATE to connect with for DELIVERY of the CONTENT. 3.5.3 DNS Redirection Model using CNAME records This example describes a pure DNS redirection model. DNS is utilized exclusively by the AUTHORITATIVE DIRECTION SYSTEM for INTER-CDN redirection and exclusively by the CDN DIRECTION SYSTEM for INTRA-CDN redirection. We assume in this example that the CDN DIRECTION SYSTEM R2 has a INTER-CDN peering relationship with the AUTHORITATIVE SYSTEM R1. When the CLIENT request's a URI, the DNS resolution request will first be made to DIRECTION SYSTEM R1 since it is the authoritative DIRECTION SYSTEM. The DIRECTION SYSTEM R1 has to decide now if it wants to serve the content from one of its own SURROGATEs or if the content should be served from the CDN with DIRECTION SYSTEM R2. If R1 wants to serve the content it returns an A record with the IP address of the appropriate SURROGATE. If R1 decides R2 should serve the content it returns a CNAME record to the CLIENT site DNS server denying a recursive resolution. In this case the AUTHORITATIVE DIRECTION SYSTEM for the CNAME (not the original name requested by the CLIENT) has to be R2. R2 can now decide which SURROGATE to use and returns an appropriate A record. At this point, the CLIENT has the correct SURROGATE to connect with for DELIVERY of the CONTENT. This scheme allows for an easier introduction of additional redirection levels as the NS scheme described in Section 3.5.2. Green, et. al. Expires April 20, 2001 [Page 15] Internet-Draft CDNP Architecture October 2000 3.5.4 Hybrid DNS & Content Aware Redirection Models These examples describes hybrid DNS/Content-Aware direction models: server-side and client-side direction models. 3.5.4.1 Server-side direction model In the server-side direction model, DNS is used in the initial SURROGATE selection process by the CDN DIRECTION SYSTEM while Content-Aware redirection is employed to further direct the CLIENT REQUEST to a better SURROGATE based upon the content requested in the CLIENT REQUEST itself. Since there is more semantic information contained within the CLIENT REQUEST than was present in the DNS lookup, it is possible to more finely target the direction to a suitable SURROGATE. We assume the same R1 and R2 relationship that was present in the previous modified DNS DIRECTION MODEL. We also assume the same process that caused R1 to determine R2 needs to perform the INTRA-CDN direction. However, in this case, R2 does not perform the request routing computation, but rather selects a virtual SURROGATE that is in fact a Content-Aware redirection network element. R2 returns the result of the virtual SURROGATE to R1 which in turns passes it on to the CLIENT. 3.5.4.2 Client-side direction model In the client-side direction model, a content-aware network element is in the path between the client and the CDN DIRECTION SYSTEM and performs CDN selection based on the content requested in the CLIENT REQUEST. In this case, the client is within R1's administration and R2 exchanges peering information with R1 that includes URI level information that enables R1 to proxy or redirect content requests towards R2. In both cases, the CLIENT connects to the virtual SURROGATE and sends the CLIENT REQUEST. The virtual SURROGATE performs a Content-Aware request routing computation and may either send an application level redirects such as an HTTP [8] or RTSP [6] 302 reply to the CLIENT; or proxy the CLIENT REQUEST to a remote DELIVERY NODE. At this point, the CLIENT has the correct DELIVERY NODE for the CONTENT. While the examples above provide a summary of conformant request direction systems, they are just that, a summary. Consult [15] for in-depth information on these request direction systems. Green, et. al. Expires April 20, 2001 [Page 16] Internet-Draft CDNP Architecture October 2000 4. Distribution Peering System The DISTRIBUTION PEERING system represents the content distribution function of the CDN peering system. It is responsible for moving content from one DISTRIBUTION CPG to another DISTRIBUTION CPG and for supplying content location information to the DIRECTION PEERING system. 4.1 Distribution Overview One goal of the CDN peering system is to move content closer to the client. Typically this is accomplished by replicating content from ORIGIN servers to SURROGATEs which are then used to deliver the content directly to the CLIENT. For example this content replication path may traverse links internal to a content provider's network, then external links to reach the CDN and then links internal to the CDN's network to finally arrive at the surrogate. For the purposes of the CDN peering system we consider only the path between the two networks. In the above example the last server on the content provider's network in the path, and the first server on the CDN's network in the path, must contain DISTRIBUTION CPGs which communicate directly with each other. The DISTRIBUTION CPGs could be located in the ORIGIN server and the SURROGATE server. Thus in the simplest form the ORIGIN server is in direct contact with the SURROGATE. However the DISTRIBUTION CPG in the content provider's network could aggregate content from multiple ORIGIN servers and the DISTRIBUTION CPG in the CDN's network could represent multiple SURROGATEs. These DISTRIBUTION CPGs could then be co-located in an exchange facility. Figure 3 contains a architecture diagram of the entities involved in the DISTRIBUTION PEERING system. Green, et. al. Expires April 20, 2001 [Page 17] Internet-Draft CDNP Architecture October 2000 .................................. .................. . Peering CDN . . Peering CDN . +-------+ . +----------+ +------------+ . . +------------+ . +------+ |CLIENT |---|SURROGATE |----|DISTRIBUTION|------|DISTRIBUTION|---|ORIGIN| +-------+ . +----------+ /--| CPG | . /--| CPG | . +------+ . | +------------+ . |. +------------+ . +-------+ . +----------+ | . |.................. |CLIENTs|---|SURROGATEs|-/ . | +-------+ . +----------+ . | . . | .................................. | | .................................. | . Peering CDN . | +-------+ . +----------+ +------------+ . | |CLIENT |---|SURROGATE |----|DISTRIBUTION|---/ +-------+ . +----------+ /--| CPG | . . | +------------+ . +-------+ . +----------+ | . |CLIENTs|---|SURROGATEs|-/ . +-------+ . +----------+ . . . .................................. Figure 3 DISTRIBUTION PEERING system Architecture 4.2 Distribution Models Replication advertisement may take place in a layer 5 model similar to the way BGP is used today at layer 3. DISTRIBUTION CPGs could take care of exterior content replication between content providers and CDNs, while at the same time performing content replication interior to their networks in an independent manner. If this model is used then the internal structure of the networks is hidden and the only knowledge of other networks is the locations of DISTRIBUTION CPGs. Replication of content may take place using a push model, or a pull model, or a combination of both. Hierarchical caching, where SURROGATEs, upon getting a cache miss, retrieve CONTENT from a cache higher up the chain, represents the pull model. Replication of CONTENT from ORIGIN servers to replica origin servers represents the push model. Replication of CONTENT from ORIGIN servers to SURROGATEs, in order to pre-populate the caches, also represents the push model. A combination of the two models would be a cache hierarchy that has a replica origin server as its root. DISTRIBUTION CPGs may be located at various points in these models depending on the topologies of the networks involved. Green, et. al. Expires April 20, 2001 [Page 18] Internet-Draft CDNP Architecture October 2000 With CDN peering it may be necessary to replicate content through a network, which has no internal SURROGATEs. On one hand it may be possible to do this transparently with no DISTRIBUTION CPGs on the transit network. On the other hand it may be desirable for the transit network to have DISTRIBUTION CPGs. For example add a transit network between the content provider network and the CDN network to the example above. The transit network could have a DISTRIBUTION CPG co-located with the content provider's DISTRIBUTION CPG which acts as a proxy for the CDN. The transit network could also have a DISTRIBUTION CPG co-located with the CDN's DISTRIBUTION CPG which acts as a proxy for the content provider. In a simpler example the transit network could have a single DISTRIBUTION CPG which acts as a proxy for both the content provider and the CDN. Replication of CONTINUOUS MEDIA takes place in a different model from content which has a fixed length CONTENT DATA UNIT, especially in the case of live streaming data. Replication in this case typically takes the form of splitting the live streaming data at various points in the network. In the CDN peering system DISTRIBUTION CPGs could perform this function. In this sense the collection of DISTRIBUTION CPGs would constitute an application layer multicast overlay network. 4.3 Distribution Components The three main components of distribution are replication, signaling and advertising. Each of these is utilized between DISTRIBUTION CPGs belonging to content providers and CDNs. They may also be used between CDNs. The final goal of replication involves moving the content from an ORIGIN server to SURROGATE delivery servers. The immediate goal in CDN peering is moving the content between DISTRIBUTION CPGs. The second component of content distribution is content signaling. Content signaling is the propagation of content meta-data. This meta-data may include such information such as the immediate expiration of content or a change in the expiration time of a given CONTENT DATA UNIT. The third component of content distribution is content advertising. Content providers must be able to advertise content that can be distributed by CDNs and its associated terms. It is important that the advertising of content must be able to aggregate content information. Green, et. al. Expires April 20, 2001 [Page 19] Internet-Draft CDNP Architecture October 2000 4.4 Distribution Problems to Solve Some of the problems in distribution revolve around supporting both a push model and a pull model for replication of content in that they are not symmetric. The push model is used for pre-loading of content and the pull model is used for on-demand fetching and pre-fetching of content. These models are not symmetric in that the amount of available resources in which to place the content on the target server must be known. In the fetching cases the server that pulls the content knows the available resources on the target server, itself. In the pre-loading case the server that pushes the content must find out the available resources from the target server before pushing the data. 4.4.1 Replication Problems Specific problems in replication needing further investigation include: 1. How do replication systems direct a request? 2. How are policies communicated between the replication systems? 3. What are the replication protocols? 4. Does replication only take place between CPGs? 4.4.2 Signaling Problems Specific problems in content signaling needing further investigation include: 1. How do we represent a content signal? 2. What protocols should be used for content signals? 3. What is a scalable manner for delivering content signals? 4. Do content signals need a virtual distribution system of their own? 4.4.3 Advertising Problems Specific problems in content advertisement needing further investigation include: 1. How do we represent a collection of meta-data in a concise and compressed manner? Green, et. al. Expires April 20, 2001 [Page 20] Internet-Draft CDNP Architecture October 2000 2. How do we represent aggregates of meta-data? 3. What protocols to use for the aggregation of this data? 4. How distributed of an approach should be used for this problem? 5. How do we prevent looping? 4.5 Distribution Requirements Replication systems must have a peering relationship. This peering relationship must exchange sets of aggregated content and its meta-data. Meta-data may change over time independently of the content data and must be exchanged independently as well. Replication systems may require some coupling to redirection systems. It is possible that when fetching content as opposed to pushing content that sessions between replication peering systems may be directed by the redirection system. 4.5.1 Replication Requirements The specific requirements in content replication are: 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. Security mechanisms. 5. Scalable distribution of the content. 4.5.2 Signaling Requirements The specific requirements in content signaling are: 1. Minimum support for a "flush" and an "expiration time update" signal. 2. Security mechanisms. 3. Scalable distribution of the signals on a large scale. Green, et. al. Expires April 20, 2001 [Page 21] Internet-Draft CDNP Architecture October 2000 4.5.3 Advertising Requirements The specific requirements in content advertisement are: 1. A common protocol for the advertisement of content. 2. A common format for the actual advertisements in the protocol. 3. A well-known state machine. 4. Use of TCP or SCTP (because soft-state protocols will not scale). 5. Well-known error codes to diagnose protocols between different networks. 6. Capability negotiation. 7. Ability to represent policy. Green, et. al. Expires April 20, 2001 [Page 22] Internet-Draft CDNP Architecture October 2000 5. Accounting Peering System The ACCOUNTING PEERING system represents the accounting data collection function of the CDN peering system. It is responsible for moving accounting data from one ACCOUNTING CPG to another ACCOUNTING CPG. 5.1 Accounting Overview CDN peering must provide the ability for the content provider to collect data from surrogates that are delivering their content directly to clients. ACCOUNTING CPGs retrieve the data from SURROGATEs that collect and store the data locally. This interior data may be collected from the SURROGATEs by ACCOUNTING CPGs using SNMP or FTP, for example. ACCOUNTING CPGs transfer the data to exterior neighboring ACCOUNTING CPGs on request or in an asynchronous manner. This architecture is only concerned with the latter exchange. Accounting data may also be aggregated before it is transferred. Figure 4 contains a architecture diagram of the entities involved in the ACCOUNTING PEERING system. Green, et. al. Expires April 20, 2001 [Page 23] Internet-Draft CDNP Architecture October 2000 ..................................... .................... . Peering CDN . . Peering CDN . . +-----------+ +--------------+ . . +--------------+ . +---------+ . | SURROGATE |----| ACCOUNTING |-------| ACCOUNTING |-----| ORIGIN | . +-----------+ /--| CPG | . ---| CPG |---\ +---------+ . | +--------------+ . / . +--------------+ . | . +-----------+ | . | . . | +---------+ . | SURROGATEs|-/ . | .................... \-| BILLING | . +-----------+ . | | ORG. | . . | +---------+ ..................................... | | ..................................... | . Peering CDN . | . +-----------+ +--------------+ . | . | SURROGATE |----| ACCOUNTING |--/ . +-----------+ /--| CPG | . . | +--------------+ . . +-----------+ | . . | SURROGATEs|-/ . . +-----------+ . . . ..................................... Figure 4 ACCOUNTING PEERING system Architecture In addition information needs to be exchanged between ACCOUNTING CPGs in order for SURROGATEs to be able to provide authentication, authorization, and policy enforcement as specified by the content provider. It is possible that this meta-data could be included with the content replicated by the DISTRIBUTION PEERING system. However these types of data are grouped together in the work of the Authentication, Authorization and Accounting (AAA) working group in the IETF. This work as well as the work of the Authentication Authorization Accounting Architecture (AAAARCH) research group in the IRTF should be examined to determine their applicability to CDN peering accounting. 5.2 Accounting Data Types Accounting data generally falls into the network or system management, policy, and settlement categories, which are gathered to collect information about the use of the content. Network and system management data allows for the monitoring of resources in order to perform load balancing and to observe the conformance to Service Level Agreements (SLAs). Policy information allows for the enforcement of authentication and authorization. Data needed for settlement includes statistics such as proxy hits and misses, Green, et. al. Expires April 20, 2001 [Page 24] Internet-Draft CDNP Architecture October 2000 information from log files, and session detail records for CONTINUOUS MEDIA. 5.3 Accounting Models In one model a third-party BILLING ORGANIZATION must be able to receive the information necessary to bill the appropriate party. In another model this function may be performed by the PUBLISHER or AUTHORITATIVE DIRECTION SYSTEM. Consult [14] for detailed information on CDN peering billing models. Accounting data may be requested by an ACCOUNTING CPG or supplied asynchronously by another ACCOUNTING CPG. Asynchronous data may be subscribed to or sent in an solicited manner. Guidelines should be set on the amount of accounting data traffic which should be allowed in proportion to the content data and how aggregation of accounting data is performed. Some accounting data may be sensitive to time. Four categories of time sensitive management data have been identified. The first is real-time data that consists of events that require immediate action or attention. The second is data that is needed within 5 seconds of generation such as resource loading or diagnostic data. The third is data that is needed in 5-minute intervals such as statistics. The fourth is data that is needed on a 24 hour or less basis such as logs or billing data. 5.4 Accounting Problems to Solve There are several problems with data retrieval that need to be solved. These include latency, overhead, and large data size. The core set of facilities must provide solutions to these and must consist of collection of data on the server, controlled access to the data, and the aggregation and archival of the data on ACCOUNTING CPGs. Specific problems in accounting data exchange needing further investigation include: 1. How do we represent accounting info for a given object? 2. How do we represent accounting for many media types? 3. How do we aggregate this information? 4. How do we signal upload place or type? 5. How do we aggregate this information "hop-by-hop" back to the BILLING ORGANIZATION? Green, et. al. Expires April 20, 2001 [Page 25] Internet-Draft CDNP Architecture October 2000 5.5 Accounting Requirements The complexity of CDN peering requires that a method be created for the exchange of accounting information. This information must be accurately logged, aggregated and ultimately collected at the BILLING entity for each PUBLISHER. The specific requirements for accounting data exchange are: 1. Simple methods for representing accounting information. 2. Simple methods for aggregating this accounting information. 3. Agreed upon protocols for the uploading and distribution of this information. 4. Agreed upon standardized accounting records. Green, et. al. Expires April 20, 2001 [Page 26] Internet-Draft CDNP Architecture October 2000 6. Security Considerations Security concerns with respect to CDN Peering can be generally categorized into trust within the system and protection of the system from threats. The trust model utilized with CDN peering is predicated largely on transitive trust between the ORIGIN, DIRECTION PEERING system, DISTRIBUTION PEERING system, ACCOUNTING PEERING system and SURROGATES. Network elements within the CDN Peering system are considered to be "insiders" and therefore trusted. 6.1 Threats to CDN Peering The following sections document key threats to CLIENTs, PUBLISHERs, and CDNs. The threats are classified according to the party that they most directly harm, but, of course, a threat to any party is ultimately a threat to all. (For example, having a credit card number stolen may most directly affect a CLIENT; however, the resulting dissatisfaction and publicity will almost certainly cause some harm to the PUBLISHER and CDN, even if the harm is only to those organizations' reputations.) 6.1.1 Threats to the CLIENT 6.1.1.1 Defeat of CLIENT's Security Settings Because the SURROGATE's location may differ from that of the ORIGIN, the use of a SURROGATE may inadvertently or maliciously defeat any location-based security settings employed by the CLIENT. And since the SURROGATE's location is generally transparent to the CLIENT, the CLIENT may be unaware that its protections are no longer in force. For example, a CDN may relocate CONTENT from a Internet Explorer user's "Internet Web Content Zone" to that user's "Local Intranet Web Content Zone." If the relocation is visible to the Internet Explorer browser but otherwise invisible to the user, the browser may be employing less stringent security protections than the user is expecting for that CONTENT. (Note that this threat differs, at least in degree, from the substitution of security parameters threat below, as Web Content Zones can control whether or not, for example, the browser executes unsigned active content.) 6.1.1.2 Delivery of Bad Accounting Information In the case of CONTENT with value, CLIENTs may be inappropriately charged for viewing content that they did not successfully access. Conversely, some PUBLISHERs may reward CLIENTs for viewing certain CONTENT (e.g. programs that "pay" users to surf the Web). Should a CDN fail to deliver appropriate accounting information, the CLIENT may not receive appropriate credit for viewing the required CONTENT. Green, et. al. Expires April 20, 2001 [Page 27] Internet-Draft CDNP Architecture October 2000 6.1.1.3 Delivery of Bad CONTENT A CDN that does not deliver the appropriate CONTENT may provide the user misleading information (either maliciously or inadvertently). This threat can be manifested as a failure of either the DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or REDIRECTION SYSTEM (redirection to inappropriate SURROGATEs, even though they may have appropriate CONTENT), or both. A REDIRECTION SYSTEM may also fail by redirecting the CLIENT when no redirection is appropriate, or by failing to redirect the CLIENT when redirection is appropriate. 6.1.1.4 Denial of Service A CDN that does not redirect the CLIENT appropriately may deny the CLIENT access to CONTENT. 6.1.1.5 Exposure of Private Information CDNs may inadvertently or maliciously expose private information (passwords, buying patterns, page views, credit card numbers) as it transits from SURROGATEs to ORIGINs and/or PUBLISHERs. 6.1.1.6 Substitution of Security Parameters If a SURROGATE does not duplicate completely the security facilities of the ORIGIN (e.g. encryption algorithms, key lengths, certificate authorities) CONTENT delivered through the SURROGATE may be less secure than the CLIENT expects. 6.1.1.7 Substitution of Security Policies If a SURROGATE does not employ the same security policies and procedures as the ORIGIN, the CLIENT's private information may be treated with less care than the CLIENT expects. For example, the operator of a SURROGATE may not have as rigorous protection for the CLIENT's password as does the operator of the ORIGIN server. This threat may also manifest itself if the legal jurisdiction of the SURROGATE differs from that of the ORIGIN, should, for example, legal differences between the jurisdictions require or permit different treatment of the CLIENT's private information. 6.1.2 Threats to the PUBLISHER 6.1.2.1 Delivery of Bad Accounting Information If a CDN does not deliver accurate accounting information, the PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it may reward CLIENTs inappropriately. Inaccurate accounting Green, et. al. Expires April 20, 2001 [Page 28] Internet-Draft CDNP Architecture October 2000 information may also cause a PUBLISHER to pay for services (e.g. content distribution) that were not actually rendered.) Invalid accounting information may also effect PUBLISHERs indirectly by, for example, undercounting the number of site visitors (and, thus, reducing the PUBLISHER's advertising revenue). 6.1.2.2 Denial of Service A CDN that does not distribute CONTENT appropriately may deny CLIENTs access to CONTENT. 6.1.2.3 Substitution of Security Parameters If a SURROGATE does not duplicate completely the security services of the ORIGIN (e.g. encryption algorithms, key lengths, certificate authorities, client authentication) CONTENT stored on the SURROGATE may be less secure than the PUBLISHER prefers. 6.1.2.4 Substitution of Security Policies If a SURROGATE does not employ the same security policies and procedures as the ORIGIN, the CONTENT may be treated with less care than the PUBLISHER expects. This threat may also manifest itself if the legal jurisdiction of the SURROGATE differs from that of the ORIGIN, should, for example, legal differences between the jurisdictions require or permit different treatment of the CONTENT. 6.1.3 Threats to a CDN 6.1.3.1 Bad Accounting Information If a CDN is unable to collect or receive accurate accounting information, it may be unable to collect compensation for its services from PUBLISHERs. 6.1.3.2 Denial of Service Misuse of a CDN may make that CDN's facilities unavailable, or available only at reduced functionality, to legitimate customers or the CDN provider itself. Denial of service attacks can be targeted at a CDN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REDIRECTION SYSTEM. 6.1.3.3 Transitive Threats To the extent that a CDN acts as either a CLIENT or a PUBLISHER (such as, for example, in transitive implementations) such a CDN may be exposed to any or all of the threats described above for both roles. Green, et. al. Expires April 20, 2001 [Page 29] Internet-Draft CDNP Architecture October 2000 7. Impact on the Internet Architecture On the face of it, the architectural framework proposed in this paper for adding intermediate DISTRIBUTION systems to Internet infrastructure looks like a major change in the end-to-end model [5] that has been so successful in the Internet. However, in this model, the SURROGATEs are delegated by ORIGIN servers to act in their behalf, and thus are the terminating servers for CLIENTs in the end-to-end model. Conceptually, there are multiple end-to-end relationships introduced by peering CDNs, each being linked together by intermediary DIRECTION SYSTEMs, DISTRIBUTION SYSTEMs, and ACCOUNTING SYSTEMs, duly authorized by the parties involved to provide intermediate services. This model has precedence in the Internet, with the Domain Name Service [3] being a classic example. The value of the end to end model is that the network is simple and transparent [9], so it is easy to add services, and easy to diagnose problems when they occur. With the end to end model, there are only two active entities that count, the CLIENT and the ORIGIN (or requesting peer and replying peer in peer-to-peer services). As previously stated, the end to end model is still in effect for the client and server relationship, thus, preserving transparency in the rendering of services by DIRECTION SYSTEMs and SURROGATEs to CLIENTs. Green, et. al. Expires April 20, 2001 [Page 30] Internet-Draft CDNP Architecture October 2000 8. Acknowledgements The authors would like to acknowledge the contributions and comments of Mark Day (Cisco), Fred Douglis (AT&T), Don Gilletti (Entera), John Martin (Network Appliance), Raj Nair (Cisco), Doug Potter (Cisco), John Scharber (Entera), Oliver Spatscheck (AT&T) and Stephen Thomas (TransNexus). Green, et. al. Expires April 20, 2001 [Page 31] Internet-Draft CDNP Architecture October 2000 References [1] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, March 1996, . [2] Hares, S. and D. Katz, "Administrative Domains and Routing Domains A Model for Routing in the Internet", RFC 1136, December 1989, . [3] Postel, J., "Domain Name Structure and Delegation", RFC 1591, March 1994, . [4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995, . [5] Carpenter, B., "Architecture Principles of the Internet", RFC 1958, June 1996, . [6] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol", RFC 2326, April 1998, . [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998, . [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, . [9] Carpenter, B., "Internet Transparency", RFC 2775, February 2000, . [10] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", draft-ietf-wrec-taxonomy-04.txt (work in progress), June 2000, . [11] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, Green, et. al. Expires April 20, 2001 [Page 32] Internet-Draft CDNP Architecture October 2000 G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", draft-ietf-aaa-authz-arch-00.txt (work in progress), October 1999, . [12] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering", draft-day-cdnp-model-02.txt (work in progress), October 2000, . [13] Day, M. and D. Gilletti, "Content Distribution Network Peering Scenarios", draft-day-cdnp-scenarios-01.txt (work in progress), October 2000, . [14] Gilletti, D., Nair, R. and J. Scharber, "Accounting Models for CDN Peering", draft-gilletti-cdnp-accounting-models-02.txt (work in progress), October 2000, . [15] Douglis, F., Nair, R., Spatscheck, O. and M. Green, "Known CDN Redirection Mechanisms", draft-douglis-cdnp-rdir-known-mechs-00.txt, not yet published (work in progress), October 2000. [16] G. & C. Merriam Co., "Webster's New Collegiate Dictionary", 1977. [17] CUKIER, K., "Peering and Fearing: ISP Interconnection and Regulatory Issues", March 1998, . Authors' Addresses Mark Green Entera, Inc. 40971 Encyclopedia Circle Fremont, CA 94538 US Phone: +1 510 770 5268 EMail: markg@entera.com Green, et. al. Expires April 20, 2001 [Page 33] Internet-Draft CDNP Architecture October 2000 Brad Cain Mirror Image Internet 49 Dragon Court Woburn, MA 01801 US Phone: +1 781 276 1904 EMail: brad.cain@mirror-image.com Gary Tomlinson Entera, Inc. 40971 Encyclopedia Circle Fremont, CA 94538 US Phone: +1 510 580 3726 EMail: garyt@entera.com Green, et. al. Expires April 20, 2001 [Page 34] Internet-Draft CDNP Architecture October 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Green, et. al. Expires April 20, 2001 [Page 35]