idnits 2.17.1 draft-ietf-cdi-aaa-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 38 instances of too long lines in the document, the longest one being 10 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 == Line 291 has weird spacing: '...d by/to a CDN...' == Line 307 has weird spacing: '...e above menti...' == Line 320 has weird spacing: '...terface shall...' == Line 725 has weird spacing: '...ultiple excha...' -- 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 (June 13, 2002) is 7987 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) ** Downref: Normative reference to an Informational RFC: RFC 2904 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2975 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '3') -- 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' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Content Distribution Interworking D. Gilletti 3 Working Group CacheFlow, Inc. 4 Internet-Draft R. Nair 5 Expires: December 12, 2002 Cisco Systems 6 J. Scharber 7 CacheFlow, Inc. 8 J. Guha 9 Apogee Networks 10 D. Frascone 11 Blackstorm Networks 12 June 13, 2002 14 Content Distribution Interworking (CDI) AAA Requirements 15 draft-ietf-cdi-aaa-reqs-01 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 12, 2002. 40 Copyright Notice 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 44 Abstract 46 In developing a solution for CDN Internetworking it is necessary to 47 define and accommodate requirements for Authentication, 48 Authorization, and Accounting. Since the Authentication, 49 Authorization, and Accounting (AAA) working group is already focused 50 on defining these requirements, this document attempts to leverage 51 that work. It contains the requirements that would have to be 52 supported by a AAA service to formulate a solution for CDN peering. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Conventions used in this document . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Overview of Accounting Peering System . . . . . . . . . . 8 60 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.2 CDR Generation & Reception . . . . . . . . . . . . . . . . 10 63 4.3 Storage Requirements . . . . . . . . . . . . . . . . . . . 10 64 4.4 Authentication & Authorization . . . . . . . . . . . . . . 10 65 4.5 Measurement / Metering Systems . . . . . . . . . . . . . . 10 66 4.6 Inter-Domain Trust . . . . . . . . . . . . . . . . . . . . 11 67 4.7 Proxy CDN-I Account-Peering systems . . . . . . . . . . . 11 68 5. Accounting 'Works' . . . . . . . . . . . . . . . . . . . . 12 69 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.2 General Requirements . . . . . . . . . . . . . . . . . . . 12 71 5.2.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.2.2 Form-Factor of CDRs . . . . . . . . . . . . . . . . . . . 13 73 5.2.3 Timing Requirement of CDR exchange . . . . . . . . . . . . 13 74 5.2.4 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.2.5 Measures . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.2.6 Counters . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2.7 Name Space Convention (Distributed,Domained,Global) . . . 13 78 5.2.8 Security Requirements . . . . . . . . . . . . . . . . . . 14 79 5.3 Core Works Requirements . . . . . . . . . . . . . . . . . 14 80 5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.3.1.1 List of Attributes . . . . . . . . . . . . . . . . . . . . 14 82 5.3.1.2 Encoding and Representation . . . . . . . . . . . . . . . 14 83 5.3.1.3 Use Case Model . . . . . . . . . . . . . . . . . . . . . . 14 84 5.3.1.4 Work Flow Model . . . . . . . . . . . . . . . . . . . . . 15 85 5.3.1.5 Work State Model . . . . . . . . . . . . . . . . . . . . . 15 86 5.3.2 ContentInjection Work . . . . . . . . . . . . . . . . . . 15 87 5.3.3 ContentDistribution Work . . . . . . . . . . . . . . . . . 16 88 5.3.4 ContentRequest Work . . . . . . . . . . . . . . . . . . . 16 89 5.3.5 ContentRetrieval Work . . . . . . . . . . . . . . . . . . 17 90 5.3.6 ContentServiceDelivery Work . . . . . . . . . . . . . . . 18 91 6. Data Exchange Mechanism / Protocol . . . . . . . . . . . . 20 92 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 93 6.2 General Requirements . . . . . . . . . . . . . . . . . . . 20 94 6.2.1 Separation of Exchange Protocol from CDR payload . . . . . 20 95 6.2.2 Transfer Capability Negotiation . . . . . . . . . . . . . 20 96 6.2.3 Singular, Batched, Flow, & RealTime Modes of Data Exchange 20 97 6.2.4 Efficient Encoding . . . . . . . . . . . . . . . . . . . . 20 98 6.2.5 Transfer Flow & Rate Control . . . . . . . . . . . . . . . 20 99 6.2.6 Guaranteed Delivery . . . . . . . . . . . . . . . . . . . 20 100 6.2.7 CDR Relationship Identifiers . . . . . . . . . . . . . . . 21 101 6.2.8 Protocol State Machines . . . . . . . . . . . . . . . . . 21 102 6.2.9 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 21 103 6.3 Authorization and Authentication . . . . . . . . . . . . . 21 104 6.4 CDR Receivers . . . . . . . . . . . . . . . . . . . . . . 21 105 6.5 CDR Generators : . . . . . . . . . . . . . . . . . . . . . 21 106 6.6 Fault-Tolerance . . . . . . . . . . . . . . . . . . . . . 21 107 7. Further Issues . . . . . . . . . . . . . . . . . . . . . . 23 108 8. Recommendations . . . . . . . . . . . . . . . . . . . . . 24 109 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 25 110 References . . . . . . . . . . . . . . . . . . . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 26 112 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 28 113 Full Copyright Statement . . . . . . . . . . . . . . . . . 29 115 1. Introduction 117 The initial model for the World Wide Web (WWW) was based on clients 118 interacting with origin servers to request and receive content or 119 services. As the Web increased in scale this model proved unwieldy 120 for several reasons and resulted in current industry efforts to build 121 and operate Content Distribution Networks or CDNs. The overall 122 purpose of these CDNs is to create a scalable service that can meet 123 aggregate client demand while improving the performance and quality 124 of delivery. With increased demand for CDN services a need has been 125 generated for a mechanism for interconnecting or peering these 126 systems. 128 A typical CDN has relationships with publishers and provides them 129 with accounting and access related information. This information is 130 typically provided in the form of aggregate or detailed log files. 132 In addition, these CDNs typically collect accounting information to 133 aid in operation, billing and SLA verification. Since all accounting 134 data is collected within the CDN's administrative domain there is no 135 requirement for generalized systems or protocols. 137 Peering or interconnecting these CDNs introduces the need to obtain 138 similar accounting data from a foreign domain. This requirement 139 means that customers of a peered CDN service (publishers, clients, 140 and CDNs) must now have a generalized or standard means of obtaining 141 accounting information to support current as well as planned business 142 models. For example, the desire to implement business models such as 143 "Pay Per View" may require that there exist a mechanism for 144 authenticating and authorizing clients at a delivery point that lies 145 in a foreign domain. 147 This document is focused on describing requirements for the 148 Accounting Peering System as described in [7] 150 This document frames the requirements for the Accounting Peering 151 System against the ongoing work of the AAA working group. This was 152 done because the authors realized that considerable effort has 153 already been expended in identifying inter-domain trust models and 154 accounting requirements within that working group. Therefore, a 155 conscious decision has been made to leverage that existing body of 156 work before making additional proposals. As such, this document 157 relies heavily on RFC 2904 [1], RFC 2975 [2], and RFC 2977 [3]. 159 Since the concentration of this effort is to determine the 160 requirements for CDN internetworking / peering, the accounting 161 requirements within an individual CDN are largely ignored within this 162 document. 164 The core actions and activities within the CDN-I domain is 165 essentially enumerated as Content Injection, Content Distribution, 166 Content Request, Content/Service Delivery, and Content Retrieval. 167 These are the primary activities that need to be tracked and 168 accounted. Please refer architectural diagrams in [5], [6], and [7]. 170 This document focuses and details the requirements on the digital 171 representation of the above activities, along with the means and 172 mechanisms to exchange these representations between peering parties 173 which have participated in the activity, and/or any other component 174 in a secure and guaranteed manner. 176 Requirements for the remaining CDI architectural elements, the 177 Request Routing System, which is responsible for directing user 178 agents to the distributed content, and the Distribution Peering 179 Requirements for CDI, which is responsible for distributing content 180 between a CDN and the elements that it, are detailed in [8], [9]. 182 1.1 Conventions used in this document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [4]. 188 2. Terminology 190 This section introduces new terminology not already defined in < RFC 191 2975 [2], RFC 2977 [3], or [5] 193 CDN Service: An action that is directly or indirectly related to the 194 act of moving content from publisher to consumer. 196 Customer: A billable entity (typically a publisher, client or peered 197 CDN) that agrees to exchange compensation for a CDN Service. 199 Entitlement: A right to access a given CDN Service or content object 200 typically provided to a customer by a provider. 202 Flat Rate: Indicates there is no limit on the amount of CDN Service 203 that a customer can consume during a Period. 205 Percentile: Indicates that a CDN Service will be billed at a rate 206 that is based on a multiplier (Usage Rate) times the Usage during 207 the Period. 209 Period: The duration for which the Usage counter or Entitlement is 210 active. 212 Provider: An entity that offers a CDN Service in exchange for 213 Compensation. 215 Unit Of Measure (UOM): Indicates how Usage should be tracked (i.e. 216 minutes, seconds, bytes, etc). 218 Usage: A counter that measures the access or use of a CDN Service by 219 the Customer. 221 Usage Rate: A per-unit cost associated with the Usage of a CDN 222 Service. 224 Pricing / Rating Tiers: Indicates the existence of a schedule against 225 which Usage of a given CDN Service is tracked and billed. 227 Work: This is the definition of an activity in which a CDN partakes 228 by providing a specific function, role or service. These 229 activities are restricted to only those which involve the 230 participation of peering entities outside the CDNs administrative 231 domain. 233 Tier: This is the conceptual enclosure of a specific function (such 234 as accounting, settlement, rating, billing, invoicing, payment, 235 provisioning etc) in the context of a layered / phased multi- 236 function environment. 238 CDR (Content Detail Record): This is the digital entity which capture 239 the 'what', 'who', 'when', 'where', and 'how' of the work done. 241 3. Overview of Accounting Peering System 243 The Accounting Peering system is responsible for the definition, 244 generation and exchange of usage / consumption data entities (CDRs) 245 which depict the activities and works performed, requested, and 246 completed between peering CDNs, and any component internetworking 247 with a CDN. These CDRs typically will contain 'what work was done', 248 'who did the work', 'when was the work done', 'how was the work 249 done', 'Resources Used' etc. 251 --------------------------------------------------------------------- 253 * * 254 +---------------+ * * +---------------+ 255 | Origin | * ==== ContentInjection =====> * | CDN X | 256 +---------------+ * <==== ContentRequest ======= * |...............| 257 * * | | 258 +---------------+ * <==== ContentDistribution ==> * |...............| 259 | Peering CDN | * <==== ContentRetrieve ======> * | | 260 +---------------+ * * |...............| 261 * * | | 262 +---------------+ * <==== ContentServiceDelivery= * | | 263 | Client | * =====ContentRequest =====> * | | 264 + --------------+ * * +---------------+ 265 * * 266 * * 267 Acct-CPG Acct-CPG 269 Figure 1: Accounting Peering System Components and Activities 271 --------------------------------------------------------------------- 273 The above diagram (Figure 1) illustrates the architectural entities 274 which will internetwork with a CDN as well as the activities that 275 transpire between any two peering entities . Each activity is to be 276 considered as discrete accountable events in their own right. The 277 arrows indicate the parties and roles involved in each activity as 278 each activity has a source and destination role in the communications 279 exchange (note : the arrows do not indicate who is generating / 280 receiving the CDR ) 282 The model above allows for complex chaining and sequencing of 283 activities which express the relationship of interoperations that a 284 typical CDN will encounter. 286 The core activities (as described above) that need to be accounted 287 are ContentInjection, ContentDistribution, ContentRequest, 288 ContentRetrieval, and ContentServiceDelivery. The activities above 289 cannot span multiple internetworking hops. 291 Each independent piece of activity or work performed by/to a CDN, 292 can be transmitted and collected by any entity or instrumentation, 293 which implements the Accounting-Peering System Interface(Acct-CPG). 295 It is envisioned that each CDN would have an instrumentation platform 296 which would detect or be informed of the activities described above. 297 This platform or detection mechanism is not in-scope of Acct-CPG. 299 A transport protocol would be used to exchange CDRs between an entity 300 which generates a CDR, and an entity which receives a CDR. 301 Presumably, the entity which is capable of detecting the activity 302 will be the entity that generates the CDR to an entity interested in 303 receiving the CDR. The Acct-CPG interface will not specify which 304 entity can, must, or should implement the Acct-CPG interface. 306 Accounting systems in general will have to support the real-time 307 occurrence of the above mentioned activities. That is when the 308 activities do take place, the activity must be recorded and not lost. 309 Reliability of recording accountable events/activities is required or 310 otherwise the accounting infrastructure will be compromised. However 311 the Acct-CPG will not specify the mechanism to record the activities 312 that have occurred, but will solely impress upon the necessity of 313 reliability and integrity in the process of activity detection, and 314 recording. 316 The nature of certain activities may also span a segment of time from 317 activity initiation to completion. Acct-CPG systems shall be able to 318 generate interim, and composite CDRs of each discrete activity which 319 depict the passage of time and states of an activity. Thus, the 320 Acct-CPG interface shall be charged with the responsibility of 321 support for interim and composite CDRs, and support for real time 322 and/or offline/batch exchange of accountable works / activities. 324 The Accounting data entities (CDRs) may be used by other downstream 325 functional tiers such as Rating & Billing, Capacity Planning, 326 Performance & Monitoring Analysis, Payment systems, Account 327 Management, Settlement Systems etc. These downstream tiers are 328 considered out-of-scope, but the solution should not be incompatible 329 with this functionality 331 4. Assumptions 333 Certain assumptions/expectations of the operating environment are 334 detailed below. Should any of the assumptions change, there may be 335 material implications on the requirements of the CDN-I Accounting 336 Peering (Acct-CPG) systems. 338 4.1 Firewalls 340 There are no firewalls between the path of the Accounting Peering 341 Systems. Peering CDN-I Accounting systems can establish a 342 communication channel between themselves provided they have the 343 appropriate and valid trust credentials. 345 4.2 CDR Generation & Reception 347 Any entity (network element or service element) can be a CDR 348 Generator and/or a CDR Receiver as long as the entity is 'CDN-I Acct- 349 CPG' enabled. 351 4.3 Storage Requirements 353 The CDN-I Accounting Peering requirements shall not place any 354 constraints or restrictions on the storage of CDRs. CDR Storage is 355 essentially out of scope. However, to provide fail-over and recovery 356 in the data exchange protocol, there most likely will be storage 357 implications for an entity to be considered 'CDN-I Accounting 358 Peering' enabled. 360 4.4 Authentication & Authorization 362 The CDN-I Accounting Peering requirements shall only exchange 363 Authentication & Authorization Messages to enable the exchange of 364 CDRs. The policies, and mechanisms which influence these 365 Authentication and Authorizations messages are to be provided and 366 maintained by an external functional component or process, and are to 367 be considered out-of-scope, except to the extent that it influences 368 the requirements of accounting data exchange. 370 4.5 Measurement / Metering Systems 372 Instrumentation (hard and/or soft) exists on the CDN-I network which 373 can detect, recognize, and inform an Accounting-Peering System when a 374 ContentInjection, ContentDistribution, ContentRequest, 375 ContentRetrieval, and ContentServiceDelivery act / event has taken 376 place. 378 4.6 Inter-Domain Trust 380 All systems are conformant with the AAA Authentication and 381 Authorization Framework for Inter-Domain trust. Refer [1] 383 4.7 Proxy CDN-I Account-Peering systems 385 If Accounting-Peering (Acct-CPG) system communicate through 386 intermediate Acct-CPG systems, it is necessary that the CDR payload 387 is secure between the originator Acct-CPG and target Acct-CPG server. 388 The security requirement may be end-to-end security, CDR payload 389 integrity, confidentiality, replay protection, and non-repudiation. 390 Refer [1]. 392 5. Accounting 'Works' 394 The objective of this section is to define the requirement of a 395 scalable framework for depicting all the various acts / services / 396 'works' performed by any entity which internetworks with a CDN, and 397 which needs to be accounted. It is envisioned that a finite (core) 398 set of works will need to be defined so as to achieve initial 399 adoption and traction. Thereafter the framework must accommodate 400 expansion of acts / services / work in the CDN Internetworking 401 domain. 403 5.1 Introduction 405 An expression of 'work' performed consists of a collection/sequence 406 of attributes which consist of identifiers, measures, and counters. 407 The attributes serve to answer the who, what, where, and how of these 408 elements of usage or acts of consumption (CDRs). 410 For the CDN peering/interconnection scenario, it is important to 411 construct the expressions/acts of consumption such that there is no 412 dispute and ambiguity in meaning between parties producing and 413 receiving these expressions. In each act of consumption, there is a 414 minimum set of attributes in which an act/expression of consumption/ 415 usage is considered "complete and indisputable" and therefore able to 416 be used by any downstream tiers (ex : rating and billing). 418 5.2 General Requirements 420 5.2.1 Framework 422 A framework which can accommodate the scalable definition of CDRs is 423 required. This framework shall be able to introduce new CDRs and 424 their associated schemas at a later time frame. 426 The framework must ensure that 'Context' of the CDR payload is 427 available to any party such that domains / scope of CDR and attribute 428 applicability / validity is defined. 'Context' will mean roles of 429 participating entities, domain, and scope. There shall be no 430 overloading of attribute meanings. Every measure and counter must 431 have have units, minima and maxima, and incrementals defined. Every 432 identifier must be persistent within a defined domain and time frame. 433 Decisions on in-band or out-of-band context embedding will be needed 434 and shall be defined in the framework. The framework shall support 435 self-description of the usage attributes. 437 This framework shall NOT define any actions, rules, constraints and 438 context with regards to the processing of CDRs. 440 XML technology should be considered as a vehicle to achieve the above 441 framework. Other strategies can also be considered if the end-value 442 is achievable. 444 5.2.2 Form-Factor of CDRs 446 The representation and form-factor of the CDRs must also be 447 addressed. Binary based and character based form factors need to be 448 supported. 450 5.2.3 Timing Requirement of CDR exchange 452 Certain CDRTypes will have delivery requirements which meet timing 453 constraints. For each independent operating scenario and 'work' 454 (CDR) type, requirements on CDR transport exchange and timings need 455 to be assessed. It will be required to specify timing constraints 456 for certain CDR Types, and will be used by the data exchange protocol 457 during the channel setup phase. 459 5.2.4 Identifiers 461 An identifier is an attribute which associates a name convention to 462 an entity. Examples of identifies are OrganizationName, EndUserName, 463 Name of Movie, ContentID etc These identifiers can and do have 464 properties and characteristics such as persistence, scope & domain, 465 time-to-live etc. In the accounting context, these identifiers must 466 be resolvable, unambiguous, recoverable and unique in the applicable 467 domain. 469 5.2.5 Measures 471 Measures are attributes that help to describe 'how' a certain piece 472 of work was performed, delivered or consumed. Typical examples are 473 QoS, JitterDelay, etc. Measures need to be defined completely and 474 without ambiguity by defining known minima, maxima, unit of 475 increments etc. The definition of measures must remain persistent 476 and consistent within its scope and domain. 478 5.2.6 Counters 480 Counters are attributes that help to describe the quantity of 481 resources consumed by a singular accountable act / work. Typically 482 Counters must be defined by its units, minima and maxima and the 483 mathematical operations that are permissible on a counter. 485 5.2.7 Name Space Convention (Distributed,Domained,Global) 487 In a distributed environment, a domain consistent way of naming 488 entities such as a customer, ContentID, ContentType etc is required, 489 so that any member participating in the CDN Internetworking 490 activities can be consistently identified. The scope / domain of 491 applicability of every identifier must be referenceable by any party 492 participating in the work represented by the specific CDR, and / or 493 by any party involved in the exchange of the specific CDR. 495 Likewise, the framework must also provision a Name Space mechanism 496 for naming a specific content within the federation. For example, a 497 specific movie or song might need to be named in the same way in all 498 of the different points of the federation, independently of the 499 domain that is delivering the specific content. This SHOULD follow a 500 standard that can be interpreted by every member of the federation. 502 5.2.8 Security Requirements 504 This document assumes that the solutions suggested within this 505 document will be compliant with the trust model given in RFC 2904 506 [1]. 508 5.3 Core Works Requirements 510 This section defines those 'work' items that form the initial core 511 set of 'works' that must be supported by any 'CDN-I Accounting' 512 enabled entity. The objective here is to achieve consensus around a 513 set of accountable works which are deemed sufficiently important such 514 that its definition and support is warranted. 516 5.3.1 Introduction 518 For each of the accountable works defined below in the subsections, 519 the following must be defined : 521 5.3.1.1 List of Attributes 523 Each attribute must define its name, its meaning, whether it is a 524 required / optional / conditional attribute, its data type (int, 525 string, complex etc) 527 5.3.1.2 Encoding and Representation 529 The encoding and representation format of each attribute inside the 530 CDR must be defined. 532 5.3.1.3 Use Case Model 534 Generally describes the involved entities in the creation of the CDR. 535 The 'Context' of the CDR will most likely be defined here as well. 537 5.3.1.4 Work Flow Model 539 Details the sequencing of events of the involved entities which 540 generates the CDR and where the CDR has to be sent. 542 5.3.1.5 Work State Model 544 Details the state transition diagram of the 'Work' by defining the 545 triggers and the state of work from inception to completion. The 546 'State' of Work may or may not be distributed across one or more 547 elements in the federation. 549 5.3.2 ContentInjection Work 551 This 'work' is the event(CDR) that represents the act of a Host 552 Origin Server which successfully 'injects' a piece of 'content' into 553 a CDN for further distribution. An example scenario is where a 554 Content Provider or a Publisher wishes to distribute content. The 555 Publisher typically transfer the relevant content to a CDN Service 556 Provider. This transaction is referred to as Injection. 558 --------------------------------------------------------------------- 560 A logical representation of this CDR is as below : 562 | CDRType | TimeStamp | ContentID | ContentType | OriginID | CDN_ID | 563 ContentByteSize | State | ErrorCode | 565 Attribute Name | Type | Description 566 ---------------------------------------------------------------------------- 567 CDRType | String| Type of CDR (Value = ContentInjection) 568 TimeStamp | Long | Time of Content Injection transaction (Start/End) 569 ContentURI | String| Unique identifier for the injected content 570 ContentType | String| Type of Content (WebPage, Movie, Song etc) 571 Origin ID | String| Unique Identifier for Content Source 572 CDN_ID | String| Unique Identifier for CDN ServiceProvider 573 ContentByteSize | Long | Size of Content Injected in Bytes 574 State | String| State of Injection (start,complete,error) 575 ErrorCode | String| UnAuthorized,UnAuthenticated,TimeOut,etc 577 Figure 2: Content Injection CDR 579 --------------------------------------------------------------------- 581 5.3.3 ContentDistribution Work 583 This 'work' is the event (CDR) that represents the act where a CDN 584 'distributes' the 'content' to another peering CDN. 586 --------------------------------------------------------------------- 588 A logical representation of this CDR is as below : 590 | CDRType | TimeStamp | Content_ID | ContentType | CDNSrcID | CDNDestID| 591 | ContentByteSize | State | ErrorCode | 593 Attribute Name | Type | Description 594 ---------------------------------------------------------------------------- 595 CDRType | String| Type of CDR (Value = ContentDistribution) 596 TimeStamp | Long | Time of Content Distribution transaction (start/end) 597 ContentURI | String| Unique identifier of content to be distributed 598 ContentType | String| Type of Content (WebPage, Movie, Song etc) 599 CDNSrcID | String| Unique Identifier of src distributing content 600 CDNDestID | String| Unique Identifier of dest receiving content 601 ContentByteSize | Long | Size of Content distributed in Bytes 602 State | String| Distribution State (start,complete,error) 603 ErrorCode | String| UnAuthorized,UnAuthenticated,TimeOut,etc 605 Figure 3: Content Distribution CDR 607 --------------------------------------------------------------------- 609 5.3.4 ContentRequest Work 611 This transaction is the event (CDR) that represents the act where an 612 end-user (EU) request access to a specific Content. 614 --------------------------------------------------------------------- 616 A logical representation of this CDR is as below : 618 | CDRType | TimeStamp | ContentURI | ContentType | ContentByteSize | 619 | RequesterID | ReceiverID | State | ErrorCode | 621 Attribute Name | Type | Description 622 ------------------------------------------------------------------------------ 623 CDRType |String| Type of CDR (Value = ContentRequest) 624 TimeStamp | Long | Time of content request transaction (start/end) 625 ContentURI |String| Unique identifier for the content to be distributed 626 ContentType |String| Type of Content (WebPage, Movie, Song etc) 627 RequesterID |String| Unique Identifier for entity requesting the content 628 ReceiverID |String| Unique Identifier for entity receiving request 629 ContentByteSize |Long | Size of Content distributed in Bytes 630 State |String| State of Request (start,complete,error) 631 ErrorCode |String| UnAuthorized,UnAuthenticated,TimeOut,etc 633 Figure 4: Content Request CDR 635 --------------------------------------------------------------------- 637 5.3.5 ContentRetrieval Work 639 This transaction is the event (CDR) that represents the act where 640 when a Content Request 'Miss' occurs, the 'content' is retrieved 641 from the origin server and delivered to the element (CDN / cache) 642 where the miss occurred. 644 --------------------------------------------------------------------- 646 A logical representation of this CDR is as below : 648 | CDRType | TimeStamp | ContentURI | ContentType | ContentByteSize | 649 | Origin_ID | Receiver_ID | State | ErrorCode | 651 Attribute Name | Type | Description 652 ---------------------------------------------------------------------------- 653 CDRType |String | Type of CDR (Value = ContentRetrieval) 654 TimeStamp | Long | Time of Content Retrieval transaction (start/end) 655 ContentURI |String | Unique identifier for the retrieved content 656 ContentType |String | Type of Content (WebPage, Movie, Song etc) 657 Origin ID |String | Unique Identifier for Content Source 658 Receiver_ID |String | Unique Identifier for receiver of content retrieved 659 ContentByteSize | Long | Size of Content Injected in Bytes 660 State |String | State of Injection (start,complete,error) 661 ErrorCode |String | UnAuthorized,UnAuthenticated,TimeOut,etc 663 Figure 5: Content Retrieval CDR 665 --------------------------------------------------------------------- 667 5.3.6 ContentServiceDelivery Work 669 This transaction is the event (CDR) that represents the act where a 670 CDN delivers the Content requested to the entity which requested the 671 content. 673 --------------------------------------------------------------------- 675 A logical representation of this CDR is as below : 677 | CDRType | TimeStamp | ContentServiceURI | ContentServiceType | 678 | ContentByteSize | DelivererID | ReceiverID | State | ErrorCode | 680 Attribute Name | Type | Description 681 ---------------------------------------------------------------------------- 682 CDRType |String | Type of CDR (Value = Content/Service Delivery) 683 TimeStamp |Long | Time of Content Delivery transaction (start/end) 684 Content/ServiceURI |String | Unique identifier the delivered content/service 685 Content/ServiceType|String | Type of Content/Service (WebPage, Movie, Song etc) 686 DeliveryMode |String | mode of delivery (stream, filetransfer, http, etc) 687 DelivererID |String | Unique Identifier of entity delivering the content 688 ReceiverID |String | Unique Identifier for entity receiving the content 689 ContentByteSize |Long | Size of Content Injected in Bytes 690 State |String | State of Delivery (start,complete,error) 691 ErrorCode |String | UnAuthorized,UnAuthenticated,TimeOut,etc 693 Figure 6: Content Service Delivery CDR 695 --------------------------------------------------------------------- 697 6. Data Exchange Mechanism / Protocol 699 6.1 Introduction 701 This objective of this section is to develop the requirements of a 702 transport mechanism which shall be responsible for the transfer / 703 exchange of a 'Work/Activity' (CDR) from one entity to another 704 entity. 706 6.2 General Requirements 708 This section details some of the general requirements of a transport 709 protocol. 711 6.2.1 Separation of Exchange Protocol from CDR payload 713 The transfer protocol must be cleanly decoupled from the CDR payloads 714 that it will transfer. 716 6.2.2 Transfer Capability Negotiation 718 Support for push, pull and poll transfers modes need to be supported. 720 6.2.3 Singular, Batched, Flow, & RealTime Modes of Data Exchange 722 The transport protocol shall support batch, flow, and real-time modes 723 of exchange of CDR payloads. Support for multiple channels of 724 transport must exist to accommodate multiple varying throughput rate 725 requirements, and/or multiple exchange modes between the accounting 726 peering parties which occur at the same time. A specific transport 727 channel shall be able to exchange multiple CDRs of a singular 728 CDRType. That is, mixed CDRTypes within a singular channel is not 729 supported. 731 6.2.4 Efficient Encoding 733 6.2.5 Transfer Flow & Rate Control 735 The transfer protocol shall support flow control mechanisms to 736 achieve sustainable delivery throughput between the two data exchange 737 peers. 739 6.2.6 Guaranteed Delivery 741 It is to be assumed that all works that are to be accounted for MUST 742 never be lost. Therefore all transfer modes must achieve reliable 743 and guaranteed delivery of CDR payloads. Unless there is a 744 compelling case for an non-guaranteed delivery requirement, this 745 assumption and requirement shall stand. 747 6.2.7 CDR Relationship Identifiers 749 CDR EventIdentifiers (unique) may be required if relationships exist 750 across a set of CDRs. Situations where interim CDRs are generated, 751 it is necessary to track the sequencing of a related set to ensure 752 completeness, detect errors, and the retransmission of CDRs. If 753 relationships of a set of CDR spans a distributed domain, then a 754 distributed numbering strategy must exist. 756 6.2.8 Protocol State Machines 758 Clear visualization of transport protocol state machines in the 759 sender and receiver must be developed. 761 6.2.9 Encryption 763 It is recommended that encryption works from other IETF standards be 764 leveraged to ensure data / CDR security. 766 6.3 Authorization and Authentication 768 Authorization and authentication mechanisms must exist in the data 769 exchange protocol to enable the initiation of data exchange. This 770 mechanism may be influenced by external (out-of-scope) policy and 771 control mechanisms / processes which precede the transfer / exchange 772 of CDRs. 774 6.4 CDR Receivers 776 Any entity that is 'CDN-I Accounting' enabled is eligible to receive 777 a CDR. To enable the delivery of CDRs, the CDR Receiver must contact 778 a CDR Generator and establish a channel. A channel must only be able 779 to transfer CDRs of a singular CDRType. 781 6.5 CDR Generators : 783 Only 1 CDR must be generated for a singular incidence of 'work'. Any 784 entity which is 'CDN-I Accounting' enabled, is eligible to generate 785 the CDR. The CDR Generator entity must be able to support the 786 delivery of a CDR stream to multiple recipients if a single channel 787 has been created between each recipient and the CDR Generator. 789 6.6 Fault-Tolerance 791 Fault Tolerance, fail-over, and recovery mechanism mechanisms are 792 required to insure against network failure, accounting peering 793 component failure, packet loss, and/or device reboots. 795 7. Further Issues 796 8. Recommendations 798 [Editor's Note: This section is here only to record some ideas that 799 need to be discussed while this specification is being progressed.] 801 One means of accommodating these types of services is to build off of 802 the ongoing work of the IETF AAA working group [2]. At present this 803 work is centered on the Diameter framework and protocol suite for 804 both provisioning and accounting. Early observations indicate that 805 Diameter has several characteristics that are desirable for 806 consideration in fulfilling these accounting requirements. The high 807 point characteristics are that it: 809 Has a model that supports either direct aggregation to home 810 provider 3rd party brokering. 812 Has well developed security and trust relationships. 814 Supports standardized, extensible accounting record format. 816 Is generally extensible. 818 Has hop-by-hop, as well as end-to-end encryption support. 820 9. Conclusion 822 There is a considerable amount of work remaining in defining the 823 accounting requirements and relationships. As such, the authors 824 welcome additional input from interested parties. 826 References 828 [1] "AAA Authorization Framework", August 2000, . 831 [2] "Introduction to Accounting Management", October 2000, . 834 [3] "Mobile IP Authentication, Authorization, and Accounting 835 Requirements", October 2000, . 838 [4] "Key words for use in RFCs to Indicate Requirement Levels", 839 March 1997, . 841 [5] "A Model for Content Internetworking (CDI)", February 2002, 842 . 845 [6] "Content Internetworking (CDI) Scenarios", February 2002, 846 . 849 [7] "Content Internetworking Architectural Overview", February 2002, 850 . 853 [8] "Request-Routing Requirements for Content Internetworking", 854 February 2002, . 857 [9] "Distribution Requirements for Content Internetworking", 858 February 2002, . 861 Authors' Addresses 863 Don Gilletti 864 CacheFlow, Inc. 865 551 Moffett Park Drive 866 Sunnyvale, CA 94089 867 USA 869 Phone: +1 408 543 0437 870 EMail: don@cacheflow.com 871 Raj Nair 872 Cisco Systems 874 John Scharber 875 CacheFlow, Inc. 876 551 Moffett Park Drive 877 Sunnyvale, CA 94089 878 USA 880 EMail: john.scharber@cacheflow.com 882 Jay Guha 883 Apogee Networks 884 Park 80 West, Plaza II 885 Saddle Brook, NJ 886 USA 888 Phone: +1 201 368 8800 889 EMail: jayg@apogeenet.com 891 David Frascone 892 Blackstorm Networks 893 250 Cambridge Avenue, Suite 200 894 Palo Alto, CA 94306 895 USA 897 Phone: +1 972 524 6346 898 EMail: codemonkey@bstormnetworks.com 900 Appendix A. Acknowledgments 902 The authors acknowledge the contributions and comments of Brad Cain 903 (Mirror Image), Mark Day (Cisco), Fred Douglis (AT&T), John Martin 904 (Network Appliance), Doug Potter (Cisco), Oliver Spatscheck (AT&T), 905 Gary Tomlinson (Entera), Lisa Amini (IBM) and Abhi Deskmukh (Apogee). 907 Full Copyright Statement 909 Copyright (C) The Internet Society (2002). All Rights Reserved. 911 This document and translations of it may be copied and furnished to 912 others, and derivative works that comment on or otherwise explain it 913 or assist in its implementation may be prepared, copied, published 914 and distributed, in whole or in part, without restriction of any 915 kind, provided that the above copyright notice and this paragraph are 916 included on all such copies and derivative works. However, this 917 document itself may not be modified in any way, such as by removing 918 the copyright notice or references to the Internet Society or other 919 Internet organizations, except as needed for the purpose of 920 developing Internet standards in which case the procedures for 921 copyrights defined in the Internet Standards process must be 922 followed, or as required to translate it into languages other than 923 English. 925 The limited permissions granted above are perpetual and will not be 926 revoked by the Internet Society or its successors or assigns. 928 This document and the information contained herein is provided on an 929 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 930 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 931 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 932 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 933 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 935 Acknowledgement 937 Funding for the RFC Editor function is currently provided by the 938 Internet Society.