idnits 2.17.1 draft-ietf-cdi-scenarios-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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: '3' is defined on line 628, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 635, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-cdi-model-00 ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-model (ref. '1') == Outdated reference: A later version (-01) exists of draft-ietf-cdi-architecture-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-01) exists of draft-ietf-cdi-aaa-reqs-00 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2975 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 22, 2002 D. Gilletti 5 CacheFlow 6 P. Rzewski 7 Inktomi 8 February 22, 2002 10 Content Internetworking (CDI) Scenarios 11 draft-ietf-cdi-scenarios-00.txt 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 Internet- 21 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 22, 2002. 36 Copyright Notice 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 Abstract 42 In describing content internetworking as a technology targeted for 43 use in the "real world", it's useful to provide examples of the 44 possible sequence of events that may occur when two content networks 45 decide to interconnect. The scenarios presented here seek to provide 46 some concrete examples of what content internetworking is, and also 47 to provide a basis for evaluating content internetworking proposals. 49 Table of Contents 51 1. Introduction...................................................3 52 1.1 Terminology....................................................3 53 2. Special Cases of Content Networks..............................3 54 2.1 Publishing Content Network.....................................4 55 2.2 Brokering Content Network......................................4 56 2.3 Local Request-Routing Content Network..........................4 57 3. Content Internetworking Arrangements...........................5 58 4. Content Internetworking Scenarios..............................6 59 4.1 General Content Internetworking................................6 60 4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING 61 INTERNETWORKING................................................9 62 4.3 BCN providing ACCOUNTING INTERNETWORKING......................11 63 4.4 PCN ENLISTS multiple CNs......................................12 64 4.5 Multiple CNs ENLIST LCN.......................................13 65 5. Security Considerations.......................................15 66 6. Acknowledgements..............................................15 67 References....................................................15 68 Authors' Addresses............................................16 69 Full Copyright Statement..........................................16 71 1. Introduction 73 In [1], the concept of a "content network" is introduced and 74 described. In addition to describing some general types of content 75 networks, it also describes motivations for allowing content 76 networks to interconnect (defined as �content internetworking�). 78 In describing content internetworking as a technology targeted for 79 use in the "real world", it's useful to provide examples of the 80 possible sequence of events that may occur when two content networks 81 decide to interconnect. Naturally, different types of content 82 networks may be created due to different business motivations, and 83 so many combinations are likely. 85 This document first provides detailed examples of special cases of 86 content networks that are specifically designed to participate in 87 content internetworking (Section 2). We then discuss the steps that 88 would be taken in order to "bring up" or "tear down" a content 89 internetworking arrangement (Section 3). Next we provide some 90 detailed examples of how content networks (such as those from 91 Section 2) could interconnect (Section 4). Finally, we describe any 92 security considerations that arise specifically from the examples 93 presented here (Section 5). 95 The scenarios presented here answer two distinct needs: 97 1. To provide some concrete examples of what content 98 internetworking is, and 100 2. To provide a basis for evaluating content internetworking 101 proposals. 103 For details on the architectural framework used in the development 104 of actual content internetworking protocols and interfaces, refer to 105 [2]. For specific examples of systems where content internetworking 106 has been implemented, refer to [5]. 108 1.1 Terminology 110 Terms in ALL CAPS are defined in [1]. 112 2. Special Cases of Content Networks 114 A CN is defined in [2] as having REQUEST-ROUTING, DISTRIBUTION, and 115 ACCOUNTING interfaces. However, some participating networks may 116 gravitate toward particular subsets of the CONTENT INTERNETWORKING 117 interfaces. Others may be seen differently in terms of how they 118 relate to their CLIENT bases. This section describes these refined 119 cases of the general CN case so they may be available for easier 120 reference in the further development of CONTENT INTERNETWORKING 121 scenarios. The special cases described are the Publishing Content 122 Network, the Brokering Content Network, and the Local Request- 123 Routing Content Network. 125 2.1 Publishing Content Network 127 A Publishing Content Network (PCN), maintained by a PUBLISHER, 128 contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or 129 more CNs. A PCN may contain SURROGATES for the benefit of serving 130 some CONTENT REQUESTS locally, but does not intend to allow its 131 SURROGATES to serve CONTENT on behalf of other PUBLISHERS. 133 Several implications follow from knowing that a particular CN is a 134 PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING 135 SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the 136 PUBLISHER to determine the distribution of CONTENT REQUESTS among 137 ENLISTED CNs. Second, it implies that the PCN need only participate 138 in a subset of CONTENT INTERNETWORKING. For example, a PCN's 139 DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive 140 DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a 141 PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send 142 AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING 143 SYSTEM need only be able to receive ACCOUNTING data, it need not 144 send it. 146 2.2 Brokering Content Network 148 A Brokering Content Network (BCN) is a network that does not operate 149 its own SURROGATES. Instead, a BCN operates only CIGs as a service 150 on behalf other CNs. A BCN may therefore be regarded as a 151 "clearinghouse" for CONTENT INTERNETWORKING information. 153 For example, a BCN may choose to participate in DISTRIBUTION 154 INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to 155 aggregate ADVERTISEMENTS from one set of CNs into a single update 156 stream for the benefit of other CNs. To name a single specific 157 example, a BCN could aggregate CONTENT SIGNALS from CNs that 158 represent PUBLISHERS into a single update stream for the benefit of 159 CNs that contain SURROGATES. A BCN may also choose to participate in 160 ACCOUNTING INTERNETWORKING in order to aggregate utilization data 161 from several CNs into combined reports for CNs that represent 162 PUBLISHERS. 164 This definition of a BCN implies that a BCN's CIGs would implement 165 the sending and/or receiving of any combination of ADVERTISEMENTS 166 and ACCOUNTING data as is necessary to provide desired services to 167 other CONTENT NETWORKS. For example, a BCN only interested in 168 aggregating ACCOUNTING data on behalf of other CNs would only need 169 to have an ACCOUNTING INTERNETWORKING interface on its CIGs. 171 2.3 Local Request-Routing Content Network 172 Another type of CN is the Local Request-Routing CONTENT NETWORK 173 (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT 174 REQUESTS are always handled by some local SERVER (such as a caching 175 proxy [1]). In this context, "local" is taken to mean that both the 176 CLIENT and SERVER are within the same administrative domain, and 177 there is an administrative motivation for forcing the local mapping. 178 This type of arrangement is common in enterprises where all CONTENT 179 REQUESTS must be directed through a local SERVER for access control 180 purposes. 182 As implied by the name, the LCN creates an exception to the rule 183 that there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a 184 particular item of CONTENT. By directing CONTENT REQUESTS through 185 the local SERVER, CONTENT RESPONSES may be given to CLIENTS without 186 first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing 187 this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with 188 an LCN in order to perform DISTRIBUTION into the LCN and receive 189 ACCOUNTING data from it. Note that once it's participating in 190 DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, the 191 SERVERS within the LCN effectively take on the role of SURROGATES. 192 However, an LCN would not intend to allow its SURROGATES to be 193 accessed by non-local CLIENTS. 195 This set of assumptions implies multiple things about the LCN's 196 CONTENT INTERNETWORKING relationships. First, it is implied that the 197 LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send 198 DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is 199 implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be 200 able to send ACCOUNTING data, it need not receive it. Finally, due 201 to the locally defined REQUEST-ROUTING, the LCN would not 202 participate in REQUEST-ROUTING INTERNETWORKING. 204 3. Content Internetworking Arrangements 206 When the controlling interests of two CNs decide to interconnect 207 their respective networks (such as for business reasons), it is 208 expected that multiple steps would need to occur. 210 The first step would be the creation of a NEGOTIATED RELATIONSHIP. 211 This relationship would most likely take the form of a legal 212 document that describes the services to be provided, cost of 213 services, SLAs, and other stipulations. For example, if an 214 ORIGINATING CN wished to leverage another CN's reach into a 215 particular country, this would be laid out in the NEGOTIATED 216 RELATIONSHIP. 218 The next step would be to configure CONTENT INTERNETWORKING 219 protocols on the CIGs of the respective CNs in order to technically 220 support the terms of the NEGOTIATED RELATIONSHIP. To follow our 221 previous example, this could include the configuration of the 222 ENLISTED CN's CIGs in a particular country to send DISTRIBUTION 223 ADVERTISEMENTS to the CIGs of the ORIGINATING CN. In order to 224 configure these protocols, technical details (such as CIG 225 addresses/hostnames and authentication information) would be 226 exchanged by administrators of the respective CNs. 228 In the event that the controlling interests of two CNs no longer 229 wish to have their networks interconnected, it is expected that 230 these tasks would be undone in reverse order. That is, first the 231 protocol configurations would be changed to cease the movement of 232 ADVERTISEMENTS and/or ACCOUNTING data between the networks. After 233 this, the NEGOTIATED RELATIONSHIP would be legally terminated. 235 4. Content Internetworking Scenarios 237 This section provides several scenarios that may arise in CONTENT 238 INTERNETWORKING implementations. 240 Note that we obviously cannot examine every single permutation. 241 Specifically, it should be noted that: 243 o Any one of the interconnected CNs may have other CONTENT 244 INTERNETWORKING arrangements that may or may not be transitive to 245 the relationships being described in the diagram. 247 o The graphical figures do not illustrate the CONTENT REQUEST 248 paths. It is assumed that the direction of CONTENT REQUESTS 249 follow the methodology given in [2] and that the end result is 250 that a REQUEST-ROUTING SYSTEM eventually returns to the CLIENT 251 the IP address of the SURROGATE deemed appropriate to honor the 252 CLIENT's CONTENT REQUEST. 254 The scenarios described include a general case, two cases in which 255 BCNs provide limited interfaces, a case in which a PCN enlists the 256 services of multiple CNs, and a case in which multiple CNs enlist 257 the services of an LCN. 259 4.1 General Content Internetworking 261 This scenario considers the general case where two or more existing 262 CNs wish to establish a CONTENT INTERNETWORKING relationship in 263 order to provide increased scale and reach for their existing 264 customers. It assumes that all of these CNs already provide REQUEST- 265 ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will 266 continue to provide these services to existing customers as well as 267 offering them to other CNs. 269 In this scenario, these CIs would interconnect with others via a CIG 270 which provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a 271 DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING 272 INTERNETWORKING SYSTEM. The net result of this interconnection would 273 be that a larger set of SURROGATES will now be available to the 274 CLIENTS. 276 FIGURE 1 shows three CNs which have interconnected to provide 277 greater scale and reach to their existing customers. They are all 278 participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING 279 INTERNETWORKING, and ACCOUNTING INTERNETWORKING. 281 As a result of the NEGOTIATED RELATIONSHIPS it is assumed that: 283 1. CONTENT that has been INJECTED into any one of these ORIGINATING 284 CNs may be distributed into any other ENLISTED CN. 286 2. Commands affecting the DISTRIBUTION of CONTENT may be issued 287 within the ORIGINATING CN, or may also be issued within the 288 ENLISTED CN. 290 3. ACCOUNTING information regarding CLIENT access and/or 291 DISTRIBUTION actions will be made available to the ORIGINATING 292 CN by the ENLISTED CN. 294 4. The ORIGINATING CN would provide this ACCOUNTING information to 295 the PUBLISHER based on existing Service Level Agreements (SLAs). 297 5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within 298 any of the ENLISTED CNs. 300 The decision of where to direct an individual CONTENT REQUEST may be 301 dependent upon the DISTRIBUTION and REQUEST-ROUTING policies 302 associated with the CONTENT being requested as well as the specific 303 algorithms and methods used for directing these requests. For 304 example, a REQUEST-ROUTING policy for a piece of CONTENT may 305 indicate multiple versions exist based on the spoken language of a 306 CLIENT. Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN 307 would likely direct a CONTENT REQUEST to a SURROGATE known to be 308 holding a version of CONTENT of a language that matches that of a 309 CLIENT. 311 FIGURE 1 - General CONTENT INTERNETWORKING 313 +--------------+ +--------------+ 314 | CN A | | CN B | 315 |..............| +---------+ +---------+ |..............+ 316 | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | 317 |..............| | CONTENT | | CONTENT | |..............| 318 | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | 319 |..............| | GATEWAY | | GATEWAY | |..............| 320 | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | 321 |--------------| +---------+ +---------+ +--------------+ 322 | ^ \^ \^ \^ ^/ ^/ ^/ | ^ 323 v | \\ \\ \\ // // // v | 324 +--------------+ \\ \\ \\ // // // +--------------+ 325 | SURROGATES | \\ v\ v\ /v /v // | SURROGATES | 326 +--------------+ \\+---------+// +--------------+ 327 ^ | v| |v ^ | 328 | | | CONTENT | | | 329 | | |INTWRKING| | | 330 | | | GATEWAY | | | 331 | | | | | | 332 | | +---------+ | | 333 | | ^| ^| ^| | | 334 | | || || || | | 335 | | |v |v |v | | 336 | | +--------------+ | | 337 | | | CN C | | | 338 | | |..............| | | 339 | | | REQ-ROUTING | | | 340 | | |..............| | | 341 \ \ | DISTRIBUTION | / / 342 \ \ |..............| / / 343 \ \ | ACCOUNTING | / / 344 \ \ |--------------| / / 345 \ \ | ^ / / 346 \ \ v | / / 347 \ \ +--------------+ / / 348 \ \ | SURROGATES | / / 349 \ \ +--------------+ / / 350 \ \ | ^ / / 351 \ \ | | / / 352 \ \ v | / / 353 \ \ +---------+ / / 354 \ \-->| CLIENTS |---/ / 355 \----| |<---/ 356 +---------+ 358 4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING 359 INTERNETWORKING 361 This scenario describes the case where a single entity (BCN A) 362 performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING 363 INTERNETWORKING functions, but has no inherent DISTRIBUTION or 364 DELIVERY capabilities. A potential configuration which illustrates 365 this concept is given in FIGURE 2. 367 In the scenario shown in FIGURE 2, BCN A is responsible for 368 collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN 369 A and CN B) to provide a clearinghouse/settlement function, as well 370 as providing a REQUEST-ROUTING service for CN A and CN B. 372 In this scenario, CONTENT is injected into either CN A or CN B and 373 its DISTRIBUTION between these CNs is controlled via the 374 DISTRIBUTION INTERNETWORKING SYSTEMS within the CIGs. The REQUEST- 375 ROUTING SYSTEM provided by BCN A is informed of the ability to serve 376 a piece of CONTENT from a particular CONTENT NETWORK by the REQUEST- 377 ROUTING SYSTEMS within the interconnected CIGs. 379 BCN A collects statistics and usage information via the ACCOUNTING 380 INTERNETWORKING SYSTEM and disseminates that information to CN A and 381 CN B as appropriate. 383 As illustrated in FIGURE 2, there are separate REQUEST-ROUTING 384 SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM 385 provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a 386 given piece of CONTENT this is not a problem. However, each 387 individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING 388 SYSTEM for some portion of its PUBLISHER customers. In this case 389 care must be taken to ensure that the there is one and only one 390 AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given 391 CONTENT object. 393 FIGURE 2 - BCN providing ACCOUNTING INTERNETWORKING and 394 REQUEST-ROUTING INTERNETWORKING 396 +--------------+ 397 | BCN A | 398 |..............| +-----------+ 399 | REQ-ROUTING |<===>| | 400 |..............| | CONTENT | 401 | ACCOUNTING |<===>| INTWRKING | 402 +--------------+ | GATEWAY | 403 | | 404 +-----------+ 405 ^| ^| ^| ^| 406 +--------------+ // // \\ \\ +--------------+ 407 | CN A | |v |v |v |v | CN B | 408 |..............| +---------+ +---------+ |..............| 409 | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING | 410 |..............| | CONTENT | | CONTENT | |..............| 411 | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | 412 |..............| | GATEWAY | | GATEWAY | |..............| 413 | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | 414 |--------------| +---------+ +---------+ +--------------+ 415 | ^ | ^ 416 v | v | 417 +--------------+ +--------------+ 418 | SURROGATES | | SURROGATES | 419 +--------------+ +--------------+ 420 ^ \ ^ / 421 \ \ / / 422 \ \ / / 423 \ \ / / 424 \ \ +---------+ / / 425 \ \---->| CLIENTS |-----/ / 426 \------| |<-----/ 427 +---------+ 429 4.3 BCN providing ACCOUNTING INTERNETWORKING 431 This scenario describes the case where a single entity (BCN A) 432 performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/ 433 settlement function only. In this scenario, BCN A would enter into 434 NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their 435 own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING 436 as shown in FIGURE 3. 438 FIGURE 3 - BCN providing ACCOUNTING INTERNETWORKING 440 +--------------+ 441 | BCN A | 442 |..............| +-----------+ 443 | ACCOUNTING |<===>| | 444 +--------------+ | CONTENT | 445 | INTWRKING | 446 | GATEWAY | 447 | | 448 +-----------+ 449 ^| ^| 450 +--------------+ // \\ +--------------+ 451 | CN A | |v |v | CN B | 452 |..............| +---------+ +---------+ |..............| 453 | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | 454 |..............| | CONTENT | | CONTENT | |..............| 455 | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | 456 |..............| | GATEWAY | | GATEWAY | |..............| 457 | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | 458 |--------------| +---------+ +---------+ +--------------+ 459 | ^ | ^ 460 v | v | 461 +--------------+ +--------------+ 462 | SURROGATES | | SURROGATES | 463 +--------------+ +--------------+ 464 ^ \ ^ / 465 \ \ / / 466 \ \ / / 467 \ \ / / 468 \ \ +---------+ / / 469 \ \---->| CLIENTS |-----/ / 470 \------| |<-----/ 471 +---------+ 473 4.4 PCN ENLISTS multiple CNs 475 In the previously enumerated scenarios, PUBLISHERS have not been 476 discussed. Much of the time, it is assumed that the PUBLISHERS will 477 allow CNs to act on their behalf. For example, a PUBLISHER may 478 designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING 479 SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a 480 particular CN to aggregate all its ACCOUNTING data, even though that 481 data may originate at SURROGATES in multiple distant CNs. Finally, a 482 PUBLISHER may INJECT content only into a single CN and rely on that 483 CN to ENLIST other CNs to obtain scale and reach. 485 However, a PUBLISHER may wish to maintain more control and take on 486 the task of ENLISTING CNs itself, therefore acting as a PCN (Section 487 2.1). This scenario, shown in FIGURE 4, describes the case where a 488 PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with 489 multiple CNs. In this scenario, the PCN would operate its own CIG 490 and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING 491 INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships 492 with two or more CNs. 494 FIGURE 4 - PCN ENLISTS multiple CNs 496 +--------------+ 497 | PCN | 498 |..............| +-----------+ 499 | REQ-ROUTING |<=>| |<---\ 500 |..............| | CONTENT |----\\ 501 | DISTRIBUTION |<=>| INTWRKING | \\ 502 |..............| | GATEWAY |--\ \\ 503 | ACCOUNTING |<=>| |<-\\ \\ 504 +--------------+ +-----------+ \\ \\ 505 ^| ^| ^| ^| \\ || 506 +--------------+ || || || \\ || || +--------------+ 507 | CN A | |v |v |v \v |v |v | CN B | 508 |..............| +---------+ +---------+ |..............| 509 | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING | 510 |..............| | CONTENT | | CONTENT | |..............| 511 | DISTRIBUTION |<=>|INTWRKING| |INTWRKING|<=>| DISTRIBUTION | 512 |..............| | GATEWAY | | GATEWAY | |..............| 513 | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | 514 |--------------| +---------+ +---------+ +--------------+ 515 | ^ | ^ 516 v | v | 517 +--------------+ +--------------+ 518 | SURROGATES | | SURROGATES | 519 +--------------+ +--------------+ 520 ^ \ ^ / 521 \ \ / / 522 \ \ / / 523 \ \ / / 524 \ \ +---------+ / / 525 \ \---->| CLIENTS |-----/ / 526 \------| |<-----/ 527 +---------+ 529 4.5 Multiple CNs ENLIST LCN 531 A type of CN described in Section 2.3 is the LCN. In this scenario, 532 we imagine a tightly administered CN (such as within an enterprise) 533 has determined that all CONTENT REQUESTS from CLIENTS must be 534 serviced locally. Likely due to a large CLIENT base in the LCN, 535 multiple CNs determine they would like to engage in DISTRIBUTION 536 INTERNETWORKING with the LCN in order to extend control over CONTENT 537 objects held in the LCN's SURROGATES. Similarly, the CNs would like 538 to engage in ACCOUNTING INTERNETWORKING with the LCN in order to 539 receive ACCOUTING data regarding the usage of the content in the 540 local SURROGATES. This scenario is shown in FIGURE 5. 542 FIGURE 5 - Multiple CNs ENLIST LCN 544 +--------------+ +--------------+ 545 | CN A | | CN B | 546 |..............| +---------+ +---------+ |..............+ 547 | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | 548 |..............| | CONTENT | | CONTENT | |..............| 549 | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | 550 |..............| | GATEWAY | | GATEWAY | |..............| 551 | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | 552 |--------------| +---------+ +---------+ +--------------+ 553 | ^ \^ \^ ^/ ^/ | ^ 554 v | \\ \\ // // v | 555 +--------------+ \\ \\ // // +--------------+ 556 | SURROGATES | v\ v\ /v /v | SURROGATES | 557 +--------------+ +---------+ +--------------+ 558 | | 559 | CONTENT | 560 |INTWRKING| 561 | GATEWAY | 562 | | 563 +---------+ 564 ^| ^| 565 || || 566 |v |v 567 +--------------+ 568 | LCN A | 569 |..............| 570 | DISTRIBUTION | 571 |..............| 572 | ACCOUNTING | 573 |--------------| 574 | ^ 575 v | 576 +--------------+ 577 | SURROGATES | 578 +--------------+ 579 | ^ 580 | | 581 v | 582 +---------+ 583 | CLIENTS | 584 | | 585 +---------+ 587 5. Security Considerations 589 This section contains security considerations that arise 590 specifically from the examples presented here. For a more general 591 discussion of security in the CDI protocols, see [2]. 593 Due to the likely reliance on ACCOUNTING data as the basis of 594 payment for services, the likelihood of fraud may be a concern of 595 parties that participate in CONTENT INTERNETWORKING. Indeed, it's 596 easy to imagine fabricating log entries or increasing throughput 597 numbers to increase revenue. While this is a difficult problem to 598 solve, there are some approaches to be explored. A useful tool would 599 be a "fraud detection" analysis tool that is capable of modeling 600 human usage patterns and detecting anomalies. It may be logical for 601 such a tool to be run by a BCN that is acting as an "impartial third 602 party", ENLISTED only to ensure fairness among participants. 603 Additionally, a BCN may be ENLISTED to perform random audits of 604 ACCOUNTING data. 606 6. Acknowledgements 608 The authors acknowledge the contributions and comments of Fred 609 Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John 610 Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT), 611 Christian Hoertnagl (IBM), Christian Langkamp (Oxford University), 612 and Don Estberg (Activate). 614 References 616 [1] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for 617 Content Internetworking (CDI)", draft-ietf-cdi-model-00.txt 618 (work in progress), February 2002, 619 . 622 [2] Green, M., Cain, B., Tomlinson, G., Thomas, S., and P. Rzewski, 623 "Content Internetworking Architectural Overview", draft-ietf- 624 cdi-architecture-00.txt (work in progress), February 2002, 625 . 628 [3] Gilletti, D., Nair, R., Scharber, J., and J. Guha, "CDN-I 629 Internetworking Authentication, Authorization, and Accounting 630 Requirements", draft-ietf-cdi-aaa-reqs-00.txt (work in 631 progress), February 2002, 632 . 635 [4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to 636 Accounting Management", RFC 2975, October 2000, 637 . 639 [5] Douglis, F., Chaudhri, I. and P. Rzewski, "Known Mechanisms for 640 Content Internetworking", draft-douglis-cdi-known-mech-00.txt, 641 November 2001, 642 . 645 Authors' Addresses 647 Mark S. Day 648 Cisco Systems 649 135 Beaver Street 650 Waltham, MA 02452 651 US 653 Phone: +1 781 663 8310 654 EMail: markday@cisco.com 656 Don Gilletti 657 CacheFlow, Inc. 658 441 Moffett Park Drive 659 Sunnyvale, CA 94089 USA 660 US 662 Phone: +1 408 543 0437 663 EMail: don@cacheflow.com 665 Phil Rzewski 666 Inktomi 667 4100 East Third Avenue 668 MS FC2-4 669 Foster City, CA 94404 670 US 672 Phone +1 650 653 2487 673 Email: philr@inktomi.com 675 Full Copyright Statement 677 Copyright (C) The Internet Society (2001). All Rights Reserved. 679 This document and translations of it may be copied and furnished to 680 others, and derivative works that comment on or otherwise explain it 681 or assist in its implementation may be prepared, copied, published 682 and distributed, in whole or in part, without restriction of any 683 kind, provided that the above copyright notice and this paragraph 684 are included on all such copies and derivative works. However, this 685 document itself may not be modified in any way, such as by removing 686 the copyright notice or references to the Internet Society or other 687 Internet organizations, except as needed for the purpose of 688 developing Internet standards in which case the procedures for 689 copyrights defined in the Internet Standards process must be 690 followed, or as required to translate it into languages other than 691 English. 693 The limited permissions granted above are perpetual and will not be 694 revoked by the Internet Society or its successors or assigns. 696 This document and the information contained herein is provided on an 697 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 698 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 699 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 700 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 701 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 703 Acknowledgement 705 Funding for the RFC editor function is currently provided by the 706 Internet Society.