Network Working Group M. Day Internet-Draft Cisco Expires: May 18, 2001 B. Cain Mirror Image Internet G. Tomlinson Entera November 17, 2000 A Model for CDN Peering draft-day-cdnp-model-04.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 18, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract There is wide interest in the technology for interconnecting content distribution networks (CDNs), variously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces CDNs and CDN peering, and proposes elements for such a common vocabulary. Notes on Mailing List and Content Alliance Day, et. al. Expires May 18, 2001 [Page 1] Internet-Draft CDNPM November 2000 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.* This document is an interim product of work initiated by the Content Alliance. For more information about the Content Alliance, please see http://www.content-peering.org. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. CDNs and Other Content Architectures . . . . . . . . . . . . . 4 2.1 Problem Description . . . . . . . . . . . . . . . . . . . . . 4 2.2 Introduction to CDNs . . . . . . . . . . . . . . . . . . . . . 5 2.3 Extending Reach & Scale . . . . . . . . . . . . . . . . . . . 6 3. CDN Model Terms . . . . . . . . . . . . . . . . . . . . . . . 8 4. CDN Examples and Commentary . . . . . . . . . . . . . . . . . 11 4.1 Understanding CDNs . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Understanding content structure . . . . . . . . . . . . . . . 11 5. Peering Model Terms . . . . . . . . . . . . . . . . . . . . . 12 6. Peering Examples and Commentary . . . . . . . . . . . . . . . 14 6.1 Understanding Peering . . . . . . . . . . . . . . . . . . . . 14 6.2 Content Signalling . . . . . . . . . . . . . . . . . . . . . . 14 7. Operational Considerations . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 Day, et. al. Expires May 18, 2001 [Page 2] Internet-Draft CDNPM November 2000 1. Introduction Content distribution networks, or CDNs, are of increasing importance to the overall architecture of the Web. This document presents a vocabulary for use in developing technology for interconnecting CDNs. By analogy with peering of IP networks, this interconnection is sometimes called "content peering," or (somewhat more accurately) "peering of CDNs". Section 2 describes content distribution, CDNs, and the motivation for peering of CDNs in some more detail. Section 3 introduces the terms used for elements of a CDN and explains how those terms are used. Section 5 deals with CDN peering, introducing the terms and explaining how those terms are used. The remainder of the document notes various operational and security considerations that are relevant to CDN peering. The terminology in this document builds from the previous taxonomy of web caching and replication [2]. In particular, we have attempted to avoid the use of the common terms "proxies" or "caches" in favor of the better-defined terms "caching proxy," "reverse caching proxy," and "server accelerator." The sections defining terms are organized alphabetically, which is appropriate for reference but which makes them difficult to read the first time. Rather than reading the document from beginning to end, the authors recommend that the first-time reader skip past the sections defining terms to the following sections with examples, referring back to the definitions as necessary. The interested reader is also referred to "Content Distribution Network Peering Scenarios" [3], which enumerates scenarios for content-peering-related interactions; "CDN Peering Authentication, Authorization, and Accounting Requirements" [4], which describes requirements for accounting and associated issues; "CDN Peering Architectural Overview" [5], which gives an overall architecture of the elements for CDN peering; and "Known CDN Request-Routing Mechanisms" [6], which summarizes known mechanisms for request-routing. Day, et. al. Expires May 18, 2001 [Page 3] Internet-Draft CDNPM November 2000 2. CDNs and Other Content Architectures A CDN (content distribution network or content delivery network) is an architecture of Web-based network elements, arranged for efficient delivery of digital content. The first important use of CDNs was for the distribution of heavily-requested graphic files (such as GIF files on the home pages of popular servers). However, both in principle and increasingly in practice, a CDN can support the delivery of any digital content -- including various forms of streaming media. A number of CDN services have been built and offered commercially. In addition, a number of hardware and software vendors have developed products that enable the construction of a CDN with "off-the-shelf" parts. The proliferation of CDNs and CDN capabilities gives rise to interest in interconnecting CDNs and finding ways for distinct CDNs to cooperate for better overall service. In this section we describe the problem of content distribution, the use of server farms and server accelerators to improve the performance of content distribution, the contrast between CDNs and those solutions, and what makes a CDN valuable. 2.1 Problem Description Abstractly, the "content distribution problem" is to arrange a rendezvous between a content source at an origin server and a content sink at a viewer's client. In the trivial case, the rendezvous mechanism is that every client sends every request directly to the origin server named in the host part of the URL identifying the content. As the audience for the content source grows, so do the demands on the origin server. There are a variety of ways in which the trivial system can be modified for better performance. The single logical server may in fact be a large "farm" of server machines behind a switch. Both caching proxies and reverse caching proxies can be deployed between the client and server, so that requests can be satisfied by some cache instead of by the server. All of these techniques are useful, but have limits. Server farms and server accelerators can improve the scalability of the origin server. However, since the multiple servers and server accelerators are typically deployed near the origin server, they do little to improve performance problems that are due to congestion. Caching proxies can improve performance problems due to congestion (since they are situated near the clients) but they cache objects based on client demand -- so they may not help the distribution load of a Day, et. al. Expires May 18, 2001 [Page 4] Internet-Draft CDNPM November 2000 given origin server. Thus, a content provider with a popular content source can find that it has to invest in large server farms, load balancing, and high-bandwidth connections to keep up with demand. Even with those investments, the user experience for viewers may still be relatively poor due to congestion in the network as a whole. 2.2 Introduction to CDNs A CDN essentially combines the cache-management approach of reverse caching proxies with the network placement of (forward) caching proxies. A CDN has multiple replicas of each content item being hosted. A request from a browser for a single content item is directed to a "good" replica, where "good" usually means that the item is served to the client quickly compared to the time it would take fetch it from the origin server, with appropriate integrity and consistency. Static information about geographic locations and network connectivity is usually not sufficient to do a good job of choosing a replica. Instead, a CDN typically incorporates dynamic information about network conditions and load on the replicas, directing requests so as to balance the load. Compared to using servers and caches in a single data center, a CDN is a relatively complex system encompassing multiple points of presence, in locations that may be geographically far apart. Operating a CDN is not easy for a content provider, since a content provider wants to focus its resources on developing high-value content, not on managing network infrastructure. Instead, a more typical configuration is that a network service provider builds and operates a CDN, offering a content distribution service to a number of content providers. A CDN enables a service provider to act on behalf of the content provider to deliver copies of origin server content from multiple diverse locations. The increase in number and diversity of locations is intended to improve download times and thus improve the user experience. A CDN has some combination of a request-routing infrastructure, a content-delivery infrastructure, and a distribution infrastructure. The content-delivery infrastructure consists of a set of "surrogate" servers [2] that deliver copies of content to sets of users. The request-routing infrastructure consists of mechanisms that move a client toward a rendezvous with a surrogate. The distribution infrastructure consists of mechanisms that move content from the origin server to the surrogates. An effective CDN serves frequently-accessed content from a surrogate that is "best suited" for a given client. Day, et. al. Expires May 18, 2001 [Page 5] Internet-Draft CDNPM November 2000 2.3 Extending Reach & Scale There are two fundamental elements that give a CDN value: outsourcing infrastructure and improved content delivery. A CDN allows multiple surrogates to act on behalf of an orgin server, therefore removing the delivery of content from a centralized site to multiple and (usually) highly distributed sites. We refer to increased aggregate infrastructure size as "scale." In addition, a CDN can be constructed with copies of content near to end users, overcoming issues of network size, network congestion, and network failures. We refer to increased diversity of content locations as "reach." In a typical (non-peered) CDN, a single service provider operates the request-routers, the surrogates, and the content distributors. In addition, that service provider establishes (business) relationships with content publishers and acts on behalf of their origin sites to provide a distributed delivery system. The value of that CDN to a content provider is a combination of its scale and its reach. There are limits to how large any one network's scale and reach can be. 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. Other times, a network provider may be able to manage surrogates and a distribution system, but may have no direct relationship with content providers. Such a provider wants to have a means of affiliating their delivery and distribution infrastructure with other parties who have content to distribute. CDN peering allows different CDNs to share resources so as to provide larger scale and/or reach to each participant than they could otherwise achieve. As used in this document, "peering" is interconnection among two or more separately-administered content networks. There are several other potential meanings for "peering" that are not intended. For example, interconnection of similar-sized networks could be seen as interconnecting "peers." This document does not mean to imply a requirement that the interconnected networks be similar in size or capability. For example, a publisher might choose to have just enough of a CDN so that they could make use of several other "industrial strength" CDNs, without any intent of building a global distribution network themselves. Another example is the distinction between "peering" and "transit," where the former means a settlement-free economic relationship and the latter means that one Day, et. al. Expires May 18, 2001 [Page 6] Internet-Draft CDNPM November 2000 network is paying the other. This document does not mean to imply a requirement for any particular economic or business relationship among the interconnected networks. Day, et. al. Expires May 18, 2001 [Page 7] Internet-Draft CDNPM November 2000 3. CDN Model Terms This section consists of the definitions of a number of terms used to refer to roles, participants, and objects involved in CDNs. ACCOUNTING Measurement and recording of DISTRIBUTION and DELIVERY activities, especially when the information recorded is ultimately used as a basis for the subsequent transfer of money, goods, or obligations. ACCOUNTING SYSTEM A collection of NETWORK ELEMENTS that supports ACCOUNTING for a single CDN. AUTHORITATIVE REQUEST-ROUTING SYSTEM The REQUEST-ROUTING SYSTEM that is the correct/final authority for a particular item of CONTENT. CDN Content Delivery Network or Content Distribution Network. A collection of NETWORK ELEMENTS arranged for more effective delivery of CONTENT to CLIENTS. Typically a CDN consists of a REQUEST-ROUTING SYSTEM, SURROGATES, a DISTRIBUTION SYSTEM, and an ACCOUNTING SYSTEM. [Editor note: we need to clarify what is the "minimum" CDN. One possibility is that a collection of SURROGATES is the minimum. Another possibility is that SURROGATES and a REQUEST-ROUTING SYSTEM is the minimum.] CLIENT The origin of a REQUEST and the destination of the corresponding delivered CONTENT. CONTENT Digital data resources. [Editor note: discussion is currently active about correct alignment between resource/entity/variant model of HTTP and "content".] One important form of CONTENT with additional constraints on DISTRIBUTION and DELIVERY is CONTINUOUS MEDIA. CONTENT SIGNAL A message delivered through a DISTRIBUTION SYSTEM that specifies information about an item of CONTENT. For example, a CONTENT SIGNAL can indicate that the ORIGIN has a new version of some piece of CONTENT. CONTINUOUS MEDIA CONTENT where there is a timing relationship between source and sink; that is, the sink must reproduce the timing relationship Day, et. al. Expires May 18, 2001 [Page 8] Internet-Draft CDNPM November 2000 that existed at the source. The most common examples of CONTINUOUS MEDIA are audio and motion video. CONTINUOUS MEDIA can be real-time (interactive), where there is a "tight" timing relationship between source and sink, or streaming (playback), where the relationship is less strict. DELIVERY The activity of presenting a PUBLISHER's CONTENT for consumption by a CLIENT. Contrast with DISTRIBUTION and REQUEST-ROUTING. DISTRIBUTION The activity of moving a PUBLISHER's CONTENT from its ORIGIN to one or more SURROGATEs. DISTRIBUTION can happen either in anticipation of a SURROGATE receiving a REQUEST (pre-positioning) or in response to a SURROGATE receiving a REQUEST (fetching on demand). Contrast with DELIVERY and REQUEST-ROUTING. DISTRIBUTION SYSTEM A collection of NETWORK ELEMENTS that support DISTRIBUTION for a single CDN. The DISTRIBUTION SYSTEM also propagates CONTENT SIGNALs. MAPPING See REQUEST-ROUTING. Some earlier versions of this document and others used the term MAPPING, but REQUEST-ROUTING is now preferred. NETWORK ELEMENT A device or system that affects the processing of network messages. ORIGIN The point at which CONTENT first enters a DISTRIBUTION SYSTEM. The ORIGIN for any item of CONTENT is the server or set of servers at the "core" of the distribution, holding the "master" or "authoritative" copy of that CONTENT. PUBLISHER The party that ultimately controls the content and its distribution. REACHABLE SURROGATES The collection of SURROGATES that can be contacted via a particular DISTRIBUTION SYSTEM or REQUEST-ROUTING SYSTEM. REQUEST A message identifying a particular item of CONTENT to be delivered. [Editor Note: Brad Cain recommends distinguishing REQUEST-ROUTING REQUEST from CONTENT REQUEST. Does this make the Day, et. al. Expires May 18, 2001 [Page 9] Internet-Draft CDNPM November 2000 model too closely tied to DNS-style request-routing? To be discussed.] REQUEST-ROUTING The activity of steering or directing a REQUEST from a CLIENT to a suitable SURROGATE. REQUEST-ROUTING SYSTEM A collection of NETWORK ELEMENTS that support REQUEST-ROUTING for a single CDN. SURROGATE A delivery server, other than the ORIGIN. Receives a mapped REQUEST and delivers the corresponding CONTENT. Note: This definition has a narrower semantic context than the more generally used term defined in [2]. Day, et. al. Expires May 18, 2001 [Page 10] Internet-Draft CDNPM November 2000 4. CDN Examples and Commentary This section uses the terms of the previous to explain concepts of CDNs and content. 4.1 Understanding CDNs With the elements defined so far, we can outline the operation of a "typical" CDN at a high level. The CLIENT's REQUEST enters a REQUEST-ROUTING SYSTEM, and the ORIGIN's CONTENT enters a DISTRIBUTION SYSTEM. Note that the relative timing of these events is unspecified. Both systems (REQUEST-ROUTING and DISTRIBUTION) converge on SURROGATES, which are non-ORIGIN servers of CONTENT. Effectively, the DISTRIBUTION SYSTEM is moving CONTENT out to SURROGATES, and the REQUEST-ROUTING SYSTEM is then taking advantage of that distribution of CONTENT. [Editor Note: Could change this description to deal with REQUEST-ROUTING REQUESTS and CONTENT REQUESTS.] 4.2 Understanding content structure The model defines CONTENT as well as a subsidiary concept: CONTINUOUS MEDIA. Any identifiable resource of digital data is an item of CONTENT. So CONTENT is the most generic description of what is transported and served up by a CDN. In many cases, an item of CONTENT can be delivered by a CDN without concern about maintaining timing relationships. However, there are some forms of CONTENT where it is critical that some timing relationships be met. The model refers to those forms of CONTENT as CONTINUOUS MEDIA. Day, et. al. Expires May 18, 2001 [Page 11] Internet-Draft CDNPM November 2000 5. Peering Model Terms This section consists of the definitions of a number of terms used to refer to roles, participants, and objects involved in peering CDNs. ACCOUNTING ADVERTISEMENT ADVERTISEMENT from a CDN's ACCOUNTING PEERING SYSTEM about the collections of CONTENT for which that CDN requires ACCOUNTING information. ACCOUNTING PEERING Interconnection of two or more ACCOUNTING SYSTEMS so as to enable the exchange of information between them. The form of ACCOUNTING PEERING required may depend on the nature of the NEGOTIATED RELATIONSHIP between the peering parties -- in particular, on the value of the economic exchanges anticipated. ACCOUNTING PEERING SYSTEM See PEERING SYSTEM. ADVERTISEMENT Information about available resources, exchanged among PEERING SYSTEMS. Types of ADVERTISEMENT include REQUEST-ROUTING ADVERTISEMENTS, DISTRIBUTION ADVERTISEMENTS and ACCOUNTING ADVERTISEMENTS. BILLING ORGANIZATION An entity that operates an ACCOUNTING SYSTEM to support billing within a NEGOTIATED RELATIONSHIP with a PUBLISHER. CONTENT PEERING GATEWAY (CPG) A point through which a CDN can be peered with others through one or more kinds of peering. A CPG may be the point of contact for DISTRIBUTION PEERING, REQUEST-ROUTING PEERING, and/or ACCOUNTING PEERING, and thus may incorporate some or all of the corresponding PEERING SYSTEMs for the CDN. DISTRIBUTING CDN A CDN that does not have a NEGOTIATED RELATIONSHIP with the PUBLISHER for the CONTENT being delivered. DISTRIBUTION ADVERTISEMENT An ADVERTISEMENT from a CDN's DISTRIBUTION PEERING SYSTEM describing the availability of collections of CONTENT via the CDN's DISTRIBUTION SYSTEM. DISTRIBUTION PEERING Interconnection of two or more DISTRIBUTION SYSTEMS so as to Day, et. al. Expires May 18, 2001 [Page 12] Internet-Draft CDNPM November 2000 propagate CONTENT SIGNALS and copies of CONTENT to groups of SURROGATES. DISTRIBUTION PEERING SYSTEM See PEERING SYSTEM. INTER-CDN Related to an activity that involves more than one CDN. Contrast with INTRA-CDN. INTRA-CDN Related to an activity within a single CDN. Contrast with INTER-CDN. NEGOTIATED RELATIONSHIP A relationship whose terms and conditions are partially or completely established outside the context of CDN peering protocols. PEERING SYSTEM A collection of NETWORK ELEMENTS supporting some form of interconnected operation among two or more CDNs. Examples (not separately defined): ACCOUNTING PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM, REQUEST-ROUTING PEERING SYSTEM. REMOTE CDN A CDN able to deliver CONTENT for a particular REQUEST that is not the AUTHORITATIVE REQUEST-ROUTING SYSTEM for that REQUEST. REQUEST-ROUTING ADVERTISEMENT An ADVERTISEMENT from a CDN's REQUEST-ROUTING PEERING SYSTEM describing the availability of collections of CONTENT via that CDN's REQUEST-ROUTING SYSTEM. REQUEST-ROUTING PEERING Interconnection of two or more REQUEST-ROUTING SYSTEMS so as to increase the number of REACHABLE SURROGATES for at least one of the interconnected systems. REQUEST-ROUTING PEERING SYSTEM See PEERING SYSTEM. Day, et. al. Expires May 18, 2001 [Page 13] Internet-Draft CDNPM November 2000 6. Peering Examples and Commentary This section uses the terms of the previous to explain concepts of CDN peering. 6.1 Understanding Peering The model offers a number of ways in which different CDNs can be interconnected. An arrangement of interconnected REQUEST-ROUTING SYSTEMS is called REQUEST-ROUTING PEERING. Analogously, interconnected DISTRIBUTION SYSTEMS give rise to DISTRIBUTION PEERING, and interconnected ACCOUNTING SYSTEMS give rise to ACCOUNTING PEERING. The communicating elements on each side are referred to as PEERING SYSTEMS. So when two or more DISTRIBUTION SYSTEMS may be interconnected by PEERING, it is actually the DISTRIBUTION PEERING SYSTEMS that are communicating with each other to accomplish the exchange of information required. A CONTENT PEERING GATEWAY (CPG) is a generic term used in the model for one or more PEERING SYSTEMS when it is not important to distinguish the PEERING SYSTEM or form of PEERING involved. CPGs exchange ADVERTISEMENTS. There are three main kinds of ADVERTISEMENT: ACCOUNTING ADVERTISEMENTS, REQUEST-ROUTING ADVERTISEMENTS, and DISTRIBUTION ADVERTISEMENTS. An ACCOUNTING ADVERTISEMENT describes a collection of URLs for which a given ACCOUNTING SYSTEM wants to receive accounting information when the content is delivered. [Editor note: is accounting information potentially collected for REQUEST-ROUTING or DISTRIBUTION as well?] A REQUEST-ROUTING ADVERTISEMENT describes a collection of URLs whose content can be delivered by REQUEST-ROUTING through the corresponding CDN. A DISTRIBUTION ADVERTISEMENT describes the service level(s) available from a CDN's SURROGATES (as a whole) to some collection of CLIENT addresses. 6.2 Content Signalling CDNs operate on behalf of PUBLISHERs and ORIGINs and therefore must provide accurate, up-to-date copies of CONTENT. A CDN DISTRIBUTION SYSTEM may deliver CONTENT SIGNALS to relevant SURROGATES when appropriate. In the presence of peered distribution where the peered systems support such signals, CONTENT SIGNALS must be propagated to each SURROGATE with a copy of the relevant CONTENT. Day, et. al. Expires May 18, 2001 [Page 14] Internet-Draft CDNPM November 2000 7. Operational Considerations [Editor's Note: Consider problem of incorrect advertisements of content or service levels. Need to ensure that there are means within the protocol or recommended practices so that CDNs aren't encouraged to pull traffic they can't really handle.] Day, et. al. Expires May 18, 2001 [Page 15] Internet-Draft CDNPM November 2000 8. Security Considerations CDN peering raises some security-related issues, and a detailed discussion of those issues appears in the "CDN Peering Architectural Overview" [5]. Day, et. al. Expires May 18, 2001 [Page 16] Internet-Draft CDNPM November 2000 9. Acknowledgements The definition of CONTINUOUS MEDIA is adapted from RFC 2326. The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Don Gilletti (Entera), Markus Hoffmann (Lucent), Barron Housel (Cisco), Barbara Liskov (Cisco), John Martin (Network Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter (Cisco), and Oliver Spatscheck (AT&T). Day, et. al. Expires May 18, 2001 [Page 17] Internet-Draft CDNPM November 2000 References [1] 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, . [2] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", draft-ietf-wrec-taxonomy-05.txt (work in progress), June 2000, . [3] Day, M. and D. Gilletti, "CDN Peering Scenarios", draft-day-cdnp-scenarios-02.txt (work in progress), Novmber 2000, . [4] Gilletti, D., Nair, R. and J. Scharber, "CDN Peering Authentication, Authorization, and Accounting Requirements", draft-gilletti-cdnp-aaa-reqs-00.txt (work in progress), November 2000, . [5] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CDN Peering Architectural Overview", draft-green-cdnp-gen-arch-02.txt (work in progress), November 2000, . [6] Cain, B., Douglis, F., Green, M., Hoffmann, M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request-Routing Mechanisms", draft-green-cdnp-gen-arch-02.txt (work in progress), November 2000, . Day, et. al. Expires May 18, 2001 [Page 18] Internet-Draft CDNPM November 2000 Authors' Addresses Mark S. Day Cisco Systems 135 Beaver Street Waltham, MA 02452 US Phone: +1 781 663 8310 EMail: markday@cisco.com 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 Day, et. al. Expires May 18, 2001 [Page 19] Internet-Draft CDNPM November 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. Day, et. al. Expires May 18, 2001 [Page 20]