idnits 2.17.1 draft-amini-cdi-distribution-reqs-02.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 (March 2001) is 8443 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '1' is defined on line 798, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 807, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 810, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 824, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Amini 3 Internet-Draft IBM Research 4 Expires: August 30, 2001 S. Thomas 5 TransNexus, Inc 6 O. Spatscheck 7 AT&T Labs 8 March 2001 10 Distribution Requirements for Content Internetworking 11 draft-amini-cdi-distribution-reqs-02 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 30, 2001. 36 Copyright Notice 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 Abstract 42 This document specifies requirements for interconnecting, or 43 peering, the distribution systems of Content Networks (CN). 44 Distribution internetworking requires advertising the capabilities 45 of a CN offering distribution services, moving content from one CN 46 to another, and signaling requirements for consistent storage and 47 delivery of content. This document does not address requirements for 48 directing user agents to distributed content, nor for aggregating 49 access information for distributed content. 51 1. Introduction 53 Content Internetworking (CI) assumes an architecture wherein the 54 resources of multiple CNs are combined so as to achieve a larger 55 scale or reach than any of the component CNs could individually [3]. 56 A Content Distribution Network (CDN) is an example of a CN. 58 At the core of CI are three principal architectural elements. These 59 elements are Request Routing, the Distribution and the Accounting. 60 The focus of this document, the Internetworking Distribution 61 Systems, is responsible for moving content from one Distribution CN 62 to another Distribution CN. Note that the original content provider 63 is considered a degenerate case of a Distribution CN. 65 In any Distribution Internetworking arrangement, the relationships 66 between Distribution CNs can always be decomposed into one or more 67 pairs of CNs. Each CN pair comprises one CN which has, or has access 68 to, content, and another CN which has, or has access to, systems 69 capable of providing distribution and/or delivery functions for 70 content. The former CN is referred to as the Content Source, while 71 the latter is referred to as the Content Destination. 73 This document describes the overall architectural structure and 74 building blocks of the internetworked Distribution Systems. It also 75 defines the protocol requirements for interconnecting two or more 76 Distribution CNs via their respective Content Internetworking 77 Gateways (CIG). Specifically, it defines the requirements for: 79 Distribution Advertising: announcing the distribution 80 capabilities of a Content Destination to potential Content 81 Sources. 83 Content Signaling: communicating content meta-data to enable 84 consistent storage and delivery of content to user agents. 86 Content Replication: moving content from a Content Source to a 87 Content Destination. 89 Although this document does not specifically address requirements 90 for communicating within a CN, it is plausible that protocols 91 developed to meet inter-CN requirements may also be well-suited for 92 intra-CN communications. 94 Requirements for the remaining CI architectural elements, the 95 Request Routing System, which is responsible for directing user 96 agents to the distributed content, and the Accounting System, which 97 is responsible for aggregating information related to the access of 98 distributed content, are detailed in [6], [7]. 100 1.1 Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in RFC-2119 [2]. 106 All other terms in ALL CAPS, except those qualified with explicit 107 citations, are defined in [8]. 109 1.2 Change Log 111 1. Fixed terminology to comply with updated Models doc. 113 2. Intro: fixed reach or scale so not synonyms 115 3. Section 1: clarified definition for Content Signaling 117 4. Section 2: clarified that fig 1 is a logical view, need not have 118 this strictly hierarchical relationship. 120 5. Section 2.1-2.2: deleted these sections, feedback indicated they 121 confused more than claried; material is adequately covered in 122 Models doc. 124 6. Section 3: change Use-initiated to surrogate initiated. 126 7. Section 3 (para 2): cig is not necessarily a box, could be 127 functionality (protocol conformance) implemented in multiple 128 boxes. 130 8. Section 4.1: clarified content signalling example. 132 9. Section 4.3: clarified common base replication vs. content type 133 specific replication 135 10. Section 4.4: fixed "extensible model..." wording 137 11. Section 5.1: clarified that content pull for delivery services 138 preparation is optional. 140 12. Section 5.3 3-4: modified, added request for feedback 142 13. Section 5.3.5: clarified advertisements as optional 144 14. Section 5.4: dropped requirement for sending data with content 145 signal. 147 15. Section 5.4 6: dropped part about source encryption -- if the 148 object is encrypted at source and not decrypted until it 149 reaches the client, then it is just a (downloadable) blob as 150 far as the dist system is concerned. 152 16. Section 5.5 8: dropped subscription fee and next hop. 154 17. Section 5.5 8: changed content id to content set id. 156 18. Section 5.5: added information on relationship to WEBI/RUP. 158 2. Distribution System Overview 160 In Distribution System Internetworking, even the most complex 161 communication arrangements can be expressed in terms of simple 162 interactions between a Content Source and a Content Destination. 163 Figure 1, for example, shows a relationship between four different 164 administrative authorities. CN A operates a network of SURROGATES, 165 and "CN D" (actually the original content provider, or ORIGIN) has 166 content to be distributed. CN A communicates with CN B, which 167 communications with CN C, which, in turn, communicates with CN D. 169 +------------+ +-----------+ +-----------+ +------------+ 170 | CN A | | CN B | | CN C | | "CN D" | 171 |(SURROGATES)|<->| (agent |<->| (agent |<->| (ORIGIN) | 172 | | | for A) | | for D) | | | 173 +------------+ +-----------+ +-----------+ +------------+ 175 CONTENT DST <-> CONTENT SRC 176 CONTENT DST <-> CONTENT SRC 177 CONTENT DST <-> CONTENT SRC 179 Figure 1: Distribution System Interworking 181 In each case, one of the parties in the communications has the role 182 of Content Destination, while the other party is the Content Source. 183 Note that a particular CN's role may change, depending on the party 184 with whom it is communicating. CN B, for example, is a Content 185 Source when communicating with CN A, but a Content Destination when 186 communicating with CN C. 188 Note that a Content Destination which peers directly with the 189 Content ORIGIN, will interface with the ORIGIN just as it interfaces 190 with any other Content Source. 192 Although Figure 1 provides an example of multiple CNs peered in 193 series, a Distribution CN may serve as the Content Source for 194 multiple Content Destinations. Likewise, a Distribution CN may 195 serve as the Content Destination for multiple Content Sources. 197 Additionally, it is possible for the internetworking relationship 198 between a single Source-Destination pair to be reciprocal for 199 different content sets. That is, CN A may request distribution 200 services from CN B for Content Set A, while CN B requests 201 distribution services from CN A for Content Set B. 203 Further, note that Figure 1 is a logical view of the internetworking 204 relationship between several Content Source-Destination pairs; 205 actual communications are not restricted to this pair-wise 206 hierarchy. For example, CDN D may specify a single authoritative 207 distribution channel from which any distributing CN must retrieve 208 the CONTENT. 210 3. Replication Models 212 Replication of content may take place using a push model, or a pull 213 model, or a combination of both. 215 o SURROGATE-initiated replication of CONTENT, where a SURROGATE 216 retrieves CONTENT based on a cache miss or on a prefetching 217 policy specified at the SURROGATE, represents the pull model. 218 This is the model currently used by caching proxies. 220 o ORIGIN-initiated replication of CONTENT to SURROGATEs represents 221 the push model. This model is used to preposition CONTENT in 222 anticipation of demand. 224 Replication, when between the administrative domains of different 225 Distribution CNs must adhere to the CI protocol for content 226 replicaiton. Replication within a single Distribution CN is an 227 intra-CN communication and therefore, need not adhear to CI 228 protocols. Further, the replication model used within a single 229 Distribution CN need not be the same as the model used to replicate 230 CONTENT between CNs. 232 For both ORIGIN- and SURROGATE- initiated replication, the Content 233 Source may use replication mechanisms beyond a simple transfer. For 234 example, it may be desirable to have the Content Destination join a 235 multicast channel on which a set of content is pushed to all 236 SURROGATES. 238 Another example is for CONTINUOUS MEDIA. In the case of live 239 broadcasts, the data need not be cached on the SURROGATES. Instead, 240 replication takes the form of "splitting" the live stream at various 241 points in the network. Splitting is also referred to as application 242 layer multicast. 244 Replication of CONTINUOUS MEDIA streams which are not live, and 245 therefore may be stored on SURROGATES, also benefits from mechanisms 246 beyond in-line replication. For example, CONTINUOUS MEDIA is often 247 delivered to CLIENTS over an unreliable channel. However, a CN 248 distributing this content to many CLIENTS should work with a full 249 replica. Existing proprietary replication protocols enable 250 distribution of CONTINUOUS MEDIA objects in which a full or partial 251 replica can be propagated, the data may be encrypted and/or 252 authenticated, and the SURROGATE can support CONTINUOUS 253 MEDIA-related services such as random access and stream 254 insertion/splicing. 256 It may be desirable to replicate content to a Distribution CN which 257 has no internal SURROGATES. For example, a Distribution CN may have 258 servers at key exchange points within the network which only serve 259 content to other distribution systems, and peer with other CNs which 260 provide SURROGATES which deliver content to CLIENTS. 262 4. Distribution Internetworking Requirements 264 This section details general requirements for exchange of 265 inter-domain distribution information. 267 4.1 General Requirements 269 The goal of the Distribution Internetworking is to interconnect the 270 Distribution Systems of multiple CNs. The intent of this 271 interconnection is to effectively position content for fast, 272 reliable access by CLIENTs. Generally this is accomplished by 273 replicating content on SURROGATEs. While the communications path 274 from ORIGIN to CLIENTs may traverse a number of links, some within a 275 Distribution CN and some between Distribution CNs, Distribution 276 Internetworking is concerned only with those communications between 277 Distribution CNs. 279 The three main components of Distribution Internetworking are 280 advertising, replication, and signaling. 282 Advertising: Distribution CNs MAY advertise their capabilities to 283 potential Content Source CNs. 285 Replication: Distribution CNs MUST be able to move content from a 286 Content Source to a Content Destination. 288 Content signaling: Distribution CNs MUST be able to propagate 289 content meta-data. This meta-data includes information such as 290 the immediate invalidation of content or a change in the source 291 or distribution method of content. 293 Note that these requirements do not necessarily translate directly 294 into three distinct Distribution Internetworking protocols. 296 4.2 Advertising Requirements 298 The following list specifies requirements to enable advertising of 299 distribution capabilities. 301 1. A common protocol for the Advertisement of distribution 302 capabilities. 304 2. A common format for the actual distribution capabilities 305 Advertisements in the protocol. 307 3. Security mechanisms. 309 4.3 Replication Requirements 311 The following list specifies requirements to enable content 312 replication. 314 1. A common base protocol for the replication of content. 316 2. This common base protocol should specify: 318 * a common format for the actual content data in the protocol. 320 * A common format for the content meta-data in the protocol. 322 3. Alternate content-specific protocols for the replication of 323 content should be enabled. The replication protocol for a 324 particular content set is specified via content signaling. 326 4. Scalable distribution of the content. 328 5. Security mechanisms. 330 4.4 Content Signaling Requirements 332 The following list specifies requirements to enable content 333 signaling. 335 1. A common protocol for signaling content meta-data. 337 2. An extenisble format for communicating content metadata. 338 Minimally, support is required for "add," "withdraw," and 339 "expiration time update." 341 3. Scalable distribution of signals on a scale to enable 342 Internet-wide peering. 344 4. Security mechanisms. 346 5. Distribution Internetworking Protocol Requirements 348 This section defines protocol requirements for each of the 349 advertising, replication and content signaling components of 350 Distribution Internetworking. Note that these requirements do not 351 necessarily translate directly into either one converged or three 352 distinct Distribution Internetworking protocols. 354 5.1 Overview of Distribution Internetworking Flow 356 In a Distribution Internetworking arrangement, the following 357 sequence of events is expected: 359 1. A Content Source may receive distribution capabilities 360 advertisements from one or more Content Destinations. A Content 361 Source may or may not require receipt of distribution 362 capabilities advertisements prior to requesting services. For 363 example, a Content Source may request services based on a 364 contractual agreement negotiated off-line. 366 2. The Content Source will make a decision to request content 367 distribution services from a Content Destination. 369 3. The Content Source will send a content signal requesting 370 distribution services. 372 4. The Content Destination will accept or reject the request; no 373 partial acceptance or negotiation is defined. 375 * If the request is rejected, the error code SHOULD provide 376 enough information for the Content Source to determine if it 377 should send a request with modified service requirements. 379 * If the request is accepted, the Content Destination will 380 prepare for distribution services. Generally, this 381 preparation will entail: 383 + optionally retrieving a copy of the object(s), 385 + joining the content update channel (if any), and 387 + preparing to provide access information to the Accounting 388 System 390 * Each of the above steps are according to the Content Source's 391 specification, and to the Content Destination's policies and 392 configuration. 394 5. Once the Content Destination is prepared, it will notify the 395 Request Routing System of the content's availability. 397 6. The Content Destination will terminate service on first 398 occurrence of either: 400 * the time frame specified in the Content Source's request for 401 distribution services expires or 403 * a content signal requesting withdrawal of the content is 404 received. 406 5.2 General Distribution Internetworking Protocol Requirements 408 Protocols must be scalable, i.e., support Distribution 409 Internetworking on an Internet-wide scale. 411 Protocols must prevent looping of advertisements, replication and 412 content signaling. 414 Protocols must support the ability to optionally conduct 415 authenticated and/or encrypted exchanges. 417 Protocols must support the ability to optionally exchange 418 credentials. 420 5.3 Advertising Protocol Requirements 422 1. Distribution Internetworking protocols MUST enable a Content 423 Destination to advertise the capabilities of its distribution 424 service in a common format. This common format for distribution 425 service capabilities will be referred to as a Service Profile 426 for the remainder of this draft. 428 2. The advertisement protocol must be extensible with the 429 restriction that implementation-specific capabilities may be 430 safely ignored by Content Source. 432 3. Distribution Internetworking protocols MUST provide 433 low-overhead, mechanism to notify in-line elements (e.g., 434 proxies) of CI support. 436 4. [ Editor's Note: prev item can be as simple has having the 437 Content Source include a reference to it's CIG so that inline 438 systems could contact the CIG and establish an internetworking 439 arrangement. But the feedback has been lukewarm to bad -- 440 drop? ] 442 5. Distribution Advertising by a Content Destination must be 443 optional. That is, a Content Source may not require real-time 444 advertisement of distribution capabilities in order to 445 establish a Distribution Internetworking arrangement. 446 Distribution capabilities may be communicated via 447 Advertisements or some other agreed upon mechanism such as an 448 off-line contract negotiated between the parties. 450 6. Advertised capabilities are those available to the peer, 451 potentially based on some off-line contractual agreement, and 452 may not necessarily reflect the total capacity of the Content 453 Destination. 455 7. The protocol MUST enable a Content Destination to advertise 456 multiple service profiles. Each service profile MUST be 457 specifiable by a profile identifier. The profile identifier 458 MAY encode Content Source or Content Destination specific 459 information, but it has local significance only (i.e., it is 460 strictly between the Content Source and Content Destination). 462 8. The protocol MUST enable a Content Destination to advertise 463 multiple services profiles to the same or different potential 464 Content Sources. 466 9. A Content Destination with regional capabilities SHOULD 467 advertise capabilities on a per region basis. A Content 468 Destination which advertises regional capabilities MUST 469 minimally be able to identify regions by network 470 addresses/prefixes. 472 10. By default, advertisements are advisory. A Content Destination 473 SHOULD be able to specify whether the capabilities are advisory 474 or binding. 476 11. The protocol MUST provide the ability to specify distribution 477 capabilities in terms of one or more of the following 478 attributes: 480 Profile ID: Identifier for the service profile being 481 advertised. The profile identifier is to be used by the 482 Content Source when requesting service. This attribute is 483 required for all advertisements. The value need not be 484 unique across Distribution CNs, and may be used in 485 advertisements to multiple Content Sources. 487 FootPrint: The areas served by the CN. Minimally, a Content 488 Destination should support expressing footprint according to 489 IP network addresses/prefixes. 491 Content Type: The type of content (e.g. static Web pages, 492 streaming media, etc.) that the CN is able to distribute. 494 Capacity: The storage capacity that the CN can provide. 496 Bandwidth: Maximum outbound bandwidth available from the CN. 498 Object Bandwidth: Maximum outbound bandwidth supported for a 499 single object. 501 Distribution Method: The distribution methods that the CN 502 supports; one or more of push, pull, and alm. "alm" refers 503 to application layer multicast, or splitting, of CONTINUOUS 504 MEDIA; if specified, supported protocols must also be 505 specified. 507 [ Editor's Note: Specifying support for splitting 508 requires refinement. ] 510 Request Routing Type: Type(s) of request routing supported for 511 CI Request Routing Systems. 513 Accounting System Format: Supported protocol(s) and format(s) 514 for sending accounting and access feedback to a specified CI 515 Accounting System. 517 Time Frame: Time frame for which this advertisement is valid. 519 Client Protocols: Indicates the client protocols supported. 520 Currently only HTTP and RTSP are valid. However, this field 521 must be further qualified than just the transport or 522 signalling protocol. The protocol must clearly define a 523 level of support implicated by a given Client Protocol 524 value. 526 Distribution Fee: Indicates the fee charged for distribution 527 services. The value may be expressed in Mbps 528 (megabits/second) or in MB (megabytes of storage). 530 Advertisement Type: Indicates whether the advertisement is 531 advisory or binding. By default, all advertisements are 532 advisory. 534 Private Extensions: Additional metrics that the communicating 535 parties may agree to use, but are not part of the IETF 536 standard. Extensions must be defined such that if not 537 understood by the Content Source, they can be safely 538 ignored. 540 5.3.1 Advertising Examples 542 To be provided. 544 5.4 Replication Protocol Requirements 546 1. A common (base) replication protocol MUST be defined which is 547 supported by all CIGs, for any content type which can be used to 548 transport meta-data and a full replica of content data. 550 2. Replication MUST support the ability for a Content Source to 551 specify a replication channel from which content may be 552 retrieved. 554 1. [ Editors Note: I am using channel as a generic term which 555 would provide a contact point and protocol, and any 556 additional info required to establish a connection. E.g. 557 wcips://invalidation.com/content_set for signaling; will 558 provide clarification later ] 560 3. Replication MUST enable specifying optionally supported, 561 alternative replication protocols which may be better suited 562 than the common base protocol for specific content types or 563 configuration scenarios. 565 4. A Content Source SHOULD be able to specify an authoritative 566 source for content as well as distribution points. 568 5. The protocol MUST enable replication that is secured (encrypted) 569 across the communications channel. 571 5.4.1 Replication Examples 573 To be provided. 575 5.5 Content Signaling Protocol Requirements 577 1. A Content Source MUST be able to request distribution services 578 for one or more content objects. 580 2. A Content Destination MUST explicitly accept or reject a request 581 for distribution services. 583 3. A Content Source MUST be able to withdraw (cancel) a request for 584 content services for one or multiple content objects. 586 4. Rejected requests for distribution services MUST include error 587 codes. Partial rejections or negotiations are not supported. A 588 Content Source may follow a rejection with a request for 589 distribution services under alternate service requirements. 591 5. A Content Source MUST be able to signal consistency meta-data. 592 Minimally, Content Sources SHOULD support weak consistency 593 mechanisms. Content Sources MAY support mechanisms for strong 594 consistency. 596 6. Content signaling SHOULD include mechanisms to aggregate content 597 information. 599 7. Content Signaling SHOULD be decoupled from the content ORIGIN. 600 I.e., a Content Source should be able to specify a content 601 signaling channel. 603 8. The following attributes are defined for content signals: 605 Content Set ID: A unique identifier for this specific content 606 set, so that future references (e.g. to modify the content or 607 to withdraw it from distribution) may be resolved. This value 608 can also be used to avoid loops. The Content Set ID MUST be 609 global and unique, i.e., a given content set MUST have the 610 same ID across all Distribution Systems, and this ID MUST be 611 unique across *all* Distribution Systems. 613 URI: The uniform resource identifier for the content. It 614 identifies how CLIENTS will request delivery services from 615 the Distribution CN. This attribute can support an atomic 616 unit of content or it can be used to generally specify a URI 617 path. For pull distribution, a URI path serves as pattern 618 (e.g. http://origin/images/*) to qualify which content should 619 receive the specified service. For push distribution, only 620 URIs which identify an atomic unit of content may be used. 622 [Ed: The editor would prefer further discussion on whether 623 this attribute must uniquely identify an atomic unit of 624 content or whether it can more generally specify a URI 625 path. Allowing paths may significantly reduce the size of 626 any protocol transfers, but, there are some attributes 627 (e.g. size, content type) that do not apply as cleanly to 628 paths, and some distribution methods (e.g. pull) cannot be 629 easily accommodate paths.] 631 Authoritative Source: Identifies the channel where the 632 authoritative copy of the content may be retrieved. In the 633 case of live CONTINUOUS MEDIA, this channel may represent 634 where the Content Destination may retrieve meta-data required 635 to provide application layer multicasting services. 637 Distribution Method: Push, pull, on-demand, alm or withdraw. 639 Specifies how the Content Destination should retrieve the 640 content. Withdraw is a special case that indicates a Content 641 Destination should cease distribution of previously accepted 642 content. 644 Service Profile ID: Identifies the service profile to be 645 associated with this request. The Service Profile ID may 646 have been provided by a Content Destination advertisement or 647 some other means (e.g. contractual agreement negotiated 648 off-line). The identifier MAY encode Content Source or 649 Content Destination specific information, but it has local 650 significance only (i.e., it is strictly between the Content 651 Source and Content Destination). 653 Size: Size of the content. 655 Time Frame: The period of time for which the Content Source 656 requests distribution. 658 Request Routing Type: Type of Request Routing requested for this 659 content. Depending on the Request Routing type, an RRS 660 channel may also be supplied. 662 [ Editor's Note: Request Routing Types to be defined according 663 to [6]. ] 665 Accounting Format: Format for sending accounting and access 666 feedback. 668 Accounting Type: Accounting/access feedback type desired. 669 Depending on the type requested, an Accounting channel may 670 also be supplied. The information conveyed with this 671 attribute should also indicate whether the Content 672 Destination is required to provide this feedback. 674 [ Editor's Note: Accounting Formats and Types to be defined 675 according to [7]. ] 677 Distribution Authority: Indicates whether the Content 678 Destination can serve as the Authoritative Source for this 679 content set or if the Authoritative Source attribute must be 680 treated as a global attribute. By default, the Content 681 Destination can serve as Authoritative Source to Content 682 Destinations for which it is the Content Source. 684 Mirrors: Alternate channels for retrieving the content. 686 Update Channel: Alternate channels for receiving consistency 687 signals. The information conveyed in this attribute should 688 also indicate whether the Content Destination is required to 689 subscribe to this channel. 691 Content Data: The actual content data to be distributed; this is 692 expected to be used for small objects only. 694 Expires: Indicates the date/time after which this version of the 695 content is considered stale. 697 Prefetch: If content is to be prefetched, indicates the 698 date/time when the prefetch should be requested. 700 9. The following table specifies the relationship between content 701 signal types and the defined attributes. 703 Attribute Add Update Withdrawal 704 --------------------- -------- --------- ----------- 705 Content Set ID required required required 706 URI required optional unsupported 707 Service Profile ID optional optional optional 708 Authoritative Source required optional unsupported 709 Distribution Method required optional unsupported 710 Time Frame required optional required 711 Request Routing Type required optional unsupported 712 Accounting Format required optional unsupported 713 Accounting Type required optional unsupported 714 Mirrors optional optional unsupported 715 Distribution Authority optional optional unsupported 716 Update Channel optional optional unsupported 717 Content Data optional optional unsupported 718 Expires optional required unsupported 720 5.5.1 Resource Update Protocol (RUP) Relationship 722 The IETF Web Intermediaries (WEBI) Working Group is currently 723 developing requirements for a Resource Update Protocol (RUP) [10]. 724 RUP defines requirements for a protocol enabling communication about 725 changes to content accessible from caching proxies and surrogates. 726 Operations required by RUP include cache invalidation, content 727 location update, content prefetch hints, removal and addition of 728 resources to a resource group, adjustments to cache consistency 729 parameters. 731 Several of the RUP defined operations coincide with the requirements 732 listed for CI Distribution Signaling (CI-DS). The intent of this 733 document is to specify those requirements which are specific to the 734 CI environment. The CI-DS requirements which would be met by a 735 protocol designed to meet the RUP requirements are: 737 Both RUP and CI-DS require transport of content metadata from a 738 single point of control (RUP Server) to a large number of 739 surrogates (RUP clients). 741 In the CI-DS environment, the RUP Server and RUP Clients are 742 expected to be in multiple administrative domains. Also, RUP 743 Clients are likely to be CIG responsible for propogating content 744 signals to downstream surrogates which are in the same 745 administrative domain as the CIG. It is anticipated, but not 746 required, the signals relayed to downstream surrogates will also 747 conform to the protocol designed to meet RUP requirements. 749 The transport defined to carry content metadata must enable 750 enforcing secrecy and authentication for payloads. 752 The transport must enable the point of control to specify 753 explicit acknowledgement of messages. 755 The following mapping of metadata fields are anticipated: 757 CI-DS Content Set ID field maps to RUP Resource Groups. 759 CI-DS URI field maps to RUP Object ID. 761 CI-DS Update Channel may reference a RUP server providing 762 cache consistency for this Content Set. 764 CI-DS Authoritative Source maps to a RUP Content Location. 766 CI-DS Expires maps to the RUP document expiration time. 768 CI-DS enables the ability to specify when an object should be 769 prefetched; RUP enables the ability to specify an object 770 should be prefetched. 772 In addition to the metadata fields which were defined for CI-DS, but 773 not mapped to an RUP field, CI-DS requires the following 774 functionality. 776 Ability to specifically request a Content Set be added or 777 withdrawn from the list of objects being serviced. This 778 requirement could be covered by adding the ability to dynamically 779 define Resource Groups to RUP. 781 Specifically, a master Resource Group could be defined which 782 would be used as the channel to communicate which Resource Groups 783 to be added/withdrawn from service. The CIG would then establish 784 channels to receive cache coherency messages for these Resource 785 Groups. 787 Ability to update metadata for an object. While it is possible 788 this can be covered by withdrawal and re-add of the Content Set, 789 due to the number and types of fields supported, inability to 790 update would impact efficiency. 792 5.5.2 Content Signaling Examples 794 To be provided. 796 References 798 [1] Bradner, S.O., "The Internet Standards Process -- Revision 3", 799 RFC 2026, BCP 9, October 1996. 801 [2] Bradner, S.O., "Key words for use in RFCs to Indicate 802 Requirement Levels", RFC 2119, BCP 14, March 1997. 804 [3] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CN Peering 805 Architectural Overview", January 2001. 807 [4] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web 808 Replication and Caching Taxonomy", January 2001. 810 [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. 811 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 812 January 2001. 814 [6] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request 815 Routing Requirements for Content Internetworking", January 816 2001. 818 [7] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Accounting 819 Requirements for CDN Internetworking", January 2001. 821 [8] Day, M., Cain, B. and G. Tomlinson, "A Model for Content 822 Distribution Internetworking", January 2001. 824 [9] Day, M., Cain, B. and G. Tomlinson, "Content Distribution 825 Network Peering Scenarios", January 2001. 827 [10] Hamilton, M., Cooper, I. and D. Li, "Requirements for a 828 Resource Update Protocol", November 2001. 830 Authors' Addresses 832 Lisa D. Amini 833 IBM Research 834 30 Saw Mill River Road 835 Hawthorne, NY 10532 836 US 838 Phone: +1 914 784 7366 839 EMail: aminil@us.ibm.com 840 Stephen Thomas 841 TransNexus, Inc 842 430 Tenth Street NW Suite N204 843 Atlanta, GA 30318 844 US 846 Phone: +1 404 872 4887 847 EMail: stephen.thomas@transnexus.com 849 Oliver Spatscheck 850 AT&T Labs 851 180 Park Ave, Bldg 103 852 Florham Park, NJ 07932 854 Phone: 855 EMail: spatsch@research.att.com 857 Appendix A. Acknowledgements 859 The editors would like to thank the following for their assistance: 860 Kobus van der Merwe, Nalin Mistry, Don Easton, Christian Hoertnagl, 861 John Robertson, Dan Li, Phil Rzewski, Brad Cain, Mark Day, Fred 862 Douglis, and Ingrid Melve. 864 Full Copyright Statement 866 Copyright (C) The Internet Society (2001). All Rights Reserved. 868 This document and translations of it may be copied and furnished to 869 others, and derivative works that comment on or otherwise explain it 870 or assist in its implementation may be prepared, copied, published 871 and distributed, in whole or in part, without restriction of any 872 kind, provided that the above copyright notice and this paragraph 873 are included on all such copies and derivative works. However, this 874 document itself may not be modified in any way, such as by removing 875 the copyright notice or references to the Internet Society or other 876 Internet organizations, except as needed for the purpose of 877 developing Internet standards in which case the procedures for 878 copyrights defined in the Internet Standards process must be 879 followed, or as required to translate it into languages other than 880 English. 882 The limited permissions granted above are perpetual and will not be 883 revoked by the Internet Society or its successors or assigns. 885 This document and the information contained herein is provided on an 886 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 887 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 888 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 889 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 890 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 892 Acknowledgement 894 Funding for the RFC editor function is currently provided by the 895 Internet Society.