draft-ietf-cdni-logging-06.txt   draft-ietf-cdni-logging-07.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: March 31, 2014 I. Oprescu, Ed. Expires: April 13, 2014 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
September 27, 2013 October 10, 2013
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-06 draft-ietf-cdni-logging-07
Abstract Abstract
This memo specifies the Logging interface between a downstream CDN This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN) that are interconnected as per the (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
CDN Interconnection (CDNI) framework. First, it describes a CDN Interconnection (CDNI) framework. First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2014. This Internet-Draft will expire on April 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5
2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5
2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8
2.2.1. Logging Generation and During-Generation Aggregation 9 2.2.1. Logging Generation and During-Generation Aggregation 9
2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10
2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10
2.2.4. Logging Rectification and Post-Generation Aggregation 11 2.2.4. Logging Rectification and Post-Generation Aggregation 11
2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 11
2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 11
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12
2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12
2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 13 2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 12
2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13 2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 12
2.2.5.6. Notions common to multiple Log Consuming 2.2.5.6. Notions common to multiple Log Consuming
Applications . . . . . . . . . . . . . . . . . . 13 Applications . . . . . . . . . . . . . . . . . . 13
3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16
3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 18 3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 18
3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 21 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 21
3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 22 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 22
3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 29 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 29
4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 30 4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 30
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 31 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 30
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 31 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 31
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 32 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 31
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 32 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 32
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 32 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 32
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 33 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 33
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
5.1. CDNI Logging Directive Names Registry . . . . . . . . . . 34 5.1. CDNI Logging Directive Names Registry . . . . . . . . . . 34
5.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 35 5.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 35
5.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 35 5.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 35
5.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 36 5.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Authentication, Confidentiality, Integrity Protection . . 36 6.1. Authentication, Confidentiality, Integrity Protection . . 36
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Compliance with CDNI Requirements . . . . . . . . . 40
A.1. Compliance with cdni-requirements . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
A.1.1. General requirements . . . . . . . . . . . . . . . . 40
A.1.2. Logging Interface requirements . . . . . . . . . . . 40
A.1.3. Security requirements . . . . . . . . . . . . . . . . 42
A.2. Considerations on CDNI Logging Applicability . . . . . . 42
A.2.1. Timeliness . . . . . . . . . . . . . . . . . . . . . 42
A.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 42
A.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 42
A.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . 42
A.2.5. Consistency between CDNI Logging and CDN Logging . . 43
A.2.6. Dispatching/Filtering . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This memo specifies the CDNI Logging interface between a downstream This memo specifies the CDNI Logging interface between a downstream
CDN (dCDN) and an upstream CDN (uCDN). First, it describes a CDN (dCDN) and an upstream CDN (uCDN). First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
The reader should be familiar with the following documents: The reader should be familiar with the following documents:
skipping to change at page 6, line 12 skipping to change at page 6, line 5
place within the dCDN and does not directly involve CDNI place within the dCDN and does not directly involve CDNI
interfaces. interfaces.
o communication by the dCDN to the uCDN of the logging information o communication by the dCDN to the uCDN of the logging information
collected by the dCDN relevant to the uCDN. This is supported by collected by the dCDN relevant to the uCDN. This is supported by
the CDNI Logging interface and in the scope of the present the CDNI Logging interface and in the scope of the present
document. For example, the uCDN may use this logging information document. For example, the uCDN may use this logging information
to charge the CSP, to perform analytics and monitoring for to charge the CSP, to perform analytics and monitoring for
operational reasons, to provide analytics and monitoring views on operational reasons, to provide analytics and monitoring views on
its content delivery to the CSP or to perform trouble-shooting. its content delivery to the CSP or to perform trouble-shooting.
This document specifies non-real-time exchange of logging This document exclusively specifies non-real-time exchange of
information; closer to real-time exchange of logging information logging information. Closer to real-time exchange of logging
(say sub-minute or sub-second) is outside the scope of the present information (say sub-minute or sub-second) is outside the scope of
document and left for further study. This document specifies the present document and left for further study. This document
exchange of logging information related to content delivery; exclusively specifies exchange of logging information related to
exchange of logging information related to operational events content delivery. Exchange of logging information related to
(e.g. dCDN request routing function unavailable, content operational events (e.g. dCDN request routing function
acquisition failure by dCDN) for audit or operational reactive unavailable, content acquisition failure by dCDN) for audit or
adjustments by uCDN is outside the scope of the present document operational reactive adjustments by uCDN is outside the scope of
and left for further study. the present document and left for further study.
o customization by the dCDN of the logging to be performed by the o customization by the dCDN of the logging to be performed by the
uCDN on behalf of the dCDN. The mechanism to support the uCDN on behalf of the dCDN. The mechanism to support the
customisation by the dCDN of CDNI Logging information is outside customisation by the dCDN of CDNI Logging information is outside
the scope of this document and left for further study. the scope of this document and left for further study.
o generation and collection by the uCDN of logging information o generation and collection by the uCDN of logging information
related to the completion of any task performed by the uCDN on related to the completion of any task performed by the uCDN on
behalf of the dCDN (e.g., serving of content by uCDN to dCDN for behalf of the dCDN (e.g., serving of content by uCDN to dCDN for
acquisition purposes by dCDN) or related to events happening in acquisition purposes by dCDN) or related to events happening in
skipping to change at page 7, line 6 skipping to change at page 6, line 46
particular scenario where 4 CDNs are involved in the delivery of particular scenario where 4 CDNs are involved in the delivery of
content from a given CSP: the uCDN has a CDNI interconnection with content from a given CSP: the uCDN has a CDNI interconnection with
dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with
dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all
participate in the delivery of content for the CSP. In this example, participate in the delivery of content for the CSP. In this example,
the CDNI Logging interface enables the uCDN to obtain logging the CDNI Logging interface enables the uCDN to obtain logging
information from all the dCDNs involved in the delivery. In the information from all the dCDNs involved in the delivery. In the
example, uCDN uses the Logging data: example, uCDN uses the Logging data:
o to analyze the performance of the delivery operated by the dCDNs o to analyze the performance of the delivery operated by the dCDNs
and to adjust its operations a-posteriori (e.g., request routing) and to adjust its operations after the fact (e.g., request
as appropriate, routing) as appropriate,
o to provide (non real-time) reporting and monitoring information to o to provide (non real-time) reporting and monitoring information to
CSP. CSP.
For instance, uCDN merges Logging data, extracts relevant KPIs, and For instance, uCDN merges Logging data, extracts relevant KPIs, and
presents a formatted report to the CSP, in addition to a bill for the presents a formatted report to the CSP, in addition to a bill for the
content delivered by uCDN itself or by its dCDNs on his behalf. uCDN content delivered by uCDN itself or by its dCDNs on his behalf. uCDN
may also provide Logging data as raw log files to the CSP, so that may also provide Logging data as raw log files to the CSP, so that
the CSP can use its own logging analysis tools. the CSP can use its own logging analysis tools.
skipping to change at page 17, line 44 skipping to change at page 17, line 32
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 3: Structure of Logging Files Figure 3: Structure of Logging Files
The CDNI Logging File format is inspired from the W3C Extended Log The CDNI Logging File format is inspired from the W3C Extended Log
File Format [ELF]. However, it is fully specified by the present File Format [ELF]. However, it is fully specified by the present
document. Where the present document differs from the W3C Extended document. Where the present document differs from the W3C Extended
Log File Format, an implementation of CDNI Logging MUST comply with Log File Format, an implementation of CDNI Logging MUST comply with
the present document. the present document.
Using a format that resembles the W3C Extended Log File Format is
intended to keep CDNI logging format close to intra-CDN logging
format commonly used in CDNs today, thereby minimizing systematic
translation at CDN/CDNI boundary.
A CDNI Logging File MUST contain a sequence of lines containing US- A CDNI Logging File MUST contain a sequence of lines containing US-
ASCII characters [CHAR_SET] terminated by CRLF. ASCII characters [CHAR_SET] terminated by CRLF.
Each line of a CDNI Logging File MUST contain either a directive or a Each line of a CDNI Logging File MUST contain either a directive or a
CDNI Logging Record. CDNI Logging Record.
Directives record information about the CDNI Logging process itself. Directives record information about the CDNI Logging process itself.
Lines containing directives MUST begin with the "#" character. Lines containing directives MUST begin with the "#" character.
Directives are specified in Section 3.3. Directives are specified in Section 3.3.
skipping to change at page 29, line 4 skipping to change at page 28, line 43
o cs- method o cs- method
o cs-uri o cs-uri
o u-uri o u-uri
o protocol o protocol
o sc-status o sc-status
o sc- total-bytes o sc- total-bytes
o sc-entity-bytes o sc-entity-bytes
o cs(<HTTP-header>) o cs(<HTTP-header>)
o sc(<HTTP-header>) o sc(<HTTP-header>)
o s-ccid
o s-sid
o s-cached o s-cached
A dCDN-side implementation of the CDNI Logging interface MAY support A dCDN-side implementation of the CDNI Logging interface MAY support
the ability to include valid values for the following Logging Fields the ability to include valid values for the following Logging Fields
in a CDNI Logging Record of Record-Type "cdni_http_request_v1": in a CDNI Logging Record of Record-Type "cdni_http_request_v1":
o c-ip-anonimizing o c-ip-anonimizing
o s-ccid o s-ccid
skipping to change at page 32, line 16 skipping to change at page 32, line 5
CDNI Logging files MUST NOT be modified by the dCDN once published in CDNI Logging files MUST NOT be modified by the dCDN once published in
the CDNI Logging feed. the CDNI Logging feed.
The frequency with which the subscription feed is updated, the period The frequency with which the subscription feed is updated, the period
of time covered by each CDNI Logging file or each archive document, of time covered by each CDNI Logging file or each archive document,
and timeliness of publishing of CDNI Logging files is outside the and timeliness of publishing of CDNI Logging files is outside the
scope of the present document and is expected to be agreed upon by scope of the present document and is expected to be agreed upon by
uCDN and dCDN via other means (e.g. human agreement). uCDN and dCDN via other means (e.g. human agreement).
The server-side implementation MUST retain, and be ready to serve,
any CDNI Logging File currently published by the server-side in the
subscription document of the CDNI Logging Feed.
The server-side implementation SHOULD use HTTP cache control headers The server-side implementation SHOULD use HTTP cache control headers
on the subscription feed to indicate the frequency at which the on the subscription feed to indicate the frequency at which the
client-side is to poll for updates. client-side is to poll for updates.
4.1.3. Redundant Feeds 4.1.3. Redundant Feeds
The server-side implementation MAY present more than one CDNI Logging The server-side implementation MAY present more than one CDNI Logging
feed and for redundancy, CDNI Logging files MAY be published in more feed and for redundancy, CDNI Logging files MAY be published in more
than one feed. than one feed.
skipping to change at page 33, line 39 skipping to change at page 33, line 33
</feed> </feed>
Figure 4: Example subscription document of a CDNI Logging Feed Figure 4: Example subscription document of a CDNI Logging Feed
4.2. CDNI Logging File Pull 4.2. CDNI Logging File Pull
A client-side implementation of the CDNI Logging interface MUST pull, A client-side implementation of the CDNI Logging interface MUST pull,
at its convenience, a CDNI Logging File that is published by the at its convenience, a CDNI Logging File that is published by the
server-side in the CDNI Logging Feed. To do so, the client-side: server-side in the CDNI Logging Feed. To do so, the client-side:
o MUST use HTTP v1.1 ( [RFC2616]) o MUST use HTTP v1.1 ( [RFC2616]);
o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS")
as per [RFC2818] whenever protection of the CDNI Logging as per [RFC2818] whenever protection of the CDNI Logging
information is required (see Section 6.1) information is required (see Section 6.1);
o MUST use the URI that was associated to the CDNI Logging File o MUST use the URI that was associated to the CDNI Logging File
(within the "src" attribute of the corresponding atom:content (within the "src" attribute of the corresponding atom:content
element) in the CDNI Logging Feed element) in the CDNI Logging Feed
o MUST support exchange of uncompressed CDNI Logging Files (i.e. o MUST support exchange of CDNI Logging Files with no content
using "identity" content coding as defined in [RFC2616]) encoding applied to the representation;
o SHOULD support exchange of gzip compressed CDNI Logging Files o SHOULD support exchange of CDNI Logging Files with "gzip" content
(i.e. using "gzip" content coding as defined in [RFC2616]) encoding (as defined in [RFC2616]) applied to the representation.
Note that a client-side implementation of the CDNI Logging interface Note that a client-side implementation of the CDNI Logging interface
MAY pull a CDNI Logging File that it has already pulled, as long as MAY pull a CDNI Logging File that it has already pulled, as long as
the file is still published by the server-side in the subscription the file is still published by the server-side in the subscription
document of CDNI Logging Feed. document of CDNI Logging Feed.
[Editor's note: if a given Logging file is moved away from
subscription document to an archive document, do we agree it may no
longer be accessible to uCDN?]
The server-side implementation MUST respond to any valid pull request The server-side implementation MUST respond to any valid pull request
by a client-side implementation for a CDNI Logging File published by by a client-side implementation for a CDNI Logging File published by
the server-side in the subscription document of the CDNI Logging the server-side in the subscription document of the CDNI Logging
Feed. The server-side implementation: Feed. The server-side implementation:
o MUST handle the client-side request as per HTTP v1.1 o MUST handle the client-side request as per HTTP v1.1;
o MUST include the CDNI Logging File identified by the request URI o MUST include the CDNI Logging File identified by the request URI
inside the body of the HTTP response inside the body of the HTTP response;
o MUST support exchange of uncompressed CDNI Logging Files (i.e. o MUST support exchange of CDNI Logging Files with no content
using "identity" content-coding as defined in [RFC2616]) encoding applied to the representation;
o SHOULD support exchange of gzip compressed CDNI Logging Files o SHOULD support exchange of CDNI Logging Files with "gzip" content
(i.e. using "gzip" content-coding as defined in [RFC2616] encoding (as defined in [RFC2616]) applied to the representation.
Content negotiation approaches defined in [RFC2616] (e.g. using Content negotiation approaches defined in [RFC2616] (e.g. using
Accept-Encoding request-header field or Content-Encoding entity- Accept-Encoding request-header field or Content-Encoding entity-
header field) MAY be used by the client-side and server-side header field) MAY be used by the client-side and server-side
implementations to establish the content-coding to be used for a implementations to establish the content-coding to be used for a
particular exchange of a CDNI Logging File. particular exchange of a CDNI Logging File.
Applying compression content encoding (such as "gzip") is expected to
mitigate the impact of exchanging the large volumes of logging
information expected across CDNs. This is expected to be
particularly useful in the presence of HTTP Adaptive Streaming (HAS)
which, as per the present version of the document, will result in a
separate CDNI Log Record for each HAS segment delivery in the CDNI
Logging File.
5. IANA Considerations 5. IANA Considerations
5.1. CDNI Logging Directive Names Registry 5.1. CDNI Logging Directive Names Registry
The IANA is requested to create a new registry, CDNI Logging The IANA is requested to create a new registry, CDNI Logging
Directive Names. Directive Names.
The initial contents of the CDNI Logging File Directives registry The initial contents of the CDNI Logging File Directives registry
comprise the names of the directives specified in Section 3.3 of the comprise the names of the directives specified in Section 3.3 of the
present document, and are as follows: present document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
+ Directive Name + Reference | | Directive Name + Reference |
+------------------------------+-----------+ +------------------------------+-----------+
+ Version + RFC xxxx | | Version + RFC xxxx |
+ UUID + RFC xxxx | | UUID + RFC xxxx |
+ Claimed-Origin + RFC xxxx | | Claimed-Origin + RFC xxxx |
+ Verified-Origin + RFC xxxx | | Verified-Origin + RFC xxxx |
+ Record-Type + RFC xxxx | | Record-Type + RFC xxxx |
+ Fields + RFC xxxx | | Fields + RFC xxxx |
+ Integrity-Hash + RFC xxxx | | Integrity-Hash + RFC xxxx |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 5 Figure 5
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, names are to be allocated by IANA according to Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226]. the "Specification Required" policy specified in [RFC5226].
5.2. CDNI Logging Record-Types Registry 5.2. CDNI Logging Record-Types Registry
The IANA is requested to create a new registry, CDNI Logging Record- The IANA is requested to create a new registry, CDNI Logging Record-
Types. Types.
The initial contents of the CDNI Logging Record-Types registry The initial contents of the CDNI Logging Record-Types registry
comprise the names of the CDNI Logging Record types specified in comprise the names of the CDNI Logging Record types specified in
Section 3.4 of the present document, and are as follows: Section 3.4 of the present document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
+ Record-Types + Reference | | Record-Types + Reference |
+------------------------------+-----------+ +------------------------------+-----------+
+ cdni_http_request_v1 + RFC xxxx | | cdni_http_request_v1 + RFC xxxx |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 6 Figure 6
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, Record-Types are to be allocated by IANA Within the registry, Record-Types are to be allocated by IANA
according to the "Specification Required" policy specified in according to the "Specification Required" policy specified in
[RFC5226]. [RFC5226].
skipping to change at page 36, line 10 skipping to change at page 36, line 10
5.3. CDNI Logging Field Names Registry 5.3. CDNI Logging Field Names Registry
The IANA is requested to create a new registry, CDNI Logging Field The IANA is requested to create a new registry, CDNI Logging Field
Names. Names.
The initial contents of the CDNI Logging Fields Names registry The initial contents of the CDNI Logging Fields Names registry
comprise the names of the CDNI Logging fields specified in comprise the names of the CDNI Logging fields specified in
Section 3.4 of the present document, and are as follows: Section 3.4 of the present document, and are as follows:
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
+ Field Name + Reference | | Field Name + Reference |
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
+ date + RFC xxxx | | date + RFC xxxx |
+ time + RFC xxxx | | time + RFC xxxx |
+ time-taken + RFC xxxx | | time-taken + RFC xxxx |
+ c-ip + RFC xxxx | | c-ip + RFC xxxx |
+ c-ip-anonimizing + RFC xxxx | | c-ip-anonimizing + RFC xxxx |
+ c-port + RFC xxxx | | c-port + RFC xxxx |
+ s-ip + RFC xxxx | | s-ip + RFC xxxx |
+ s-hostname + RFC xxxx | | s-hostname + RFC xxxx |
+ s-port + RFC xxxx | | s-port + RFC xxxx |
+ cs- method + RFC xxxx | | cs- method + RFC xxxx |
+ cs-uri + RFC xxxx | | cs-uri + RFC xxxx |
+ u-uri + RFC xxxx | | u-uri + RFC xxxx |
+ protocol + RFC xxxx | | protocol + RFC xxxx |
+ sc-status + RFC xxxx | | sc-status + RFC xxxx |
+ sc- total-bytes + RFC xxxx | | sc- total-bytes + RFC xxxx |
+ sc-entity-bytes + RFC xxxx | | sc-entity-bytes + RFC xxxx |
+ cs(<HTTP-header>) + RFC xxxx | | cs(<HTTP-header>) + RFC xxxx |
+ sc(<HTTP-header>) + RFC xxxx | | sc(<HTTP-header>) + RFC xxxx |
+ s-ccid + RFC xxxx | | s-ccid + RFC xxxx |
+ s-sid + RFC xxxx | | s-sid + RFC xxxx |
+ s-cached + RFC xxxx | | s-cached + RFC xxxx |
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
Figure 7 Figure 7
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, names are to be allocated by IANA according to Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226]. the "Specification Required" policy specified in [RFC5226].
skipping to change at page 40, line 10 skipping to change at page 40, line 10
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", RFC Content Distribution Network Interconnection (CDNI)", RFC
6983, July 2013. 6983, July 2013.
Appendix A. Requirements Appendix A. Compliance with CDNI Requirements
[Editor's Note: text in this Appendix will be revisited soon]
A.1. Compliance with cdni-requirements
This section discusses compliance of the present specification
against all the relevant requirements of
[I-D.ietf-cdni-requirements].
[Editor's Note: we may want to re-structure this into a table that
would more clearly show compliance level]
A.1.1. General requirements
Some of the general CDNI requirements defined in
[I-D.ietf-cdni-requirements] are not applicable to the CDNI Logging
Interface [GEN-5, GEN-6, GEN-7, GEN-8, GEN-9, GEN-12].
The Logging Interface does not define any new protocols [GEN-1], does
not require any change or upgrade on the user agent [GEN-2] or on the
Content Service Provider side [GEN-3]. Also, no intra-CDN
information is necessary [GEN-4] and the CDNI Logging Interface
supports any interconnection topology [GEN-10]. However, The CDNI
Logging Interface does not define a specific loop avoidance mechanism
[GEN-11], but the exchange of logs is usually done in a point to
point manner between two well identified entities situated
respectively in the uCDN and the dCDN.
The CDNI Loggin Interface supports specific logging for the HTTP
Adaptive Streaming content. [RFC6983] offers more details about
particular logging fields required for HTTP Adaptive Streaming.
A.1.2. Logging Interface requirements
Reliable transfer is achieved by the transport protocol: the logging
information is transmitted over HTTP running over TCP [LI-1].
The CDNI Logging Interface supports logs for all content deliveries
both complete and incomplete performed by the dCDN on behalf of the
uCDN [LI-2].
The CDNI Logging Interface does not impose any restrictions related
to the transmission of logs generated by intermediary CDNs. The dCDN
formats internally all the final logging files, including those
received from intermediary CDNs and the files locally generated. The
dCDN then sends all required logging files to the uCDN [LI-3].
The ATOM feed allows the uCDN to trigger the download of logging
files whenever needed [LI-4].
The uCDN can pull logging files from the dCDN whenever a new file is
available. The timing constraints for the generation of the logging
files are to be defined offline, since the CDNI Logging Interface
does not include a negotiation mechanism for the frequency of logging
file generation. Note that the current version of this document
refers strictly to non real-time logging [LI-5].
Section Section 3.4 describes the CDNI Logging Records and the
possible fields that can be included in a record [LI-6].
As a transport mechanism, the CDNI Logging Interface uses the ATOM
protocol over HTTP (or HTTPS) [LI-7].
A CDN can query another CDN for relevant current logging files by
using the ATOM feed that allows to check for newly published content.
Note that the current version of this document refers strictly to non
real-time logging [LI-8].
The current version of the document does not specify any mechanisms
for producing aggregate / summarized logs, but the exchanged logging
files provide all information that is necessary to the uCDN in order
to obtain aggregated logs. Future versions might include such
mechanisms [LI-9].
No logging of performance data or consumed resources for the dCDN
itself or any other cascaded CDN is included in the current version
of the document. Future versions of this document might define such
information [LI-10, LI-11, LI-12].
The current version of the document specifies the logging information
related strictly to the delivery process. Logging files for any
other functionalities (e.g., content purge, request routing events
etc.) might be taken into account in future versions [LI-13].
Extensibility, the logging and exchange of proprietary information
fields are detailed in Section 5 IANA Considerations [LI-14, LI-15].
The ATOM protocol allows the dCDN to publish the list of available
resources (i.e. logging files) [LI-16].
Section 3.4 provides details about the fields of the HTTP Adaptive
Streaming specific logging records, including the Content Collection
Identifier (s-ccid) and Session Identifier (s-sid) [LI-17].
A.1.3. Security requirements
[SEC-3, SEC-5] are not applicable to the CDNI Loggin Interface, all
remaining security requirements are addressed as discussed in
Section 6.
A.2. Considerations on CDNI Logging Applicability
This section discusses a number of considerations related to the
applicability of the CDNI Logging interface as specified in the
present document.
[Editor's note: How do we incorporate this info into the I-D: in
appendix? in main body? does it remain after publication or is
temporary?]
A.2.1. Timeliness
Some applications consuming CDNI Logging information, such as
accounting or trend analytics, only require logging information to be
available with a timeliness of the order of a day or the hour. This
document focuses on addressing this requirement.
Some applications consuming CDNI Logging information, such as real-
time analytics, require logging information to be available in real-
time (i.e. of the order of a second after the corresponding event).
This document leaves this requirement out of scope.
A.2.2. Reliability
CDNI logging information must be transmitted reliably. The transport
protocol should contain an anti-replay mechanism.
A.2.3. Security
CDNI logging information exchange must allow authentication,
integrity protection, and confidentiality protection.
A.2.4. Scalability [Editor's Note: this section may need a small update if ietf-cdni-
requirements introduces an additional requirement for Privacy/
Anonimization as recently discussed on the list, and if LI14 & LI-15
are modified]
CDNI logging information exchange must support large scale The three tables below review compliance against, respectively, the
information exchange, particularly so in the presence of HTTP Generic CDNI requirements, the CDNI Logging interafce requirements
Adaptive Streaming. and the CDNI security requirements of [I-D.ietf-cdni-requirements].
The first two columns of the tables indicate the requirement number,
and the requirement priority as defined in
[I-D.ietf-cdni-requirements]. The third column of the table
indicates the level of compliance of the CDNI Logging interface
specified in the present document against the given requirement, and
the fourth column provides additional comment and explanation on how
or why the compliance is achieved or not achieved.
For example, if we consider a client pulling HTTP Progressive +-------+-------+-----------+---------------------------------------+
Download content with an average duration of 10 minutes, this | Re- | Prior-| Compli- | Comment |
represents 1/600 CDNI delivery Logging Records per second. If we | quire-| ity | ance | |
assume the dCDN is simultaneously serving 100,000 such clients on | ment | | | |
behalf of the uCDN, the dCDN will be generating 167 Logging Records +-------+-------+-----------+---------------------------------------+
per second to be communicated to the uCDN over the CDNI Logging | GEN-1 | MED | Full | Leverages existing protocols incl |
interface. Or equivalently, if we assume an average delivery rate of | | | | including HTTP, TLS and ATOM |
2Mb/s, the dCDN generates 0.83 CDNI Logging Records per second for +-------+-------+-----------+---------------------------------------+
every Gb/s of streaming on behalf of the uCDN. | GEN-2 | HIGH | Full | Does not require any change or upgrade|
| | | | to the user agent |
+-------+-------+-----------+---------------------------------------+
| GEN-3 | HIGH | Full | Does not require any change or upgrade|
| | | | to the Content Service Provider |
+-------+-------+-----------+---------------------------------------+
| GEN-4 | HIGH | Full | Does not depend on intra-CDN info |
+-------+-------+-----------+---------------------------------------+
| GEN-5 | HIGH | Full | Supports logging of HTTP delivery |
+-------+-------+-----------+---------------------------------------+
| GEN-6 | HIGH | N/A | |
+-------+-------+-----------+---------------------------------------+
| GEN-7 | LOW | Not | Only supports logging for HTTP |
| | | Compliant | delivery, but easily extensible to |
| | | | add support for other delivery protos |
+-------+-------+-----------+---------------------------------------+
| GEN-8 | LOW | N/A | |
+-------+-------+-----------+---------------------------------------+
| GEN-9 | MED | Full | Supports logging across cascaded CDNs |
+-------+-------+-----------+---------------------------------------+
| GEN-10| MED | Full | Supports any toplogy of interconnected|
| | | | CDNs |
+-------+-------+-----------+---------------------------------------+
| GEN-11| HIGH | Parial | No explicit mechanism for loop |
| | | | avoidance is defined; the exchange of |
| | | | logs is usually done in a point to |
| | | | point manner between two well identi- |
| | | | fied entities situated in the uCDN and|
| | | | dCDN. Loop avoidance is expected to be|
| | | | handled by implementations based on |
| | | | inferring the CDN path from the URI |
| | | | structure in the HTTP redirection case|
| | | | and/or administrative information |
| | | | (topology restrictions in case of DNS |
| | | | redirection method also handled admi- |
| | | | nistratively) |
+-------+-------+-----------+---------------------------------------+
| GEN-12| HIGH | N/A | |
+-------+-------+-----------+---------------------------------------+
| GEN-13| HIGH | Full | Supports Logging for HTTP Adaptive |
| | | | Streaming (HSAS) content, with one |
| | | | Logging Record per HAS segment. |
| | | | Supports a few optional logging fields|
| | | | specific to HAS. Does not support |
| | | | summarized Logging Records for HAS, |
| | | | but extensible to add that. |
+-------+-------+-----------+---------------------------------------+
For example, if we consider a client pulling HAS content and Figure 8: Compliance to Generic CDNI Requirements
receiving a video chunk every 2 seconds, a separate audio chunck
every 2 seconds and a refreshed manifest every 10 seconds, this
represents 1.1 delivery Logging Record per second. If we assume the
dCDN is simultaneously serving 100,000 such clients on behalf of the
uCDN, the dCDN will be generating 110,000 Logging Records per second
to be communicated to the uCDN over the CDNI Logging interface. Or
equivalently, if we assume an average delivery rate of 2Mb/s, the
dCDN generates 550 CDNI Logging Records per second for every Gb/s of
streaming on behalf of the uCDN.
A.2.5. Consistency between CDNI Logging and CDN Logging +-------+-------+-----------+---------------------------------------+
| Re- | Prior-| Compli- | Comment |
| quire-| ity | ance | |
| ment | | | |
+-------+-------+-----------+---------------------------------------+
| LI-1 | HIGH | Full | Reliable transfer is achieved by the |
| | | | transport protocol: the logging data |
| | | | is transmitted over HTTP over TCP. |
| | | | Also, supports optional redundancy of |
| | | | the Logging feed. |
+-------+-------+-----------+---------------------------------------+
| LI-2 | HIGH | Full | Supports |
| | | | logs for all content deliveries both |
| | | | complete and incomplete performed by |
| | | | the dCDN on behalf of the uCDN |
+-------+-------+-----------+---------------------------------------+
| LI-3 | MED | Full | The CDNI Logging Interface does not |
| | | | impose any restrictions related to the|
| | | | transmission of logs generated by |
| | | | intermediary CDNs; the dCDN formats |
| | | | internally all the final logging files|
| | | | including those received from interme-|
| | | | diary CDNs and the locally generated |
+-------+-------+-----------+---------------------------------------+
| LI-4 | HIGH | Full | The ATOM feed allows the uCDN to trig-|
| | | | ger the download of logging files |
| | | | whenever needed |
+-------+-------+-----------+---------------------------------------+
| LI-5 | MED | Partial | The uCDN can pull logging files from |
| | | | the dCDN whenever a new file is |
| | | | available. The timing constraints for |
| | | | the generation of the logging files |
| | | | are to be defined offline, and can be |
| | | | defined to an arbitrary period. This |
| | | | is expected to be compatible with |
| | | | applications that have low timing |
| | | | constraints (e.g. 24 hours) such as |
| | | | billing. This is expected to be |
| | | | compatible with applications that |
| | | | have high timing constraints (e.g. 5 |
| | | | minutes) such as monitoring or |
| | | | analytics. This is not expected to be |
| | | | compatible with applications that have|
| | | | very high timing constraints (e.g. |
| | | | a few seconds or below) |
+-------+-------+-----------+---------------------------------------+
| LI-6 | HIGH | Full | Section 3.4 describes the CDNI Logging|
| | | | Records and the possible fields that |
| | | | can be included in a record. |
| | | | Supports a single type of CDNI event |
| | | | i.e. HTTP delivery |
+-------+-------+-----------+---------------------------------------+
| LI-7 | HIGH | Full | Defines an ATOM based feed and HTTP |
| | | | or HTTPS transport |
+-------+-------+-----------+---------------------------------------+
| LI-8 | MED | Partial | Allows as uCDN to pull current CDNI |
| | | | Logging files to access current |
| | | | Logging records. Does not allow uCDN |
| | | | to request Log Records before next |
| | | | Logging file is made available. |
+-------+-------+-----------+---------------------------------------+
| LI-9 | LOW | Not | The current version of the document |
| | | Compliant | does not specify any mechanisms for |
| | | | producing aggregate / summarized logs,|
| | | | but exchanged logging files provide |
| | | | all the information that is necessary |
| | | | to the uCDN in order to produce aggre-|
| | | | gated logs. Extensible to add such |
| | | | mechanisms in the future |
+-------+-------+-----------+---------------------------------------+
| LI-10 | LOW | Not | Future versions might define such a |
| | | compliant | mechanism for logging performance |
| | | | data. Allows uCDN to derive some perf |
| | | | indicators from delivery Records |
+-------+-------+-----------+---------------------------------------+
| LI-11 | MED | Not | Future versions might define such a |
| | | compliant | mechanism for logging data about |
| | | | resources consumed by the dCDN |
+-------+-------+-----------+---------------------------------------+
| LI-12 | MED | Not | Future versions might define such a |
| | | compliant | mechanism for logging data about |
| | | | resources consumed by cascaded CDNs |
+-------+-------+-----------+---------------------------------------+
| LI-13 | HIGH | Not | Not supported by CDNI Logging |
| | | compliant | interface. However, it is expected |
| | | | that teh CDNI Control interface will |
| | | | allow tracing of delete request |
| | | | results (e.g. success, failure). |
+-------+-------+-----------+---------------------------------------+
| LI-14 | HIGH | Full | Details about extensibility mechanisms|
| | | | in Section 6. |
+-------+-------+-----------+---------------------------------------+
| LI-15 | HIGH | Full | Details about proprietary fields in |
| | | | Section 6. |
+-------+-------+-----------+---------------------------------------+
| LI-16 | HIGH | Full | The CDNI Logging feed indicates which |
| | | | Logging file is (or was) available |
+-------+-------+-----------+---------------------------------------+
| LI-17 | MED | Full | Content Collection ID and Session ID |
| | | | are supported for logging records re- |
| | | | lated to HTTP Adaptive Streaming |
+-------+-------+-----------+---------------------------------------+
There are benefits in using a CDNI logging format as close as Figure 9: Compliance to CDNI Logging interface Requirements
possible to intra-CDN logging format commonly used in CDNs today in
order to minimize systematic translation at CDN/CDNI boundary.
A.2.6. Dispatching/Filtering +-------+-------+-----------+---------------------------------------+
| Re- | Prior-| Compli- | Comment |
| quire-| ity | ance | |
| ment | | | |
+-------+-------+-----------+---------------------------------------+
| SEC-1 | HIGH | Full | TLS can be used for transport of any |
| | | | CDNI logging related information which|
| | | | provides authentication, confidentia- |
| | | | lity, integrity protection as well as |
| | | | protection agasint spoofing and replay|
+-------+-------+-----------+---------------------------------------+
| SEC-2 | HIGH | Full | No specific mechanism against Denial |
| | | | of Service attacks is defined on the |
| | | | Logging Interface. Spoofed requests |
| | | | can be avoided by using TLS. |
| | | | Protection against spoofed delivery |
| | | | requests are outside the scope of CDNI|
| | | | Logging |
+-------+-------+-----------+---------------------------------------+
| SEC-3 | MED | N/A | Establishing CDN path with non- |
| | | | repudiation is outside the scope of |
| | | | CDNI Logging. Does not prevent use of |
| | | | such mechanism (e.g. including info |
| | | | in content URI). |
+-------+-------+-----------+---------------------------------------+
| SEC-4 | MED | Not | A non-repudiation mechanism for CDNI |
| | | compliant | logging might be defined in a separate|
| | | | document |
+-------+-------+-----------+---------------------------------------+
| SEC-5 | LOW | N/A | |
+-------+-------+-----------+---------------------------------------+
When a CDN is acting as a dCDN for multiple uCDNs, the dCDN needs to Figure 10: Compliance to CDNI Security Requirements
dispatch each CDNI Logging Record to the uCDN that redirected the
corresponding request. The CDNI Logging format need to allow, and
possibly facilitate, such a dispatching.
Authors' Addresses Authors' Addresses
Francois Le Faucheur (editor) Francois Le Faucheur (editor)
Cisco Systems Cisco Systems
E.Space Park - Batiment D E.Space Park - Batiment D
6254 Allee des Ormes - BP 1200 6254 Allee des Ormes - BP 1200
Mougins cedex 06254 Mougins cedex 06254
FR FR
 End of changes. 41 change blocks. 
254 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/