idnits 2.17.1 draft-ietf-cdi-distribution-reqs-01.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 a Security Considerations section. ** 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 an Authors' Addresses Section. 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 (December 2002) is 7796 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) -- Missing reference section? '3' on line 54 looks like a reference -- Missing reference section? '6' on line 97 looks like a reference -- Missing reference section? '7' on line 97 looks like a reference -- Missing reference section? '2' on line 104 looks like a reference -- Missing reference section? '8' on line 106 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Amini 2 Internet-Draft IBM Research 3 Expires: June 23, 2003 S. Thomas 4 TransNexus, Inc 5 O. Spatscheck 6 AT&T Labs 7 December 2002 9 Distribution Requirements for Content Internetworking 10 draft-ietf-cdi-distribution-reqs-01 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 23, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This document specifies requirements for interconnecting, or 42 peering, the distribution systems of Content Networks (CN). 43 Distribution internetworking requires advertising the capabilities 44 of a CN offering distribution services, moving content from one CN 45 to another, and signaling requirements for consistent storage and 46 delivery of content. This document does not address requirements for 47 directing user agents to distributed content, nor for aggregating 48 access information for distributed content. 50 1. Introduction 52 Content Internetworking (CI) assumes an architecture wherein the 53 resources of multiple CNs are combined so as to achieve a larger 54 scale or reach than any of the component CNs could individually [3]. 55 A Content Distribution Network (CDN) is an example of a CN. 57 At the core of CI are three principal architectural elements. These 58 elements are Request Routing, the Distribution and the Accounting. 59 The focus of this document, the Internetworking Distribution 60 Systems, is responsible for moving content from one Distribution CN 61 to another Distribution CN. Note that the original content provider 62 is considered a degenerate case of a Distribution CN. 64 In any Distribution Internetworking arrangement, the relationships 65 between Distribution CNs can always be decomposed into one or more 66 pairs of CNs. Each CN pair comprises one CN which has, or has access 67 to, content, and another CN which has, or has access to, systems 68 capable of providing distribution and/or delivery functions for 69 content. The former CN is referred to as the Content Source, while 70 the latter is referred to as the Content Destination. 72 This document describes the overall architectural structure and 73 building blocks of the internetworked Distribution Systems. It also 74 defines the protocol requirements for interconnecting two or more 75 Distribution CNs via their respective Content Internetworking 76 Gateways (CIG). Specifically, it defines the requirements for: 78 Distribution Advertising: announcing the distribution 79 capabilities of a Content Destination to potential Content 80 Sources. 82 Content Signaling: communicating content meta-data to enable 83 consistent storage and delivery of content to user agents. 85 Content Replication: moving content from a Content Source to a 86 Content Destination. 88 Although this document does not specifically address requirements 89 for communicating within a CN, it is plausible that protocols 90 developed to meet inter-CN requirements may also be well-suited for 91 intra-CN communications. 93 Requirements for the remaining CI architectural elements, the 94 Request Routing System, which is responsible for directing user 95 agents to the distributed content, and the Accounting System, which 96 is responsible for aggregating information related to the access of 97 distributed content, are detailed in [6], [7]. 99 1.1 Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in RFC-2119 [2]. 105 All other terms in ALL CAPS, except those qualified with explicit 106 citations, are defined in [8]. 108 1.2 Change Log 110 1. Fixed terminology to comply with updated Models doc. 112 2. Intro: fixed reach or scale so not synonyms 114 3. Section 1: clarified definition for Content Signaling 116 4. Section 2: clarified that fig 1 is a logical view, need not have 117 this strictly hierarchical relationship. 119 5. Section 2.1-2.2: deleted these sections, feedback indicated they 120 confused more than claried; material is adequately covered in 121 Models doc. 123 6. Section 3: change Use-initiated to surrogate initiated. 125 7. Section 3 (para 2): cig is not necessarily a box, could be 126 functionality (protocol conformance) implemented in multiple 127 boxes. 129 8. Section 4.1: clarified content signalling example. 131 9. Section 4.3: clarified common base replication vs. content type 132 specific replication 134 10. Section 4.4: fixed "extensible model..." wording 136 11. Section 5.1: clarified that content pull for delivery services 137 preparation is optional. 139 12. Section 5.3 3-4: modified, added request for feedback 141 13. Section 5.3.5: clarified advertisements as optional 143 14. Section 5.4: dropped requirement for sending data with content 144 signal. 146 15. Section 5.4 6: dropped part about source encryption -- if the 147 object is encrypted at source and not decrypted until it 148 reaches the client, then it is just a (downloadable) blob as 149 far as the dist system is concerned. 151 16. Section 5.5 8: dropped subscription fee and next hop. 153 17. Section 5.5 8: changed content id to content set id. 155 18. Section 5.5: added information on relationship to WEBI/RUP. 157 2. Distribution System Overview 159 In Distribution System Internetworking, even the most complex 160 communication arrangements can be expressed in terms of simple 161 interactions between a Content Source and a Content Destination. 162 Figure 1, for example, shows a relationship between four different 163 administrative authorities. CN A operates a network of SURROGATES, 164 and "CN D" (actually the original content provider, or ORIGIN) has 165 content to be distributed. CN A communicates with CN B, which 166 communications with CN C, which, in turn, communicates with CN D. 168 +------------+ +-----------+ +-----------+ +------------+ 169 | CN A | | CN B | | CN C | | "CN D" | 170 |(SURROGATES)|<->| (agent |<->| (agent |<->| (ORIGIN) | 171 | | | for A) | | for D) | | | 172 +------------+ +-----------+ +-----------+ +------------+ 174 CONTENT DST <-> CONTENT SRC 175 CONTENT DST <-> CONTENT SRC 176 CONTENT DST <-> CONTENT SRC 178 Figure 1: Distribution System Interworking 180 In each case, one of the parties in the communications has the role 181 of Content Destination, while the other party is the Content Source. 182 Note that a particular CN's role may change, depending on the party 183 with whom it is communicating. CN B, for example, is a Content 184 Source when communicating with CN A, but a Content Destination when 185 communicating with CN C. 187 Note that a Content Destination which peers directly with the 188 Content ORIGIN, will interface with the ORIGIN just as it interfaces 189 with any other Content Source. 191 Although Figure 1 provides an example of multiple CNs peered in 192 series, a Distribution CN may serve as the Content Source for 193 multiple Content Destinations. Likewise, a Distribution CN may 194 serve as the Content Destination for multiple Content Sources. 196 Additionally, it is possible for the internetworking relationship 197 between a single Source-Destination pair to be reciprocal for 198 different content sets. That is, CN A may request distribution 199 services from CN B for Content Set A, while CN B requests 200 distribution services from CN A for Content Set B. 202 Further, note that Figure 1 is a logical view of the internetworking 203 relationship between several Content Source-Destination pairs; 204 actual communications are not restricted to this pair-wise 205 hierarchy. For example, CDN D may specify a single authoritative 206 distribution channel from which any distributing CN must retrieve 207 the CONTENT. 209 3. Replication Models 211 Replication of content may take place using a push model, or a pull 212 model, or a combination of both. 214 o SURROGATE-initiated replication of CONTENT, where a SURROGATE 215 retrieves CONTENT based on a cache miss or on a prefetching 216 policy specified at the SURROGATE, represents the pull model. 217 This is the model currently used by caching proxies. 219 o ORIGIN-initiated replication of CONTENT to SURROGATEs represents 220 the push model. This model is used to preposition CONTENT in 221 anticipation of demand. 223 Replication, when between the administrative domains of different 224 Distribution CNs must adhere to the CI protocol for content 225 replicaiton. Replication within a single Distribution CN is an 226 intra-CN communication and therefore, need not adhear to CI 227 protocols. Further, the replication model used within a single 228 Distribution CN need not be the same as the model used to replicate 229 CONTENT between CNs. 231 For both ORIGIN- and SURROGATE- initiated replication, the Content 232 Source may use replication mechanisms beyond a simple transfer. For 233 example, it may be desirable to have the Content Destination join a 234 multicast channel on which a set of content is pushed to all 235 SURROGATES. 237 Another example is for CONTINUOUS MEDIA. In the case of live 238 broadcasts, the data need not be cached on the SURROGATES. Instead, 239 replication takes the form of "splitting" the live stream at various 240 points in the network. Splitting is also referred to as application 241 layer multicast. 243 Replication of CONTINUOUS MEDIA streams which are not live, and 244 therefore may be stored on SURROGATES, also benefits from mechanisms 245 beyond in-line replication. For example, CONTINUOUS MEDIA is often 246 delivered to CLIENTS over an unreliable channel. However, a CN 247 distributing this content to many CLIENTS should work with a full 248 replica. Existing proprietary replication protocols enable 249 distribution of CONTINUOUS MEDIA objects in which a full or partial 250 replica can be propagated, the data may be encrypted and/or 251 authenticated, and the SURROGATE can support CONTINUOUS 252 MEDIA-related services such as random access and stream 253 insertion/splicing. 255 It may be desirable to replicate content to a Distribution CN which 256 has no internal SURROGATES. For example, a Distribution CN may have 257 servers at key exchange points within the network which only serve 258 content to other distribution systems, and peer with other CNs which 259 provide SURROGATES which deliver content to CLIENTS. 261 4. Distribution Internetworking Requirements 263 This section details general requirements for exchange of 264 inter-domain distribution information. 266 4.1 General Requirements 268 The goal of the Distribution Internetworking is to interconnect the 269 Distribution Systems of multiple CNs. The intent of this 270 interconnection is to effectively position content for fast, 271 reliable access by CLIENTs. Generally this is accomplished by 272 replicating content on SURROGATEs. While the communications path 273 from ORIGIN to CLIENTs may traverse a number of links, some within a 274 Distribution CN and some between Distribution CNs, Distribution 275 Internetworking is concerned only with those communications between 276 Distribution CNs. 278 The three main components of Distribution Internetworking are 279 advertising, replication, and signaling. 281 Advertising: Distribution CNs MAY advertise their capabilities to 282 potential Content Source CNs. 284 Replication: Distribution CNs MUST be able to move content from a 285 Content Source to a Content Destination. 287 Content signaling: Distribution CNs MUST be able to propagate 288 content meta-data. This meta-data includes information such as 289 the immediate invalidation of content or a change in the source 290 or distribution method of content. 292 Note that these requirements do not necessarily translate directly 293 into three distinct Distribution Internetworking protocols. 295 4.2 Advertising Requirements 297 The following list specifies requirements to enable advertising of 298 distribution capabilities. 300 1. A common protocol for the Advertisement of distribution 301 capabilities. 303 2. A common format for the actual distribution capabilities 304 Advertisements in the protocol. 306 3. Security mechanisms. 308 4.3 Replication Requirements 310 The following list specifies requirements to enable content 311 replication. 313 1. A common base protocol for the replication of content. 315 2. This common base protocol should specify: 317 * a common format for the actual content data in the protocol. 319 * A common format for the content meta-data in the protocol. 321 3. Alternate content-specific protocols for the replication of 322 content should be enabled. The replication protocol for a 323 particular content set is specified via content signaling. 325 4. Scalable distribution of the content. 327 5. Security mechanisms. 329 4.4 Content Signaling Requirements 331 The following list specifies requirements to enable content 332 signaling. 334 1. A common protocol for signaling content meta-data. 336 2. An extenisble format for communicating content metadata. 337 Minimally, support is required for "add," "withdraw," and 338 "expiration time update." 340 3. Scalable distribution of signals on a scale to enable 341 Internet-wide peering. 343 4. Security mechanisms. 345 5. Distribution Internetworking Protocol Requirements 347 This section defines protocol requirements for each of the 348 advertising, replication and content signaling components of 349 Distribution Internetworking. Note that these requirements do not 350 necessarily translate directly into either one converged or three 351 distinct Distribution Internetworking protocols. 353 5.1 Overview of Distribution Internetworking Flow 355 In a Distribution Internetworking arrangement, the following 356 sequence of events is expected: 358 1. A Content Source may receive distribution capabilities 359 advertisements from one or more Content Destinations. A Content 360 Source may or may not require receipt of distribution 361 capabilities advertisements prior to requesting services. For 362 example, a Content Source may request services based on a 363 contractual agreement negotiated off-line. 365 2. The Content Source will make a decision to request content 366 distribution services from a Content Destination. 368 3. The Content Source will send a content signal requesting 369 distribution services. 371 4. The Content Destination will accept or reject the request; no 372 partial acceptance or negotiation is defined. 374 * If the request is rejected, the error code SHOULD provide 375 enough information for the Content Source to determine if it 376 should send a request with modified service requirements. 378 * If the request is accepted, the Content Destination will 379 prepare for distribution services. Generally, this 380 preparation will entail: 382 + optionally retrieving a copy of the object(s), 384 + joining the content update channel (if any), and 386 + preparing to provide access information to the Accounting 387 System 389 * Each of the above steps are according to the Content Source's 390 specification, and to the Content Destination's policies and 391 configuration. 393 5. Once the Content Destination is prepared, it will notify the 394 Request Routing System of the content's availability. 396 6. The Content Destination will terminate service on first 397 occurrence of either: 399 * the time frame specified in the Content Source's request for 400 distribution services expires or 402 * a content signal requesting withdrawal of the content is 403 received. 405 5.2 General Distribution Internetworking Protocol Requirements 407 Protocols must be scalable, i.e., support Distribution 408 Internetworking on an Internet-wide scale. 410 Protocols must prevent looping of advertisements, replication and 411 content signaling. 413 Protocols must support the ability to optionally conduct 414 authenticated and/or encrypted exchanges. 416 Protocols must support the ability to optionally exchange 417 credentials. 419 5.3 Advertising Protocol Requirements 421 1. Distribution Internetworking protocols MUST enable a Content 422 Destination to advertise the capabilities of its distribution 423 service in a common format. This common format for distribution 424 service capabilities will be referred to as a Service Profile 425 for the remainder of this draft. 427 2. The advertisement protocol must be extensible with the 428 restriction that implementation-specific capabilities may be 429 safely ignored by Content Source. 431 3. Distribution Internetworking protocols MUST provide 432 low-overhead, mechanism to notify in-line elements (e.g., 433 proxies) of CI support. 435 4. [ Editor's Note: prev item can be as simple has having the 436 Content Source include a reference to it's CIG so that inline 437 systems could contact the CIG and establish an internetworking 438 arrangement. But the feedback has been lukewarm to bad -- 439 drop? ] 441 5. Distribution Advertising by a Content Destination must be 442 optional. That is, a Content Source may not require real-time 443 advertisement of distribution capabilities in order to 444 establish a Distribution Internetworking arrangement. 445 Distribution capabilities may be communicated via 446 Advertisements or some other agreed upon mechanism such as an 447 off-line contract negotiated between the parties. 449 6. Advertised capabilities are those available to the peer, 450 potentially based on some off-line contractual agreement, and 451 may not necessarily reflect the total capacity of the Content 452 Destination. 454 7. The protocol MUST enable a Content Destination to advertise 455 multiple service profiles. Each service profile MUST be 456 specifiable by a profile identifier. The profile identifier 457 MAY encode Content Source or Content Destination specific 458 information, but it has local significance only (i.e., it is 459 strictly between the Content Source and Content Destination). 461 8. The protocol MUST enable a Content Destination to advertise 462 multiple services profiles to the same or different potential 463 Content Sources. 465 9. A Content Destination with regional capabilities SHOULD 466 advertise capabilities on a per region basis. A Content 467 Destination which advertises regional capabilities MUST 468 minimally be able to identify regions by network 469 addresses/prefixes. 471 10. By default, advertisements are advisory. A Content Destination 472 SHOULD be able to specify whether the capabilities are advisory 473 or binding. 475 11. The protocol MUST provide the ability to specify distribution 476 capabilities in terms of one or more of the following 477 attributes: 479 Profile ID: Identifier for the service profile being 480 advertised. The profile identifier is to be used by the 481 Content Source when requesting service. This attribute is 482 required for all advertisements. The value need not be 483 unique across Distribution CNs, and may be used in 484 advertisements to multiple Content Sources. 486 FootPrint: The areas served by the CN. Minimally, a Content 487 Destination should support expressing footprint according to 488 IP network addresses/prefixes. 490 Content Type: The type of content (e.g. static Web pages, 491 streaming media, etc.) that the CN is able to distribute. 493 Capacity: The storage capacity that the CN can provide. 495 Bandwidth: Maximum outbound bandwidth available from the CN. 497 Object Bandwidth: Maximum outbound bandwidth supported for a 498 single object. 500 Distribution Method: The distribution methods that the CN 501 supports; one or more of push, pull, and alm. "alm" refers 502 to application layer multicast, or splitting, of CONTINUOUS 503 MEDIA; if specified, supported protocols must also be 504 specified. 506 [ Editor's Note: Specifying support for splitting 507 requires refinement. ] 509 Request Routing Type: Type(s) of request routing supported for 510 CI Request Routing Systems. 512 Accounting System Format: Supported protocol(s) and format(s) 513 for sending accounting and access feedback to a specified CI 514 Accounting System. 516 Time Frame: Time frame for which this advertisement is valid. 518 Client Protocols: Indicates the client protocols supported. 519 Currently only HTTP and RTSP are valid. However, this field 520 must be further qualified than just the transport or 521 signalling protocol. The protocol must clearly define a 522 level of support implicated by a given Client Protocol 523 value. 525 Distribution Fee: Indicates the fee charged for distribution 526 services. The value may be expressed in Mbps 527 (megabits/second) or in MB (megabytes of storage). 529 Advertisement Type: Indicates whether the advertisement is 530 advisory or binding. By default, all advertisements are 531 advisory. 533 Private Extensions: Additional metrics that the communicating 534 parties may agree to use, but are not part of the IETF 535 standard. Extensions must be defined such that if not 536 understood by the Content Source, they can be safely 537 ignored. 539 5.3.1 Advertising Examples 541 To be provided. 543 5.4 Replication Protocol Requirements 545 1. A common (base) replication protocol MUST be defined which is 546 supported by all CIGs, for any content type which can be used to 547 transport meta-data and a full replica of content data. 549 2. Replication MUST support the ability for a Content Source to 550 specify a replication channel from which content may be 551 retrieved. 553 1. [ Editors Note: I am using channel as a generic term which 554 would provide a contact point and protocol, and any 555 additional info required to establish a connection. E.g. 556 wcips://invalidation.com/content_set for signaling; will 557 provide clarification later ] 559 3. Replication MUST enable specifying optionally supported, 560 alternative replication protocols which may be better suited 561 than the common base protocol for specific content types or 562 configuration scenarios. 564 4. A Content Source SHOULD be able to specify an authoritative 565 source for content as well as distribution points. 567 5. The protocol MUST enable replication that is secured (encrypted) 568 across the communications channel. 570 5.4.1 Replication Examples 572 To be provided. 574 5.5 Content Signaling Protocol Requirements 576 1. A Content Source MUST be able to request distribution services 577 for one or more content objects. 579 2. A Content Destination MUST explicitly accept or reject a request 580 for distribution services. 582 3. A Content Source MUST be able to withdraw (cancel) a request for 583 content services for one or multiple content objects. 585 4. Rejected requests for distribution services MUST include error 586 codes. Partial rejections or negotiations are not supported. A 587 Content Source may follow a rejection with a request for 588 distribution services under alternate service requirements. 590 5. A Content Source MUST be able to signal consistency meta-data. 591 Minimally, Content Sources SHOULD support weak consistency 592 mechanisms. Content Sources MAY support mechanisms for strong 593 consistency. 595 6. Content signaling SHOULD include mechanisms to aggregate content 596 information. 598 7. Content Signaling SHOULD be decoupled from the content ORIGIN. 599 I.e., a Content Source should be able to specify a content 600 signaling channel. 602 8. The following attributes are defined for content signals: 604 Content Set ID: A unique identifier for this specific content 605 set, so that future references (e.g. to modify the content or 606 to withdraw it from distribution) may be resolved. This value 607 can also be used to avoid loops. The Content Set ID MUST be 608 global and unique, i.e., a given content set MUST have the 609 same ID across all Distribution Systems, and this ID MUST be 610 unique across *all* Distribution Systems. 612 URI: The uniform resource identifier for the content. It 613 identifies how CLIENTS will request delivery services from 614 the Distribution CN. This attr