idnits 2.17.1 draft-ietf-cdi-model-00.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 (February 22, 2002) is 8092 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 700, 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') == Outdated reference: A later version (-01) exists of draft-ietf-cdi-architecture-00 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-01) exists of draft-ietf-cdi-scenarios-00 ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-scenarios (ref. '5') == Outdated reference: A later version (-01) exists of draft-ietf-cdi-aaa-reqs-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-03) exists of draft-ietf-cdi-known-request-routing-00 ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-known-request-routing (ref. '7') == Outdated reference: A later version (-01) exists of draft-ietf-cdi-request-routing-reqs-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-01) exists of draft-ietf-cdi-distribution-reqs-00 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 6 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: August 23, 2002 B. Cain 5 Cereva 6 G. Tomlinson 7 CacheFlow 8 P. Rzewski 9 Inktomi 10 February 22, 2002 12 A Model for Content Internetworking (CDI) 13 draft-ietf-cdi-model-00.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 Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 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 http:// 31 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 August 23, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). 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, and 49 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 use 74 in developing technology for interconnecting content networks, or 75 "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 with 81 peering and interconnection of IP networks; thus we had "content 82 peering" and "CDN peering". All of these other names are now 83 deprecated, and we have worked to establish consistent usage of 84 "content internetworking" and "CDI" throughout the drafts of the IETF 85 CDI group. 87 The terminology in this document builds from the previous taxonomy of 88 web caching and replication in RFC 3040 [3] . In particular, we have 89 attempted to avoid the use of the common terms "proxies" or "caches" 90 in favor of more specific terms defined by that document, such as 91 "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 has 102 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 request- 109 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 in 129 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 to 137 the OSI stack: a "content layer", to enable richer services that rely 138 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 server 163 machines behind a switch. Both caching proxies and reverse caching 164 proxies can be deployed between the client and server, so that 165 requests can be satisfied by some cache instead of by the server. 167 For the sake of background, several sample content networks are 168 described in the following sections that each attempt to address this 169 problem. 171 2.2 Caching Proxies 173 A type of content network that has been in use for several years is a 174 caching proxy deployment. Such a network might typically be employed 175 by an ISP for the benefit of users accessing the Internet, such as 176 through dial or cable modem. 178 In the interest of improving performance and reducing bandwidth 179 utilization, caching proxies are deployed close to the users. These 180 users are encouraged to send their web requests through the caches 181 rather than directly to origin servers, such as by configuring their 182 browsers to do so. When this configuration is properly done, the 183 user's entire browsing session goes through a specific caching proxy. 184 That caching proxy will therefore contain the "hot set" of all 185 Internet content being viewed by all of the users of that caching 186 proxy. 188 When a request is being handled at a caching proxy on behalf of a 189 user, other decisions may be made, such as: 191 o A provider that deploys caches in many geographically diverse 192 locations may also deploy regional parent caches to further 193 aggregate user requests and responses. This may provide 194 additional performance improvement and bandwidth savings. When 195 parents are included, this is known as hierarchical caching. 197 o Using rich parenting protocols, redundant parents may be deployed 198 such that a failure in a primary parent is detected and a backup 199 is used instead. 201 o Using similar parenting protocols, requests may be partitioned 202 such that requests for certain content domains are sent to a 203 specific primary parent. This can help to maximize the efficient 204 use of caching proxy resources. 206 The following diagram depicts a hierarchical cache deployment as 207 described above: 209 ^ ^ 210 | | requests to 211 | | origin servers 212 | | 213 -------- -------- 214 |parent| |parent| 215 |cache | |cache | 216 |proxy | |proxy | 217 -------- -------- 218 ^ ^ 219 requests for \ / requests for 220 foo.com \ / bar.com 221 content \ / content 222 \ / 223 ------- ------- ------- ------- 224 |edge | |edge | |edge | |edge | 225 |cache| |cache| |cache| |cache| 226 |proxy| |proxy| |proxy| |proxy| 227 ------- ------- ------- ------- 228 ^ 229 | all content 230 | requests 231 | for this 232 | client 233 | 234 -------- 235 |client| 236 -------- 238 Note that this diagram shows only one possible configuration, but 239 many others are also useful. In particular, the client may be able 240 to communicate directly with multiple caching proxies. RFC 3040 [3] 241 contains additional examples of how multiple caching proxies may be 242 used. 244 2.3 Server Farms 246 Another type of content network that has been in widespread use for 247 several years is a server farm. A typical server farm makes use of a 248 so-called "intelligent" or "content" switch (i.e. one that uses 249 information in OSI layers 4-7). The switch examines content requests 250 and dispatches them among a (potentially large) group of servers. 252 Some of the goals of a server farm include: 254 o Creating the impression that the group of servers is actually a 255 single origin site. 257 o Load-balancing of requests across all servers in the group. 259 o Automatic routing of requests away from servers that fail. 261 o Routing all requests for a particular user agent's session to the 262 same server, in order to preserve session state. 264 The following diagram depicts a simple server farm deployment: 266 --------- --------- --------- --------- 267 |content| |content| |content| |content| 268 |server | |server | |server | |server | 269 | | | | | | | | 270 --------- --------- --------- --------- 271 ^ ^ 272 request from \ / request from 273 client A \ / client B 274 \ / 275 ------------- 276 | L4-L7 | 277 | switch | 278 ------------- 279 ^ ^ 280 / \ 281 / \ 282 / \ 283 request from request from 284 client A client B 286 A similar style of content network (that is, deployed close to 287 servers) may be constructed with surrogates [3] instead of a switch. 289 2.4 Content Distribution Networks 291 Both hierarchical caching and server farms are useful techniques, but 292 have limits. Server farms can improve the scalability of the origin 293 server. However, since the multiple servers and other elements are 294 typically deployed near the origin server, they do little to improve 295 performance problems that are due to network congestion. Caching 296 proxies can improve performance problems due to network congestion 297 (since they are situated near the clients) but they cache objects 298 based on client demand. Caching based on client demand performs 299 poorly if the requests for a given object, while numerous in 300 aggregate, are spread thinly among many different caching proxies. 301 (In the worst case, an object could be requested n times via n 302 distinct caching proxies, causing n distinct requests to the origin 303 server -- or exactly the same behavior that would occur without any 304 caching proxies in place.) 305 Thus, a content provider with a popular content source can find that 306 it has to invest in large server farms, load balancing, and high- 307 bandwidth connections to keep up with demand. Even with those 308 investments, the user experience may still be relatively poor due to 309 congestion in the network as a whole. 311 To address these limitations, another type of content network that 312 has been deployed in increasing numbers in recent years is the CDN 313 (Content Distribution Network or Content Delivery Network). A CDN 314 essentially moves server-farm-like configurations out into network 315 locations more typically occupied by caching proxies. A CDN has 316 multiple replicas of each content item being hosted. A request from 317 a browser for a single content item is directed to a "good" replica, 318 where "good" usually means that the item is served to the client 319 quickly compared to the time it would take fetch it from the origin 320 server, with appropriate integrity and consistency. Static 321 information about geographic locations and network connectivity is 322 usually not sufficient to do a good job of choosing a replica. 323 Instead, a CDN typically incorporates dynamic information about 324 network conditions and load on the replicas, directing requests so as 325 to balance the load. 327 Compared to using servers and surrogates in a single data center, a 328 CDN is a relatively complex system encompassing multiple points of 329 presence, in locations that may be geographically far apart. 330 Operating a CDN is not easy for a content provider, since a content 331 provider wants to focus its resources on developing high-value 332 content, not on managing network infrastructure. Instead, a more 333 typical arrangement is that a network service provider builds and 334 operates a CDN, offering a content distribution service to a number 335 of content providers. 337 A CDN enables a service provider to act on behalf of the content 338 provider to deliver copies of origin server content to clients from 339 multiple diverse locations. The increase in number and diversity of 340 location is intended to improve download times and thus improve the 341 user experience. A CDN has some combination of a content-delivery 342 infrastructure, a request-routing infrastructure, a distribution 343 infrastructure, and an accounting infrastructure. The content- 344 delivery infrastructure consists of a set of "surrogate" servers [3] 345 that deliver copies of content to sets of users. The request-routing 346 infrastructure consists of mechanisms that move a client toward a 347 rendezvous with a surrogate. The distribution infrastructure 348 consists of mechanisms that move content from the origin server to 349 the surrogates. Finally, the accounting infrastructure tracks and 350 collects data on request-routing, distribution, and delivery 351 functions within the CDN. 353 The following diagram depicts a simple CDN as described above: 355 ---------- ---------- 356 |request-| |request-| 357 |routing | |routing | 358 | system | | system | 359 ---------- ---------- 360 ^ | 361 (1) client's | | (2) response 362 content | | indicating 363 request | | location of ----------- 364 | | content |surrogate| 365 | | ----------- 366 ----------- | | 367 |surrogate| | | ----------- 368 ----------- | | |surrogate| 369 | | ----------- 370 | | ^ 371 | v / (3) client opens 372 client--- connection to 373 retrieve content 375 2.4.1 Historic Evolution of CDNs 377 The first important use of CDNs was for the distribution of heavily- 378 requested graphic files (such as GIF files on the home pages of 379 popular servers). However, both in principle and increasingly in 380 practice, a CDN can support the delivery of any digital content -- 381 including various forms of streaming media. For a streaming media 382 CDN (or media distribution network or MDN), the surrogates may be 383 operating as splitters (serving out multiple copies of a stream). 384 The splitter function may be instead of, or in addition to, a role as 385 a caching proxy. However, the basic elements defined in this model 386 are still intended to apply to the interconnection of content 387 networks that are distributing streaming media. 389 2.4.2 Describing CDN Value: Reach and Scale 391 There are two fundamental elements that give a CDN value: outsourcing 392 infrastructure and improved content delivery. A CDN allows multiple 393 surrogates to act on behalf of an orgin server, therefore removing 394 the delivery of content from a centralized site to multiple and 395 (usually) highly distributed sites. We refer to increased aggregate 396 infrastructure size as "scale." In addition, a CDN can be constructed 397 with copies of content near to end users, overcoming issues of 398 network size, network congestion, and network failures. We refer to 399 increased diversity of content locations as "reach." 400 In a typical (non-internetworked) CDN, a single service provider 401 operates the request-routers, the surrogates, and the content 402 distributors. In addition, that service provider establishes 403 (business) relationships with content publishers and acts on behalf 404 of their origin sites to provide a distributed delivery system. The 405 value of that CDN to a content provider is a combination of its scale 406 and its reach. 408 3. Content Network Model Terms 410 This section consists of the definitions of a number of terms used to 411 refer to roles, participants, and objects involved in content 412 networks. Although the following uses many terms that are based on 413 those used in RFC 2616 [1] or RFC 3040 [3], there is no necessary 414 connection to HTTP or web caching technology. Content 415 internetworking and this vocabulary are applicable to other protocols 416 and styles of content delivery. 418 Phrases in upper-case refer to other defined terms. 420 ACCOUNTING 421 Measurement and recording of DISTRIBUTION and DELIVERY activities, 422 especially when the information recorded is ultimately used as a 423 basis for the subsequent transfer of money, goods, or obligations. 425 ACCOUNTING SYSTEM 426 A collection of CONTENT NETWORK ELEMENTS that supports ACCOUNTING 427 for a single CONTENT NETWORK. 429 AUTHORITATIVE REQUEST-ROUTING SYSTEM 430 The REQUEST-ROUTING SYSTEM that is the correct/final authority for 431 a particular item of CONTENT. 433 CDN 434 Content Delivery Network or Content Distribution Network. A type 435 of CONTENT NETWORK in which the CONTENT NETWORK ELEMENTS are 436 arranged for more effective delivery of CONTENT to CLIENTS. 437 Typically a CDN consists of a REQUEST-ROUTING SYSTEM, SURROGATES, 438 a DISTRIBUTION SYSTEM, and an ACCOUNTING SYSTEM. 440 CLIENT 441 A program that sends CONTENT REQUESTS and receives corresponding 442 CONTENT RESPONSES. [Note: this is similar to the definition in 443 RFC 2616 [1] but we do not require establishment of a connection.] 445 CONTENT 446 Any form of digital data, CONTENT approximately corresponds to 447 what is referred to as an "entity" in RFC 2616 [1]. One important 448 form of CONTENT with additional constraints on DISTRIBUTION and 449 DELIVERY is CONTINUOUS MEDIA. 451 CONTENT NETWORK 452 An arrangement of CONTENT NETWORK ELEMENTS, controlled by a common 453 management in some fashion. 455 CONTENT NETWORK ELEMENT 456 A network device that performs at least some of its processing by 457 examining CONTENT-related parts of network messages. In IP-based 458 networks, a CONTENT NETWORK ELEMENT is a device whose processing 459 depends on examining information contained in IP packet bodies; 460 network elements (as defined in RFC 3040) examine only the header 461 of an IP packet. Note that many CONTENT NETWORK ELEMENTS do not 462 examine or even see individual IP packets, instead receiving the 463 body of one or more packets assembled into a message of some 464 higher-level protocol. 466 CONTENT REQUEST 467 A message identifying a particular item of CONTENT to be 468 delivered. 470 CONTENT RESPONSE 471 A message containing a particular item of CONTENT, identified in a 472 previous CONTENT REQUEST. 474 CONTENT SIGNAL 475 A message delivered through a DISTRIBUTION SYSTEM that specifies 476 information about an item of CONTENT. For example, a CONTENT 477 SIGNAL can indicate that the ORIGIN has a new version of some 478 piece of CONTENT. 480 CONTINUOUS MEDIA 481 CONTENT where there is a timing relationship between source and 482 sink; that is, the sink must reproduce the timing relationship 483 that existed at the source. The most common examples of 484 CONTINUOUS MEDIA are audio and motion video. CONTINUOUS MEDIA can 485 be real-time (interactive), where there is a "tight" timing 486 relationship between source and sink, or streaming (playback), 487 where the relationship is less strict. [Note: This definition is 488 essentially identical to the definition of continuous media in 489 [2]] 491 DELIVERY 492 The activity of providing a PUBLISHER's CONTENT, via CONTENT 493 RESPONSES, to a CLIENT. Contrast with DISTRIBUTION and REQUEST- 494 ROUTING. 496 DISTRIBUTION 497 The activity of moving a PUBLISHER's CONTENT from its ORIGIN to 498 one or more SURROGATEs. DISTRIBUTION can happen either in 499 anticipation of a SURROGATE receiving a REQUEST (pre-positioning) 500 or in response to a SURROGATE receiving a REQUEST (fetching on 501 demand). Contrast with DELIVERY and REQUEST-ROUTING. 503 DISTRIBUTION SYSTEM 504 A collection of CONTENT NETWORK ELEMENTS that support DISTRIBUTION 505 for a single CONTENT NETWORK. The DISTRIBUTION SYSTEM also 506 propagates CONTENT SIGNALs. 508 ORIGIN 509 The point at which CONTENT first enters a DISTRIBUTION SYSTEM. 510 The ORIGIN for any item of CONTENT is the server or set of servers 511 at the "core" of the distribution, holding the "master" or 512 "authoritative" copy of that CONTENT. [Note: We believe this 513 definition is compatible with that for "origin server" in RFC 2616 514 [1] but includes additional constraints useful for CDI.] 516 PUBLISHER 517 The party that ultimately controls the CONTENT and its 518 distribution. 520 REACHABLE SURROGATES 521 The collection of SURROGATES that can be contacted via a 522 particular DISTRIBUTION SYSTEM or REQUEST-ROUTING SYSTEM. 524 REQUEST-ROUTING 525 The activity of steering or directing a CONTENT REQUEST from a 526 USER AGENT to a suitable SURROGATE. 528 REQUEST-ROUTING SYSTEM 529 A collection of CONTENT NETWORK ELEMENTS that support REQUEST- 530 ROUTING for a single CONTENT NETWORK. 532 SERVER 533 A program that accepts CONTENT REQUESTS and services them by 534 sending back CONTENT RESPONSES. Any given program may be capable 535 of being both a client and a server; our use of these terms refers 536 only to the role being performed by the program. [Note: this is 537 adapted from a similar definition in RFC 2616 [1].] 539 SURROGATE 540 A delivery server, other than the ORIGIN. Receives a CONTENT 541 REQUEST and delivers the corresponding CONTENT RESPONSE. [Note: 542 this is a different definition from that in RFC 3040 [3], which 543 appears overly elaborate for our purposes. A "CDI surrogate" is 544 always an "RFC 3040 surrogate"; we are not sure if the reverse is 545 true.] 547 USER AGENT 548 The CLIENT which initiates a REQUEST. These are often browsers, 549 editors, spiders (web-traversing robots), or other end user tools. 550 [Note: this definition is identical to the one in RFC 2616 [1].] 552 4. Content Internetworking 554 There are limits to how large any one network's scale and reach can 555 be. Increasing either scale or reach is ultimately limited by the 556 cost of equipment, the space available for deploying equipment, and/ 557 or the demand for that scale/reach of infrastructure. Sometimes a 558 particular audience is tied to a single service provider or a small 559 set of providers by constraints of technology, economics, or law. 560 Other times, a network provider may be able to manage surrogates and 561 a distribution system, but may have no direct relationship with 562 content providers. Such a provider wants to have a means of 563 affiliating their delivery and distribution infrastructure with other 564 parties who have content to distribute. 566 Content internetworking allows different content networks to share 567 resources so as to provide larger scale and/or reach to each 568 participant than they could otherwise achieve. By using commonly 569 defined protocols for content internetworking, each content network 570 can treat neighboring content networks as "black boxes", allowing 571 them to hide internal details from each other. 573 5. Content Internetworking Model Terms 575 This section consists of the definitions of a number of terms used to 576 refer to roles, participants, and objects involved in internetworking 577 content networks. The purpose of this section is to identify common 578 terms and provide short definitions. A more detailed technical 579 discussion of these terms and their relationships appears in "Content 580 Internetworking Architectural Overview" [4]. 582 ACCOUNTING INTERNETWORKING 583 Interconnection of two or more ACCOUNTING SYSTEMS so as to enable 584 the exchange of information between them. The form of ACCOUNTING 585 INTERNETWORKING required may depend on the nature of the 586 NEGOTIATED RELATIONSHIP between the peering parties -- in 587 particular, on the value of the economic exchanges anticipated. 589 ADVERTISEMENT 590 Information about resources available to other CONTENT NETWORKS, 591 exchanged via CONTENT INTERNETWORKING GATEWAYS. Types of 592 ADVERTISEMENT include AREA ADVERTISEMENTS, CONTENT ADVERTISEMENTS, 593 and DISTRIBUTION ADVERTISEMENTS. 595 AREA ADVERTISEMENT 596 ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM 597 about aspects of topology, geography and performance of a CONTENT 598 NETWORK. Contrast with CONTENT ADVERTISEMENT, DISTRIBUTION 599 ADVERTISEMENT. 601 BILLING ORGANIZATION 602 An entity that operates an ACCOUNTING SYSTEM to support billing 603 within a NEGOTIATED RELATIONSHIP with a PUBLISHER. 605 CONTENT ADVERTISEMENT 606 ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM 607 about the availability of one or more collections of CONTENT on a 608 CONTENT NETWORK. Contrast with AREA ADVERTISEMENT, DISTRIBUTION 609 ADVERTISEMENT 611 CONTENT DESTINATION 612 A CONTENT NETWORK or DISTRIBUTION SYSTEM that is accepting CONTENT 613 from another such network or system. Contrast with CONTENT 614 SOURCE. 616 CONTENT INTERNETWORKING GATEWAY (CIG) 617 An identifiable element or system through which a CONTENT NETWORK 618 can be interconnected with others. A CIG may be the point of 619 contact for DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING 620 INTERNETWORKING, and/or ACCOUNTING INTERNETWORKING, and thus may 621 incorporate some or all of the corresponding systems for the 622 CONTENT NETWORK. 624 CONTENT REPLICATION 625 The movement of CONTENT from a CONTENT SOURCE to a CONTENT 626 DESTINATION. Note that this is specifically the movement of 627 CONTENT from one network to another. There may be similar or 628 different mechanisms that move CONTENT around within a single 629 network's DISTRIBUTION SYSTEM. 631 CONTENT SOURCE 632 A CONTENT NETWORK or DISTRIBUTION SYSTEM that is distributing 633 CONTENT to another such network or system. Contrast with CONTENT 634 DESTINATION. 636 DISTRIBUTION ADVERTISEMENT 637 An ADVERTISEMENT from a CONTENT NETWORK's DISTRIBUTION SYSTEM to 638 potential CONTENT SOURCES, describing the capabilities of one or 639 more CONTENT DESTINATIONS. Contrast with AREA ADVERTISEMENT, 640 CONTENT ADVERTISEMENT. 642 DISTRIBUTION INTERNETWORKING 643 Interconnection of two or more DISTRIBUTION SYSTEMS so as to 644 propagate CONTENT SIGNALS and copies of CONTENT to groups of 645 SURROGATES. 647 INJECTION 648 A "send-only" form of DISTRIBUTION INTERNETWORKING that takes 649 place from an ORIGIN to a CONTENT DESTINATION. 651 INTER- 652 Describes activity that involves more than one CONTENT NETWORK 653 (e.g. INTER-CDN). Contrast with INTRA-. 655 INTRA- 656 Describes activity within a single CONTENT NETWORK (e.g. INTRA- 657 CDN). Contrast with INTER-. 659 NEGOTIATED RELATIONSHIP 660 A relationship whose terms and conditions are partially or 661 completely established outside the context of CONTENT NETWORK 662 internetworking protocols. 664 REMOTE CONTENT NETWORK 665 A CONTENT NETWORK able to deliver CONTENT for a particular REQUEST 666 that is not the AUTHORITATIVE REQUEST-ROUTING SYSTEM for that 667 REQUEST. 669 REQUEST-ROUTING INTERNETWORKING 670 Interconnection of two or more REQUEST-ROUTING SYSTEMS so as to 671 increase the number of REACHABLE SURROGATES for at least one of 672 the interconnected systems. 674 6. Security Considerations 676 There are no security-related issues related to the terms defined in 677 this document. The technology of content internetworking does raise 678 some security-related issues, and a detailed discussion of those 679 issues appears in "Content Internetworking Architectural Overview" 680 [4]. 682 7. Acknowledgements 684 The authors acknowledge the contributions and comments of Fred 685 Douglis (AT&T), Don Gilletti (CacheFlow), Markus Hoffmann (Lucent), 686 Barron Housel (Cisco), Barbara Liskov (Cisco), John Martin (Network 687 Appliance), Nalin Mistry (Nortel Networks) Raj Nair (Cisco), Hilarie 688 Orman (Volera), Doug Potter (Cisco), and Oliver Spatscheck (AT&T). 690 [Note to RFC Editor: The last normative reference is [4], all 691 subsequent references starting with [5] can be deleted.] 693 References 695 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 696 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 697 HTTP/1.1", RFC 2616, June 1999, . 700 [2] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 701 Protocol", RFC 2326, April 1998, . 704 [3] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web 705 Replication and Caching Taxonomy", RFC 3040, June 2000, . 708 [4] Green, M., Cain, B., Tomlinson, G., Thomas, S. and P. Rzewskip, 709 "Content Internetworking Architectural Overview", draft-ietf- 710 cdi-architecture-00.txt (work in progress), February 2002, 711 . 714 [5] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking 715 Scenarios", draft-ietf-cdi-scenarios-00.txt (work in progress), 716 February 2002, . 719 [6] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Content 720 Internetworking (CDI) Authentication, Authorization, and 721 Accounting Requirements", draft-ietf-cdi-aaa-reqs-00.txt (work 722 in progress), Februrary 2002, . 725 [7] Barbir, A., Cain, B., Douglis, F., Green, M., Hoffmann, M., 726 Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request- 727 Routing Mechanisms", draft-ietf-cdi-known-request-routing-00.txt 728 (work in progress), February 2002, . 731 [8] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request- 732 Routing Requirements for Content Internetworking", draft-ietf- 733 cdi-request-routing-reqs-00.txt (work in progress), February 734 2002, . 737 [9] Amini, L., Spatscheck, O. and S. Thomas, "Distribution 738 Requirements for Content Internetworking", draft-ietf-cdi- 739 distribution-reqs-00.txt (work in progress), February 2002, 740 . 743 Authors' Addresses 745 Mark Stuart Day 746 Cisco Systems 747 1414 Massachusetts Avenue 748 Boxborough, MA 01719 749 US 751 Phone: +1 978 936 1089 752 EMail: markday@cisco.com 754 Brad Cain 755 Cereva Networks 756 3 Network Drive 757 Marlborough, MA 01752 758 US 760 Phone: +1 508-787-5000 761 EMail: bcain@cereva.com 763 Gary Tomlinson 764 CacheFlow, Inc. 765 12034 134th Ct. NE Suite 201 766 Redmond, WA 98052 767 US 769 Phone: +1 425 820 3009 770 EMail: garyt@cacheflow.com 772 Phil Rzewski 773 Inktomi 774 4100 East Third Avenue, MS FC2-4 775 Foster City, CA 94404 776 US 778 Phone: +1 650 653 2487 779 EMail: philr@inktomi.com 781 Full Copyright Statement 783 Copyright (C) The Internet Society (2002). All Rights Reserved. 785 This document and translations of it may be copied and furnished to 786 others, and derivative works that comment on or otherwise explain it 787 or assist in its implementation may be prepared, copied, published 788 and distributed, in whole or in part, without restriction of any 789 kind, provided that the above copyright notice and this paragraph are 790 included on all such copies and derivative works. However, this 791 document itself may not be modified in any way, such as by removing 792 the copyright notice or references to the Internet Society or other 793 Internet organizations, except as needed for the purpose of 794 developing Internet standards in which case the procedures for 795 copyrights defined in the Internet Standards process must be 796 followed, or as required to translate it into languages other than 797 English. 799 The limited permissions granted above are perpetual and will not be 800 revoked by the Internet Society or its successors or assigns. 802 This document and the information contained herein is provided on an 803 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 804 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 805 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 806 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 807 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Acknowledgement 811 Funding for the RFC Editor function is currently provided by the 812 Internet Society.