idnits 2.17.1 draft-day-cdnp-model-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2001) is 8193 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 706, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '1') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2326 (ref. '2') (Obsoleted by RFC 7826) ** Downref: Normative reference to an Informational RFC: RFC 3040 (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-05) exists of draft-day-cdnp-scenarios-03 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-05) exists of draft-cain-cdnp-known-request-routing-02 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-03) exists of draft-cain-request-routing-req-02 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-02) exists of draft-amini-cdi-distribution-reqs-01 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Day 3 Internet-Draft Cisco 4 Expires: May 21, 2002 B. Cain 5 Cereva 6 G. Tomlinson 7 CacheFlow 8 P. Rzewski 9 Inktomi 10 November 20, 2001 12 A Model for Content Internetworking (CDI) 13 draft-day-cdnp-model-09.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 21, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). All Rights Reserved. 42 Abstract 44 Content [distribution] internetworking (CDI) is the technology for 45 interconnecting content networks, sometimes previously called 46 "content peering" or "CDN peering." A common vocabulary helps the 47 process of discussing such interconnection and interoperation. This 48 document introduces content networks and content internetworking, 49 and defines elements for such a common vocabulary. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Content Networks . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Problem Description . . . . . . . . . . . . . . . . . . . . 4 56 2.2 Caching Proxies . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3 Server Farms . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.4 Content Distribution Networks . . . . . . . . . . . . . . . 7 59 2.4.1 Historic Evolution of CDNs . . . . . . . . . . . . . . . . . 9 60 2.4.2 Describing CDN Value: Reach and Scale . . . . . . . . . . . 9 61 3. Content Network Model Terms . . . . . . . . . . . . . . . . 11 62 4. Content Internetworking . . . . . . . . . . . . . . . . . . 14 63 5. Content Internetworking Model Terms . . . . . . . . . . . . 15 64 6. Security Considerations . . . . . . . . . . . . . . . . . . 18 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 66 References . . . . . . . . . . . . . . . . . . . . . . . . . 20 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . 22 70 1. Introduction 72 Content networks are of increasing importance to the overall 73 architecture of the Web. This document presents a vocabulary for 74 use in developing technology for interconnecting content networks, 75 or "content internetworking." 77 The accepted name for the technology of interconnecting content 78 networks is "content internetworking." For historical reasons, we 79 abbreviate this term using the acronym CDI (from "content 80 distribution internetworking"). Earlier names relied on analogy 81 with peering and interconnection of IP networks; thus we had 82 "content peering" and "CDN peering". All of these other names are 83 now deprecated, and we have worked to establish consistent usage of 84 "content internetworking" and "CDI" throughout the drafts of the 85 IETF CDI group. 87 The terminology in this document builds from the previous taxonomy 88 of web caching and replication in RFC 3040 [3] . In particular, we 89 have attempted to avoid the use of the common terms "proxies" or 90 "caches" in favor of more specific terms defined by that document, 91 such as "caching proxy." 93 Section 2 provides background on content networks. Section 3 94 introduces the terms used for elements of a content network and 95 explains how those terms are used. Section 4 provides additional 96 background on interconnecting content networks, following which 97 Section 5 introduces additional terms and explains how those 98 internetworking terms are used. 100 [Note to RFC Editor: This entire paragraph may be deleted so as to 101 avoid references to internet-drafts in RFCs.] The IETF CDI effort 102 has produced a number of other documents related to content 103 internetworking. Other documents providing general information about 104 CDI are: "Content Internetworking Scenarios" [5], which enumerates 105 scenarios for content-internetworking-related interactions; "Content 106 Internetworking Architectural Overview" [4], which gives an overall 107 architecture of the elements for CDI; and "Known CDN Request-Routing 108 Mechanisms" [7], which summarizes known mechanisms for 109 request-routing. In addition, there are documents describing the 110 requirements for various aspects of CDI: "Request-Routing 111 Requirements for Content Internetworking" [8], "Distribution 112 Requirements for Content Internetworking" [9], and "Content 113 Internetworking (CDI) Authentication, Authorization, and Accounting 114 Requirements" [6] 116 2. Content Networks 118 The past several years have seen the evolution of technologies 119 centered around "content." Protocols, appliances, and entire markets 120 have been created exclusively for the location, download, and usage 121 tracking of content. Some sample technologies in this area have 122 included web caching proxies, content management tools, intelligent 123 "web switches", and advanced log analysis tools. 125 When used together, these tools form new types of networks, dubbed 126 "content networks". Whereas network infrastructures have 127 traditionally processed information at layers 1 through 3 of the OSI 128 stack, content networks include network infrastructure that exists 129 in layers 4 through 7. Whereas lower-layer network infrastructures 130 centered on the routing, forwarding, and switching of frames and 131 packets, content networks deal with the routing and forwarding of 132 requests and responses for content. The units of transported data in 133 content networks, such as images, movies, or songs, are often very 134 large and may span hundreds or thousands of packets. 136 Alternately, content networks can be seen as a new virtual overlay 137 to the OSI stack: a "content layer", to enable richer services that 138 rely on underlying elements from all 7 layers of the stack. Whereas 139 traditional applications, such as file transfer (FTP), relied on 140 underlying protocols such as TCP/IP for transport, overlay services 141 in content networks rely on layer 7 protocols such as HTTP or RTSP 142 for transport. 144 The proliferation of content networks and content networking 145 capabilities gives rise to interest in interconnecting content 146 networks and finding ways for distinct content networks to cooperate 147 for better overall service. 149 2.1 Problem Description 151 Content networks typically play some role in solving the "content 152 distribution problem". Abstractly, the goal in solving this problem 153 is to arrange a rendezvous between a content source at an origin 154 server and a content sink at a viewer's user agent. In the trivial 155 case, the rendezvous mechanism is that every user agent sends every 156 request directly to the origin server named in the host part of the 157 URL identifying the content. 159 As the audience for the content source grows, so do the demands on 160 the origin server. There are a variety of ways in which the trivial 161 system can be modified for better performance. The apparent single 162 logical server may in fact be implemented as a large "farm" of 163 server machines behind a switch. Both caching proxies and reverse 164 caching proxies can be deployed between the client and server, so 165 that requests can be satisfied by some cache instead of by the 166 server. 168 For the sake of background, several sample content networks are 169 described in the following sections that each attempt to address 170 this problem. 172 2.2 Caching Proxies 174 A type of content network that has been in use for several years is 175 a caching proxy deployment. Such a network might typically be 176 employed by an ISP for the benefit of users accessing the Internet, 177 such as through dial or cable modem. 179 In the interest of improving performance and reducing bandwidth 180 utilization, caching proxies are deployed close to the users. These 181 users are encouraged to send their web requests through the caches 182 rather than directly to origin servers, such as by configuring their 183 browsers to do so. When this configuration is properly done, the 184 user's entire browsing session goes through a specific caching 185 proxy. That caching proxy will therefore contain the "hot set" of 186 all Internet content being viewed by all of the users of that 187 caching proxy. 189 When a request is being handled at a caching proxy on behalf of a 190 user, other decisions may be made, such as: 192 o A provider that deploys caches in many geographically diverse 193 locations may also deploy regional parent caches to further 194 aggregate user requests and responses. This may provide 195 additional performance improvement and bandwidth savings. When 196 parents are included, this is known as hierarchical caching. 198 o Using rich parenting protocols, redundant parents may be deployed 199 such that a failure in a primary parent is detected and a backup 200 is used instead. 202 o Using similar parenting protocols, requests may be partitioned 203 such that requests for certain content domains are sent to a 204 specific primary parent. This can help to maximize the efficient 205 use of caching proxy resources. 207 The following diagram depicts a hierarchical cache deployment as 208 described above: 210 ^ ^ 211 | | requests to 212 | | origin servers 213 | | 214 -------- -------- 215 |parent| |parent| 216 |cache | |cache | 217 |proxy | |proxy | 218 -------- -------- 219 ^ ^ 220 requests for \ / requests for 221 foo.com \ / bar.com 222 content \ / content 223 \ / 224 ------- ------- ------- ------- 225 |edge | |edge | |edge | |edge | 226 |cache| |cache| |cache| |cache| 227 |proxy| |proxy| |proxy| |proxy| 228 ------- ------- ------- ------- 229 ^ 230 | all content 231 | requests 232 | for this 233 | client 234 | 235 -------- 236 |client| 237 -------- 239 Note that this diagram shows only one possible configuration, but 240 many others are also useful. In particular, the client may be able 241 to communicate directly with multiple caching proxies. RFC 3040 [3] 242 contains additional examples of how multiple caching proxies may be 243 used. 245 2.3 Server Farms 247 Another type of content network that has been in widespread use for 248 several years is a server farm. A typical server farm makes use of a 249 so-called "intelligent" or "content" switch (i.e. one that uses 250 information in OSI layers 4-7). The switch examines content requests 251 and dispatches them among a (potentially large) group of servers. 253 Some of the goals of a server farm include: 255 o Creating the impression that the group of servers is actually a 256 single origin site. 258 o Load-balancing of requests across all servers in the group. 260 o Automatic routing of requests away from servers that fail. 262 o Routing all requests for a particular user agent's session to the 263 same server, in order to preserve session state. 265 The following diagram depicts a simple server farm deployment: 267 --------- --------- --------- --------- 268 |content| |content| |content| |content| 269 |server | |server | |server | |server | 270 | | | | | | | | 271 --------- --------- --------- --------- 272 ^ ^ 273 request from \ / request from 274 client A \ / client B 275 \ / 276 ------------- 277 | L4-L7 | 278 | switch | 279 ------------- 280 ^ ^ 281 / \ 282 / \ 283 / \ 284 request from request from 285 client A client B 287 A similar style of content network (that is, deployed close to 288 servers) may be constructed with surrogates [3] instead of a switch. 290 2.4 Content Distribution Networks 292 Both hierarchical caching and server farms are useful techniques, 293 but have limits. Server farms can improve the scalability of the 294 origin server. However, since the multiple servers and other 295 elements are typically deployed near the origin server, they do 296 little to improve performance problems that are due to network 297 congestion. Caching proxies can improve performance problems due to 298 network congestion (since they are situated near the clients) but 299 they cache objects based on client demand. Caching based on client 300 demand performs poorly if the requests for a given object, while 301 numerous in aggregate, are spread thinly among many different 302 caching proxies. (In the worst case, an object could be requested n 303 times via n distinct caching proxies, causing n distinct requests to 304 the origin server -- or exactly the same behavior that would occur 305 without any caching proxies in place.) 307 Thus, a content provider with a popular content source can find that 308 it has to invest in large server farms, load balancing, and high- 309 bandwidth connections to keep up with demand. Even with those 310 investments, the user experience may still be relatively poor due to 311 congestion in the network as a whole. 313 To address these limitations, another type of content network that 314 has been deployed in increasing numbers in recent years is the CDN 315 (Content Distribution Network or Content Delivery Network). A CDN 316 essentially moves server-farm-like configurations out into network 317 locations more typically occupied by caching proxies. A CDN has 318 multiple replicas of each content item being hosted. A request from 319 a browser for a single content item is directed to a "good" replica, 320 where "good" usually means that the item is served to the client 321 quickly compared to the time it would take fetch it from the origin 322 server, with appropriate integrity and consistency. Static 323 information about geographic locations and network connectivity is 324 usually not sufficient to do a good job of choosing a replica. 325 Instead, a CDN typically incorporates dynamic information about 326 network conditions and load on the replicas, directing requests so 327 as to balance the load. 329 Compared to using servers and surrogates in a single data center, a 330 CDN is a relatively complex system encompassing multiple points of 331 presence, in locations that may be geographically far apart. 332 Operating a CDN is not easy for a content provider, since a content 333 provider wants to focus its resources on developing high-value 334 content, not on managing network infrastructure. Instead, a more 335 typical arrangement is that a network service provider builds and 336 operates a CDN, offering a content distribution service to a number 337 of content providers. 339 A CDN enables a service provider to act on behalf of the content 340 provider to deliver copies of origin server content to clients from 341 multiple diverse locations. The increase in number and diversity of 342 location is intended to improve download times and thus improve the 343 user experience. A CDN has some combination of a content-delivery 344 infrastructure, a request-routing infrastructure, a distribution 345 infrastructure, and an accounting infrastructure. The content- 346 delivery infrastructure consists of a set of "surrogate" servers [3] 347 that deliver copies of content to sets of users. The request-routing 348 infrastructure consists of mechanisms that move a client toward a 349 rendezvous with a surrogate. The distribution infrastructure 350 consists of mechanisms that move content from the origin server to 351 the surrogates. Finally, the accounting infrastructure tracks and 352 collects data on request-routing, distribution, and delivery 353 functions within the CDN. 355 The following diagram depicts a simple CDN as described above: 357 ---------- ---------- 358 |request-| |request-| 359 |routing | |routing | 360 | system | | system | 361 ---------- ---------- 362 ^ | 363 (1) client's | | (2) response 364 content | | indicating 365 request | | location of ----------- 366 | | content |surrogate| 367 | | ----------- 368 ----------- | | 369 |surrogate| | | ----------- 370 ----------- | | |surrogate| 371 | | ----------- 372 | | ^ 373 | v / (3) client opens 374 client--- connection to 375 retrieve content 377 2.4.1 Historic Evolution of CDNs 379 The first important use of CDNs was for the distribution of heavily- 380 requested graphic files (such as GIF files on the home pages of 381 popular servers). However, both in principle and increasingly in 382 practice, a CDN can support the delivery of any digital content -- 383 including various forms of streaming media. For a streaming media 384 CDN (or media distribution network or MDN), the surrogates may be 385 operating as splitters (serving out multiple copies of a stream). 386 The splitter function may be instead of, or in addition to, a role 387 as a caching proxy. However, the basic elements defined in this 388 model are still intended to apply to the interconnection of content 389 networks that are distributing streaming media. 391 2.4.2 Describing CDN Value: Reach and Scale 393 There are two fundamental elements that give a CDN value: 394 outsourcing infrastructure and improved content delivery. A CDN 395 allows multiple surrogates to act on behalf of an orgin server, 396 therefore removing the delivery of content from a centralized site 397 to multiple and (usually) highly distributed sites. We refer to 398 increased aggregate infrastructure size as "scale." In addition, a 399 CDN can be constructed with copies of content near to end users, 400 overcoming issues of network size, network congestion, and network 401 failures. We refer to increased diversity of content locations as 402 "reach." 404 In a typical (non-internetworked) CDN, a single service provider 405 operates the request-routers, the surrogates, and the content 406 distributors. In addition, that service provider establishes 407 (business) relationships with content publishers and acts on behalf 408 of their origin sites to provide a distributed delivery system. The 409 value of that CDN to a content provider is a combination of its 410 scale and its reach. 412 3. Content Network Model Terms 414 This section consists of the definitions of a number of terms used 415 to refer to roles, participants, and objects involved in content 416 networks. Although the following uses many terms that are based on 417 those used in RFC 2616 [1] or RFC 3040 [3], there is no necessary 418 connection to HTTP or web caching technology. Content 419 internetworking and this vocabulary are applicable to other 420 protocols and styles of content delivery. 422 Phrases in upper-case refer to other defined terms. 424 ACCOUNTING 425 Measurement and recording of DISTRIBUTION and DELIVERY 426 activities, especially when the information recorded is 427 ultimately used as a basis for the subsequent transfer of money, 428 goods, or obligations. 430 ACCOUNTING SYSTEM 431 A collection of CONTENT NETWORK ELEMENTS that supports ACCOUNTING 432 for a single CONTENT NETWORK. 434 AUTHORITATIVE REQUEST-ROUTING SYSTEM 435 The REQUEST-ROUTING SYSTEM that is the correct/final authority 436 for a particular item of CONTENT. 438 CDN 439 Content Delivery Network or Content Distribution Network. A type 440 of CONTENT NETWORK in which the CONTENT NETWORK ELEMENTS are 441 arranged for more effective delivery of CONTENT to CLIENTS. 442 Typically a CDN consists of a REQUEST-ROUTING SYSTEM, SURROGATES, 443 a DISTRIBUTION SYSTEM, and an ACCOUNTING SYSTEM. 445 CLIENT 446 A program that sends CONTENT REQUESTS and receives corresponding 447 CONTENT RESPONSES. [Note: this is similar to the definition in 448 RFC 2616 [1] but we do not require establishment of a connection.] 450 CONTENT 451 Any form of digital data, CONTENT approximately corresponds to 452 what is referred to as an "entity" in RFC 2616 [1]. One important 453 form of CONTENT with additional constraints on DISTRIBUTION and 454 DELIVERY is CONTINUOUS MEDIA. 456 CONTENT NETWORK 457 An arrangement of CONTENT NETWORK ELEMENTS, controlled by a 458 common management in some fashion. 460 CONTENT NETWORK ELEMENT 461 A network device that performs at least some of its processing by 462 examining CONTENT-related parts of network messages. In IP-based 463 networks, a CONTENT NETWORK ELEMENT is a device whose processing 464 depends on examining information contained in IP packet bodies; 465 network elements (as defined in RFC 3040) examine only the header 466 of an IP packet. Note that many CONTENT NETWORK ELEMENTS do not 467 examine or even see individual IP packets, instead receiving the 468 body of one or more packets assembled into a message of some 469 higher-level protocol. 471 CONTENT REQUEST 472 A message identifying a particular item of CONTENT to be 473 delivered. 475 CONTENT RESPONSE 476 A message containing a particular item of CONTENT, identified in 477 a previous CONTENT REQUEST. 479 CONTENT SIGNAL 480 A message delivered through a DISTRIBUTION SYSTEM that specifies 481 information about an item of CONTENT. For example, a CONTENT 482 SIGNAL can indicate that the ORIGIN has a new version of some 483 piece of CONTENT. 485 CONTINUOUS MEDIA 486 CONTENT where there is a timing relationship between source and 487 sink; that is, the sink must reproduce the timing relationship 488 that existed at the source. The most common examples of 489 CONTINUOUS MEDIA are audio and motion video. CONTINUOUS MEDIA can 490 be real-time (interactive), where there is a "tight" timing 491 relationship between source and sink, or streaming (playback), 492 where the relationship is less strict. [Note: This definition is 493 essentially identical to the definition of continuous media in 494 [2]] 496 DELIVERY 497 The activity of providing a PUBLISHER's CONTENT, via CONTENT 498 RESPONSES, to a CLIENT. Contrast with DISTRIBUTION and 499 REQUEST-ROUTING. 501 DISTRIBUTION 502 The activity of moving a PUBLISHER's CONTENT from its ORIGIN to 503 one or more SURROGATEs. DISTRIBUTION can happen either in 504 anticipation of a SURROGATE receiving a REQUEST (pre-positioning) 505 or in response to a SURROGATE receiving a REQUEST (fetching on 506 demand). Contrast with DELIVERY and REQUEST-ROUTING. 508 DISTRIBUTION SYSTEM 509 A collection of CONTENT NETWORK ELEMENTS that support 510 DISTRIBUTION for a single CONTENT NETWORK. The DISTRIBUTION 511 SYSTEM also propagates CONTENT SIGNALs. 513 ORIGIN 514 The point at which CONTENT first enters a DISTRIBUTION SYSTEM. 515 The ORIGIN for any item of CONTENT is the server or set of 516 servers at the "core" of the distribution, holding the "master" 517 or "authoritative" copy of that CONTENT. [Note: We believe this 518 definition is compatible with that for "origin server" in RFC 519 2616 [1] but includes additional constraints useful for CDI.] 521 PUBLISHER 522 The party that ultimately controls the CONTENT and its 523 distribution. 525 REACHABLE SURROGATES 526 The collection of SURROGATES that can be contacted via a 527 particular DISTRIBUTION SYSTEM or REQUEST-ROUTING SYSTEM. 529 REQUEST-ROUTING 530 The activity of steering or directing a CONTENT REQUEST from a 531 USER AGENT to a suitable SURROGATE. 533 REQUEST-ROUTING SYSTEM 534 A collection of CONTENT NETWORK ELEMENTS that support 535 REQUEST-ROUTING for a single CONTENT NETWORK. 537 SERVER 538 A program that accepts CONTENT REQUESTS and services them by 539 sending back CONTENT RESPONSES. Any given program may be capable 540 of being both a client and a server; our use of these terms 541 refers only to the role being performed by the program. [Note: 542 this is adapted from a similar definition in RFC 2616 [1].] 544 SURROGATE 545 A delivery server, other than the ORIGIN. Receives a CONTENT 546 REQUEST and delivers the corresponding CONTENT RESPONSE. [Note: 547 this is a different definition from that in RFC 3040 [3], which 548 appears overly elaborate for our purposes. A "CDI surrogate" is 549 always an "RFC 3040 surrogate"; we are not sure if the reverse is 550 true.] 552 USER AGENT 553 The CLIENT which initiates a REQUEST. These are often browsers, 554 editors, spiders (web-traversing robots), or other end user 555 tools. [Note: this definition is identical to the one in RFC 2616 556 [1].] 558 4. Content Internetworking 560 There are limits to how large any one network's scale and reach can 561 be. Increasing either scale or reach is ultimately limited by the 562 cost of equipment, the space available for deploying equipment, 563 and/or the demand for that scale/reach of infrastructure. Sometimes 564 a particular audience is tied to a single service provider or a 565 small set of providers by constraints of technology, economics, or 566 law. Other times, a network provider may be able to manage 567 surrogates and a distribution system, but may have no direct 568 relationship with content providers. Such a provider wants to have a 569 means of affiliating their delivery and distribution infrastructure 570 with other parties who have content to distribute. 572 Content internetworking allows different content networks to share 573 resources so as to provide larger scale and/or reach to each 574 participant than they could otherwise achieve. By using commonly 575 defined protocols for content internetworking, each content network 576 can treat neighboring content networks as "black boxes", allowing 577 them to hide internal details from each other. 579 5. Content Internetworking Model Terms 581 This section consists of the definitions of a number of terms used 582 to refer to roles, participants, and objects involved in 583 internetworking content networks. The purpose of this section is to 584 identify common terms and provide short definitions. A more 585 detailed technical discussion of these terms and their relationships 586 appears in "Content Internetworking Architectural Overview" [4]. 588 ACCOUNTING INTERNETWORKING 589 Interconnection of two or more ACCOUNTING SYSTEMS so as to enable 590 the exchange of information between them. The form of ACCOUNTING 591 INTERNETWORKING required may depend on the nature of the 592 NEGOTIATED RELATIONSHIP between the peering parties -- in 593 particular, on the value of the economic exchanges anticipated. 595 ADVERTISEMENT 596 Information about resources available to other CONTENT NETWORKS, 597 exchanged via CONTENT INTERNETWORKING GATEWAYS. Types of 598 ADVERTISEMENT include AREA ADVERTISEMENTS, CONTENT 599 ADVERTISEMENTS, and DISTRIBUTION ADVERTISEMENTS. 601 AREA ADVERTISEMENT 602 ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM 603 about aspects of topology, geography and performance of a CONTENT 604 NETWORK. Contrast with CONTENT ADVERTISEMENT, DISTRIBUTION 605 ADVERTISEMENT. 607 BILLING ORGANIZATION 608 An entity that operates an ACCOUNTING SYSTEM to support billing 609 within a NEGOTIATED RELATIONSHIP with a PUBLISHER. 611 CONTENT ADVERTISEMENT 612 ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM 613 about the availability of one or more collections of CONTENT on a 614 CONTENT NETWORK. Contrast with AREA ADVERTISEMENT, DISTRIBUTION 615 ADVERTISEMENT 617 CONTENT DESTINATION 618 A CONTENT NETWORK or DISTRIBUTION SYSTEM that is accepting 619 CONTENT from another such network or system. Contrast with 620 CONTENT SOURCE. 622 CONTENT INTERNETWORKING GATEWAY (CIG) 623 An identifiable element or system through which a CONTENT NETWORK 624 can be interconnected with others. A CIG may be the point of 625 contact for DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING 626 INTERNETWORKING, and/or ACCOUNTING INTERNETWORKING, and thus may 627 incorporate some or all of the corresponding systems for the 628 CONTENT NETWORK. 630 CONTENT REPLICATION 631 The movement of CONTENT from a CONTENT SOURCE to a CONTENT 632 DESTINATION. Note that this is specifically the movement of 633 CONTENT from one network to another. There may be similar or 634 different mechanisms that move CONTENT around within a single 635 network's DISTRIBUTION SYSTEM. 637 CONTENT SOURCE 638 A CONTENT NETWORK or DISTRIBUTION SYSTEM that is distributing 639 CONTENT to another such network or system. Contrast with CONTENT 640 DESTINATION. 642 DISTRIBUTION ADVERTISEMENT 643 An ADVERTISEMENT from a CONTENT NETWORK's DISTRIBUTION SYSTEM to 644 potential CONTENT SOURCES, describing the capabilities of one or 645 more CONTENT DESTINATIONS. Contrast with AREA ADVERTISEMENT, 646 CONTENT ADVERTISEMENT. 648 DISTRIBUTION INTERNETWORKING 649 Interconnection of two or more DISTRIBUTION SYSTEMS so as to 650 propagate CONTENT SIGNALS and copies of CONTENT to groups of 651 SURROGATES. 653 INJECTION 654 A "send-only" form of DISTRIBUTION INTERNETWORKING that takes 655 place from an ORIGIN to a CONTENT DESTINATION. 657 INTER- 658 Describes activity that involves more than one CONTENT NETWORK 659 (e.g. INTER-CDN). Contrast with INTRA-. 661 INTRA- 662 Describes activity within a single CONTENT NETWORK (e.g. INTRA- 663 CDN). Contrast with INTER-. 665 NEGOTIATED RELATIONSHIP 666 A relationship whose terms and conditions are partially or 667 completely established outside the context of CONTENT NETWORK 668 internetworking protocols. 670 REMOTE CONTENT NETWORK 671 A CONTENT NETWORK able to deliver CONTENT for a particular 672 REQUEST that is not the AUTHORITATIVE REQUEST-ROUTING SYSTEM for 673 that REQUEST. 675 REQUEST-ROUTING INTERNETWORKING 676 Interconnection of two or more REQUEST-ROUTING SYSTEMS so as to 677 increase the number of REACHABLE SURROGATES for at least one of 678 the interconnected systems. 680 6. Security Considerations 682 There are no security-related issues related to the terms defined in 683 this document. The technology of content internetworking does raise 684 some security-related issues, and a detailed discussion of those 685 issues appears in "Content Internetworking Architectural Overview" 686 [4]. 688 7. Acknowledgements 690 The authors acknowledge the contributions and comments of Fred 691 Douglis (AT&T), Don Gilletti (CacheFlow), Markus Hoffmann (Lucent), 692 Barron Housel (Cisco), Barbara Liskov (Cisco), John Martin (Network 693 Appliance), Nalin Mistry (Nortel Networks) Raj Nair (Cisco), Hilarie 694 Orman (Volera), Doug Potter (Cisco), and Oliver Spatscheck (AT&T). 696 [Note to RFC Editor: The last normative reference is [4], all 697 subsequent references starting with [5] can be deleted.] 699 References 701 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 702 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 703 HTTP/1.1", RFC 2616, June 1999, 704 . 706 [2] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 707 Protocol", RFC 2326, April 1998, 708 . 710 [3] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web 711 Replication and Caching Taxonomy", RFC 3040, June 2000, 712 . 714 [4] Green, M., Cain, B., Tomlinson, G., Thomas, S. and P. Rzewskip, 715 "Content Internetworking Architectural Overview", 716 draft-green-cdnp-gen-arch-03.txt (work in progress), March 717 2001, 718 . 721 [5] Day, M., Gilletti, D. and P. Rzewskip, "CDN Peering Scenarios", 722 draft-day-cdnp-scenarios-03.txt (work in progress), March 2001, 723 . 726 [6] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Content 727 Internetworking (CDI) Authentication, Authorization, and 728 Accounting Requirements", draft-gilletti-cdnp-aaa-reqs-01.txt 729 (work in progress), June 2001, 730 . 733 [7] Barbir, A., Cain, B., Douglis, F., Green, M., Hoffmann, M., 734 Nair, R., Potter, D. and O. Spatscheck, "Known CDN 735 Request-Routing Mechanisms", 736 draft-cain-cdnp-known-request-routing-02.txt (work in 737 progress), June 2001, 738 . 741 [8] Cain, B., Spatscheck, O., May, M. and A. Barbir, 742 "Request-Routing Requirements for Content Internetworking", 743 draft-cain-request-routing-req-02.txt (work in progress), July 744 2001, 745 . 748 [9] Amini, L., Spatscheck, O. and S. Thomas, "Distribution 749 Requirements for Content Internetworking", 750 draft-amini-cdi-distribution-reqs-01.txt (work in progress), 751 July 2001, 752 . 755 Authors' Addresses 757 Mark Stuart Day 758 Cisco Systems 759 1414 Massachusetts Avenue 760 Boxborough, MA 01719 761 US 763 Phone: +1 978 936 1089 764 EMail: markday@cisco.com 766 Brad Cain 767 Cereva Networks 768 3 Network Drive 769 Marlborough, MA 01752 770 US 772 Phone: +1 508-787-5000 773 EMail: bcain@cereva.com 775 Gary Tomlinson 776 CacheFlow, Inc. 777 12034 134th Ct. NE Suite 201 778 Redmond, WA 98052 779 US 781 Phone: +1 425 820 3009 782 EMail: garyt@cacheflow.com 784 Phil Rzewski 785 Inktomi 786 4100 East Third Avenue, MS FC2-4 787 Foster City, CA 94404 788 US 790 Phone: +1 650 653 2487 791 EMail: philr@inktomi.com 793 Full Copyright Statement 795 Copyright (C) The Internet Society (2001). All Rights Reserved. 797 This document and translations of it may be copied and furnished to 798 others, and derivative works that comment on or otherwise explain it 799 or assist in its implementation may be prepared, copied, published 800 and distributed, in whole or in part, without restriction of any 801 kind, provided that the above copyright notice and this paragraph 802 are included on all such copies and derivative works. However, this 803 document itself may not be modified in any way, such as by removing 804 the copyright notice or references to the Internet Society or other 805 Internet organizations, except as needed for the purpose of 806 developing Internet standards in which case the procedures for 807 copyrights defined in the Internet Standards process must be 808 followed, or as required to translate it into languages other than 809 English. 811 The limited permissions granted above are perpetual and will not be 812 revoked by the Internet Society or its successors or assigns. 814 This document and the information contained herein is provided on an 815 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 816 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 817 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 818 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 819 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Acknowledgement 823 Funding for the RFC editor function is currently provided by the 824 Internet Society.