[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New draft: draft-day-cdnp-model-05.txt



Please publish the following attached file as an Internet Draft:

Title: A Model for Content Internetworking
Filename: draft-day-cdnp-model-05.txt

Thanks.



Network Working Group                                             M. Day
Internet-Draft                                                     Cisco
Expires: September 2, 2001                                       B. Cain
                                                                  Cereva
                                                            G. Tomlinson
                                                               CacheFlow
                                                              P. Rzewski
                                                                 Inktomi
                                                           March 2, 2001

                    A Model for Content Internetworking
                        draft-day-cdnp-model-05.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 September 2, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   There is wide interest in the technology for interconnecting Content
   Networks, variously called "Content Peering" or "Content
   Internetworking".  A common vocabulary helps the process of
   discussing such interconnection and interoperation.  This document
   introduces Content Networks and Content Internetworking, and
   proposes elements for such a common vocabulary.





Day, et. al.          Expires September 2, 2001              [Page 1]
Internet-Draft                CDI Model                    March 2001


Table of Contents

   1.    Introduction................................................ 3
   2.    Content Networks............................................ 3
   2.1   Problem Description......................................... 4
   2.2   Forward Proxy Caching....................................... 5
   2.3   Server Farms................................................ 6
   2.4   Content Distribution Networks............................... 7
   2.4.1 Historic Evolution of CDNs.................................. 9
   2.4.2 Describing CDN Value: Reach and Scale....................... 9
   3.    Content Network Model Terms.................................10
   4.    Content Network Examples and Commentary.....................12
   4.1   Understanding CDNs..........................................12
   4.2   Understanding content structure.............................12
   5.    Content Internetworking.....................................13
   6.    Content Internetworking Model Terms.........................13
   7.    Content Internetworking Examples and Commentary.............15
   7.1   Understanding Content Internetworking.......................15
   7.2   Content Signaling...........................................16
   8.    Operational Considerations..................................16
   9.    Security Considerations.....................................16
   10.   Acknowledgements............................................16
         References..................................................16
         Authors' Addresses..........................................17
         Full Copyright Statement....................................18



























Day, et. al.          Expires September 2, 2001              [Page 2]
Internet-Draft                CDI Model                    March 2001


1. Introduction

   Content Networks, such as CDNs, are of increasing importance to the
   overall architecture of the Web.  This document presents a
   vocabulary for use in developing technology for interconnecting
   Content Networks. By analogy with peering of IP networks, this
   interconnection is sometimes called "content peering" or "content
   internetworking".

   Section 2 provides background on Content Networks.  Section 3
   introduces the terms used for elements of a Content Network and
   explains how those terms are used. Section 5 deals with Content
   Internetworking, 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 Content
   Internetworking.

   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 [3], which enumerates
   scenarios for Content-Internetworking-related interactions; [4],
   which describes requirements for accounting and associated issues;
   [5], which gives an overall architecture of the elements for CDN
   peering; and [6], which summarizes known mechanisms for request-
   routing.

   It should be noted that previous versions of this document and other
   working drafts of CDI appear to be more specifically focused on
   "Content Distribution Networks" (CDNs) and "CDN Peering". The use of
   the more general terms "Content Networks" and "Content
   Internetworking" are currently favored because they imply a wider
   variety of real-life scenarios that may be encompassed in CDI's
   work. Also, we are attempting to take the emphasis off use of the
   word "peering" because the term is often taken to imply a
   settlement-free arrangement (as is common with bandwidth peering).

2. Content Networks

   The past several years have seen the evolution of technologies
   centered around "content". Protocols, appliances, and entire markets

Day, et. al.          Expires September 2, 2001              [Page 3]
Internet-Draft                CDI Model                    March 2001

   have been created exclusively for the location, download, and usage-
   tracking tracking of content. Some sample technologies in this area
   have included web caching proxies, content management tools,
   intelligent "web switches", and advanced log analysis tools.

   When used together, these tools form new types of networks, dubbed
   "Content Networks". Whereas network infrastructures previously have
   traditionally occupied layers 1 through 3 of the OSI stack, Content
   Networks include network infrastructure that exists in layers 4
   through 7. Whereas lower-layer network infrastructures revolved
   around the routing, forwarding, and switching of frames and packets,
   Content Networks deal with the routing and forwarding of requests
   and responses for content. The units of transported data in Content
   Networks, such as web pages, movies, or songs, are often very large
   and may span hundreds or thousands of packets.

   Content Networks can be seen as a new virtual overlay to the OSI
   stack: a "Content Layer", to enable richer services that rely on
   underlying elements from all 7 layers of the stack. Whereas
   traditional applications, such as file transfer (FTP), relied on
   underlying protocols such as TCP/IP for transport, overlay services
   in Content Networks rely on layer 7 protocols such as HTTP or RTSP
   for transport.

   The proliferation of Content Networks and Content Networking
   capabilities gives rise to interest in interconnecting Content
   Networks and finding ways for distinct Content Networks to cooperate
   for better overall service.

2.1  Problem Description

   Content Networks typically play some role in solving the "content
   distribution problem". Abstractly, the goal in solving this 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.

   For the sake of background, several sample Content Networks are
   described in the following sections that each attempt to address
   this problem.



Day, et. al.          Expires September 2, 2001              [Page 4]
Internet-Draft                CDI Model                    March 2001

2.2  Forward Proxy Caching

   A type of Content Network that has been in use for several years is
   a forward proxy cache deployment. Such a network might typically be
   employed by an ISP for the benefit of end users accessing the
   Internet, such as through dial or cable modem.

   In the interest of improving performance and reducing bandwidth
   utilization, caching proxies are deployed close to the end users.
   These end users are encouraged to route their web requests through
   the caches rather than directly to origin servers, such as by
   configuring their browsers to do so. Note that when this is done,
   the end user's entire browsing session goes through a specific proxy
   cache. That proxy cache will therefore contain the "hot set" of all
   Internet content being viewed by the totality of access users
   utilizing that proxy cache.

   When a request is being handled a caching proxy on behalf of a user,
   other routing decisions may be made, such as:

   o  A provider that deploys access caches in many geographically
      diverse locations may also deploy regional parent caches to
      further aggregate user requests and responses. This may provide
      additional performance improvement and bandwidth savings. When
      parents are included, this is known as hierarchical caching.

   o  Using rich parenting protocols, redundant parents may be deployed
      such that a failure in a primary parent is detected and a backup
      is used instead.

   o  Using similar parenting protocols, requests may be partitioned
      such that requests for certain content domains are sent to a
      specific primary parent. This can help to maximize the efficient
      use of caching proxy resources.



















Day, et. al.          Expires September 2, 2001              [Page 5]
Internet-Draft                CDI Model                    March 2001


   The following diagram depicts a hierarchical cache deployment as
   described above:

                              ^        ^
                              |        |   requests to
                              |        |   origin servers
                              |        |
                          --------   --------
                          |parent|   |parent|
                          |cache |   |cache |
                          |proxy |   |proxy |
                          --------   --------
                               ^         ^
                   requests for \       / requests for
                        foo.com  \     /  bar.com
                        content   \   /   content
                                   \ /
               -------  -------  -------  -------
               |edge |  |edge |  |edge |  |edge |
               |cache|  |cache|  |cache|  |cache|
               |proxy|  |proxy|  |proxy|  |proxy|
               -------  -------  -------  -------
                                   ^
                                   | all content
                                   | requests
                                   | for this
                                   | client
                                   |
                                --------
                                |client|
                                --------
2.3  Server Farms

   Another type of Content Network that has been in widespread use for
   several years is a server farm. A typical server farm makes use of
   an intelligent switch that acts as a dispatcher for content
   requests. The switch then routes requests among a (potentially
   large) group of servers.

   Some of the goals of a a server farm include:

   o  Creating the impression that the group of servers is actually a
      single origin site.

   o  Load-balancing of requests across all servers in the group.

   o  Automatically routing of requests away from servers that fail.

   o  Routing all requests for a particular client's session to the
      same server, in order to preserve session state.


Day, et. al.          Expires September 2, 2001              [Page 6]
Internet-Draft                CDI Model                    March 2001


   The following diagram depicts a simple server farm deployment:

               ---------  ---------  ---------  ---------
               |content|  |content|  |content|  |content|
               |server |  |server |  |server |  |server |
               |       |  |       |  |       |  |       |
               ---------  ---------  ---------  ---------
                              ^          ^
                  request from \        / request from
                     client A   \      /    client B
                                 \    /
                              -------------
                              |intelligent|
                              |  switch   |
                              -------------
                                 ^     ^
                                /       \
                               /         \
                              /           \
                      request from     request from
                        client A         client B


   A similar type of Content Network may be constructed by replacing
   the switch with a server accelerator [2].

2.4  Content Distribution Networks

   Both hierarchical caching and server farms are useful techniques,
   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 network congestion.  Caching proxies can improve
   performance problems due to network 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 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.

   To address these limitations. another type of Content Network that
   has been deployed in increasing numbers in recent years is the
   Content Distribution Network, or CDN. 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

Day, et. al.          Expires September 2, 2001              [Page 7]
Internet-Draft                CDI Model                    March 2001

   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 to clients from
   multiple diverse locations. The increase in number and diversity of
   location 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, a distribution
   infrastructure, and an accounting 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. Finally, the accounting infrastructure tracks and
   collects data on request-routing, distribution, and delivery
   functions within the CDN.


















Day, et. al.          Expires September 2, 2001              [Page 8]
Internet-Draft                CDI Model                    March 2001

   The following diagram depicts a simple CDN as described above:

                     ----------          ----------
                     |request-|          |request-|
                     |routing |          |routing |
                     | system |          | system |
                     ----------          ----------
                       ^ |
          (1) client's | | (2) response
              content  | |     indicating
              request  | |     location of       -----------
                       | |     content           |surrogate|
                       | |                       -----------
         -----------   | |
         |surrogate|   | |      -----------
         -----------   | |      |surrogate|
                       | |      -----------
                       | |      ^
                       | v     / (3) client opens
                      client---      connection to
                                     retrieve content


   Because CDNs are arguably the most complicated form of Content
   Network currently deployed, they warrant further description.

2.4.1  Historic Evolution of CDNs

   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.

2.4.2  Describing CDN Value: Reach and 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."


Day, et. al.          Expires September 2, 2001              [Page 9]
Internet-Draft                CDI Model                    March 2001

   In a typical (non-internetworked) 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.

3. Content Network Model Terms

   This section consists of the definitions of a number of terms used
   to refer to roles, participants, and objects involved in Content
   Networks.

   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 CONTENT NETWORK.

   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 type
      of CONTENT NETWORK in which the NETWORK ELEMENTS are 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.

   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 NETWORK
      A collection of NETWORK ELEMENTS that assist in the location,
      download, and usage-tracking tracking of CONTENT.

   CONTENT SIGNAL


Day, et. al.          Expires September 2, 2001             [Page 10]
Internet-Draft                CDI Model                    March 2001

      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
      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 CONTENT NETWORK. 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.

Day, et. al.          Expires September 2, 2001             [Page 11]
Internet-Draft                CDI Model                    March 2001


   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
      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 CONTENT NETWORK.

   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].

4. Content Network Examples and Commentary

   This section uses the terms of the previous to explain concepts of
   CONTENT NETWORKs and CONTENT. Because CDNs contain all the major
   components of Content Networking (i.e. REQUEST-ROUTING,
   DISTRIBUTION, DELIVERY, ACCOUNTING), the example described is a CDN.

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 CONTENT NETWORK.

Day, et. al.          Expires September 2, 2001             [Page 12]
Internet-Draft                CDI Model                    March 2001


   In many cases, an item of CONTENT can be delivered by a CONTENT
   NETWORK 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.

5. Content Internetworking

   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.

   Content Internetworking allows different Content Networks to share
   resources so as to provide larger scale and/or reach to each
   participant than they could otherwise achieve.  By using commonly
   defined protocols for Content Internetworking, each Content Network
   can treat neighboring Content Networks as "black boxes", allowing
   them to hide internal details from each other.

6. Content Internetworking Model Terms

   This section consists of the definitions of a number of terms used
   to refer to roles, participants, and objects involved in
   internetworking Content Networks.

   ACCOUNTING ADVERTISEMENT
      ADVERTISEMENT from a CONTENT NETWORK's ACCOUNTING PEERING SYSTEM
      about the collections of CONTENT for which that CONTENT NETWORK
      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

Day, et. al.          Expires September 2, 2001             [Page 13]
Internet-Draft                CDI Model                    March 2001

      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 CONTENT NETWORK 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 CONTENT NETWORK.

   DISTRIBUTING CONTENT NETWORK
      A CONTENT NETWORK that does not have a NEGOTIATED RELATIONSHIP
      with the PUBLISHER for the CONTENT being delivered.

   DISTRIBUTION ADVERTISEMENT
      An ADVERTISEMENT from a CONTENT NETWORK's DISTRIBUTION PEERING
      SYSTEM describing the availability of collections of CONTENT via
      the CONTENT NETWORK's DISTRIBUTION SYSTEM.

   DISTRIBUTION PEERING
      Interconnection of two or more DISTRIBUTION SYSTEMS so as to
      propagate CONTENT SIGNALS and copies of CONTENT to groups of
      SURROGATES.

   DISTRIBUTION PEERING SYSTEM
      See PEERING SYSTEM.

   INJECTION
      A "send-only" form of DISTRIBUTION PEERING that takes place from
      an ORIGIN to a peer CONTENT NETWORK.

   INTER-
      Describes activity that involves more than one CONTENT NETWORK
      (e.g. INTER-CDN). Contrast with INTRA-.

   INTRA-
      Describes activity within a single CONTENT NETWORK (e.g. INTRA-
      CDN). Contrast with INTER-.

   NEGOTIATED RELATIONSHIP
      A relationship whose terms and conditions are partially or
      completely established outside the context of CONTENT NETWORK
      peering protocols.

   PEERING SYSTEM
      A collection of NETWORK ELEMENTS supporting some form of
      interconnected operation among two or more CDNs. Examples (not


Day, et. al.          Expires September 2, 2001             [Page 14]
Internet-Draft                CDI Model                    March 2001

      separately defined): ACCOUNTING PEERING SYSTEM, DISTRIBUTION
      PEERING SYSTEM, REQUEST-ROUTING PEERING SYSTEM.

   REMOTE CONTENT NETWORK
      A CONTENT NETWORK 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 CONTENT NETWORK's REQUEST-ROUTING PEERING
      SYSTEM describing the availability of collections of CONTENT via
      that CONTENT NETWORK'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.

7. Content Internetworking Examples and Commentary

   This section uses the terms of the previous to explain concepts of
   CONTENT NETWORK peering. Because CDNs contain all the major
   components of Content Networking (i.e. REQUEST-ROUTING,
   DISTRIBUTION, DELIVERY, ACCOUNTING), the example describes
   internetworking among CDNs.

7.1 Understanding Content Internetworking

   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 (for

Day, et. al.          Expires September 2, 2001             [Page 15]
Internet-Draft                CDI Model                    March 2001

   purposes other than tracking operational health) 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.

7.2 Content Signaling

   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.

8. 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.]

9. Security Considerations

   Content Internetworking raises some security-related issues, and a
   detailed discussion of those issues appears in [5].

10. 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 (CacheFlow), Markus Hoffmann (Lucent), Barron
   Housel (Cisco), Barbara Liskov (Cisco), John Martin (Network
   Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter
   (Cisco), Oliver Spatscheck (AT&T), and Nalin Mistry (Nortel).

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,
        <URL:http://www.rfc-editor.org/rfc/rfc2616.txt>.

   [2]  Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
        Replication and Caching Taxonomy", RFC3040, January 2001,
        <URL:http://www.ietf.org/rfc/rfc3040.txt>.

   [3]  Day, M., Gilletti, D., and P. Rzewski, "Content Internetworking
        Scenarios", draft-day-cdnp-scenarios-03.txt (work in progress),
        March 2001,


Day, et. al.          Expires September 2, 2001             [Page 16]
Internet-Draft                CDI Model                    March 2001

        <URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-
        scenarios-03.txt>.

   [4]  Gilletti, D., Nair, R., Scharber, J., and J. Guha, "CDN-I
        Internetworking Authentication, Authorization, and Accounting
        Requirements", draft-gilletti-cdnp-aaa-reqs-01.txt (work in
        progress), March 2001,
        <URL:http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-
        aaa-reqs-01.txt>.

   [5]  Green, M., Cain, B., Tomlinson, G., Thomas, S., and P. Rzewski,
        "Content Internetworking Architectural Overview", draft-green-
        cdnp-gen-arch-03.txt (work in progress), March 2001,
        <URL:http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-
        arch-03.txt>.

   [6]  Barbir, A., Cain, B., Douglis, F., Green, M., Hoffmann, M.,
        Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request-
        Routing Mechanisms", draft-cain-cdnp-known-request-routing-
        01.txt (work in progress), February 2001,
        <URL:http://www.ietf.org/internet-drafts/draft-cain-cdnp-known-
        request-routing-01.txt>.

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
   Cereva Networks

   Email: bcain@cereva.com


   Gary Tomlinson
   CacheFlow Inc.
   12034 134th Ct. NE Suite 201
   Redmond, WA 98052
   US

   Phone: +1 425 820 3009
   EMail: garyt@cacheflow.com


   Phil Rzewski

Day, et. al.          Expires September 2, 2001             [Page 17]
Internet-Draft                CDI Model                    March 2001

   Inktomi
   4100 East Third Avenue
   MS FC1-4
   Foster City, CA 94404
   US

   Phone +1 650 653 2487
   Email: philr@inktomi.com

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.












Day, et. al.          Expires September 2, 2001             [Page 18]
--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)