Internet Engineering Task Force G. Bertrand Internet-Draft France Telecom - Orange Intended status: Informational September 3, 2012 Expires: March 7, 2013 CDN Footprint Discovery draft-bertrand-cdni-footprint-discovery-01 Abstract Interconnected CDNs need to exchange information on the set of end- users to which they can deliver content. This information is commonly referred to as "CDN Footprint". This memo presents use cases for CDN Footprint Discovery in CDNI. It provides a survey of existing work on the subject and a set of additional requirements for controlling the exchange of Footprint information. 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 March 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Bertrand Expires March 7, 2013 [Page 1] Internet-Draft CDN Footprint Discovery September 2012 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. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 3. Use-Cases for Footprint Discovery . . . . . . . . . . . . . . 5 3.1. Protocol Not Required . . . . . . . . . . . . . . . . . . 5 3.2. Protocol Potentially Required . . . . . . . . . . . . . . 6 4. Additional Requirements . . . . . . . . . . . . . . . . . . . 6 5. Survey of CDN Footprint Discovery . . . . . . . . . . . . . . 7 5.1. Legacy Protocols . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Legacy BGP . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. Legacy BGP Community Tag . . . . . . . . . . . . . . . 8 5.2. New Proposals . . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. BGP Extension for CDNI . . . . . . . . . . . . . . . . 8 5.2.2. ALTO Footprint . . . . . . . . . . . . . . . . . . . . 8 6. Survey of CDN Delivery Proximity Discovery . . . . . . . . . . 9 6.1. BGP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. BGP AIGP . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. BGP Extension for CDNI . . . . . . . . . . . . . . . . . . 9 6.4. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.5. Generic Capability Advertisement . . . . . . . . . . . . . 10 7. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Bertrand Expires March 7, 2013 [Page 2] Internet-Draft CDN Footprint Discovery September 2012 1. Terminology We adopt the terminology described in [I-D.ietf-cdni-problem-statement] and [I-D.davie-cdni-framework], and extend it with the additional terms defined below. Aggregate CDN Footprint: a set of User-Agent reachability information for which a CDN claims that it can deliver content in good conditions, by itself or through one of its dCDNs. The CDN Footprint aggregates information on the footprint of the dCDNs with whom a uCDN is interconnected. High-Level CDN Footprint: the part of the footprint information that reflects rather static and business-level information. As an example, the failure of a Surrogate does not change the High-level CDN Footprint information but may change detailed information of an element of the CDN Footprint. On-Net Footprint: a set of User-Agent reachability information for which a CDN claims that it can deliver content directly. For instance, a given Access CDN may assert that its On-Net CDN Footprint encompasses all end-users in AS 64496 and AS 64497. CDN Delivery Proximity: Information on the network distance between a set of end-users in the CDN Footprint and the closest Surrogates of the considered CDN or of one of its dCDNs. Various metrics can be considered for defining this distance; examples of such metrics include the AS hop count or an accumulated Interior Gateway Protocol (IGP) metric. CDN Footprint Discovery: discovery of information on CDN Footprint and CDN Delivery Proximity. CDN Footprint Discovery provides the information that enables a uCDN's Request Routing Interface to select the most appropriate dCDN for a given content request. CDN Footprint Discovery encompasses two different parts: 1. High-Level Footprint Discovery permits discovering groups of end- users/Surrogates and interconnection costs between them. 2. Detailed Footprint Discovery permits exchanging information that is subject to more scalability and confidentiality constraints. The level of information sharing must be tightly controlled. CDN Footprint Discovery Interface: An interface that enables CDN Footprint Discovery. Section 3 details the use cases for a CDN Footprint Discovery Interface. Bertrand Expires March 7, 2013 [Page 3] Internet-Draft CDN Footprint Discovery September 2012 2. Introduction This memo presents use cases for CDN Footprint and CDN Delivery Proximity discovery in CDNI. It provides a survey of existing work on the subject and a set of additional requirements for controlling the exchange of Footprint information. The reader should be familiar with the work of the CDNI WG: o CDNI problem statement [I-D.ietf-cdni-problem-statement] defines the problem area that the CDNI working group is chartered to address. o [I-D.ietf-cdni-use-cases] outlines real world use-cases for interconnecting CDNs. These use cases (e.g., "QoE and QoS Improvement") require the discovery of CDN Footprint information. o [I-D.ietf-cdni-requirements] specifies a set of requirements for CDN Footprint Discovery. The present document describes: o The use cases for CDN Footprint Discovery (Section 3), o The requirements for CDN Footprint Discovery (Section 4), o A survey of Footprint Discovery protocols (Section 5). 2.1. Abbreviations o CDN: Content Delivery Network o CDNP: Content Delivery Network Provider o CSP: Content Service Provider o dCDN: downstream CDN o IGP: Interior Gateway Protocol o NSP: Network Service Provider o uCDN: upstream CDN Bertrand Expires March 7, 2013 [Page 4] Internet-Draft CDN Footprint Discovery September 2012 3. Use-Cases for Footprint Discovery The present memo considers the use cases for a Footprint Discovery Protocol in a multi-CDN case [I-D.ietf-cdni-use-cases]. It does not consider mono-CDN issues. [I-D.davie-cdni-framework] (Section 3.5.) describes "Dynamic Footprint Discovery" as a situation where "being able to dynamically discover the set of requests that a given dCDN is willing and able to serve is beneficial. For example, a CDN might at one time be able to serve a certain set of client IP prefixes, but that set might change over time due to changes in the topology and routing policies of the IP network." [I-D.davie-cdni-framework] provides an example where footprint information exchanges occur through the request routing interface and are triggered by an end-user's request (DNS resolution or content request). In the present memo, we seek to clarify in which cases such Footprint Discovery through a protocol is required. 3.1. Protocol Not Required In most cases, High-Level CDN Footprint Discovery does not require a protocol, as in the following examples cases: o High-Level CDN Footprint is Germany o High-Level CDN Footprint is AS 64496 However, the two following special cases deserve particular attention: 1. When the dCDNs' Footprints overlap, 2. When end-users outside the dCDNs' Footprints can request content. In these two cases, the uCDN needs additional criteria than the dCDN's Footprint to select the "best" CDN. For instance, a static rule can be configured to select one of the available dCDNs. Alternatively, the uCDN may use dCDN's Delivery Proximity information to elect a delivering CDN. The remainder of this memo focuses on cases, where either CDN Footprint is defined dynamically or uCDN requires dynamic Delivery Proximity information on dCDNs. Bertrand Expires March 7, 2013 [Page 5] Internet-Draft CDN Footprint Discovery September 2012 3.2. Protocol Potentially Required In some cases, the uCDN needs dCDNs' Delivery Proximity information to determine which dCDN is the "best" to serve a given set of end- users. For instance, the "best" CDN can be defined as the one that has deployed Surrogates topologically the closest to the end-user (e.g., an Access CDN). This topological information is tightly related to the underlying networks: one may consider that a Surrogate is topologically far from the end-user if the path between these two entities crosses high cost links or many links. While information about the Surrogates location is rather confidential, abstract information about the path's cost between a set of end-users and the closest Surrogates in a CDN may be generic enough to avoid disclosing confidential information about the network. CDN federations might involve several levels of CDN interconnection. In such scenarios, the CDN Footprint of a given CDN represents the aggregation of the CDN Footprint of all its own dCDNs. Therefore, some variations of the dCDNs' Footprint can result in variations of the CDN's Footprint. This example shows that the more levels of delegation we consider, the more dynamic the CDN Footprint information becomes. Nevertheless, in the medium term, complex deployments scenarios involving more than a few levels of delegations are unlikely, because of performance issues. Consequently, we consider that the High-Level CDN Footprint is rather static and remains valid for at least 24 hours. Depending on the considered metric, the CDN Delivery Proximity may change rarely (e.g., AS hop count) or more frequently (e.g., accumulated IGP metric). 4. Additional Requirements [I-D.ietf-cdni-requirements], already specifies two requirements related to Footprint Discovery: REQ-2 and REQ-3. We remind these two requirements below. "REQ-2 [MED] The CDNI Request-Routing interface should allow the Downstream CDN to communicate to the Upstream CDN aggregate information to facilitate CDN selection during request routing, such as Downstream CDN capabilities, resources and affinities (i.e. Preferences or cost). This information could, for example, include: o supported content types and delivery protocols o footprint (e.g., layer-3 coverage) Bertrand Expires March 7, 2013 [Page 6] Internet-Draft CDN Footprint Discovery September 2012 o a set of metrics/attributes (e.g., Streaming bandwidth, storage resources, distribution and delivery priority) o a set of affinities (e.g., Preferences, indication of distribution/delivery fees) o information to facilitate request redirection (e.g., Reachability information of Downstream CDN Request Routing system)." "REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- Routing interface shall allow the Downstream CDN to also include in the information communicated to the Upstream CDN, information on the capabilities, resources and affinities of CDNs to which the Downstream CDN may (in turn) redirect requests received by the Upstream CDN. In that case, the CDNI Request-Routing interface shall prevent looping of such information exchange." We define additional requirements, specific to Footprint Discovery. FPT-1 [MED] A uCDN must be able to discover CDN Footprint and CDN Delivery Proximity information about dCDNs. FPT-2 [HIGH] A dCDN MUST be able to control what other CDNs can discover about its CDN Footprint and CDN Delivery Proximity. We also clarify REQ-3: FPT-3 [MED] A uCDN should not forward to any other CDN the Footprint and Delivery Proximity information that it has discovered about a dCDN without the explicit agreement of this dCDN. Finally, the deployment of a Footprint Discovery Interface imposes some operational requirements. For instance, a Footprint Discovery protocol must not affect network stability and scalability. It must also be simple enough to avoid increasing the networks' operation complexity. FPT-4 [HIGH] A Footprint Discovery protocol should not affect network stability and scalability. 5. Survey of CDN Footprint Discovery 5.1. Legacy Protocols Bertrand Expires March 7, 2013 [Page 7] Internet-Draft CDN Footprint Discovery September 2012 5.1.1. Legacy BGP Consider a dCDN that claims its CDN Footprint covers AS 64496. BGP advertises AS-Path information that easily enables a uCDN to map end- users to the dCDN, basing on the end-users' IP address and on a mapping of IP addresses to AS numbers. BGP also provides CDN Delivery Proximity information: for instance, a CDN listening to BGP advertisements is able to determine the AS-path length to the advertised prefixes. Note that BGP information might be collected in the network and provided to the CDN through another protocol rather than directly through BGP. 5.1.2. Legacy BGP Community Tag The NSP may use part of the community tags carried by its legacy internal BGP to filter and gather the prefixes in stable groups (see section 5.1.7 of [I-D.ietf-alto-deployments]) that are then used by its internal CDN [I-D.jenkins-alto-cdn-use-cases] for fine-grained request routing based on these groups. A protocol (e.g., HTTP-based) can be used to advertise aggregated information on such groups rather than detailed information per prefix. This provides a simple way to aggregate information for scalability and confidentiality purposes. An operator may consider that the grouping of prefixes into zones (the list of prefixes with a given community value) is confidential, as this grouping discloses information on the network's organization. 5.2. New Proposals 5.2.1. BGP Extension for CDNI [I-D.previdi-cdni-footprint-advertisement] proposes a BGP-based mechanism to advertise connectivity information in the context of CDNI. It is based on the introduction of a CDN sub address Family (SAFI) and leverages BGP (extended) community tags. It uses Multiprotocol-BGP (MP-BGP [RFC4760]) in order for CDNs and/or ISPs to advertise their connectivity to footprints. A new NLRI is defined to carry CDN connectivity advertisements. In summary, the draft defines a "CDN-level BGP" to complement the legacy network-level BGP described in Section 5.1.1 and Section 5.1.2. 5.2.2. ALTO Footprint [I-D.jenkins-alto-cdn-use-cases] describes the use cases for a CDN to be able to obtain network topology and cost information from an ALTO server. These use cases include: "Exposing NSP End User Reachability to a CDN, Exposing CDN End User Reachability to CSPs, CDN deployed Bertrand Expires March 7, 2013 [Page 8] Internet-Draft CDN Footprint Discovery September 2012 within a Broadband network, CDN delivering Over-The-Top of a NSP's network, and CDN acquiring content from multiple upstream sources". An additional use case may be to advertise CDN End User Reachability to upstream CDNs. The NSP CDN acting as a dCDN ALTO server may filter and send prefix groups (see Section 5.1.2) to uCDN ALTO clients according to its policies and with respect to a separate agreement it has with each uCDN. A group may appear as a PID in ALTO network and cost maps. 6. Survey of CDN Delivery Proximity Discovery 6.1. BGP-TE [I-D.gredler-idr-ls-distribution] proposes a BGP-based mechanism by which link state and traffic engineering information can be collected from networks and shared with external components. 6.2. BGP AIGP The Accumulated IGP Metric Attribute for BGP [I-D.ietf-idr-aigp] defines a new TLV attribute in BGP that allows redistribution of IGP costs between ASes belonging to the same managing entity. With AIGP, path selection can take into account IGP costs from other ASes for reaching a certain prefix. For the interconnection of multiple CDNs managed by the same entity ("Inter-Affiliates Interconnection" [I-D.ietf-cdni-use-cases]), the AIGP information may enable a uCDN to determine which dCDN is topologically the closest to a set of end- users. However, the deployment limitations of AIGP listed in [I-D.ietf-idr-aigp] (Section 2. and 3.1.) restrict the applicability of AIGP for this use case. 6.3. BGP Extension for CDNI See Section 5.2.1. 6.4. ALTO [I-D.penno-alto-cdn] (Section 7.1.) describes how ALTO can be used by CDNs in a different administrative domain than the ISP to provide the cost from each CDN node to all known Subscriber PIDs. This mechanism enables the CDN to determine its CDN Delivery Proximity to groups of end users. [I-D.ietf-alto-deployments] discusses deployment related issues of ALTO for peer-to-peer and CDNs. In Section 5.1, it presents the use of ALTO for a mono-CDN case. The ALTO server may leverage the BGP Bertrand Expires March 7, 2013 [Page 9] Internet-Draft CDN Footprint Discovery September 2012 information (e.g., BGP community attribute) to group prefixes into PIDs. ALTO cost map permits providing cost information between PIDs and could be used by a dCDN to communicate its CDN Delivery Proximity to an uCDN. [I-D.seedorf-alto-for-cdni] briefly mentions that ALTO could support selection of downstream CDN but does not indicate the way the ALTO server is fed. 6.5. Generic Capability Advertisement [I-D.he-cdni-cap-info-advertising] proposes an HTTP/1.1-based protocol which is used to communicate capability information (e.g., resources, footprint, load) "to facilitate selection of the Downstream CDN by the Upstream CDN request routing system". 7. Synthesis The use cases section shows that in the short term, the need for a Footprint Advertisement Protocol is limited to specific use cases. The survey shows that multiple new proposals addressing CDN Footprint Discovery are being defined, but none is mature and fulfills all the requirements yet. As a result, we consider that if there is enough interest for developing a CDN Footprint Advertisement Protocol, more work is needed to fulfill the specific requirements that arise in the context of CDNI. Key building blocks for a Footprint Discovery protocol are clearly identified: 1. Information on the network-level connectivity to groups of prefixes, i.e., to groups of end-users, is required. For instance, BGP-level inter-domain routing data can typically be the source of this type of information, which may be advertised through a protocol based on HTTP, for example, or directly through BGP. 2. A mechanism to group end-users that must be served from the same set of Surrogates (e.g., representing a given CDN) is required. For example, BGP extended community attribute and ALTO PIDs typically provide such mechanisms. The grouping of end-users can disclose confidential information on the CDN or network organization, therefore, a CDN/NSP will provide the groups' definitions only to its trusted partners. Bertrand Expires March 7, 2013 [Page 10] Internet-Draft CDN Footprint Discovery September 2012 3. A mechanism to discover generic cost information (uCDN Delivery Proximity) for the delivery from a given set of Surrogates (e.g., a CDN) to a given set of end-users is required. For example, ALTO cost maps, legacy BGP, BGP AIGP, and Previdi's MP-BGP extension typically provide such information, which may be advertised through the aforementioned protocols directly or through another protocol (e.g., HTTP based). To fulfill the topology hiding requirements (identified in [RFC5693] (Section 5.5.) and [I-D.penno-alto-cdn] (Section 6.1.)), the advertised information must not disclose confidential information on the CDN's and underlying networks' topology (i.e., it must not permit to derive a detailed network map). IETF may design a Footprint Discovery mechanism basing on these building blocks. To increase the chances for this mechanism to be deployed by operators, such a mechanism should give enough control on information advertisement and respect operational requirements such as not being too tightly bound to the network. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations Footprint Discovery exposes information about the internals of CDNs. Therefore, it is subject to confidentiality issues. 10. Acknowledgments The authors would like to thank Christian Jacquenet, Yannick Le Louedec, Sophie Nachman-Ghnassia, Iuniana Oprescu, Marcin Pilarski, and Emile Stephan for discussions about early versions of this document. They also thank the contributors of the EU FP7 OCEAN project for valuable inputs. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bertrand Expires March 7, 2013 [Page 11] Internet-Draft CDN Footprint Discovery September 2012 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 11.2. Informative References [I-D.davie-cdni-framework] Davie, B. and L. Peterson, "Framework for CDN Interconnection", draft-davie-cdni-framework-01 (work in progress), October 2011. [I-D.gredler-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., and A. Farrel, "North-Bound Distribution of Link-State and TE Information using BGP", draft-gredler-idr-ls-distribution-02 (work in progress), July 2012. [I-D.he-cdni-cap-info-advertising] He, X., Dawkins, S., Chen, G., Zhang, Y., and W. Ni, "Capability Information Advertising for CDN Interconnection", draft-he-cdni-cap-info-advertising-01 (work in progress), March 2012. [I-D.ietf-alto-deployments] Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO Deployment Considerations", draft-ietf-alto-deployments-04 (work in progress), March 2012. [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf-cdni-problem-statement-08 (work in progress), June 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", 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. [I-D.ietf-idr-aigp] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, Bertrand Expires March 7, 2013 [Page 12] Internet-Draft CDN Footprint Discovery September 2012 "The Accumulated IGP Metric Attribute for BGP", draft-ietf-idr-aigp-08 (work in progress), June 2012. [I-D.jenkins-alto-cdn-use-cases] Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", draft-jenkins-alto-cdn-use-cases-03 (work in progress), June 2012. [I-D.penno-alto-cdn] Penno, R., Medved, J., Alimi, R., Yang, R., and S. Previdi, "ALTO and Content Delivery Networks", draft-penno-alto-cdn-03 (work in progress), March 2011. [I-D.previdi-cdni-footprint-advertisement] Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and L. Faucheur, "CDNI Footprint Advertisement", draft-previdi-cdni-footprint-advertisement-01 (work in progress), March 2012. [I-D.seedorf-alto-for-cdni] Seedorf, J., "ALTO for CDNi Request Routing", draft-seedorf-alto-for-cdni-00 (work in progress), October 2011. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. Author's Address Gilles Bertrand France Telecom - Orange 38-40 rue du General Leclerc Issy les Moulineaux, 92130 FR Phone: +33 1 45 29 89 46 Email: gilles.bertrand@orange.com Bertrand Expires March 7, 2013 [Page 13]