idnits 2.17.1 draft-ietf-cdni-logging-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2013) is 3958 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 1491, but not defined == Unused Reference: 'RFC2119' is defined on line 1725, but no explicit reference was found in the text == Unused Reference: 'RFC5424' is defined on line 1749, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-01 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-03 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-07 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Bertrand, Ed. 3 Internet-Draft I. Oprescu, Ed. 4 Intended status: Informational France Telecom - Orange 5 Expires: December 27, 2013 F. Le Faucheur, Ed. 6 Cisco Systems 7 R. Peterkofsky 8 Skytide, Inc. 9 June 25, 2013 11 CDNI Logging Interface 12 draft-ietf-cdni-logging-04 14 Abstract 16 This memo specifies the Logging interface between a downstream CDN 17 (dCDN) and an upstream CDN (uCDN) that are interconnected as per the 18 CDN Interconnection (CDNI) framework. First, it describes a 19 reference model for CDNI logging. Then, it specifies the CDNI 20 Logging File format and the actual protocol for exchange of CDNI 21 Logging Files. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 27, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5 72 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5 73 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8 74 2.2.1. Logging Generation and During-Generation Aggregation 9 75 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 76 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 77 2.2.4. Logging Rectification and Post-Generation Aggregation 11 78 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 11 79 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 11 80 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12 81 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12 82 2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 12 83 2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13 84 2.2.5.6. Notions common to multiple Log Consuming 85 Applications . . . . . . . . . . . . . . . . . . 13 86 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15 87 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16 89 3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 18 90 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 21 91 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 22 92 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 29 93 4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 30 94 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 31 95 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 31 96 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 98 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 33 99 6.2. CDNI Logging Record-Type Registry . . . . . . . . . . . . 34 100 6.3. CDNI Logging Field Name Registry . . . . . . . . . . . . 34 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 102 7.1. Authentication, Confidentiality, Integrity Protection . . 35 103 7.2. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 36 104 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 36 105 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 108 9.2. Informative References . . . . . . . . . . . . . . . . . 37 109 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 38 110 A.1. Compliance with cdni-requirements . . . . . . . . . . . . 38 111 A.2. Additional Requirements . . . . . . . . . . . . . . . . . 39 112 A.2.1. Timeliness . . . . . . . . . . . . . . . . . . . . . 39 113 A.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 39 114 A.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 39 115 A.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . 39 116 A.2.5. Consistency between CDNI Logging and CDN Logging . . 40 117 A.2.6. Dispatching/Filtering . . . . . . . . . . . . . . . . 40 118 Appendix B. Analysis of candidate protocols for Logging 119 Transport . . . . . . . . . . . . . . . . . . . . . 40 120 B.1. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . 40 121 B.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 122 B.3. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 125 1. Introduction 127 This memo specifies the Logging interface between a downstream CDN 128 (dCDN) and an upstream CDN (uCDN). First, it describes a reference 129 model for CDNI logging. Then, it specifies the CDNI Logging File 130 format and the actual protocol for exchange of CDNI Logging Files. 132 The reader should be familiar with the following documents: 134 o CDNI problem statement [RFC6707] and framework 135 [I-D.ietf-cdni-framework] identify a Logging interface, 137 o Section 8 of [I-D.ietf-cdni-requirements] specifies a set of 138 requirements for Logging, 140 o [RFC6770] outlines real world use-cases for interconnecting CDNs. 141 These use cases require the exchange of Logging information 142 between the dCDN and the uCDN. 144 As stated in [RFC6707], "the CDNI Logging interface enables details 145 of logs or events to be exchanged between interconnected CDNs". 147 The present document describes: 149 o The CDNI Logging reference model (Section 2), 151 o The CDNI Logging File format (Section 3), 153 o The CDNI Logging File Exchange protocol (Section 4). 155 1.1. Terminology 157 In this document, the first letter of each CDNI-specific term is 158 capitalized. We adopt the terminology described in [RFC6707] and 159 [I-D.ietf-cdni-framework], and extend it with the additional terms 160 defined below. 162 For clarity, we use the word "Log" only for referring to internal CDN 163 logs and we use the word "Logging" for any inter-CDN information 164 exchange and processing operations related to CDNI Logging interface. 165 Log and Logging formats may be different. 167 CDN Logging information: logging information generated and collected 168 within a CDN 170 CDNI Logging information: logging information exchanged across CDNs 171 using the CDNI Logging Interface 173 Logging information: logging information generated and collected 174 within a CDN or obtained from another CDN using the CDNI Logging 175 Interface 177 CDNI Logging Field: an atomic element of information that can be 178 included in a CDNI Logging Record. The time an event/task started, 179 the IP address of an End user to whom content was delivered, and the 180 URI of the content delivered are examples of CDNI Logging Fields. 182 CDNI Logging Record: an information record providing information 183 about a specific event. This comprises a collection of CDNI Logging 184 Fields. 186 CDNI Logging File: a file containing CDNI Logging Records, as well as 187 additional information facilitating the processing of the CDNI 188 Logging Records. 190 CDN Reporting: the process of providing the relevant information that 191 will be used to create a formatted content delivery report provided 192 to the CSP in deferred time. Such information typically includes 193 aggregated data that can cover a large period of time (e.g., from 194 hours to several months). Uses of Reporting include the collection 195 of charging data related to CDN services and the computation of Key 196 Performance Indicators (KPIs). 198 CDN Monitoring: the process of providing content delivery information 199 in real-time. Monitoring typically includes data in real time to 200 provide visibility of the deliveries in progress, for service 201 operation purposes. It presents a view of the global health of the 202 services as well as information on usage and performance, for network 203 services supervision and operation management. In particular, 204 monitoring data can be used to generate alarms. 206 2. CDNI Logging Reference Model 208 2.1. CDNI Logging interactions 210 The CDNI logging reference model between a given uCDN and a given 211 dCDN involves the following interactions: 213 o customization by the uCDN of the CDNI logging information to be 214 provided by the dCDN to the uCDN (e.g. control of which logging 215 fields are to be communicated to the uCDN for a given task 216 performed by the dCDN, control of which types of events are to be 217 logged). The dCDN takes into account this CDNI logging 218 customization information to determine what logging information to 219 provide to the uCDN, but it may, or may not, take into account 220 this CDNI logging customization information to influence what CDN 221 logging information is to be generated and collected within the 222 dCDN (e.g. even if the uCDN requests a restricted subset of the 223 logging information, the dCDN may elect to generate a broader set 224 of logging information). The mechanism to support the 225 customisation by the uCDN of CDNI Logging information is outside 226 the scope of this document and left for further study. We note 227 that the CDNI Control interface or the CDNI Metadata interface 228 appear as candidate interfaces on which to potentially build such 229 a customisation mechanism in the future. Before such a mechanism 230 is available, the uCDN and dCDN are expected to agree off-line on 231 what CDNI logging information is to be provide by dCDN to UCDN and 232 rely on management plane actions to configure the CDNI Logging 233 functions to generate (respectively, expect) in dCDN 234 (respectively, in uCDN). 236 o generation and collection by the dCDN of logging information 237 related to the completion of any task performed by the dCDN on 238 behalf of the uCDN (e.g., delivery of the content to an end user) 239 or related to events happening in the dCDN that are relevant to 240 the uCDN (e.g., failures or unavailability in dCDN). This takes 241 place within the dCDN and does not directly involve CDNI 242 interfaces. 244 o communication by the dCDN to the uCDN of the logging information 245 collected by the dCDN relevant to the uCDN. This is supported by 246 the CDNI Logging interface and in the scope of the present 247 document. For example, the uCDN may use this logging information 248 to charge the CSP, to perform analytics and monitoring for 249 operational reasons, to provide analytics and monitoring views on 250 its content delivery to the CSP or to perform trouble-shooting. 252 o customization by the dCDN of the logging to be performed by the 253 uCDN on behalf of the dCDN. The mechanism to support the 254 customisation by the dCDN of CDNI Logging information is outside 255 the scope of this document and left for further study. 257 o generation and collection by the uCDN of logging information 258 related to the completion of any task performed by the uCDN on 259 behalf of the dCDN (e.g., serving of content by uCDN to dCDN for 260 acquisition purposes by dCDN) or related to events happening in 261 the uCDN that are relevant to the dCDN. This takes place within 262 the uCDN and does not directly involve CDNI interfaces. 264 o communication by the uCDN to the dCDN of the logging information 265 collected by the uCDN relevant to the dCDN. For example, the dCDN 266 might potentially benefit form this information for security 267 auditing or content acquisition troubleshooting. This is outside 268 the scope of this document and left for further study. 270 Figure 1 provides an example of CDNI Logging interactions (focusing 271 only on the interactions that are in the scope of this document) in a 272 particular scenario where 4 CDNs are involved in the delivery of 273 content from a given CSP: the uCDN has a CDNI interconnection with 274 dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with 275 dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all 276 participate in the delivery of content for the CSP. In this example, 277 the CDNI Logging interface enables the uCDN to obtain logging 278 information from all the dCDNs involved in the delivery. In the 279 example, uCDN uses the Logging data: 281 o to analyze the performance of the delivery operated by the dCDNs 282 and to adjust its operations (e.g., request routing) as 283 appropriate, 285 o to provide reporting (non real-time) and monitoring (real-time) 286 information to CSP. 288 For instance, uCDN merges Logging data, extracts relevant KPIs, and 289 presents a formatted report to the CSP, in addition to a bill for the 290 content delivered by uCDN itself or by its dCDNs on his behalf. uCDN 291 may also provide Logging data as raw log files to the CSP, so that 292 the CSP can use its own logging analysis tools. 294 +-----+ 295 | CSP | 296 +-----+ 297 ^ Reporting and monitoring data 298 * Billing 299 ,--*--. 300 Logging ,-' `-. 301 Data =>( uCDN )<= Logging 302 // `-. _,-' \\ Data 303 || `-'-'-' || 304 ,-----. ,-----. 305 ,-' `-. ,-' `-. 306 ( dCDN-1 ) ( dCDN-2 )<== Logging 307 `-. ,-' `-. _,-' \\ Data 308 `--'--' `--'-' || 309 ,-----. 310 ,' `-. 311 ( dCDN-3 ) 312 `. ,-' 313 `--'--' 315 ===> CDNI Logging Interface 316 ***> outside the scope of CDNI 318 Figure 1: Interactions in CDNI Logging Reference Model 320 A dCDN (e.g., dCDN-2) integrates the relevant logging information 321 obtained from its dCDNs (e.g., dCDN-3) in the logging information 322 that it provides to the uCDN, so that the uCDN ultimately obtains all 323 logging information relevant to a CSP for which it acts as the 324 authoritative CDN. 326 Note that the format of Logging information that a CDN provides over 327 the CDNI interface might be different from the one that the CDN uses 328 internally. In this case, the CDN needs to reformat the Logging 329 information before it provides this information to the other CDN over 330 the CDNI Logging interface. Similarly, a CDN might reformat the 331 Logging data that it receives over the CDNI Logging interface before 332 injecting it into its log-consuming applications or before providing 333 some of this logging information to the CSP. Such reformatting 334 operations introduce latency in the logging distribution chain and 335 introduce a processing burden. Therefore, there are benefits in 336 specifying CDNI Logging format that are suitable for use inside CDNs 337 and also are close to the CDN Log formats commonly used in CDNs 338 today. 340 2.2. Overall Logging Chain 342 This section discusses the overall logging chain within and across 343 CDNs to clarify how CDN Logging information is expected to fit in 344 this overall chain. Figure 2 illustrates the overall logging chain 345 within the dCDN, across CDNs using the CDNI Logging interface and 346 within the uCDN. Note that the logging chain illustrated in the 347 Figure is obviously only indicative and varies depending on the 348 specific environments. For example, there may be more or less 349 instantiations of each entity (i.e., there may be 4 Log consuming 350 applications in a given CDN). As another example, there may be one 351 instance of Rectification process per Log Consuming Application 352 instead of a shared one. 354 Log Consuming Log Consuming 355 App App 356 /\ /\ 357 | | 358 Rectification-------- 359 /\ 360 | 361 Filtering 362 /\ 363 | 364 Collection uCDN 365 /\ /\ 366 | | 367 | Generation 368 | 369 CDNI Logging --------------------------------------------- 370 exchange 371 /\ Log Consuming Log Consuming 372 | App App 373 | /\ /\ 374 | | | 375 Rectification Rectification--------- 376 /\ /\ 377 | | 378 Filtering 379 /\ 380 | 381 Collection dCDN 382 /\ /\ 383 | | 384 Generation Generation 386 Figure 2: CDNI Logging in the overall Logging Chain 388 The following subsections describe each of the processes potentially 389 involved in the logging chain of Figure 2. 391 2.2.1. Logging Generation and During-Generation Aggregation 393 CDNs typically generate logging information for all significant task 394 completions, events, and failures. Logs are typically generated by 395 many devices in the CDN including the surrogates, the request routing 396 system, and the control system. 398 The amount of Logging information generated can be huge. Therefore, 399 during contract negotiations, interconnected CDNs often agree on a 400 Logging retention duration, and optionally, on a maximum size of the 401 Logging data that the dCDN must keep. If this size is exceeded, the 402 dCDN must alert the uCDN but may not keep more Logs for the 403 considered time period. In addition, CDNs may aggregate logs and 404 transmit only summaries for some categories of operations instead of 405 the full Logging data. Note that such aggregation leads to an 406 information loss, which may be problematic for some usages of Logging 407 (e.g., debugging). 409 [I-D.brandenburg-cdni-has] discusses logging for HTTP Adaptive 410 Streaming (HAS). In accordance with the recommendations articulated 411 there, it is expected that a surrogate will generate separate logging 412 information for delivery of each chunk of HAS content. This ensures 413 that separate logging information can then be provided to 414 interconnected CDNs over the CDNI Logging interface. Still in line 415 with the recommendations of [I-D.brandenburg-cdni-has], the logging 416 information for per-chunck delivery may include some information (a 417 Content Collection IDentifier and a Session IDentifier) intended to 418 facilitate subsequent post-generation aggregation of per-chunk logs 419 into per-session logs. Note that a CDN may also elect to generate 420 aggregate per-session logs when performing HAS delivery, but this 421 needs to be in addition to, and not instead of, the per-chunk 422 delivery logs. We note that this may be revisited in future versions 423 of this document. 425 Note that in the case of non real-time logging, the trigger of the 426 transmission or generation of the logging file appears to be a 427 synchronous process from a protocol standpoint. The implementation 428 algorithm can choose to enforce a maximum size for the logging file 429 beyond which the transmission is automatically triggered (and thus 430 allow for an asynchronous transmission process). 432 2.2.2. Logging Collection 434 This is the process that continuously collects logs generated by the 435 log-generating entities within a CDN. 437 In a CDNI environment, in addition to collecting logging information 438 from log-generating entities within the local CDN, the Collection 439 process also collects logging information provided by another CDN, or 440 other CDNs, through the CDNI Logging interface. This is illustrated 441 in Figure 2 where we see that the Collection process of the uCDN 442 collects logging information from log-generating entities within the 443 uCDN as well as logging information coming through CDNI Logging 444 exchange with the dCDN through the CDNI Logging interface. 446 2.2.3. Logging Filtering 448 A CDN may require to only present different subset of the whole 449 logging information collected to various log-consuming applications. 450 This is achieved by the Filtering process. 452 In particular, the Filtering process can also filter the right subset 453 of information that needs to be provided to a given interconnected 454 CDN. For example, the filtering process in the dCDN can be used to 455 ensure that only the logging information related to tasks performed 456 on behalf of a given uCDN are made available to that uCDN (thereby 457 filtering all the logging information related to deliveries by the 458 dCDN of content for its own CSPs). Similarly, the Filtering process 459 may filter or partially mask some fields, for example, to protect End 460 Users' privacy when communicating CDNI Logging information to another 461 CDN. Filtering of logging information prior to communication of this 462 information to other CDNs via the CDNI Logging interface requires 463 that the downstream CDN can recognize the set of log records that 464 relate to each interconnected CDN. 466 The CDN will also filter some internal scope information such as 467 information related to its internal alarms (security, failures, load, 468 etc). 470 In some use cases described in [RFC6770], the interconnected CDNs do 471 not want to disclose details on their internal topology. The 472 filtering process can then also filter confidential data on the 473 dCDNs' topology (number of servers, location, etc.). In particular, 474 information about the requests served by every Surrogate may be 475 confidential. Therefore, the Logging information must be protected 476 so that data such as Surrogates' hostnames is not disclosed to the 477 uCDN. In the "Inter-Affiliates Interconnection" use case, this 478 information may be disclosed to the uCDN because both the dCDN and 479 the uCDN are operated by entities of the same group. 481 2.2.4. Logging Rectification and Post-Generation Aggregation 483 If Logging is generated periodically, it is important that the 484 sessions that start in one Logging period and end in another are 485 correctly reported. If they are reported in the starting period, 486 then the Logging of this period will be available only after the end 487 of the session, which delays the Logging generation. 489 A Logging rectification/update mechanism could be useful to reach a 490 good trade-off between the Logging generation delay and the Logging 491 accuracy. Depending on the selected Logging protocol(s), such 492 mechanism may be invaluable for real time Logging, which must be 493 provided rapidly and cannot wait for the end of operations in 494 progress. 496 In the presence of HAS, some log-consuming applications can benefit 497 from aggregate per-session logs. For example, for analytics, per- 498 session logs allow display of session-related trends which are much 499 more meaningful for some types of analysis than chunk-related trends. 500 In the case where the log-generating entities have generated during- 501 generation aggregate logs, those can be used by the applications. In 502 the case where aggregate logs have not been generated, the 503 Rectification process can be extended with a Post-Generation 504 Aggregation process that generates per-session logs from the per- 505 chunk logs, possibly leveraging the information included in the per- 506 chunk logs for that purpose (Content Collection IDentifier and a 507 Session IDentifier). However, in accordance with 508 [I-D.brandenburg-cdni-has], this document does not define exchange of 509 such aggregate logs on the CDNI Logging interface. We note that this 510 may be revisited in future versions of this document. 512 2.2.5. Log-Consuming Applications 514 2.2.5.1. Maintenance/Debugging 516 Logging is useful to permit the detection (and limit the risk) of 517 content delivery failures. In particular, Logging facilitates the 518 resolution of configuration issues. 520 To detect faults, Logging must enable the reporting of any CDN 521 operation success and failure, such as request redirection, content 522 acquisition, etc. The uCDN can summarize such information into KPIs. 523 For instance, Logging format should allow the computation of the 524 number of times during a given epoch that content delivery related to 525 a specific service succeeds/fails. 527 Logging enables the CDN providers to identify and troubleshoot 528 performance degradations. In particular, Logging enables the 529 communication of traffic data (e.g., the amount of traffic that has 530 been forwarded by a dCDN on behalf of an uCDN over a given period of 531 time), which is particularly useful for CDN and network planning 532 operations. 534 2.2.5.2. Accounting 536 Logging is essential for accounting, to permit inter-CDN billing and 537 CSP billing by uCDNs. For instance, Logging information provided by 538 dCDNs enables the uCDN to compute the total amount of traffic 539 delivered by every dCDN for a particular Content Provider, as well 540 as, the associated bandwidth usage (e.g., peak, 95th percentile), and 541 the maximum number of simultaneous sessions over a given period of 542 time. 544 2.2.5.3. Analytics and Reporting 546 The goal of analytics is to gather any relevant information to track 547 audience, analyze user behavior, and monitor the performance and 548 quality of content delivery. For instance, Logging enables the CDN 549 providers to report on content consumption (e.g., delivered sessions 550 per content) in a specific geographic area. 552 The goal of reporting is to gather any relevant information to 553 monitor the performance and quality of content delivery and allow 554 detection of delivery issues. For instance, reporting could track 555 the average delivery throughput experienced by End-Users in a given 556 region for a specific CSP or content set over a period of time. 558 2.2.5.4. Security 560 The goal of security is to prevent and monitor unauthorized access, 561 misuse, modification, and denial of access of a service. A set of 562 information is logged for security purposes. In particular, a record 563 of access to content is usually collected to permit the CSP to detect 564 infringements of content delivery policies and other abnormal End 565 User behaviors. 567 2.2.5.5. Legal Logging Duties 569 Depending on the country considered, the CDNs may have to retain 570 specific Logging information during a legal retention period, to 571 comply with judicial requisitions. 573 2.2.5.6. Notions common to multiple Log Consuming Applications 575 2.2.5.6.1. Logging Information Views 577 Within a given log-consuming application, different views may be 578 provided to different users depending on privacy, business, and 579 scalability constraints. 581 For example, an analytics tool run by the uCDN can provide one view 582 to an uCDN operator that exploits all the logging information 583 available to the uCDN, while the tool may provide a different view to 584 each CSP exploiting only the logging information related to the 585 content of the given CSP. 587 As another example, maintenance and debugging tools may provide 588 different views to different CDN operators, based on their 589 operational role. 591 2.2.5.6.2. Key Performance Indicators (KPIs) 593 This section presents, for explanatory purposes, a non-exhaustive 594 list of Key Performance Indicators (KPIs) that can be extracted/ 595 produced from logs. 597 Multiple log-consuming applications, such as analytics, monitoring, 598 and maintenance applications, often compute and track such KPIs. 600 In a CDNI environment, depending on the situation, these KPIs may be 601 computed by the uCDN or by the dCDN. But it is usually the uCDN that 602 computes KPIs, because uCDN and dCDN may have different definitions 603 of the KPIs and the computation of some KPIs requires a vision of all 604 the deliveries performed by the uCDN and all its dCDNs. 606 Here is a list of important examples of KPIs: 608 o Number of delivery requests received from End-Users in a given 609 region for each piece of content, during a given period of time 610 (e.g., hour/day/week/month) 612 o Percentage of delivery successes/failures among the aforementioned 613 requests 615 o Number of failures listed by failure type (e.g., HTTP error code) 616 for requests received from End Users in a given region and for 617 each piece of content, during a given period of time (e.g., hour/ 618 day/week/month) 620 o Number and cause of premature delivery termination for End Users 621 in a given region and for each piece of content, during a given 622 period of time (e.g., hour/day/week/month) 624 o Maximum and mean number of simultaneous sessions established by 625 End Users in a given region, for a given Content Provider, and 626 during a given period of time (e.g., hour/day/week/month) 628 o Volume of traffic delivered for sessions established by End Users 629 in a given region, for a given Content Provider, and during a 630 given period of time (e.g., hour/day/week/month) 632 o Maximum, mean, and minimum delivery throughput for sessions 633 established by End Users in a given region, for a given Content 634 Provider, and during a given period of time (e.g., hour/day/week/ 635 month) 637 o Cache-hit and byte-hit ratios for requests received from End Users 638 in a given region for each piece of content, during a given period 639 of time (e.g., hour/day/week/month) 641 o Top 10 of the most popularly requested content (during a given day 642 /week/month), 644 o Terminal type (mobile, PC, STB, if this information can be 645 acquired from the browser type header, for example). 647 Additional KPIs can be computed from other sources of information 648 than the Logging, for instance, data collected by a content portal or 649 by specific client-side application programming interfaces. Such 650 KPIs are out of scope for the present memo. 652 The KPIs used depend strongly on the considered log-consuming 653 application -- the CDN operator may be interested in different 654 metrics than the CSP is. In particular, CDN operators are often 655 interested in delivery and acquisition performance KPIs, information 656 related to Surrogates' performance, caching information to evaluate 657 the cache-hit ratio, information about the delivered file size to 658 compute the volume of content delivered during peak hour, etc. 660 Some of the KPIs, for instance those providing an instantaneous 661 vision of the active sessions for a given CSP's content, are useful 662 essentially if they are provided in real-time. By contrast, some 663 other KPIs, such as the one averaged on a long period of time, can be 664 provided in non-real time. 666 3. CDNI Logging File 668 3.1. Rules 670 This specification uses the Augmented Backus-Naur Form (ABNF) 671 notation and core rules of [RFC5234]. In particular, the present 672 document uses the following rules from [RFC5234]: 674 CR = %x0D ; carriage return 676 DIGIT = %x30-39 ; 0-9 678 DQUOTE = %x22 ; " (Double Quote) 680 CRLF = CR LF ; Internet standard newline 682 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 684 HTAB = %x09 ; horizontal tab 686 LF = %x0A ; linefeed 688 OCTET = %x00-FF ; 8 bits of data 690 The present document also uses the following rules from [RFC3986]: 692 host = as specified in section 3.2.2 of [RFC3986]. 694 IPv4address = as specified in section 3.2.2 of [RFC3986]. 696 IPv6address = as specified in section 3.2.2 of [RFC3986]. 698 The present document also defines the folowing additional rules: 700 ADDRESS = IPv4address / IPv6address 702 DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT 704 Dates are recorded in the format YYYY-MM-DD where YYYY, MM and 705 DD stand for the numeric year, month and day respectively. All 706 dates are specified in Universal Time Coordinated (UTC). 708 DEC = 1*DIGIT ["." *DIGIT] 710 QSTRING = DQUOTE *NDQUOTE DQUOTE ; where 711 NDQUOTE = / 2DQUOTE ; whereby a 712 DQUOTE is conveyed inside a QSTRING unambiguously by repeating 713 it. 715 NHTABSTRING = *NHTAB ; where 717 NHTAB = 719 TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] 721 Times are recorded in the form HH:MM:SS or HH:MM:SS.S where HH 722 is the hour in 24 hour format, MM is minutes and SS is seconds. 723 All times are specified in Universal Time Coordinated (UTC). 725 3.2. CDNI Logging File Structure 727 As defined in Section 1.1 a CDNI logging field is as an atomic 728 logging information element and a CDNI Logging Record is a collection 729 of CDNI Logging Fields containing all logging information 730 corresponding to a single logging event. This document defines a 731 third level of structure, the CDNI Logging File, that is a collection 732 of CDNI Logging Records. This structure is illustrated in Figure 3. 734 +----------------------------------------------------------+ 735 |CDNI Logging File | 736 | | 737 | #Directive 1 | 738 | #Directive 2 | 739 | ... | 740 | #Directive P | 741 | | 742 | +------------------------------------------------------+ | 743 | |CDNI Logging Record 1 | | 744 | | +-------------+ +-------------+ +-------------+ | | 745 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 746 | | | Field 1 | | Field 2 | | Field N | | | 747 | | +-------------+ +-------------+ +-------------+ | | 748 | +------------------------------------------------------+ | 749 | | 750 | +------------------------------------------------------+ | 751 | |CDNI Logging Record 2 | | 752 | | +-------------+ +-------------+ +-------------+ | | 753 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 754 | | | Field 1 | | Field 2 | | Field N | | | 755 | | +-------------+ +-------------+ +-------------+ | | 756 | +------------------------------------------------------+ | 757 | | 758 | ... | 759 | | 760 | #Directive P+1 | 761 | | 762 | ... | 763 | | 764 | +------------------------------------------------------+ | 765 | |CDNI Logging Record M | | 766 | | +-------------+ +-------------+ +-------------+ | | 767 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 768 | | | Field 1 | | Field 2 | | Field N | | | 769 | | +-------------+ +-------------+ +-------------+ | | 770 | +------------------------------------------------------+ | 771 | | 772 | | 773 | #Directive P+Q | 774 +----------------------------------------------------------+ 776 Figure 3: Structure of Logging Files 778 The CDNI Logging File format is inspired from the W3C Extended Log 779 File Format [ELF]. However, it is fully specified by the present 780 document. Where the present document differs from the W3C Extended 781 Log File Format, an implementation of CDNI Logging MUST comply with 782 the present document. 784 A CDNI Logging File MUST contain a sequence of lines containing US- 785 ASCII characters [CHAR_SET] terminated by CRLF. 787 Each line of a CDNI Logging File MUST contain either a directive or a 788 CDNI Logging Record. 790 Directives record information about the CDNI Logging process itself. 791 Lines containing directives MUST begin with the "#" character. 792 Directives are specified in Section 3.3. 794 Logging Records provide actual details of the logged event. Logging 795 Records are specified in Section 3.4. 797 The CDNI File structure is defined by the following rules: 799 DIRLINE = "#" directive CRLF 801 DIRGROUP = 1*DIRLINE 803 RECLINE = CRLF 805 RECGROUP = *RECLINE 806 = 1* 808 3.3. CDNI Logging File Directives 810 The CDNI Logging File directives are defined by the following rules: 812 directive = DIRNAME ":" HTAB DIRVAL 814 DIRNAME = = "Version" / "UUID" / "Claimed-Origin" 815 / "Verified-Origin" / "Record-Type" / "Fields" / "Integrity-Hash" 816 / "Non-Repudiation-Signature" 818 DIRVAL = 821 An implementation of the CDNI Logging interface MUST support the 822 following directives, listed below by their directive name: 824 o Version: 826 * format: "CDNI" "/" 1*DIGIT "." 1*DIGIT 828 * directive value: indicates the version of the CDNI Logging File 829 format. The value MUST be "CDNI/1.0" for the version specified 830 in the present document. 832 * occurrence: there MUST be one and only one instance of this 833 directive. It MUST be the first line of the CDNI Logging file. 835 o UUID: 837 * format: QSTRING 839 * directive value: this is Universally Unique IDentifier for the 840 CDNI Logging File as specified in [RFC4122]. [Editor's note: 841 check RFC4122 format to see if QSTRING is the right format] 843 * occurrence: there MUST be one and only one instance of this 844 directive. 846 o Claimed-Origin: 848 * format: host 849 * directive value: this contains the claimed identification of 850 the entity transmitting the CDNI Logging File (e.g. the host in 851 a dCDN supporting the CDNI Logging interface) or the entity 852 responsible for transmitting the CDNI Logging File (e.g. the 853 dCDN). 855 * occurrence: there MUST be zero or one instance of this 856 directive. This directive MAY be included by the dCDN. It 857 MUST NOT be included or modified by the uCDN. 859 o Verified-Origin: 861 * format: host 863 * directive value: this contains the identification, as 864 established by the entity receiving the CDNI Logging file, of 865 the entity transmitting the CDNI Logging File (e.g. the host in 866 a dCDN supporting the CDNI Logging interface) or the entity 867 responsible for transmitting the CDNI Logging File (e.g. the 868 dCDN). 870 * occurrence: there MUST be zero or one instance of this 871 directive. This directive MAY be added by the uCDN. It MUST 872 NOT be included by the dCDN. The mechanisms used by the uCDN 873 to establih and validate the entity respondible for the CDNI 874 Logging File is outside the scope of the present document. We 875 observe that, in particular, this may be achieved through 876 authentication mechanisms that are part of the CDNI Logging 877 File pull mechanism (Section 4.2). 879 o Record-Type: 881 * format: NHTABSTRING 883 * directive value: indicates the type of the CDNI Logging Records 884 that follow this directive, until another Record-Type directive 885 (or the end of the CDNI Logging File). "cdni_http_request_v1" 886 MUST be indicated as the Record-Type directive value for CDNI 887 Logging records corresponding to HTTP request (e.g. a HTTP 888 delivery request) as specified in Section 3.4.1. 890 * occurrence: there MUST be at least one instance of this 891 directive. The first instance of this directive MUST precede a 892 Fields directive and precede any CDNI Logging Record. 894 o Fields: 896 * format: FIENAME * ; where FIENAME is specified in 897 Section 3.4. 899 * directive value: this lists the names of all the fields for 900 which a value is to appear in the CDNI Logging Records that are 901 after this directive. The names of the fields, as well as 902 their possible occurrences, are specified for each type of CDNI 903 Logging Records in Section 3.4. 905 * occurrence: there MUST be at least one instance of this 906 directive per Record-Type directive. The first instance of 907 this directive for a given Record-Type MUST precede any CDNI 908 Logging Record for this Record-Type. 910 o Integrity-Hash: 912 * format: 32HEXDIG 914 * directive value: This directive permits the detection of a 915 corrupted CDNI Logging File. This can be useful, for instance, 916 if a problem occurs on the filesystem of the dCDN Logging 917 system and leads to a truncation of a logging file. The 918 Integrity-Hash value is computed, and included in this 919 directive by the entity that transmits the CDNI Logging File. 920 It is computed by applying the MD5 ([RFC1321]) cryptographic 921 hash function on the CDNI Logging File, including all the 922 directives and logging records, up to the Intergrity-Hash 923 directive itself, excluding the Integrity-Hash directive itself 924 and, when present, also excluding the Non-Repudiation-Hash 925 directive. The Integrity-Hash value is represented as a US- 926 ASCII encoded hexadecimal number, 32 digits long (representing 927 a 128 bit hash value). The entity receiving the CDNI Logging 928 File also computes in a similar way the MD5 hash on the 929 received CDNI Logging File and compares this hash to the value 930 of the Integrity-Hash directive. If the two values are equal, 931 then the received CDNI Logging File MUST be considered non- 932 corrupted. If the two values are different, the received CDNI 933 Logging File MUST be considered corrupted. The behavior of the 934 entity that received a corrupted CDNI Logging File is outside 935 the scope of this specification; we note that the entity MAY 936 attempt to pull again the same CDNI Logging file from the 937 transmitting entity. If the entity receiving the CDNI Logging 938 File adds a Verified-Origin directive, it MUST recompute and 939 update the Integrity-Hash directive so it also protects the 940 added Verified-Origin directive. 942 * occurrence: there MUST be zero or one instance of this 943 directive. There SHOULD be one instance of this directive. 945 One situation where that directive could be omitted is where 946 integrity protection is already provided via another mechanism 947 (for example if an integrity hash is associated to the CDNI 948 Logging file out of band through the CDNI Logging Logging Feed 949 Section 4.1 leveraging ATOM extensions such as those proposed 950 in [I-D.snell-atompub-link-extensions]. When present, this 951 field MUST be the last line of the CDNI Logging File when the 952 Non-Repudiation-Hash is absent, and MUST be the one before last 953 line of the CDNI Logging File when the Non-Repudiation-Hash is 954 present. 956 o Non-Repudiation-Signature: 958 * format: QSTRING [Editor's Note: revisit format once this field 959 is specified] 961 * directive value: This field contains a signature that supports 962 the non-repudiation of the CDNI Logging File by the entity that 963 transmitted the CDNI Logging File. [Editor's Note: Detailed 964 description To Be Added. David Mandelberg has the lead for 965 drafting text.The text needs to indicate that the Claimed- 966 Origin directive MUST be covered and the Verified-Origin 967 directive MUST NOT be covered by the signature. We may want to 968 refer to RFC4949 for terminology around Non-Redudiation] 970 * occurrence: there MAY be one and only one instance of this 971 directive. When present, this directive MUST be the last line 972 of the CDNI Logging File. 974 3.4. CDNI Logging Records 976 A CDNI Logging Record consists of a sequence of CDNI Logging Fields 977 relating to that single CDNI Logging Record. 979 CDNI Logging Fields MUST be separated by the "horizontal tabulation 980 (HTAB)" character. 982 To facilitate readability, a prefix scheme is used for CDNI Logging 983 field names in a similar way to the one used in W3C Extended Log File 984 Format [ELF] . The semantics of the prefix in the present document 985 is: 987 o c: refers to the User Agent that issues the request (corresponds 988 to the "client" of W3C Extended Log Format) 990 o d: refers to the dCDN (relative to a given CDN acting as a uCDN) 991 o s: refers to the dCDN Surrogate that serves the request 992 (corresponds to the "server" of W3C Extended Log Format) 994 o u: refers to the uCDN (relative to a given CDN acting as a dCDN) 996 o x: refers to extensions for vendor-specific logging fields 998 o cs: refers to communication from the dCDN Surrogate towards the 999 User-Agent 1001 o sc: refers to communication from the User-Agent towards the dCDN 1002 Surrogate 1004 An implementation of the CDNI Logging interface as per the present 1005 specification MUST support the CDNI HTTP Delivery Records as 1006 specified in Section 3.4.1. [Editor's Note": other types of delivery 1007 records will be listed here if we specify other types for this 1008 version eg Request Routing]. 1010 A CDNI Logging Record is defined by the following rules: 1012 FIEVAL = 1014 = FIEVAL * ; where FIEVAL 1015 contains the CDNI Logging field values corresponding to the CDNI 1016 Logging field names (FIENAME) listed is the last Fields directive 1017 predecing the present CDNI Logging Record. 1019 FIENAME = "date" / "time" / "time-taken" / "c-ip" / "c-ip- 1020 anonimizing" / "c-port" / "s-ip" / "s-hostname" / "s-port" / "cs- 1021 method" / "cs-uri" / "u-uri" / "protocol" / "sc-status" / "sc- 1022 total-bytes" / "sc-entity-bytes" / "cs(" ")" / "sc(" 1023 ")" / "s-ccid" / "s-sid" / "s-cached" / "s-uri- 1024 signing" / "x-" "-" 1027 3.4.1. HTTP Request Logging Record 1029 The HTTP Request Logging Record is a CDNI Logging Record of Record- 1030 Type "cdni_http_request_v1". It contains the following CDNI Logging 1031 Fields, listed by their field name: 1033 o date: 1035 * format: DATE 1037 * field value: the date at which the processing of request 1038 completed on the Surrogate. 1040 * occurrence: there MUST be one and only one instance of this 1041 field. 1043 o time: 1045 * format: TIME 1047 * field value: the time at which the processing of request 1048 completed on the Surrogate. 1050 * occurrence: there MUST be one and only one instance of this 1051 field. 1053 o time-taken: 1055 * format: DEC 1057 * field value: decimal value of the duration, in seconds, between 1058 the start of the processing of the request and the completion 1059 of the request processing (e.g. completion of delivery) by the 1060 Surrogate. 1062 * occurrence: there MUST be one and only one instance of this 1063 field. 1065 o c-ip: 1067 * format: ADDRESS 1069 * field value: the source IPv4 or IPv6 address (i.e. the "client" 1070 address) in the request received by the Surrogate. 1072 * occurrence: there MUST be one and only one instance of this 1073 field. 1075 o c-ip-anonimizing: 1077 * format: 1*DIGIT 1079 * field value: the number of rightmost bits of the address in the 1080 c-ip field that are zeroed-out in order to anonymize the 1081 logging record. The mechanism by which the two ends of the 1082 CDNI Logging interface agree on whether anonimization is to be 1083 supported and the number of bits that need to be zeroed-out for 1084 this purpose are outside the scope of the present document. 1086 * occurrence: there MUST be zero or one instance of this field. 1088 o c-port: 1090 * format: 1*DIGIT 1092 * field value: the source TCP port (i.e. the "client" port) in 1093 the request received by the Surrogate. 1095 * occurrence: there MUST be zero or exactly one instance of this 1096 field. 1098 o s-ip: 1100 * format: ADDRESS 1102 * field value: the IPv4 or IPv6 address of the Surrogate that 1103 served the request (i.e. the "server" address). 1105 * occurrence: there MUST be zero or exactly one instance of this 1106 field. 1108 o s-hostname: 1110 * format: host 1112 * field value: the hostname of the Surrogate that served the 1113 request (i.e. the "server" hostname). 1115 * occurrence: there MUST be zero or exactly one instance of this 1116 field. 1118 o s-port: 1120 * format: 1*DIGIT 1122 * field value: the destination TCP port (i.e. the "server" port) 1123 in the request received by the Surrogate. 1125 * occurrence: there MUST be zero or exactly one instance of this 1126 field. 1128 o cs-method: 1130 * format: NHTABSTRING 1132 * field value: this is the HTTP method of the HTTP request 1133 received by the Surrogate. 1135 * occurrence: There MUST be one and only one instance of this 1136 field. 1138 o cs-uri: 1140 * format: NHTABSTRING 1142 * field value: this is the complete URL of the request received 1143 by the Surrogate. It is exactly in the format of a http_URL 1144 specified in [RFC2616]) or, when the request was a HTTPS 1145 request ([RFC2818]), it is in the format of a http_URL but with 1146 the scheme part set to "https" instead of "http". 1148 * occurrence: there MUST be zero or exactly one instance of this 1149 field. 1151 o u-uri: 1153 * format: NHTABSTRING 1155 * field value: this is a complete URL, derived from the complete 1156 URI of the request received by the Surrogate (i.e. the cs-uri) 1157 but transformed by the entity generating or transmitting the 1158 CDNI Logging Record, in a way that is agreed upon between the 1159 two ends of the CDNI Logging interface, so the transformed URI 1160 is meaningful to the uCDN. For example, the two ends of the 1161 CDNI Logging interface could agree that the u-uri is 1162 constructed from the cs-uri by removing the part of the 1163 hostname that exposes which individual Surrogate actually 1164 performed the delivery. The details of modification performed 1165 to generate the u-uri, as well as the mechanism to agree on 1166 these modifications between the two sides of the CDNI Logging 1167 interface are outside the scope of the present document. 1169 * occurrence: there MUST be one and only one instance of this 1170 field. 1172 o protocol: 1174 * format: NHTABSTRING 1176 * field value: this is value of the HTTP-Version field as 1177 specified in [RFC2616] of the Request-Line of the request 1178 received by the Surrogate (e.g. "HTTP/1.1"). 1180 * occurrence: there MUST be one and only one instance of this 1181 field. 1183 o sc-status: 1185 * format: 3DIGIT 1187 * field value: this is the HTTP Status-Code in the HTTP response 1188 from the Surrogate. 1190 * occurrence: There MUST be one and only one instance of this 1191 field. 1193 o sc-total-bytes: 1195 * format: 1*DIGIT 1197 * field value: this is the total number of bytes of the HTTP 1198 response sent by the Surrogate in response to the request. 1199 This includes the bytes of the Status-Line (including HTTP 1200 headers) and of the message-body. 1202 * occurrence: There MUST be one and only one instance of this 1203 field. 1205 o sc-entity-bytes: 1207 * format: 1*DIGIT 1209 * field value: this is the number of bytes of the message-body in 1210 the HTTP response sent by the Surrogate in response to the 1211 request. This does not include the bytes of the Status-Line 1212 (and therefore does not include the bytes of the HTTP headers). 1214 * occurrence: there MUST be zero or exactly one instance of this 1215 field. 1217 o cs(): 1219 * format: QSTRING 1221 * field value: the value of the HTTP header (identified by the 1222 in the CDNI Logging field name) as it 1223 appears in the request processed by the Surrogate. For 1224 example, when the CDNI Logging field name (FIENAME) listed in 1225 the prededing Fields directive is "cs(User-Agent"), this CDNI 1226 Logging field value contains the value of the User-Agent HTTP 1227 header as received by the Surrogate in the request it 1228 processed. 1230 * occurrence: there MUST be zero, one or any number of instance 1231 of this field. 1233 o sc(): 1235 * format: QSTRING 1237 * field value: the value of the HTTP header (identified by the 1238 in the CDNI Logging field name) as it 1239 appears in the response issued by the Surrogate to serve the 1240 request. 1242 * occurrence: there MUST be zero, one or any number of instance 1243 of this field. 1245 o s-ccid: 1247 * format: QSTRING 1249 * field value: this contains the value of the Content Collection 1250 IDentifier associated by the uCDN to the content served by the 1251 Surrogate via the CDNI Metadata interface 1252 ([I-D.ietf-cdni-metadata]). 1254 * occurrence: there MUST be zero or exactly one instance of this 1255 field. 1257 o s-sid: 1259 * format: QSTRING 1261 * field value: this contains the value of a Session IDentifier 1262 generated by the dCDN for a specific HTTP Adaptive Streaming 1263 (HAS) session and whose value is included in the Logging record 1264 for every content chunk delivery of that session in view of 1265 facilitating the later correlation of all the per content chunk 1266 log records of a given HAS session. See section 3.4.2.2. of 1267 [I-D.brandenburg-cdni-has] for more discussion on the concept 1268 of Session IDentifier. 1270 * occurrence: there MUST be zero or exactly one instance of this 1271 field. 1273 o s-cached: 1275 * format: 1DIGIT 1276 * field value: this characterises whether the Surrogate could 1277 serve the request using content already stored on its local 1278 cache. The allowed values are "0" (for miss) and "1" for hit). 1279 "1" MUST be used when the Surrogate could serve the request 1280 using exclusively content already stored on its local cache. 1281 "0" MUST be used otherwise (including cases where the Surrogate 1282 served the request using some, but not all, content already 1283 stored on its local cache). Note that a "0" only means a cache 1284 miss in the Surrogate and does not provide any information on 1285 whether the content was already stored, or not, in another 1286 device of the dCDN i.e. whether this was a "dCDN hit" or "dCDN 1287 miss". 1289 * occurrence: there MUST be zero or exactly one instance of this 1290 field. 1292 o s-uri-signing: 1294 * format: 1DIGIT 1296 * field value: this characterises the uri signing validation 1297 performed by the Surrogate on the request. The allowed values 1298 are: 1300 * 1302 + "0" : no uri signature validation performed 1304 + "1" : uri signature validation performed and validated 1306 + "2" : uri signature validation performed and rejected 1308 * occurrence: there MUST be zero or exactly one instance of this 1309 field. 1311 o x-"vendor-ID"-"vendor-specific-cdni-logging-field-name": 1313 * format: specified by the vendor for the actual vendor-specific 1314 logging field. This format is outside the scope of the present 1315 document. 1317 * field value: this contains a vendor specific logging field. 1318 The "vendor-ID" identifies the vendor and the "vendor-specific- 1319 cdni-logging-field-name" identifies the actual vendor-specific 1320 logging field. For example, a vendor specific field name would 1321 look like "x-vendor1-important_info1". 1323 * occurrence: there MUST be zero, one or any number of instance 1324 of this field 1326 The "Fields" directive corresponding to a HTTP Request Logging Record 1327 MUST list all the fields name whose occurrence is specified above as 1328 "There MUST be one and only one instance of this field". The 1329 corresponding fields value MUST be present in every HTTP Request 1330 Logging Record. 1332 The "Fields" directive corresponding to a HTTP Request Logging Record 1333 MAY list all the fields value whose occurrence is specified above as 1334 "there MUST be zero or exactly one instance of this field" or "there 1335 MUST be zero, one or any number of instance of this field". The set 1336 of such fields name actually listed in the "Fields" directive is 1337 selected by the implementation generating the CDNI Logging File based 1338 on agreements between the interconnected CDNs established through 1339 mechanisms outside the scope of this specification (e.g. contractual 1340 agreements) . When such a field name is not listed in the "Fields" 1341 directive, the corresponding field value MUST NOT be included in the 1342 Logging Record. When such a field name is listed in the "Fields" 1343 directive, the corresponding field value MUST be included in the 1344 Logging Record; in that case, if the value for the field is not 1345 available, this MUST be conveyed via a dash character ("-"). 1347 The fields name listed in the "Fields" directive MAY be listed in the 1348 order in which they are listed in Section 3.4.1 or MAY be listed in 1349 any other order. 1351 3.5. CDNI Logging File Example 1353 #Version:CDNI/1.0 1355 #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1357 #Claimed-Origin:cdni-logging-entity.dcdn.example.com 1359 #Record-Type:cdni_http_request_v1 1361 #Fields:datetimetime-takenc-ipcs- 1362 methodu-uriprotocolsc-statussc-total- 1363 bytescs(User-Agent)cs(Referer)s-cached 1365 2013-05-1700:38:06.82588.95810.5.7.1GET 1366 http://cdni-ucdn.dcdn.example.com/video/movie100.mp4HTTP/ 1367 1.1200672989"Mozilla/5.0 (Windows; U; Windows NT 1368 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 1369 Safari /533.4""host1.example.com"1 1370 2013-05-1700:39:09.145169.79010.5.10.5GEThttp://cdni-ucdn.dcdn.example.com/video/movie118.mp4HTTP/ 1372 1.12001579920"Mozilla/5.0 (Windows; U; Windows NT 1373 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 1374 Safari /533.4""host1.example.com"1 1376 2013-05-1700:42:53.4372.87910.5.10.5GET 1377 http://cdni-ucdn.dcdn.example.com/video/picture11.mp4HTTP/ 1378 1.020017724"Mozilla/5.0 (Windows; U; Windows NT 1379 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 1380 Safari /533.4""host5.example.com"0 1382 #Integrity-Hash: 9e107d9d372bb6826bd81d3542a419d6 [Editor's Note: 1383 include the correct MD5-hash value for the actual example] 1385 4. CDNI Logging File Exchange Protocol 1387 This document specifies a protocol for the exchange of CDNI Logging 1388 Files as specified in Section 3. 1390 This protocol comprises: 1392 o a CDNI Logging feed, allowing the dCDN to notify the uCDN about 1393 the CDNI Logging files that can be retrieved by that uCDN from the 1394 dCDN, as well as all the information necessary for retrieving each 1395 of these CDNI Logging File. The CDNI Logging feed is specified in 1396 Section 4.1. 1398 o a CDNI Logging File pull mechanism, allowing the uCDN to obtain 1399 from the dCDN a given CDNI Logging File at the uCDN convenience. 1400 The CDNI Logging File pull mechanisms is specified in Section 4.2. 1402 An implementation of the CDNI Logging interface as per the present 1403 document generating CDNI Logging file (i.e. on the dCDN side) MUST 1404 support the server side of the CDNI Logging feed and the server side 1405 of the CDNI Logging pull mechanism. 1407 An implementation of the CDNI Logging interface as per the present 1408 document consuming CDNI Logging file (i.e. on the uCDN side) MUST 1409 support the client side of the CDNI Logging feed and the client side 1410 of the CDNI Logging pull mechanism. 1412 [Editor's note: verify that the client side and server side are well 1413 defined in the respective sections] 1415 We note that implementations of the CDNI Logging interface MAY also 1416 support other mechanisms to exchange CDNI Logging Files, for example 1417 in view of exchanging logging information with minimum time-lag (e.g. 1419 sub-minute or sub-second) between when the event occurred in the dCDN 1420 and when the corresponding Logging Record is made available to the 1421 uCDN (e.g. for log-consuming applications requiring extremely fresh 1422 logging information such as near-real-time content delivery 1423 monitoring). Such mechanism might be defined in future version of 1424 the present document. 1426 4.1. CDNI Logging Feed 1428 [Editor's Note: text to be added. Feed is based on ATOM and contains 1429 a UUID + URI for each CDNI Logging File in "window" - if appropriate 1430 the text should refer to the side generating the CDNI Logging Feed 1431 "as server-side", and the side consuming the Feed as the client- 1432 side]. 1434 4.2. CDNI Logging File Pull 1436 A client-side implementation of the CDNI Logging interface MAY pull 1437 at its convenience any CDNI Logging File that is advertised by the 1438 server-side in the CDNI Logging Feed. To do so, the client-side: 1440 o MUST use HTTP v1.1 1442 o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") 1444 o MUST use the URI associated to the CDNI Logging File in the CDNI 1445 Logging Feed 1447 o SHOULD indicate the compression schemes it supports 1449 Note that a client-side implementation of the CDNI Logging interface 1450 MAY pull a CDNI Logging File that it has already pulled, as long as 1451 the file is still advertised by the server-side in the CDNI Logging 1452 Feed. 1454 The server-side implementation MUST respond to any valid pull request 1455 by a client-side implementation for a CDNI Logging File advertised by 1456 the server-side in the CDNI Logging Feed. The server-side 1457 implementation: 1459 o MUST handle the client-side request as per HTTP v1.1 1461 o MUST include the CDNI Logging File identified by the request URI 1462 inside the body of the HTTP response 1464 o MUST support the gzip and deflate compression schemes 1466 o MAY support other compression schemes 1467 o when the client-side request indicates client-supported 1468 compression schemes, SHOULD use a compression scheme that it 1469 supports and is supported by the client-side 1471 [Editor's Note: discuss Non-Repudiation : it is a nice to have and 1472 how it could be supported, via a different digest than the one for 1473 integrity] 1475 5. Open Issues 1477 o Compression: When we say the server MUST support gzip & 1478 deflate we probably need to think through whether we mean content- 1479 encoding, transfer-encoding or both. The semantics get a little 1480 confusing so we probably just need to think them through to ensure 1481 we allow a server to store compressed logs as transmit them 1482 compressed. 1484 o Handling of Event logs and notifications: There are two aspects of 1485 that question: 1487 * non-real-time exchange of event logs from dCDN to uCDN for 1488 audit purposes. This could be added to current spec presumably 1489 in the form of additional Record-Types and without requiring a 1490 significant change to the current CDNI LOgging file exchange 1491 approach. It is proposed that this be handled as a [MED] 1492 requirement. e.g. try first specify what events and what 1493 information needs to be exchanged; and depending on progress, 1494 decide to include in initial logging spec or not 1496 * real-time exchange of event notification from dCDN to uCDN for 1497 immediate operational action (eg on notification by dCDN that 1498 dCDN request routing is down, uCDN stops redirecting to this 1499 dCDN). This would presumably require definition/extension of 1500 another CDNI interface or significant change/extension to the 1501 current CDNI logging spec. It is proposed that thisbe kept out 1502 of the scope of the current cdni-logging spec . 1504 Another question is what set of events should be logged/notified. 1505 The first type of events realtes to "service-level" events i.e. 1506 high level events that affect the service that the dCDN is 1507 providing to the uCDN (e.g.dCDN request routing is down, dCDN is 1508 overloaded). There is general agreements that it is desirable to 1509 be able to log/notify such service-level events. The second type 1510 of events is "atomic-level" events i.e. low level events that may 1511 be useful to identify or track a component issue or a delivery 1512 issue. logging/notifying about such events may be useful in some 1513 situations (eg uCDN and dCDN have a particular relationship 1514 allowing them to share detailed operational information) and may 1515 not be useful in some situations (because the dCDN does not want 1516 to expose details of its CDN operation). Ideal approach is to 1517 define both types of events and have the first type as MUST and 1518 the second type as MAY. Fall back approach woudl be to only 1519 define the first type initially. 1521 o Add precise definition of what must be supported by transmitting 1522 implementation and what must be implemented by receiving 1523 application (regardless of what may actually be used in a given 1524 deployment). For example, it may be reasonable to mandate that a 1525 receiving implementaton but be able to receive all the directives 1526 specified in the doc and all fields. 1528 6. IANA Considerations 1530 6.1. CDNI Logging Directive Names Registry 1532 The IANA is requested to create a new registry, CDNI Logging 1533 Directive Names. 1535 The initial contents of the CDNI Logging File Directives registry 1536 comprise the names of the directives specified in Section 3.3 of the 1537 present document, and are as follows: 1539 +------------------------------+-----------+ 1540 + Directive name + Reference | 1541 +------------------------------+-----------+ 1542 + Version + RFC xxxx | 1543 + UUID + RFC xxxx | 1544 + Claimed-Origin + RFC xxxx | 1545 + Verified-Origin + RFC xxxx | 1546 + Record-Type + RFC xxxx | 1547 + Fields + RFC xxxx | 1548 + Integrity-Hash + RFC xxxx | 1549 + Non-Repudiation-Signature + RFC xxxx | 1550 +------------------------------+-----------+ 1552 Figure 4 1554 [Instructions to IANA: Replace "RFC xxxx" by the RFC number of the 1555 present document] 1557 Additions to that registry are permitted by Standards Action, as 1558 defined by [RFC5226]. 1560 [Editor's Note: reserve a range of names -e.g."x-" for vendor- 1561 specific extensions] 1563 6.2. CDNI Logging Record-Type Registry 1565 The IANA is requested to create a new registry, CDNI Logging Record- 1566 Types. 1568 The initial contents of the CDNI Logging Record-Types registry 1569 comprise the names of the CDNI Logging Record types specified in 1570 Section 3.4 of the present document, and are as follows: 1572 +------------------------------+-----------+ 1573 + Directive name + Reference | 1574 +------------------------------+-----------+ 1575 + cdni_http_request_v1 + RFC xxxx | 1576 +------------------------------+-----------+ 1578 Figure 5 1580 [Instructions to IANA: Replace "RFC xxxx" by the RFC number of the 1581 present document] 1583 Additions to that registry are permitted by Standards Action, as 1584 defined by [RFC5226]. 1586 [Editor's Note: reserve a range of names -e.g."x-" for vendor- 1587 specific extensions] 1589 6.3. CDNI Logging Field Name Registry 1591 The IANA is requested to create a new registry, CDNI Logging Field 1592 Names. 1594 The initial contents of the CDNI Logging Fiels Names registry 1595 comprise the names of the CDNI Logging fields specified in 1596 Section 3.4 of the present document, and are as follows: 1598 +---------------------------------------------+-----------+ 1599 + Field name + Reference | 1600 +---------------------------------------------+-----------+ 1601 + date + RFC xxxx | 1602 + time + RFC xxxx | 1603 + time-taken + RFC xxxx | 1604 + c-ip + RFC xxxx | 1605 + c-ip- anonimizing + RFC xxxx | 1606 + c-port + RFC xxxx | 1607 + s-ip + RFC xxxx | 1608 + s-hostname + RFC xxxx | 1609 + s-port + RFC xxxx | 1610 + cs- method + RFC xxxx | 1611 + cs-uri + RFC xxxx | 1612 + u-uri + RFC xxxx | 1613 + protocol + RFC xxxx | 1614 + sc-status + RFC xxxx | 1615 + sc- total-bytes + RFC xxxx | 1616 + sc-entity-bytes + RFC xxxx | 1617 + cs() + RFC xxxx | 1618 + sc() + RFC xxxx | 1619 + s-ccid + RFC xxxx | 1620 + s-sid + RFC xxxx | 1621 + s-cached + RFC xxxx | 1622 + s-uri- signing + RFC xxxx | 1623 + x- + | 1624 + - + RFC xxxx | 1625 +---------------------------------------------+-----------+ 1627 Figure 6 1629 [Instructions to IANA: Replace "RFC xxxx" by the RFC number of the 1630 present document] 1632 Additions to that registry are permitted by Standards Action, as 1633 defined by [RFC5226]. 1635 [Editor's Note: tweak text for the range of names -e.g."x-" for 1636 vendor-specific extensions] 1638 7. Security Considerations 1640 7.1. Authentication, Confidentiality, Integrity Protection 1642 The use of TLS for transport of the CDNI Logging feed mechanism 1643 (Section 4.1) and CDNI Logging File pull mechanism (Section 4.2) 1644 allows: 1646 o the dCDN and uCDN to authenticate each other (to ensure they are 1647 transmitting/receiving CDNI Logging File from an authenticated 1648 CDN) 1650 o the CDNI Logging information to be transmitted with 1651 confidentiality 1653 o the integrity of the CDNI Logging information to be protected 1654 during the exchange. 1656 The Integrity-Hash directive inside the CDNI Logging File provides 1657 additional integrity protection, this time targeting potential 1658 corruption of the CDNI logging information during the CDNI Logging 1659 File generation. This mechanism does not allow restoration of the 1660 corrupted CDNI Logging information, but it allows detection of such 1661 corruption and therefore triggering of appropraite correcting actions 1662 (e.g. discard of corrupted information, attempt to re-obtain the CDNI 1663 Logging information). 1665 7.2. Non Repudiation 1667 The Non-Repudiation-Signature directive in the CDNI Logging File 1668 allows support of non-repudiation of the CDNI Logging File by the 1669 dCDN. The optional Non-Repudiation-Hash can be used on the CDNI 1670 Logging interface where needed. 1672 7.3. Privacy 1674 CDNs have the opportunity to collect detailed information about the 1675 downloads performed by End-Users. The provision of this information 1676 to another CDN introduces potential End-Users privacy protection 1677 concerns. We observe that when CDNI interconnection is realised as 1678 per [I-D.ietf-cdni-framework], the uCDN handles the initial End-User 1679 requests (before it is redirected to the dCDN) so, regardless of 1680 which information is, or is not, communicated to the uCDN through the 1681 CDNI Logging interface, the uCDN has visibility on significant 1682 information such as the IP address of the End-User request and the 1683 URL of the request. Nonetheless, if the dCDN and uCDN agree that 1684 anonymization is required to avoid making some detailed information 1685 available to the uCDN (such as how much bytes of the content has been 1686 watched by an enduser and/or at what time) or is required to meet 1687 some legal obligations, then the uCDN and dCDN can agree to exchange 1688 anonymized End-User IP addresses in CDNI Logging files and the c-ip- 1689 anonymization field can be used to convey the number of bits that 1690 have been anonymized so that the meaningful information can still be 1691 easily extracted from the anonymized addressses (e.g. for geolocation 1692 aware analytics). 1694 8. Acknowledgments 1696 This document borrows from the W3C Extended Log Format [ELF]. 1698 The authors would like to thank Sebastien Cubaud, Pawel Grochocki, 1699 Christian Jacquenet, Yannick Le Louedec, Anne Marrec and Emile 1700 Stephan for their contributions on early versions of this document. 1702 The authors would like also to thank Rob Murray, Fabio Costa, Sara 1703 Oueslati, Yvan Massot, Renaud Edel, and Joel Favier for their input 1704 and comments. 1706 Finally, they thank the contributors of the EU FP7 OCEAN project for 1707 valuable inputs. 1709 9. References 1711 9.1. Normative References 1713 [I-D.ietf-cdni-metadata] 1714 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 1715 Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- 1716 ietf-cdni-metadata-01 (work in progress), February 2013. 1718 [I-D.snell-atompub-link-extensions] 1719 Snell, J., "Atom Link Extensions", draft-snell-atompub- 1720 link-extensions-09 (work in progress), June 2012. 1722 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1723 April 1992. 1725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1726 Requirement Levels", BCP 14, RFC 2119, March 1997. 1728 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1729 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1730 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1732 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1734 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1735 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1736 3986, January 2005. 1738 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1739 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 1740 2005. 1742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1743 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1744 May 2008. 1746 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1747 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1749 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1751 9.2. Informative References 1753 [CHAR_SET] 1754 , "IANA Character Sets registry", , . 1757 [ELF] Phillip M. Hallam-Baker, . and . Brian Behlendorf, 1758 "Extended Log File Format, W3C (work in progress), WD- 1759 logfile-960323", , . 1761 [I-D.brandenburg-cdni-has] 1762 Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung, 1763 "Models for adaptive-streaming-aware CDN Interconnection", 1764 draft-brandenburg-cdni-has-05 (work in progress), April 1765 2013. 1767 [I-D.brandenburg-cdni-has] 1768 Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung, 1769 "Models for adaptive-streaming-aware CDN Interconnection", 1770 draft-brandenburg-cdni-has-05 (work in progress), April 1771 2013. 1773 [I-D.ietf-cdni-framework] 1774 Peterson, L. and B. Davie, "Framework for CDN 1775 Interconnection", draft-ietf-cdni-framework-03 (work in 1776 progress), February 2013. 1778 [I-D.ietf-cdni-requirements] 1779 Leung, K. and Y. Lee, "Content Distribution Network 1780 Interconnection (CDNI) Requirements", draft-ietf-cdni- 1781 requirements-07 (work in progress), May 2013. 1783 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1784 Distribution Network Interconnection (CDNI) Problem 1785 Statement", RFC 6707, September 2012. 1787 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1788 K., and G. Watson, "Use Cases for Content Delivery Network 1789 Interconnection", RFC 6770, November 2012. 1791 Appendix A. Requirements 1793 A.1. Compliance with cdni-requirements 1795 This section checks that all the identified requirements in the 1796 Section 7 of [I-D.ietf-cdni-requirements] are fulfilled by this 1797 document. 1799 [Editor's node: to be written later] 1801 A.2. Additional Requirements 1803 This section identies additional requirements that must also be met. 1805 [Editor's node: How do we incorporate this info into the I-D: in 1806 appendix? in main body? does it remain after publication or is 1807 temporary?] 1809 A.2.1. Timeliness 1811 Some applications consuming CDNI Logging information, such as 1812 accounting or trend analytics, only require logging information to be 1813 available with a timeliness of the order of a day or the hour. This 1814 document focuses on addressing this requirement. 1816 Some applications consuming CDNI Logging information, such as real- 1817 time analytics, require logging information to be available in real- 1818 time (i.e. of the order of a second after the corresponding event). 1819 This document leaves this requirement out of scope. 1821 A.2.2. Reliability 1823 CDNI logging information must be transmitted reliably. The transport 1824 protocol should contain an anti-replay mechanism. 1826 A.2.3. Security 1828 CDNI logging information exchange must allow authentication, 1829 integrity protection, and confidentiality protection. Also, a non- 1830 repudiation mechanism is mandatory, the transport protocol should 1831 support it. 1833 A.2.4. Scalability 1835 CDNI logging information exchange must support large scale 1836 information exchange, particularly so in the presence of HTTP 1837 Adaptive Streaming. 1839 For example, if we consider a client pulling HTTP Progressive 1840 Download content with an average duration of 10 minutes, this 1841 represents 1/600 CDNI delivery Logging Records per second. If we 1842 assume the dCDN is simultaneously serving 100,000 such clients on 1843 behalf of the uCDN, the dCDN will be generating 167 Logging Records 1844 per second to be communicated to the uCDN over the CDNI Logging 1845 interface. Or equivalently, if we assume an average delivery rate of 1846 2Mb/s, the dCDN generates 0.83 CDNI Logging Records per second for 1847 every Gb/s of streaming on behalf of the uCDN. 1849 For example, if we consider a client pulling HAS content and 1850 receiving a video chunk every 2 seconds, a separate audio chunck 1851 every 2 seconds and a refreshed manifest every 10 seconds, this 1852 represents 1.1 delivery Logging Record per second. If we assume the 1853 dCDN is simultaneously serving 100,000 such clients on behalf of the 1854 uCDN, the dCDN will be generating 110,000 Logging Records per second 1855 to be communicated to the uCDN over the CDNI Logging interface. Or 1856 equivalently, if we assume an average delivery rate of 2Mb/s, the 1857 dCDN generates 550 CDNI Logging Records per second for every Gb/s of 1858 streaming on behalf of the uCDN. 1860 A.2.5. Consistency between CDNI Logging and CDN Logging 1862 There are benefits in using a CDNI logging format as close as 1863 possible to intra-CDN logging format commonly used in CDNs today in 1864 order to minimize systematic translation at CDN/CDNI boundary. 1866 A.2.6. Dispatching/Filtering 1868 When a CDN is acting as a dCDN for multiple uCDNs, the dCDN needs to 1869 dispatch each CDNI Logging Record to the uCDN that redirected the 1870 corresponding request. The CDNI Logging format need to allow, and 1871 possibly facilitate, such a dispatching. 1873 Appendix B. Analysis of candidate protocols for Logging Transport 1875 This section will be expanded later with an analysis of alternative 1876 candidate protocols for transport of CDNI Logging in non-real-time as 1877 well as real-time. 1879 B.1. Syslog 1881 [Ed. node: to be written later] 1883 B.2. XMPP 1885 [Ed. node: to be written later] 1887 B.3. SNMP 1889 Authors' Addresses 1890 Gilles Bertrand (editor) 1891 France Telecom - Orange 1892 38-40 rue du General Leclerc 1893 Issy les Moulineaux 92130 1894 FR 1896 Phone: +33 1 45 29 89 46 1897 Email: gilles.bertrand@orange.com 1899 Iuniana Oprescu (editor) 1900 France Telecom - Orange 1901 38-40 rue du General Leclerc 1902 Issy les Moulineaux 92130 1903 FR 1905 Phone: +33 6 89 06 92 72 1906 Email: iuniana.oprescu@orange.com 1908 Francois Le Faucheur (editor) 1909 Cisco Systems 1910 E.Space Park - Batiment D 1911 6254 Allee des Ormes - BP 1200 1912 Mougins cedex 06254 1913 FR 1915 Phone: +33 4 97 23 26 19 1916 Email: flefauch@cisco.com 1918 Roy Peterkofsky 1919 Skytide, Inc. 1920 One Kaiser Plaza, Suite 785 1921 Oakland CA 94612 1922 USA 1924 Phone: +01 510 250 4284 1925 Email: roy@skytide.com