--- 1/draft-ietf-cdi-scenarios-00.txt 2007-12-18 18:42:25.000000000 +0100 +++ 2/draft-ietf-cdi-scenarios-01.txt 2007-12-18 18:42:25.000000000 +0100 @@ -1,21 +1,21 @@ -Network Working Group M. Day -Internet-Draft Cisco -Expires: August 22, 2002 D. Gilletti +Network Working Group P. Rzewski +Internet-Draft Inktomi +Expires: October 24, 2002 M. Day + Cisco + D. Gilletti CacheFlow - P. Rzewski - Inktomi - February 22, 2002 + April 24, 2002 Content Internetworking (CDI) Scenarios - draft-ietf-cdi-scenarios-00.txt + draft-ietf-cdi-scenarios-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -24,34 +24,34 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 22, 2002. + This Internet-Draft will expire on October 24, 2002. Copyright Notice - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract In describing content internetworking as a technology targeted for - use in the "real world", it's useful to provide examples of the - possible sequence of events that may occur when two content networks - decide to interconnect. The scenarios presented here seek to provide - some concrete examples of what content internetworking is, and also - to provide a basis for evaluating content internetworking proposals. + use in production networks, it's useful to provide examples of the + sequence of events that may occur when two content networks decide + to interconnect. The scenarios presented here seek to provide some + concrete examples of what content internetworking is, and also to + provide a basis for evaluating content internetworking proposals. Table of Contents 1. Introduction...................................................3 1.1 Terminology....................................................3 2. Special Cases of Content Networks..............................3 2.1 Publishing Content Network.....................................4 2.2 Brokering Content Network......................................4 2.3 Local Request-Routing Content Network..........................4 3. Content Internetworking Arrangements...........................5 @@ -59,35 +59,35 @@ 4.1 General Content Internetworking................................6 4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING INTERNETWORKING................................................9 4.3 BCN providing ACCOUNTING INTERNETWORKING......................11 4.4 PCN ENLISTS multiple CNs......................................12 4.5 Multiple CNs ENLIST LCN.......................................13 5. Security Considerations.......................................15 6. Acknowledgements..............................................15 References....................................................15 Authors' Addresses............................................16 - Full Copyright Statement..........................................16 + Full Copyright Statement......................................16 1. Introduction In [1], the concept of a "content network" is introduced and described. In addition to describing some general types of content networks, it also describes motivations for allowing content - networks to interconnect (defined as ôcontent internetworkingö). + networks to interconnect (defined as "content internetworking"). In describing content internetworking as a technology targeted for - use in the "real world", it's useful to provide examples of the - possible sequence of events that may occur when two content networks - decide to interconnect. Naturally, different types of content - networks may be created due to different business motivations, and - so many combinations are likely. + use in production networks, it's useful to provide examples of the + sequence of events that may occur when two content networks decide + to interconnect. Naturally, different types of content networks may + be created due to different business motivations, and so many + combinations are likely. This document first provides detailed examples of special cases of content networks that are specifically designed to participate in content internetworking (Section 2). We then discuss the steps that would be taken in order to "bring up" or "tear down" a content internetworking arrangement (Section 3). Next we provide some detailed examples of how content networks (such as those from Section 2) could interconnect (Section 4). Finally, we describe any security considerations that arise specifically from the examples presented here (Section 5). @@ -157,47 +157,47 @@ example, a BCN could aggregate CONTENT SIGNALS from CNs that represent PUBLISHERS into a single update stream for the benefit of CNs that contain SURROGATES. A BCN may also choose to participate in ACCOUNTING INTERNETWORKING in order to aggregate utilization data from several CNs into combined reports for CNs that represent PUBLISHERS. This definition of a BCN implies that a BCN's CIGs would implement the sending and/or receiving of any combination of ADVERTISEMENTS and ACCOUNTING data as is necessary to provide desired services to - other CONTENT NETWORKS. For example, a BCN only interested in - aggregating ACCOUNTING data on behalf of other CNs would only need - to have an ACCOUNTING INTERNETWORKING interface on its CIGs. + other CONTENT NETWORKS. For example, if a BCN is only interested in + aggregating ACCOUNTING data on behalf of other CNs, it would only + need to have an ACCOUNTING INTERNETWORKING interface on its CIGs. 2.3 Local Request-Routing Content Network Another type of CN is the Local Request-Routing CONTENT NETWORK (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT REQUESTS are always handled by some local SERVER (such as a caching proxy [1]). In this context, "local" is taken to mean that both the CLIENT and SERVER are within the same administrative domain, and there is an administrative motivation for forcing the local mapping. This type of arrangement is common in enterprises where all CONTENT REQUESTS must be directed through a local SERVER for access control purposes. As implied by the name, the LCN creates an exception to the rule that there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a particular item of CONTENT. By directing CONTENT REQUESTS through the local SERVER, CONTENT RESPONSES may be given to CLIENTS without first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an LCN in order to perform DISTRIBUTION into the LCN and receive - ACCOUNTING data from it. Note that once it's participating in - DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, the - SERVERS within the LCN effectively take on the role of SURROGATES. - However, an LCN would not intend to allow its SURROGATES to be - accessed by non-local CLIENTS. + ACCOUNTING data from it. Note that once SERVERS participate in + DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they + effectively take on the role of SURROGATES. However, an LCN would + not intend to allow its SURROGATES to be accessed by non-local + CLIENTS. This set of assumptions implies multiple things about the LCN's CONTENT INTERNETWORKING relationships. First, it is implied that the LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be able to send ACCOUNTING data, it need not receive it. Finally, due to the locally defined REQUEST-ROUTING, the LCN would not participate in REQUEST-ROUTING INTERNETWORKING. @@ -218,26 +218,31 @@ The next step would be to configure CONTENT INTERNETWORKING protocols on the CIGs of the respective CNs in order to technically support the terms of the NEGOTIATED RELATIONSHIP. To follow our previous example, this could include the configuration of the ENLISTED CN's CIGs in a particular country to send DISTRIBUTION ADVERTISEMENTS to the CIGs of the ORIGINATING CN. In order to configure these protocols, technical details (such as CIG addresses/hostnames and authentication information) would be exchanged by administrators of the respective CNs. + Note also that some terms of the NEGOTIATED RELATIONSHIP would be + upheld through means outside the scope of CDI protocols. These could + include non-technical terms (such as financial settlement) or other + technical terms (such as SLAs). + In the event that the controlling interests of two CNs no longer wish to have their networks interconnected, it is expected that - these tasks would be undone in reverse order. That is, first the - protocol configurations would be changed to cease the movement of - ADVERTISEMENTS and/or ACCOUNTING data between the networks. After - this, the NEGOTIATED RELATIONSHIP would be legally terminated. + these tasks would be undone. That is, the protocol configurations + would be changed to cease the movement of ADVERTISEMENTS and/or + ACCOUNTING data between the networks, and the NEGOTIATED + RELATIONSHIP would be legally terminated. 4. Content Internetworking Scenarios This section provides several scenarios that may arise in CONTENT INTERNETWORKING implementations. Note that we obviously cannot examine every single permutation. Specifically, it should be noted that: o Any one of the interconnected CNs may have other CONTENT @@ -260,39 +265,41 @@ This scenario considers the general case where two or more existing CNs wish to establish a CONTENT INTERNETWORKING relationship in order to provide increased scale and reach for their existing customers. It assumes that all of these CNs already provide REQUEST- ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will continue to provide these services to existing customers as well as offering them to other CNs. In this scenario, these CIs would interconnect with others via a CIG - which provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a + that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING INTERNETWORKING SYSTEM. The net result of this interconnection would be that a larger set of SURROGATES will now be available to the CLIENTS. FIGURE 1 shows three CNs which have interconnected to provide greater scale and reach to their existing customers. They are all participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING INTERNETWORKING, and ACCOUNTING INTERNETWORKING. As a result of the NEGOTIATED RELATIONSHIPS it is assumed that: 1. CONTENT that has been INJECTED into any one of these ORIGINATING CNs may be distributed into any other ENLISTED CN. 2. Commands affecting the DISTRIBUTION of CONTENT may be issued within the ORIGINATING CN, or may also be issued within the - ENLISTED CN. + ENLISTED CN. The latter case allows local decisions to be made + about DISTRIBUTION within the ENLISTED CN, but such commands + would not control DISTRIBUTION within the ORIGINATING CN. 3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION actions will be made available to the ORIGINATING CN by the ENLISTED CN. 4. The ORIGINATING CN would provide this ACCOUNTING information to the PUBLISHER based on existing Service Level Agreements (SLAs). 5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within any of the ENLISTED CNs. @@ -311,21 +318,21 @@ FIGURE 1 - General CONTENT INTERNETWORKING +--------------+ +--------------+ | CN A | | CN B | |..............| +---------+ +---------+ |..............+ | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | - |--------------| +---------+ +---------+ +--------------+ + +--------------+ +---------+ +---------+ +--------------+ | ^ \^ \^ \^ ^/ ^/ ^/ | ^ v | \\ \\ \\ // // // v | +--------------+ \\ \\ \\ // // // +--------------+ | SURROGATES | \\ v\ v\ /v /v // | SURROGATES | +--------------+ \\+---------+// +--------------+ ^ | v| |v ^ | | | | CONTENT | | | | | |INTWRKING| | | | | | GATEWAY | | | | | | | | | @@ -404,21 +411,21 @@ +-----------+ ^| ^| ^| ^| +--------------+ // // \\ \\ +--------------+ | CN A | |v |v |v |v | CN B | |..............| +---------+ +---------+ |..............| | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | - |--------------| +---------+ +---------+ +--------------+ + +--------------+ +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / @@ -448,21 +455,21 @@ +-----------+ ^| ^| +--------------+ // \\ +--------------+ | CN A | |v |v | CN B | |..............| +---------+ +---------+ |..............| | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | - |--------------| +---------+ +---------+ +--------------+ + +--------------+ +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / @@ -504,21 +511,21 @@ +--------------+ +-----------+ \\ \\ ^| ^| ^| ^| \\ || +--------------+ || || || \\ || || +--------------+ | CN A | |v |v |v \v |v |v | CN B | |..............| +---------+ +---------+ |..............| | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>|INTWRKING| |INTWRKING|<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | - |--------------| +---------+ +---------+ +--------------+ + +--------------+ +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / @@ -542,21 +549,21 @@ FIGURE 5 - Multiple CNs ENLIST LCN +--------------+ +--------------+ | CN A | | CN B | |..............| +---------+ +---------+ |..............+ | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING | |..............| | CONTENT | | CONTENT | |..............| | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | - |--------------| +---------+ +---------+ +--------------+ + +--------------+ +---------+ +---------+ +--------------+ | ^ \^ \^ ^/ ^/ | ^ v | \\ \\ // // v | +--------------+ \\ \\ // // +--------------+ | SURROGATES | v\ v\ /v /v | SURROGATES | +--------------+ +---------+ +--------------+ | | | CONTENT | |INTWRKING| | GATEWAY | | | @@ -607,24 +614,24 @@ The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT), Christian Hoertnagl (IBM), Christian Langkamp (Oxford University), and Don Estberg (Activate). References [1] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for - Content Internetworking (CDI)", draft-ietf-cdi-model-00.txt + Content Internetworking (CDI)", draft-ietf-cdi-model-01.txt (work in progress), February 2002, . + 01.txt>. [2] Green, M., Cain, B., Tomlinson, G., Thomas, S., and P. Rzewski, "Content Internetworking Architectural Overview", draft-ietf- cdi-architecture-00.txt (work in progress), February 2002, . [3] Gilletti, D., Nair, R., Scharber, J., and J. Guha, "CDN-I Internetworking Authentication, Authorization, and Accounting Requirements", draft-ietf-cdi-aaa-reqs-00.txt (work in @@ -667,21 +674,21 @@ 4100 East Third Avenue MS FC2-4 Foster City, CA 94404 US Phone +1 650 653 2487 Email: philr@inktomi.com Full Copyright Statement - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of