draft-ietf-cdni-footprint-capabilities-semantics-12.txt   draft-ietf-cdni-footprint-capabilities-semantics-13.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: September 9, 2016 Neustar Expires: October 6, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
March 8, 2016 April 4, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-12 draft-ietf-cdni-footprint-capabilities-semantics-13
Abstract Abstract
This document captures the semantics of the "Footprint and This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e., the desired meaning of "Footprint" and interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and "Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries further defines a Base Advertisement Object, the necessary registries
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 September 9, 2016. This Internet-Draft will expire on October 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16
8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17 8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17
8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17
8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction and Scope 1. Introduction and Scope
The CDNI working group is working on a set of protocols to enable the The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs. This CDN interconnection (CDNI) interconnection of multiple CDNs. This CDN interconnection (CDNI)
can serve multiple purposes, as discussed in [RFC6770], for instance, can serve multiple purposes, as discussed in [RFC6770], for instance,
to extend the reach of a given CDN to areas in the network which are to extend the reach of a given CDN to areas in the network which are
not covered by this particular CDN. not covered by this particular CDN.
The goal of this document is to achieve a clear understanding about The goal of this document is to achieve a clear understanding about
skipping to change at page 3, line 35 skipping to change at page 3, line 35
FCI protocols are provided. FCI protocols are provided.
General assumptions in this document: General assumptions in this document:
o The CDNs participating in the interconnected CDN have already o The CDNs participating in the interconnected CDN have already
performed a boot strap process, i.e., they have connected to each performed a boot strap process, i.e., they have connected to each
other, either directly or indirectly, and can exchange information other, either directly or indirectly, and can exchange information
amongst each other. amongst each other.
o The upstream CDN (uCDN) receives footprint and/or capability o The upstream CDN (uCDN) receives footprint and/or capability
advertisements from a set of dCDNs. Footprint advertisement and advertisements from a set of downstream CDNs (dCDNs). Footprint
capability advertisement need not use the same underlying advertisement and capability advertisement need not use the same
protocol. underlying protocol.
o The uCDN receives the initial request-routing request from the o The uCDN receives the initial request-routing request from the
endpoint requesting the resource. endpoint requesting the resource.
The CDNI Problem Statement [RFC6707] describes the Request Routing The CDNI Problem Statement [RFC6707] describes the Request Routing
Interface as: "[enabling] a Request Routing function in an Upstream Interface as: "[enabling] a Request Routing function in an Upstream
CDN to query a Request Routing function in a Downstream CDN to CDN to query a Request Routing function in a Downstream CDN to
determine if the Downstream CDN is able (and willing) to accept the determine if the Downstream CDN is able (and willing) to accept the
delegated Content Request". In addition, the RFC says "the CDNI delegated Content Request". In addition, RFC6707 says "the CDNI
Request Routing interface is also expected to enable a downstream CDN Request Routing interface is also expected to enable a downstream CDN
to provide to the upstream CDN (static or dynamic) information (e.g., to provide to the upstream CDN (static or dynamic) information (e.g.,
resources, footprint, load) to facilitate selection of the downstream resources, footprint, load) to facilitate selection of the downstream
CDN by the upstream CDN request routing system when processing CDN by the upstream CDN request routing system when processing
subsequent content requests from User Agents". It thus considers subsequent content requests from User Agents". It thus considers
"resources" and "load" as capabilities to be advertised by the "resources" and "load" as capabilities to be advertised by the
downstream CDN. downstream CDN.
The range of different footprint definitions and possible The range of different footprint definitions and possible
capabilities is very broad. Attempting to define a comprehensive capabilities is very broad. Attempting to define a comprehensive
skipping to change at page 6, line 35 skipping to change at page 6, line 35
of the dCDN state needs to be pushed to the uCDN and qualitatively of the dCDN state needs to be pushed to the uCDN and qualitatively
how often that information needs to be updated. how often that information needs to be updated.
2.3. Advertisement versus Queries 2.3. Advertisement versus Queries
In a CDNI environment, each dCDN shares some of its state with the In a CDNI environment, each dCDN shares some of its state with the
uCDN. The uCDN uses this information to build a unified picture of uCDN. The uCDN uses this information to build a unified picture of
all of the dCDNs available to it. In architectures that share all of the dCDNs available to it. In architectures that share
detailed capability information, the uCDN could perform the entire detailed capability information, the uCDN could perform the entire
request-routing operation down to selecting a particular cache in the request-routing operation down to selecting a particular cache in the
dCDN (note: within the current CDNI WG charter, such direct selection dCDN. However, when the uCDN needs to deal with many potential
of specific caches by the uCDN is out-of-scope). However, when the dCDNs, this approach does not scale, especially for dCDNs with
uCDN needs to deal with many potential dCDNs, this approach does not thousands or tens of thousands of caches; the volume of updates to
scale, especially for dCDNs with thousands or tens of thousands of footprint and capability becomes onerous.
caches; the volume of updates to footprint and capability becomes
onerous.
Were the volume of FCI updates from dCDNs to exceed the volume of Were the volume of FCI updates from dCDNs to exceed the volume of
requests to the uCDN, it might make more sense for the uCDN to query requests to the uCDN, it might make more sense for the uCDN to query
dCDNs upon receiving requests (as is the case in the recursive dCDNs upon receiving requests (as is the case in the recursive
redirection mode described in [RFC7336]), instead of receiving redirection mode described in [RFC7336]), instead of receiving
advertisements and tracking the state of dCDNs. The advantage of advertisements and tracking the state of dCDNs. The advantage of
querying dCDNs would be that much of the dynamic data that dCDNs querying dCDNs would be that much of the dynamic data that dCDNs
cannot share with the uCDN would now be factored into the uCDN's cannot share with the uCDN would now be factored into the uCDN's
decision. dCDNs need not replicate any state to the uCDN - uCDNs decision. dCDNs need not replicate any state to the uCDN - uCDNs
could effectively operate in a stateless mode. could effectively operate in a stateless mode.
skipping to change at page 11, line 21 skipping to change at page 11, line 18
cascaded CDNs. Further, the downstream CDN needs to be able to cascaded CDNs. Further, the downstream CDN needs to be able to
express its footprint to an interested upstream CDN (uCDN) in a express its footprint to an interested upstream CDN (uCDN) in a
comprehensive form, e.g., as a data set containing the complete comprehensive form, e.g., as a data set containing the complete
footprint. Making incremental updates, however, to express dynamic footprint. Making incremental updates, however, to express dynamic
changes in state is also desirable. changes in state is also desirable.
5. Semantics for Capabilities Advertisement 5. Semantics for Capabilities Advertisement
In general, the dCDN MUST be able to express its general capabilities In general, the dCDN MUST be able to express its general capabilities
to the uCDN. These general capabilities could express if the dCDN to the uCDN. These general capabilities could express if the dCDN
supports a given service, for instance, HTTP delivery, RTP/RTSP supports a given service, for instance, HTTP vs HTTPS delivery.
delivery or RTMP. Furthermore, the dCDN MUST be able to express Furthermore, the dCDN MUST be able to express particular capabilities
particular capabilities for the delivery in a particular footprint for the delivery in a particular footprint area. For example, the
area. For example, the dCDN might in general offer RTMP but not in dCDN might in general offer HTTPS but not in some specific areas,
some specific areas, either for maintenance reasons or because the either for maintenance reasons or because the caches covering this
caches covering this particular area cannot deliver this type of particular area cannot deliver this type of service. Hence, in
service. Hence, in certain cases footprint and capabilities are tied certain cases footprint and capabilities are tied together and cannot
together and cannot be interpreted independently from each other. In be interpreted independently from each other. In such cases, i.e.,
such cases, i.e., where capabilities need to be expressed on a per where capabilities need to be expressed on a per footprint basis, it
footprint basis, it could be beneficial to combine footprint and could be beneficial to combine footprint and capabilities
capabilities advertisement. advertisement.
A high-level and very rough semantic for capabilities is thus the A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to following: Capabilities are types of information that allow a uCDN to
determine if a downstream CDN is able (and willing) to accept (and determine if a downstream CDN is able (and willing) to accept (and
properly handle) a delegated content request. In addition, properly handle) a delegated content request. In addition,
Capabilities are characterized by the fact that this information can Capabilities are characterized by the fact that this information can
change over time based on the state of the network or caches. change over time based on the state of the network or caches.
At a first glance, several broad categories of capabilities seem At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g., real-time delivery capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically performance metrics, CDN resource load, or other highly dynamically
changing QoS information) is beyond the scope for CDNI FCI. First, changing QoS information) is beyond the scope for CDNI FCI. First,
out of the multitude of possible metrics and capabilities, it is hard out of the multitude of possible metrics and capabilities, it is hard
to agree on a subset and the precise metrics to be used. Second, and to agree on a subset and the precise metrics to be used. Second, it
perhaps more importantly, it seems infeasible to specify such highly seems infeasible to specify such highly dynamically changing
dynamically changing capabilities and the corresponding metrics capabilities and the corresponding metrics within a reasonable time-
within the CDNI charter time-frame. frame.
Useful capabilities refer to information that does not change highly Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if on a particular dCDN for a given end user request. For instance, if
an end user request concerns the delivery of a video file with a an end user request concerns the delivery of a video file with a
certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN certain protocol, the uCDN needs to know if a given dCDN has the
has the capability of supporting this delivery protocol. capability of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs, will happen in contractual agreements between participating CDNs,
i.e., prior to the advertisement phase using the CDNI FCI. The role i.e., prior to the advertisement phase using the CDNI FCI. The role
of capability advertisement is hence rather to enable the dCDN to of capability advertisement is hence rather to enable the dCDN to
update a uCDN on changes since a contract has been set up (e.g., in update a uCDN on changes since a contract has been set up (e.g., in
case a new delivery protocol is suddenly being added to the list of case a new delivery protocol is suddenly being added to the list of
supported delivery protocols of a given dCDN, or in case a certain supported delivery protocols of a given dCDN, or in case a certain
delivery protocol is suddenly not being supported anymore due to delivery protocol is suddenly not being supported anymore due to
skipping to change at page 12, line 47 skipping to change at page 12, line 42
benefit from focusing on a small number of key use cases that are benefit from focusing on a small number of key use cases that are
highly relevant and contain enough complexity to help in highly relevant and contain enough complexity to help in
understanding what concrete capabilities are needed to facilitate CDN understanding what concrete capabilities are needed to facilitate CDN
Interconnection. Interconnection.
Under the above considerations, the following capabilities seem Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e., ones that are needed in any case useful as 'base' capabilities, i.e., ones that are needed in any case
and therefore constitute mandatory capabilities that MUST be and therefore constitute mandatory capabilities that MUST be
supported by the CDNI FCI: supported by the CDNI FCI:
o Delivery Protocol (e.g., HTTP vs. RTMP) o Delivery Protocol (for delivering content to the end user)
o Acquisition Protocol (for acquiring content from a uCDN) o Acquisition Protocol (for acquiring content from the uCDN or
origin server)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [RFC7336]) discussed in [RFC7336])
o CDNI Logging (i.e., supported logging fields) o CDNI Logging (i.e., supported logging fields)
o CDNI Metadata (i.e., supported Generic Metadata types) o CDNI Metadata (i.e., supported Generic Metadata types)
It is not feasible to enumerate all the possible options for the It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, FCI specification with defining each supported capability. Instead,
the CDNI FCI specification SHOULD define a generic protocol for the CDNI FCI specification SHOULD define a generic protocol for
conveying any capability information (e.g. with common encoding, conveying any capability information (e.g. with common encoding,
error handling, and security mechanism; further requirements for the error handling, and security mechanism; further requirements for the
skipping to change at page 18, line 46 skipping to change at page 18, line 46
integrity, an attacker could trivially deny service by forging a integrity, an attacker could trivially deny service by forging a
footprint advertisement from a dCDN which claims the network has no footprint advertisement from a dCDN which claims the network has no
footprint or capability. This would prevent the uCDN from delegating footprint or capability. This would prevent the uCDN from delegating
any requests to the dCDN. Since a pre-existing relationship between any requests to the dCDN. Since a pre-existing relationship between
all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary
credentials could be conducted before the FCI interface is brought credentials could be conducted before the FCI interface is brought
online. The authorization decision to accept advertisements would online. The authorization decision to accept advertisements would
also follow this pre-existing relationship and any contractual also follow this pre-existing relationship and any contractual
obligations that it stipulates. obligations that it stipulates.
It is not believed that there are any serious privacy risks in All protocols that implement these semantics are REQUIRED to provide
sharing footprint or capability information: it will represent highly confidentiality services. Some dCDNs are willing to share
aggregated data about networks and, at best, policy-related information about their footprint or capabilities with a uCDN but not
information about media, rather than any personally identifying with other, competing dCDNs. For example, if a dCDN incurs an outage
information. However, particular dCDNs could be willing to share that reduces footprint coverage temporarily, that could be
information about their footprint with a uCDN but not with other, information the dCDN would want to share confidentially with the
competing dCDNs. For example, if a dCDN incurs an outage that uCDN.
reduces footprint coverage temporarily, that could be information the
dCDN would want to share confidentially with the uCDN. Protocols
implementing these semantics SHOULD provide confidentiality services.
As specified in this document, the security requirements of the FCI As specified in this document, the security requirements of the FCI
could be met by hop-by-hop transport-layer security mechanisms could be met by hop-by-hop transport-layer security mechanisms
coupled with domain certificates as credentials. There is no coupled with domain certificates as credentials (e.g., TLS transport
apparent need for further object-level security in this framework, as for HTTP as per [RFC2818] and [RFC7230], with usage guidance from
the trust relationships it defines are bilateral relationships [RFC7525]). There is no apparent need for further object-level
between uCDNs and dCDNs rather than transitive relationships. security in this framework, as the trust relationships it defines are
bilateral relationships between uCDNs and dCDNs rather than
transitive relationships.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-22 (work in progress), March 2016. logging-24 (work in progress), April 2016.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-12 (work in progress), October 2015. metadata-13 (work in progress), March 2016.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>. November 2012, <http://www.rfc-editor.org/info/rfc6770>.
 End of changes. 20 change blocks. 
51 lines changed or deleted 63 lines changed or added

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