Network Working Group E. Stephan Internet-Draft G. Bertrand Intended status: Standards Track A. Marrec Expires: May 10, 2013 Y. Le Louedec France Telecom - Orange November 06, 2012 CDNI Control Operations draft-stephan-cdni-control-operations-00 Abstract This memo discusses the role of the CDNI control interface and proposes a framework clarifying the control operations for CDNI. It does not make any assumption about the protocol implementation, which may be either manual or automated. Furthermore, both uCDN and dCDN could initiate Control operations. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Stephan, et al. Expires May 10, 2013 [Page 1] Internet-Draft CDNI Control Operations November 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Stephan, et al. Expires May 10, 2013 [Page 2] Internet-Draft CDNI Control Operations November 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. The role of the CDNI Control Interface . . . . . . . . . . . . 5 2.1. Pre-position,revalidate and purge metadata and content . . 6 2.2. Bootstrapping of the other CDNI interfaces . . . . . . . . 7 3. CDNI Control Framework . . . . . . . . . . . . . . . . . . . . 8 3.1. CDNI Control Operations . . . . . . . . . . . . . . . . . 9 3.2. Control Parameters . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Service Agreement level . . . . . . . . . . . . . . . 10 3.2.2. Delivery Service Level . . . . . . . . . . . . . . . . 13 3.2.3. class-of-requests Level . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Stephan, et al. Expires May 10, 2013 [Page 3] Internet-Draft CDNI Control Operations November 2012 1. Introduction The CDNI control Interface is introduced by [RFC6707] along with the CDNI Metadata, CDNI Request Routing, CDNI Acquisition and CDNI Logging interfaces. Then [I-D.ietf-cdni-framework] specifies the high-level functions performed by each of the CDNI interfaces and the relationships between them. It defines the role of the CDNI control interface as encompassing "the operations to discover, initialize, and parameterize the other CDNI interfaces, as well as operations to pre-position, revalidate, and purge both metadata and content." Nevertheless [RFC6707] indicates that the "exact inter-CDN control functionality required to be supported by the CDNI Control interface is less well defined than the other three CDNI interfaces", and [I-D.ietf-cdni-framework] reports that "There is some ambiguity as to the line between the set of trigger-based operations in the CDNI Control interface and the Metadata interface". The present memo proposes to fill this gap. It discusses the role of the CDNI control interface and proposes a framework for working out the specification of the control operations for CDNI. 1.1. Terminology The reader must be familiar with the terminology given by [RFC6707] and by the drafts [I-D.ietf-cdni-requirements] and [I-D.ietf-cdni-framework]. Following are terms and abbreviations introduced in the document: Control Parameter: A parameter whose value may be exchanged for controlling the configuration of the CDNI interfaces; Control Operation: The exchange of messages for discovering, initializing, and parameterizing a CDNI interface. Bootstrapping: A control operation allowing the exchange of the Parameters required to establish the connectivity between servers which enforce the CDNI interfaces, including security aspects like server authentication, encryption, etc. Class-of-requests: A Class-of-requests identifies a set of content Requests, related to a specific CSP, received from clients in a given footprint and sharing common properties. These properties include: * Any header, URL parameter, query parameter of an applicative content request (e.g. of an HTTP content request) Stephan, et al. Expires May 10, 2013 [Page 4] Internet-Draft CDNI Control Operations November 2012 * Any header, or sub-domain of the FQDN of a DNS lookup request Examples: * Class-of-Requests = all the requests that include the HTTP header "User-Agent: Mozilla/5.0" related to CSP "http://*.cdn.example.com" from AS3215 * Class-of-Requests = all the DNS requests from anywhere and related to CSP "cdn*.example.com" Delivery Service: A Delivery Service is defined by a set of Class- of-Requests, related to a given CSP, and a list of parameters that apply to all these Class-of-Requests (logging format, delivery quality/capabilities requirements...) Service Agreement: A service agreement is defined by a uCDN identifier, a dCDN identifier, a set of Delivery Services and a list of parameters that apply to the Service Agreement. Once a Service Agreement is agreed between the administrative entities managing the CDNs to be interconnected, the upstream CDN and the downstream CDN of the CDN interconnection must be configured according to this agreed Service Agreement. For instance, a given uCDN (uCDN1) may request a given dCDN (dCDN1) to configure one Delivery Service for handling content requests for HTTP Adaptive streaming videos delegated by uCDN1 and related to a specific CSP (CSP1) and another one for handling content requests for static pictures delegated by uCDN1 and related to CSP1. These Delivery services would belong to the Service Agreement between uCDN1 and dCDN1 for CSP1. In this simple example, uCDN1 may request dCDN1 to include Delivery Service information in its CDNI Logging, to help uCDN1 to provide relevant reports to CSP1. CDNI Entity: we call CDNI Entity the end-point of a CDNI interface. 2. The role of the CDNI Control Interface This section discusses the role of the CDNI Control interface. The [I-D.ietf-cdni-framework] defines the role of the CDNI control interface as: o "the operations to discover, initialize, and parameterize the other CDNI interfaces" which are: CDNI request Routing, metadata and Logging. Stephan, et al. Expires May 10, 2013 [Page 5] Internet-Draft CDNI Control Operations November 2012 * The CDNI Control interface has the responsibility of bootstrapping the other CDNI interfaces, and of updating or deleting instances of the other CDNI interfaces. o "as well as operations to pre-position, revalidate, and purge both metadata and content". * This is the role of the "trigger" interface which specifications are still work in progress in the draft document[I-D.murray-cdni-triggers]. 2.1. Pre-position,revalidate and purge metadata and content Operations to pre-position, revalidate, and purge both metadata and content are defined in the draft document [I-D.murray-cdni-triggers]. That draft document [I-D.murray-cdni-triggers] defines a "message flow for trigger" based on a RESTfull web services, and specific metadata related activities an upstream CDN can trigger. The "message flow for trigger" allows: o The upstream CDN to trigger activity in downstream CDN ; o The upstream CDN to discover the status of the activity. The activities an upstream CDN can trigger in the downstream CDN and defined in [I-D.murray-cdni-triggers] are all dedicated to operations on content objects and content metadata: o Fetch metadata from uCDN or content from any origin server including uCDN (preposition) ; o Revalidate specific metadata or content before re-using it (invalidate) ; o Delete specific metadata or content purge. The interface specified in the draft "CDN Interconnect triggers" [I-D.murray-cdni-triggers] should not be part of the CDNI control interface. The main raison is that the trigger interface itself need to be bootstrapped (which is the role of the CDNI control interface). There are also other reasons, including the following ones: o Parameters needed to bootstrap a CDNI interface are static, while trigger-based operations are dynamic ; Stephan, et al. Expires May 10, 2013 [Page 6] Internet-Draft CDNI Control Operations November 2012 o All trigger activities defined in [I-D.murray-cdni-triggers] are specific to metadata ; o The CDN entities for (i.e. the "extremities" of) the CDNI control interface and for the CDNI trigger interface are not necessary the same. 2.2. Bootstrapping of the other CDNI interfaces When an upstream CDN operator wants to delegate to a downstream CDN operator the handling of the content requests belonging to a given set of class-of-requests, the uCDN and dCDN establish a Service Agreement. The Service Agreement includes all information required to set up the CDN interconnection. This Service Agreement can be specified with a hierarchical datamodel, as depicted in Figure 1: o A service agreement includes an identifier of uCDN, an identifier of dCDN, one or several delivery services, and a set of control parameters that apply to all these delivery services. For example, let us consider a service agreement that includes two delivery services: a former one corresponding to a Vod application with "premium" delivery requirements, and a latter one corresponding to a Vod application with "standard" delivery requirements ; o Each Delivery service associates one or several Class-of-requests from the same CSP with a set of control parameters that apply to all these Class-of-requests. To continue with the example introduced just above, let us consider that the delivery service corresponding to the Vod application with "premium" delivery requirements include two different class-of-requests: a former one corresponding to all the requests from end-users based in France for http://*.cdn.example.com, and a latter one corresponding to all the requests from end-users in France for rtmp://*.cdn.example.com ; o Each Class-of-requests identifies uniquely a set of requests with a given footprint and specific properties. In the example introduced just above, one of the considered class-of-request corresponds to all the requests from end-users based in France for http://*.cdn.example.com. And another one corresponds to all the requests from end-users in France for rtmp://*.cdn.example.com ; Stephan, et al. Expires May 10, 2013 [Page 7] Internet-Draft CDNI Control Operations November 2012 +---------------------+ |Service Agreement | | +----------------+ | | |Delivery Service| | +----------------------+ | +----------------+ | |Delivery Service | | |Delivery Service| | | +-----------------+ | | +----------------+ | | |Class-of-requests| | | +----------------+ | | +-----------------+ | +-----------------+ | |uCDN identifier | | | |Class-of-requests| | |Class-of requests| | +----------------+ | | +-----------------+ | | +-----------+ | | |dCDN identifier | | | |Class-of-requests| | | |footprint | | | +----------------+ | | +-----------------+ | | +-----------+ | | +----------------+ | | +-----------------+ | | +-----------+ | | |Parameters | | | |Parameters | | | |properties | | | +----------------+ | | +-----------------+ | | +-----------+ | +---------------------+ +----------------------+ +-----------------+ Figure 1 Once a Service Agreeement is agreed between the operators of the CDNs to be interconnected, the upstream CDN and the downstream CDN must be configured for this CDNI interconnection according to the agreed Service Agreement. Namely, CDNI Request Routing interface, CDNI metadata interface, CDNI logging interface and CDNI "trigger" interface must be bootstrapped according to the Service Agreeement. 3. CDNI Control Framework The CDNI control operations can possibly be performed either manually or via some automated network protocols; it means the CDNI control interface can possibly be implemented manually or via some automated network protocols. Moreover, only a part of these operations are handled by the CDNI control interface. The other operations are handled directly by the other CDNI interfaces (namely CDNI request routing, CDNI metadata, CDNI logging, CDNI acquisition and CDNI trigger interfaces). As described in Figure 1, the scope of a Control Operation according to a Control Parameter value may cover either all the Delivery Services of a Service agreement or a single Delivery Service. As an example, the configuration of the format of Logging records may apply to a single Delivery Service. Furthermore, nothing precludes Control Parameters associated to a set of Class-of-requests to change. For instance, an uCDN could require the dCDN to use two Logging formats for a given Delivery Service: one for the normal mode of operations and one temporarily for debugging the CDN interconnection. Stephan, et al. Expires May 10, 2013 [Page 8] Internet-Draft CDNI Control Operations November 2012 3.1. CDNI Control Operations The enforcement of a Service Agreeement requires the configuration of each CDNI functional interface (i.e., including CDNI Metadata, CDNI Logging and CDNI Request Routing). The value of the Control Parameters is expected to change rarely for a given Delivery Service. The core Control Operations are the following: 1. The configuration of the CDNI interfaces ; 2. The removal of this configuration when it is not required anymore (e.g., end of the scheduling of the considered Delivery Service). We illustrate Control Operations on Figure 2. The two CDNs exchange the control parameters previously agreed by the operators of the CDNs. Then, each CDN uses these control parameters to configure all the required CDNI interfaces appropriatly. ------------------------ ---------------------- / uCDN \ / dCDN \ | +-------------------+ | | +-------------------+ | | | Control | | | | Control | | | | | | CDNI | | | | | | Control | | Control | | Control | | | | parameters <----------------------> parameters | | | | | | | | | | | +-------------------+ | | +-------------------+ | \ / \ / ------------------------- ----------------------- Figure 2 Figure 1: Bootstrapping of CDNI Interfaces 3.2. Control Parameters It is in the scope of the CDNI Control interface specification to define the minimal set of Control Parameters required for initializing each CDNI interface for a given Service Agreement. Subsequent sections introduce the information to exchange through the CDNI Control interface to initialize each CDNI interface for a given Service Agreement, a given Delivery Service and a given Class-of- request. Stephan, et al. Expires May 10, 2013 [Page 9] Internet-Draft CDNI Control Operations November 2012 3.2.1. Service Agreement level This section introduces the information to exchange through the CDNI Control interface to initialize each CDNI interface for a given Service Agreement. o Service Agreement identifier; o uCDN identifier; o dCDN identifier; o List of Delivery Service identifier; Section Section 3.2.2 introduces information to exchange through the CDNI Control interface to initialize each CDNI interface for a given Delivery Service o Connectivity and security control parameters; Section Section 3.2.1.1 lists information to exchange through the CDNI Control interface to establish a secure connectivity among CDNI entities. o Redirection control parameters Section Section 3.2.1.2 lists information to exchange through the CDNI Control interface to redirect Class-of-requests of a given Service Agreeement. 3.2.1.1. Connectivity and security control parameters A CDNI Entity acts as the end point for a CDNI interface. A minimal set of information must be exchanged via the control interface to enable the connectivity and the security among CDNI entities. As an example securing a CDNI logging interface using HTTPS requires the exchange of certificates between the interconnected CDNs: 1. Certificate identifying dCDN's CDNI logging entity; 2. Certificate identifying uCDN's CDNI logging entity; 3. Certificate of the authority of certification; A CDN having an CDNi entity (e.g. CDNI Logging data server, CDNI acquisition server) protected by a firewall with strict access rules must add the IP addresses of the entities of the other CDNs which are Stephan, et al. Expires May 10, 2013 [Page 10] Internet-Draft CDNI Control Operations November 2012 allowed to connect to this entity. As examples: o When a uCDN has a dedicated CDNI acquisition server protected by a firewall the dCDN must provide the uCDN with the addresses of each dCDN content servers that could acquire content from this CDNI acquisition server; o When the CDNI Logging Server of a dCDN is protected by a firewall the uCDN must provide the uCDN with the addresses of the uCDN entities which might access to CDNI logging information on the dCDN Logging server; Subsequent sections give an overview of the security Control Parameters related to each CDNI interface (CDNI Logging, CDNI Request Routing, CDNI Metadata and CDNI Triggers) 3.2.1.1.1. Triggers We list below the pieces of information required for the bootstrapping of the triggers interface for a given Service Agreement. The CDNI trigger interface is a RESTful web service offered by dCDN, according to the draft [I-D.murray-cdni-triggers]. The CDNI Control interface must enable the communication of the following parameters from dCDN to uCDN: o the uri of the CDNI trigger entity within dCDN (i.e. of the server within the dCDN dedicated to the CDNI trigger interface): URI_dCDN_trigger_server; o Certificate identifying dCDN; o Certificate of the authority of certification; According to the draft [I-D.murray-cdni-triggers], "The dCDN must ensure that each uCDN only has access to its own Trigger Status Resources and the dCDN must ensure that activity triggered by uCDN only affects metadata or content originating from that uCDN". Consequently, the CDNI Control interface must enable the dCDN to authenticate the uCDN. This means the CDNI Control interface must enable the communication of the following parameter from uCDN to dCDN: o Certificate identifying uCDN; o Certificate of the authority of certification; Stephan, et al. Expires May 10, 2013 [Page 11] Internet-Draft CDNI Control Operations November 2012 3.2.1.1.2. CDNI Metadata We list below the pieces of information required for the bootstrapping of the CDNI Metadata interface for a given Service Agreement. According to the draft [I-D.ietf-cdni-metadata], 'If the URI for the HostIndex object is not manually configured in the downstream CDN then the HostIndex URI could be discovered via the CDNI Control interface. An upstream CDN would provide the URI of the HostIndex object to the downstream CDN via the CDNI Control Interface.'. In this second case, the CDNI Control interface must enable the communication of the following Control Parameters from uCDN to dCDN: o the uri of the CDNI metadata entity within dCDN (i.e. of the server within the dCDN dedicated to the CDNI metadata interface): URI_uCDN_metadata_server; o Certificate identifying uCDN metadata server; o Certificate of the authority of certification; According to the draft [I-D.ietf-cdni-metadata], 'If a malicious metadata server is contacted by a downstream CDN, the malicious server may provide metadata to the downstream CDN which denies service for any piece of content to any user agent. The malicious server may also provide metadata which directs a downstream CDN to a malicious origin server instead of the actual origin server. A malicious metadata client could request metadata for a piece of content from an upstream CDN. The metadata information may then be used to glean information regarding the uCDN or to contact an upstream origin server. The uCDN is expected to authenticate client requests to prevent this situation.' This means the CDNI Control interface must enable the communication of the following parameter from uCDN to dCDN: o Certificate identifying dCDN metadata server; o Certificate of the authority of certification; 3.2.1.1.3. CDNI Logging We list below the pieces of information required for the bootstrapping of the CDNI Logging interface for a given Service Agreement. o URI and protocol to use to request CDNI logging data; Stephan, et al. Expires May 10, 2013 [Page 12] Internet-Draft CDNI Control Operations November 2012 * URI_dCDN_logging_server; * the protocol to use to exchange CDNI Logging data; * etc. o parameters securing the CDNI logging interface 3.2.1.1.4. CDNI Request Routing We list below the pieces of information required for the bootstrapping of the CDNI Request Routing interface for a given Service Agreement. o Control parameters securing the Request Routing CDNI interface * Certificate identifying dCDN Request Routing/redirection CDNI entity; * Certificate identifying uCDN Request Routing/redirection CDNI entity; * Certificate identifying dCDN Request Routing/footprint CDNI entity; * Certificate identifying uCDN Request Routing/footprint CDNI entity; * Certificate of the authority of certification; [Ed. note: this section will be updated once there will be an agreed specification for the CDNI Request Routing interface within the CDNI WG.] 3.2.1.2. Redirection parameters This section lists the piece of information to exchange through the CDNI Control interface to redirect Class-of-requests of the Service Agreeement. [Ed. note: this section will be updated once there will be an agreed specification for the CDNI Request Routing interface within the CDNI WG.] 3.2.2. Delivery Service Level This section introduces the information to exchange through the CDNI Control interface to initialize each CDNI interface for a given Stephan, et al. Expires May 10, 2013 [Page 13] Internet-Draft CDNI Control Operations November 2012 delivery Service. o Delivery Service identifier; o List of identifiers of class-of-requests ; Section Section 3.2.3 introduces information to exchange through the CDNI Control interface to initialize each CDNI interface for a given Class-of-requests o CDNI Logging parameters; Section Section 3.2.2.1 lists information to exchange through the CDNI Control interface to describe the CDNI logging data for a given Delivey Service. o CDNI Delivery requirement parameters Section Section 3.2.2.2 lists information to exchange through the CDNI Control interface to describe requirements for handling class-of-requests of a given Delivey Service. 3.2.2.1. CDNI Logging parameters This section lists a first set of information to exchange through the CDNI Control interface to describe CDNI logging data for a given Delivery Service: o CDNI Logging data format, o etc. 3.2.2.2. CDNI Delivery Requirements parameters This section lists information to exchange through the CDNI Control interface to describe requirements for handling class-of-requests of a given Delivery Service. [Ed. note: this section will be updated once there will be an agreed specification for the CDNI Request Routing interface within the CDNI WG.] 3.2.3. class-of-requests Level This section introduces the information to exchange through the CDNI Control interface to initialize each CDNI interface for a given Class-of-request. Stephan, et al. Expires May 10, 2013 [Page 14] Internet-Draft CDNI Control Operations November 2012 o class-of-requests identifier; o footprint; [Ed. note: this section will be updated once there will be an agreed specification for the CDNI Request Routing interface within the CDNI WG.] o Content request commun properties; [Ed. note: this section will be updated once there will be an agreed specification for the CDNI Request Routing interface within the CDNI WG.] 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations The bootstrapping and the configuration of the CDNI interfaces are very sensible operations. Any weakness may harm the CDN that is directly attacked, as well as the CDNs interconnected with it. In addition it may endanger the security of the eyeballs and of the distributed content. 6. References 6.1. Normative References [I-D.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for CDN Interconnection", draft-ietf-cdni-framework-01 (work in progress), July 2012. [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-ietf-cdni-metadata-00 (work in progress), October 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", Stephan, et al. Expires May 10, 2013 [Page 15] Internet-Draft CDNI Control Operations November 2012 draft-ietf-cdni-requirements-03 (work in progress), June 2012. [I-D.ietf-cdni-use-cases] Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-10 (work in progress), August 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. 6.2. Informative References [I-D.bertrand-cdni-logging] Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., and P. Grochocki, "CDNI Logging Interface", draft-bertrand-cdni-logging-02 (work in progress), October 2012. [I-D.murray-cdni-triggers] Murray, R. and B. Niven-Jenkins, "CDN Interconnect Triggers", draft-murray-cdni-triggers-01 (work in progress), August 2012. Authors' Addresses Emile Stephan France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange.com Stephan, et al. Expires May 10, 2013 [Page 16] Internet-Draft CDNI Control Operations November 2012 Gilles Bertrand France Telecom - Orange 38-40 rue du General Leclerc Issy les Moulineaux, 92130 France Phone: +33 1 45 29 89 46 Email: gilles.bertrand@orange.com Anne Marrec France Telecom - Orange 2 avenue Pierre Marzin Lannion, 22307 France Phone: +33 2 96 05 18 71 Email: anne.marrec@orange.com Yannick Le Louedec France Telecom - Orange 2 avenue Pierre Marzin Lannion, 22307 France Phone: +33 2 96 05 17 64 Email: yannick.lelouedec@orange.com Stephan, et al. Expires May 10, 2013 [Page 17]