Content Delivery Networks J. Seedorf Interconnection NEC Internet-Draft October 19, 2012 Intended status: Informational Expires: April 22, 2013 CDNI Request Routing with ALTO draft-seedorf-cdni-request-routing-alto-03 Abstract Network Service Providers (NSPs) are currently considering to deploy Content Delivery Networks (CDNs) within their networks. As a consequence of this development, there is a need for interconnecting these local CDNs. The necessary interfaces for inter-connecting CDNs are currently being defined in the Content Delivery Networks Interconnection (CDNI) WG. This document focusses on the Request Routing Interface of CDNI, and more specifically on how the solutions currently being defined in the Application Layer Traffic Optimization (ALTO) WG can improve CDNI request routing. The overall intention behind this document is to foster discussions (in the CDNI as well as in the ALTO WG) regarding if, how, and under what conditions ALTO can be useful to optimize CDNI request routing. As basis for this discussion, this document provides concrete examples of how ALTO can be integrated within CDNI request routing and in particular in the process of selecting a downstream CDN. The examples in this document are based on the use cases and examples currently being discussed in the CDNI WG. 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 April 22, 2013. Copyright Notice Seedorf Expires April 22, 2013 [Page 1] Internet-Draft CDNI Request Routing with ALTO October 2012 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ALTO within CDNI Request Routing . . . . . . . . . . . . . . . 4 3. Assumptions and High-Level Design Considerations . . . . . . . 6 4. Selection of a Downstream CDN with ALTO . . . . . . . . . . . 8 4.1. Footprint Advertisement with ALTO Network Map . . . . . . 8 4.2. Resource Capabilities Advertisement with ALTO Network Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Using ALTO maps to convey Additional Information for Downstream CDN Selection . . . . . . . . . . . . . . . . . 9 4.4. Example of Selecting a Downstream CDN based on ALTO Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Advantages of using ALTO . . . . . . . . . . . . . . . . . 11 5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Informative References . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Seedorf Expires April 22, 2013 [Page 2] Internet-Draft CDNI Request Routing with ALTO October 2012 1. Introduction Many Network Service Providers (NSPs) are currently considering or have already started to deploy Content Delivery Networks (CDNs) within their networks. As a consequence of this development, there is a need for interconnecting these local CDNs. Content Delivery Networks Interconnection (CDNI) has the goal of standardizing protocols to enable such interconnection of CDNs [I-D.ietf-cdni-problem-statement]. The CDNI problem statement envisions four interfaces to be standardized within the IETF for CDN interconnection [I-D.ietf-cdni-problem-statement]: o CDNI Request Routing Interface o CDNI Metadata Interface o CDNI Logging Interface o CDNI Control Interface This document focusses solely on the CDNI Request Routing Interface. In particular, this document shows concrete examples of how ALTO [RFC5693] can be integrated in CDNI request routing. The goal of this document is to show in what cases ALTO can benefit CDNI request routing, giving concrete examples and explaining how ALTO improves CDNI request routing in each of these examples. The examples used in this document are based on the use cases and request routing proposals currently being discussed in the CDNI WG [I-D.ietf-cdni-use-cases] [I-D.peterson-CDNI-strawman] and in the ALTO WG [I-D.jenkins-alto-cdn-use-cases]. The overall rationale of this document is to foster discussions (in the CDNI as well as in the ALTO WG) regarding if, how, and under what conditions ALTO can be useful to optimize CDNI request routing. Most importantly, the document has the goal of finding consensus regarding which part of the CDNI request routing interface can use ALTO. A previous version of this document [I-D.seedorf-alto-for-cdni] contained detailed examples of actual request routing and surrogate selection with ALTO. This version solely focuses on selection of a downstream CDN and how ALTO can support such downstream CDN selection. Throughout this document, we use the terminology for CDNI defined in [I-D.ietf-cdni-problem-statement]. Seedorf Expires April 22, 2013 [Page 3] Internet-Draft CDNI Request Routing with ALTO October 2012 2. ALTO within CDNI Request Routing The main purpose of the CDNI Request Routing Interface is described in [I-D.ietf-cdni-problem-statement] as follows: "The CDNI Request Routing interface enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN is able (and willing) to accept the delegated content request and to allow the downstream CDN to control what the upstream Request Routing function should return to the User Agent in the redirection message". On a high level, the scope of the CDNI Request Routing Interface therefore contains two main tasks: o A) Determining if the downstream CDN is willing to accept a delegated content request o B) Redirecting the content request coming from an upstream CDN to the proper entry point or entity in the downstream CDN More precisely, in [I-D.ietf-cdni-framework] the request routing interface is broadly divided into two functionalities: o 1) the asynchronous advertisement of footprint and capabilities by a dCDN that allows a uCDN to decide whether to redirect particular user requests to that dCDN; o 2) the synchronous operation of actually redirecting a user request. Accorduing to consensus found at the CDNI working group session at IETF-82, we refer to 1) as "Request Routing Interface - Footprint and Capabilities Advertisement" and 2) as "Request Routing Interface - Redirection" in this document. A previous version of this document [I-D.seedorf-alto-for-cdni] provided some concrete examples how ALTO could be used for the actual "redirection" part of the request routing interface. Based on feedback received from the CDNI working group (mostly at the IETF-82 meeting), this document solely focuses on the "Footprint and Capabilities Advertisement" part of the request routing interface. In particular, the scope of the current version of this document is to show how ALTO [RFC5693] can be used for selecting a downstream CDN. Thus, the scope of the current document is to provide examples and discuss how a downstream CDN can advertise its footprint and other information by means of ALTO. Application Layer Traffic Optimization (ALTO) is an approach for guiding the resource provider selection process in distributed applications that can choose among several candidate resources providers to retrieve a given resource. By conveying network layer (topology) information, an ALTO server can provide important Seedorf Expires April 22, 2013 [Page 4] Internet-Draft CDNI Request Routing with ALTO October 2012 information to "guide" the resource provider selection process in distributed applications. Usually, it is assumed that an ALTO server conveys information these applications cannot measure themselves [RFC5693]. Originally, ALTO was motivated by the huge amount of cross-ISP traffic generated by P2P applications [RFC5693]. Recently, however, ALTO is also being considered for improving the request routing in CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also been proposed to use ALTO for selecting an entry-point in a downstream NSP's network (see section 3.4 "CDN delivering Over-The- Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, the CDNI problem statement explicitly mentions ALTO as a candidate protocol for "algorithms for selection of CDN or Surrogate by Request-Routing systems" [I-D.ietf-cdni-problem-statement]. Yet, there have not been concrete proposals so far on how to use ALTO in the context of CDN interconnection. This document tries to close this gap by giving some examples on how ALTO could be used within CDNI request routing. Seedorf Expires April 22, 2013 [Page 5] Internet-Draft CDNI Request Routing with ALTO October 2012 3. Assumptions and High-Level Design Considerations In this section we list some assumptions and design issues to be considered when using ALTO for CDNI "footprint and capabilities advertisement": o As explicitly being out-of-scope for CDNI [I-D.ietf-cdni-problem-statement], the examples used in this document assume that ingestion of content or acquiring content across CDNs is not part of request routing as considered within CDNI standardization work. The focus of using ALTO (as considered in this document) is hence on request routing only, assuming that the content (desired by the end user) is available in the downstream CDN (or can be aquired by the downstream CDN by some means). o Federation Model: "footprint and capabilities advertisement" and in general CDN request routing depends on the federation model among the CDN providers. Designing a suitable solution thus depends on whether a solution is needed for different settings, where CDNs consist of both NSP CDNs (serving individual ASes) and general, traditional CDNs (such as Akamai). We assume that CDNI is not designed for a setting where only NSP CDNs each serve a single AS only. o Many CDNs can claim that they can serve any host on the Internet due to Internet connectivity. For example, even if an NSP CDN A does not have surrogate servers inside network C, A can legitimately claim that it can serve customers inside network C. Hence, what a downstream CDN should inform an upstream CDN is performance and capability, and not (only) reachability or coverage. Although one may turn performance into (binary) reachability by defining a threshold, the metric can be content- dependent (image, video, files) or artificial. The requirement of conveying performance and capability is consistent with the context: after all, the foundation of the CDN business is to improve user QoE. o In this document, we assume that the upstream CDN (uCDN) makes the decision on selecting a downstream CDN, based on information that each downstream CDN has made available to the upstream CDN. Further, we assume that in principle more than one dCDN may be suitable for a given end-user request (i.e. different dCDNs may claim "overlapping" footprints). The uCDN hence potentially has to select among several candidate downstream CDNs for a given end user request. Seedorf Expires April 22, 2013 [Page 6] Internet-Draft CDNI Request Routing with ALTO October 2012 o The term "footprint" has not been precisely defined by the CDNI working group yet [I-D.spp-cdni-rr-foot-cap-semantics]. In this document we assume that some notion of IP prefix-range is suitable to define a footprint of a downstream CDN. Thus, a dCDN footprint may be expressed as an IP-prefix range that a given dCDN claims it can cover. However, in principle any host can reach any other host on the Internet. Thus, simple "coverage" of IP-prefix ranges seems insufficient for a uCDN to make a choice of a dCDN (see [I-D.spp-cdni-rr-foot-cap-semantics] for a discussion of this issue). The uCDN needs additional information that is "tagged along" (either implicitly or explicitly) with such a coverage footprint. Such additonal information has the prupose of conveying to the uCDN more information about a footprint, so that the uCDN can judge/assess the delivery quality that is associated with a given dCDN footprint (or part of that footprint, in the likely case that the delivery quality is not the same for a whole dCDN footprint). o It is not clear what kind(s) of business, contract, and operational relationships two peering CDNs may form. For the Internet, we see provider-customer and peering as two main relations; providers may use different charging models (e.g., 95- percentile, total volume) and may provide different SLAs. Given such unknown characteristics of CDN peering business agreements, we should design the protocol to support as much diverse potential business and operational models as possible. Seedorf Expires April 22, 2013 [Page 7] Internet-Draft CDNI Request Routing with ALTO October 2012 4. Selection of a Downstream CDN with ALTO Under the considerations stated in Section 3, ALTO can help the upstream CDN provider to select a proper downstream CDN provider for a given end user request as follows: Each downstream CDN provider hosts an ALTO server which provides ALTO information (i.e. ALTO network maps and ALTO cost maps [I-D.ietf-alto-protocol]) to an ALTO client at the upstream CDN provider. A network map provided by each of several candidate downstream CDNs can provide information to the upstream CDN provider about each dCDN's "coverage" footprint, e.g. regarding geopgraphical coverage, the (exact or rough) location of "surrogates", the IP-prefix ranges the dCDN claims it can "cover" with "good" delivery quality, or similar. Additional ALTO network maps or cost maps can provide an upstream CDN provider additional information about the footprint each individual dCDN offers, e.g. the "cost" or quality associated with delivering certain content via the downstream CDN which provided such a map. "Cost" in this context is a generic term; many types of costs are possible and can be useful in the context of CDNI request routing (see Section 4.3 for a detailed discussion), e.g. average link load, expected delay, or monetary costs. 4.1. Footprint Advertisement with ALTO Network Map An ALTO network map contains a "set of Network Location groupings" [I-D.ietf-alto-protocol]. The groupings are defined in the form of so-called "PIDs". A PID is an identifier to group network location endpoints, e.g. IP-addresses in the form of prefixes (see section 4 in [I-D.ietf-alto-protocol] for details). The concept of an ALTO network map (and the PIDs contained therein) is a natural and straightforward candidate for CDNI fooprint advertisement: The downstream CDN provider groups the IP-addresses in its footprint into PIDs and makes these groupings available to an upstream CDN via an ALTO network map. With such a network map, the upstream CDN provider can easily match a given end user request with the footprint of the downstream CDN provider to see if a given downstream CDN can in principle provide "coverage" for the IP-address of the end user. Whenever the footprint changes, the downstream CDN creates an updated network map and makes it available via its ALTO server. 4.2. Resource Capabilities Advertisement with ALTO Network Maps Out of many potentially useful capabilities, it seems mandatory to support resource capabilities (see further the discussion in [I-D.spp-cdni-rr-foot-cap-semantics]). For instance, the delivery protocols supported by a downstream CDN are important to know for an Seedorf Expires April 22, 2013 [Page 8] Internet-Draft CDNI Request Routing with ALTO October 2012 upstreamn CDN to make a selection decision. Further, certain resource capabilities may only be supported in a partial footprint of a given downstream CDN (e.g. a certain delivery protocol may only be available at a subset of a given overall dCDN footprint). ALTO network maps can convey such resource capabilities via PID names. For instance, an additional network map provided by a dCDN can group the dCDN's coverage footprint into several PIDs, where each PID name has a certain "resource capability" semantic. 4.3. Using ALTO maps to convey Additional Information for Downstream CDN Selection Additonal information (so that the uCDN can judge/assess the delivery quality that is associated with a given dCDN footprint it received in a network map from the dCDN) can be conveyed to a uCDN with additional ALTO network maps or ALTO cost maps that the dCDN will provide via its ALTO server. An ALTO cost map contains costs between defined groupings of a corresponding network map (i.e. costs between PIDs): "An ALTO Cost Map defines Path Costs pairwise amongst sets of source and destination Network Locations" [I-D.ietf-alto-protocol]. This concept enables the provider of a cost map to express (and quantify) preferences of a destination network location with respect to a given source network location. In the context of CDNI, the ALTO cost map concept is an extensive tool to facilitate selection of the "best" downstream CDN because it enables the upstream CDN provider to assess a candidate downstream CDN based on other factors besides simply network coverage (coverage footprint). Most importantly, the cost map concept provides a means for a downstream CDN provider to convey a multitude of dynamically changing information which the upstream CDN provider cannot measure itself (or only roughly estimate) otherwise. For instance, the following types of "delivery cost" can be conveyed by a downstream CDN provider via ALTO for each combination of source PID and destination PID: o Latency: the expected/average RTT o Bandwidth: the maximum bandwidth (e.g. due too bottlenecks) o Monetary Costs: The amount of actual monetary costs the downstream CDN provider would charge for the delivery of content to a given destination (see also [I-D.liu-cdni-cost]) Normally, an ALTO cost map defines "costs" pairwise among two PIDs [I-D.ietf-alto-protocol]. In the current scope of the CDNI working group, however, the destination of a request routing redirection will Seedorf Expires April 22, 2013 [Page 9] Internet-Draft CDNI Request Routing with ALTO October 2012 always be the request router of the selected downstream CDN (as direct redirection to dCDN surrogates is currently out of scope of the CDNI work). The destination PID in an ALTO cost map offered by a dCDN is thus always (i.e. in all entries) the same. Moreover, this destination PID semantically refers to the whole dCDN (or to its request router, as the decision where to route within the dCDN is outside the scope of the CDNI request routing interface). Therefore, a corresponding ALTO network map for footprint coverage offered by a dCDN should always contain a special PID that covers the whole footprint of the dCDN, i.e. the overall, whole prefix range the dCDN claims it can cover (obviously, it can additonally contain smaller prefix ranges in other PIDs, so that a cost map can have pairwise costs entries of these smaller-scale source PIDs to the overall dCDN coverage PID). Note that such ALTO cost maps are always of the type N-to-1, i.e. "costs" are expressed for each of N end user source PIDs to 1 single dCDN request router PID. Semantically, the source PID in a CDNI ALTO cost map is thus the end user location, whereas the destination is the request router to which the uCDN redirects the end user request. Note that this perspective is driven by the CDNI request routing. An alternative way - seen from the perspective of content retrieval - would be to have a 1-to-N cost map where the source is always the dCDN and the destination is the end user (with the semantic "if the source dCDN would deliver content to an end user in the destination PID, the costs would be the following). Alternatively to using cost maps for expressing delivery quality for a given coverage footprint, ALTO networks map could be used. In this case, an additional network map provided by the dCDN groups the dCDN's coverage footprint into several PIDs, where each PID name has a certain "quality" semantic. In other words, all IP-prefixes in a certain PID have the same "quality", and the meaning of this quality is expressed by the PID name. 4.4. Example of Selecting a Downstream CDN based on ALTO Maps In the following, we will outline an example of dCDN selection by a uCDN based on ALTO maps provided by each dCDN. In the example, an ALTO network map "NM_cov" is used to express the overall "coverage" footprint of each dCDN. In addition (as outlined in Section 4.3), each dCDN provides one or more ALTO cost maps "CM_1", "CM_2", ..., "CM_n" to express the delivery "costs"/quality associated with each PID in the corresponding "NM_cov" coverage footprint network map. Consider the following example: An upstream CDN (uCDN) has agreed on CDN interconnection with several downstream CDNs (dCDN-a, dCDN-b, and dCDN-c). Each of these downstream CDNs runs an ALTO server to Seedorf Expires April 22, 2013 [Page 10] Internet-Draft CDNI Request Routing with ALTO October 2012 provide information about what locations it can deliver content to (coverage footprint) by means of a network map "NM_cov" and at which "cost" (additional delivery quality information) by means of one or more cost maps "CM_1", "CM_2", ..., "CM_n". uCDN has downloaded from each candidate downstream CDN "NM_cov" and one or more ALTO cost maps (e.g. by using the "Filtered Cost Map" option and different "cost- types" as specified in 7.7.3.2. of [I-D.ietf-alto-protocol]). The ALTO network map provides "coverage" (footprint) for each downstream CDN as aggregated network locations in the form of ALTO PIDs. The cost maps provide the upstream CDN information regarding the delivery quality the selection of each individual downstream CDN would imply depending on the given location of an end user request. Whenever the upstream CDN receives a request from an end user and has determined that this request is best served by an interconnected dCDN, the uCDN uses ALTO maps to make a redirection decision. For a given request, assume that only the ALTO network maps provided by dCDN-a and dCDN-c, "NM_cov(dCDN-a)" and "NM_cov(dCDN-c)", indicate that these downstream CDNs can deliver content to the location of the request. In this case, the ALTO costs maps received from dCDN-a and dCDN-c provide useful additional information to the upstream CDN in order to make a selection decision regarding either dCDN-a or dCDN-c. For instance, if both downstream CDNs have provided two ALTO cost maps "CM_monetary" and "CM_latency" - one regarding monetary costs and one regarding expected latency for delivery - uCDN can make a downstream CDN selection based on its preferences: If one downstream CDN can deliver cheaper, but the other faster, ALTO cost maps provide such information in detail to the upstream CDN. This enables the upstream CDN to make a well-considered downstream CDN selection. In particular, the uCDN decision may take into account different delivery quality indicators or other factors (which can be weighted by the upstream CDN to make a decision). 4.5. Advantages of using ALTO The following reasons make ALTO a suitable candidate protocol for downstream CDN selection as part of CDNI request routing: o CDN request routing is done at the application layer. ALTO is a protocol specifically designed to improve application layer traffic (and application layer connections among hosts on the Internet) by providing additonal information to applications that these applications could not easily retrieve themselves. For CDNI, this is exactly the case: a uCDN wants to improve application layer CDN request routing by using dedicated information (provided by a dCDN) that the uCDN could not easily obtain otherwise. Seedorf Expires April 22, 2013 [Page 11] Internet-Draft CDNI Request Routing with ALTO October 2012 o The semantics of an ALTO network are an exact match for the needed information to convey a footprint by a downstream CDN, in particular if such a footprint is being expressed by IP-prefix ranges. o ALTO cost maps are suitable to express various types of delivery "cost" and can hence be used by an upstream to judge the delivery quality associated with a given dCDN for a given end user request. Further, an ALTO cost map can convey relevant network topology information other than simply routing hops or reachability. This facilitiates advanced and more sophisticated selection of a downstream CDN based on various metrics by the upstream CDN and increases flexibility to cover different use cases and business models for CDN interconnection. o Flexible granularity: The concept of the PID and ALTO network/cost maps allows for different degrees of granularity. This enables a dCDN to differentiate the delivery quality for serving an end user request on a fine granularity depending on the end user location (and not only express delivery quality e.g. on an AS-level). It remains at the discretion of each dCDN how fine-granular the ALTO network and cost maps are that it publishes. o ALTO maps can be signed and hence provide inherent integrity protection (see Section 6) Seedorf Expires April 22, 2013 [Page 12] Internet-Draft CDNI Request Routing with ALTO October 2012 5. Useful ALTO extensions for CDNI Request Routing It is envisioned that yet-to-be-defined ALTO extensions will be standardized that make the ALTO protocol more suitable and useful for applications other than the originally considered P2P use case [I-D.marocco-alto-next]. Some of these extensions to the ALTO protocol would be useful for ALTO to be used as a protocol within CDNI request routing, and in particular within the "Footprint and Capabilities Advertisment" part of the CDNI request routing interface. The following proposed extensions to ALTO would be beneficial to facilitate CDNI request routing with ALTO as outlined in Section 4: o Server-initiated Notifications and Incremental Updates: In case the footprint or the capabilities of a downstream CDN change abruptly (i.e. unexpectedly from the perspective of an upstream CDN), server initiated notifications would enable a dCDN to directly inform an upstream CDN about such changes. Consider the case where - due to failure - part of the footprint of the dCDN is not functioning, i.e. the CDN cannot serve content to such clients with reasonable QoS. Without server-initiated notifications, the uCDN might still use a very recent network and cost map from dCDN, and therefore redirect request to dCDN which it cannot serve. Similarly, the possibility for incremental updates would enable efficient conveyance of the aforementioned (or similar) status changes by the dCDN to the uCDN. A proposal for server-initiated ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion of incremental ALTO updates can be found in [I-D.schwan-alto-incr-updates]. o Content Availability on Hosts: A dCDN might want to express CDN capabilties in terms of certain content types (e.g. codecs/ formats, or content from certain content providers). A new endpoint property for ALTO that would be able to express such "content availability" would enable a dCDN to make available such information to an upstream CDN. This would enable a uCDN to determine if a given dCDN actually has the capabilities for a given request with respect to the type of content requested. o Resource Availability on Hosts or Links: The capabilities on links (e.g. maximum bandwidth) or caches (e.g. average load) might be useful information for an upstream CDN for optimized dowmstream CDN selection. For instance, if a uCDN receives a streaming request for content with a certain bitrate, it needs to know if it is likely that a dCDN can fulfill such stringent application-level requirements (i.e. can be expected to have enough consistent bandwidth) before it redirects the request. In general, if ALTO Seedorf Expires April 22, 2013 [Page 13] Internet-Draft CDNI Request Routing with ALTO October 2012 could convey such information via new endpoint properties, it would enable more sophisticated means for downstream CDN selection with ALTO. Seedorf Expires April 22, 2013 [Page 14] Internet-Draft CDNI Request Routing with ALTO October 2012 6. Security Considerations One important security consideration is the proper authentication of advertisement information provided by a downstream CDN. The ALTO protocol provides a specification for a signature of ALTO maps (see 8.2.2. of [I-D.ietf-alto-protocol]. ALTO thus provides a proper means for protecting the integrity of footprint advertisment information. More Security Considerations will be discussed in a future version of this document. Seedorf Expires April 22, 2013 [Page 15] Internet-Draft CDNI Request Routing with ALTO October 2012 7. Summary and Outlook This document presented conrete examples of how ALTO can be used within the downstream CDN selection of CDNI Request Routing. Further, the document provides arguments why ALTO is a meaningful protocol in this context. Essentially, ALTO network and cost maps are a means to provide detailed and various types of information to an upstream CDN, in order to facilitate well-considered downstream CDN selection. The intention of this document is to find consensus in the CDNI WG that ALTO is a useful protocol for CDNI request routing, and that ALTO has many benefits for proper selection of a downstream CDN. The overall objective is to form agreement on how ALTO should be used within the CDNI request routing protocol. It is the intention to capture the outcome of such continuing discussions in future versions of this document. Seedorf Expires April 22, 2013 [Page 16] Internet-Draft CDNI Request Routing with ALTO October 2012 8. Acknowledgements Jan Seedorf is partially supported by the CHANGE project (CHANGE: Enabling Innovation in the Internet Architecture through Flexible Flow-Processing Extensions, http://www.change-project.eu/), a research project supported by the European Commission under its 7th Framework Program (contract no. 257422). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the CHANGE project or the European Commission. Jan Seedorf has been partially supported by the COAST project (COntent Aware Searching, retrieval and sTreaming, http://www.coast-fp7.eu), a research project supported by the European Commission under its 7th Framework Program (contract no. 248036). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the COAST project or the European Commission. Thanks to Richard Yang for providing valuable comments, and for contributiong some design considerations and assumptions. Seedorf Expires April 22, 2013 [Page 17] Internet-Draft CDNI Request Routing with ALTO October 2012 9. Informative References [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [I-D.peterson-CDNI-strawman] Peterson, L. and J. Hartman, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-peterson-CDNI-strawman-01 (work in progress), May 2011. [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.marocco-alto-next] Marocco, E. and V. Gurbani, "Extending the Application- Layer Traffic Optimization (ALTO) Protocol", draft-marocco-alto-next-00 (work in progress), January 2012. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-13 (work in progress), September 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.marocco-alto-ws] Marocco, E. and J. Seedorf, "WebSocket-based server-to- client notifications for the Application-Layer Traffic Optimization (ALTO) Protocol", draft-marocco-alto-ws-01 (work in progress), July 2012. [I-D.schwan-alto-incr-updates] Seedorf Expires April 22, 2013 [Page 18] Internet-Draft CDNI Request Routing with ALTO October 2012 Schwan, N. and B. Roome, "ALTO Incremental Updates", draft-schwan-alto-incr-updates-02 (work in progress), July 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.seedorf-alto-for-cdni] Seedorf, J., "ALTO for CDNi Request Routing", draft-seedorf-alto-for-cdni-00 (work in progress), October 2011. [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.liu-cdni-cost] Liu, H., "A Cost Perspective on Using Multiple CDNs", draft-liu-cdni-cost-00 (work in progress), October 2011. [I-D.spp-cdni-rr-foot-cap-semantics] Seedorf, J., Peterson, J., and S. Previdi, "CDNI Request Routing: Footprint and Capabilities Semantics", draft-spp-cdni-rr-foot-cap-semantics-01 (work in progress), July 2012. Seedorf Expires April 22, 2013 [Page 19] Internet-Draft CDNI Request Routing with ALTO October 2012 Author's Address Jan Seedorf NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 221 Email: jan.seedorf@neclab.eu URI: http://www.neclab.eu Seedorf Expires April 22, 2013 [Page 20]