I2RS Working Group M-K. Shin Internet-Draft S. Lee Intended status: Informational ETRI Expires: January 2015 July 3, 2014 CDNI Request Routing with I2RS draft-shin-i2rs-usecases-cdni-request-routing-00 Abstract The I2RS (the Interface to the Routing System) is a programmatic asynchronous interface for transferring state into and out of the routing system. The I2RS can provide programmable control planes for network service providers (NSPs). In this sense, the I2RS could be also considered as one of candidates to facilitate CDNI Request Routing. This document discusses how I2RS can be used for downstream CDN selection within CDNI request routing. 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Shin et al., Expires January 2015 [Page 1] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 This Internet-Draft will expire on January 3, 2015. 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. I2RS within CDNI Request Routing . . . . . . . . . . . . . . 3 3. Selection of a Downstream CDN with I2RS . . . . . . . . . . . 4 4. Example of Content Request Redirection and Path Setup for Content Delivery with I2RS .. . . . . . . . . . . . . . . . . 4 5. Advantages of using I2RS . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Shin et al., Expires January 2015 [Page 2] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 1. Introduction 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 [I-D.seedorf-cdni-request-routing-alto]. Recently, Software-defined networking (SDN) is emerging and intensively discussed as one of the most promising technologies to provide programmable control planes for network service providers (NSPs). The I2RS facilitates control and observation of the routing- related state, as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the routing system [I-D.ietf-i2rs-architecture]. The I2RS can provide programmable control planes for network service providers (NSPs). In this sense, the I2RS could be also considered as one of candidates to facilitate CDNI Request Routing. This document discusses how I2RS can be integrated in CDNI request routing. 1.1. Terminology This document draws freely on the terminology defined in [RFC3466], [RFC6706], and [I-D.ietf-i2rs-architecture]. 2. I2RS within CDNI Request Routing The scope of the CDNI Request Routing Interface SHOULD contain two functionalities [I-D.ietf-cdni-framework] : o Request Routing Interface - Footprint and Capabilities Advertisement; 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 Request Routing Interface - Redirection; the synchronous operation of actually redirecting a user request First of all, it is assumed that ALTO is used for Request Routing Interface - Footprint and Capabilities Advertisement. Details and examples on how a downstream CDN can advertise its footprint and other information by means of ALTO are being discussed in [I- D.seedorf-cdni-request-routing-alto]. Application Layer Traffic Optimization (ALTO) is an approach for guiding the resource provider Shin et al., Expires January 2015 [Page 3] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 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 information to guide the resource provider selection process in distributed applications. As for the Request Routing - Redirection, HTTP and DNS are being discussed as one of candidate protocols [I-D.ietf-cdni-redirection]. Recently, the I2RS is emerging and intensively discussed as one of the most promising technologies to provide programmable control planes for network service providers (NSPs). In this sense, I2RS could be also considered as one of candidates to facilitate CDNI Request Routing as well as HTTP and DNS. This document discusses how I2RS can be integrated in CDNI request routing. 3. Selection of a downstream CDN with I2RS The I2RS can help the upstream CDN provider to select a proper downstream CDN provider for a given end user request as follows. It is assumed that each downstream CDN provider hosts an I2RS Client communicated with I2RS-capable Gateway and Routers. An example of operation is as follows : 0) dCDN advertises information relevant to its delivery capabilities (e.g. content availability, geographic footprint, etc.) using ALTO provisioning prior to any content requests being redirected. 1) A content request from a user agent arrives in the I2RS-capable Gateway of uCDN. 2) The I2RS-capable Gateway at uCDN relays the message to the its I2RS Client. 3) ALTO client at the I2RS Client requests the best dCDN information to ALTO server (ALTO cost map and/or other information may be used). 4) ALTO server responses and then the I2RS Client in uCDN knows which is the best dCDN. 5) The I2RS Client sends a massage to other I2RS Client of the best dCDN or I2RS-capable Gateway of the best dCDN. 6) uCDN redirects the request to the best dCDN. 4. Example of Content Request Redirection and Path Setup for Content Shin et al., Expires January 2015 [Page 4] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 Delivery with I2RS I2RS can help the upstream CDN provider to redirect a content request message to a downstream CDN provider for a given end user request as follows. It is assumed that the upstream and the downstream CDN providers have an I2RS Client communicated with their I2RS-capable Gateway and Routers. The I2RS sets up the path for the content delivery. An example of operation is as follows : 0) Content distribution metadata is pre-positioned between CDNs prior to any content requests being redirected; that is, an I2RS Client in uCDN knows its own surrogates in other CDNs and information relevant to its delivery capabilities (e.g. geo-blocking information, availability windows, desired distribution policy, etc.) 1) An end user issues an HTTP GET message to get content. By contacting DNS, this message is forwarded to the Gateway of uCDN which has I2RS capability. 2) The I2RS-capable Gateway of uCDN relays this message to its own I2RS Client by an message in I2RS protocol. 3) The I2RS Client of uCDN checks content distribution metadata, and sends a query to the I2RS Client of dCDN whether it can deliver the content. In the query, the source address of the request packets (i.e. the host address of the user agent) is included. Optionally, a QoS requirement for the content delivery may be specified in the query as well. And there can be multiple candidate dCDNs for a given user request. 4) If the I2RS Client of dCDN decides to provide content, it checks the location of the content object and network traffic status. And it assigns an IP address for the content delivery. The assigned IP address will be used as the content identifier, which is the source address of the data packets. After that, it sends a reply to the I2RS Client of uCDN with these data and sets up the path for content delivery from the surrogate in dCDN to the end user. 5) The I2RS Client in uCDN informs the end user of the URL of the surrogate in dCDN by sending HTTP Redirection. 6) The end user sends HTTP GET message to the surrogate in dCDN. 5. Advantages of using I2RS Shin et al., Expires January 2015 [Page 5] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 The following reasons make I2RS a suitable candidate protocol for downstream CDN selection as part of CDNI request routing: o Dynamic and asynchronous CDNI operations o More centralized, programmable (e.g., using I2RS Apps for CDNI) o More extensible (suitable for ALTO) o Traffic isolated with desired QoS/QoE, security, etc. o Secure controls o Mobility support 6. Security Considerations TBD 7. Acknowledgements TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC6707] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6706, September 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-17 (work in progress), January 2014. [I-D.ietf-cdni-framework] Peterson,L. and B. Davie, "Framework for CDN Interconnection", draft-ietf-cdni-framework-14 (work Shin et al., Expires January 2015 [Page 6] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 in progress), June 2014. [I-D.ietf-cdni-redirection] Niven-Jenkins, B., Brandenburg., "Request Routing Redirection Interface for CDN Interconnection", draft-ietf-cdni-redirection-02 (work in progress), April 2014. [I-D.seedorf-cdni-request-routing-alto] Seedorf, J., "CDNI Request Routing with ALTO", draft-seedorf-cdni-request-routing- alto-07 (work in progress), June 2014. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., Nadeau, T., "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-04 (work in progress), June 2014. Shin et al., Expires January 2015 [Page 7] Internet-Draft CDNI Request Routing with I2RS July 3, 2014 Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-700 Korea Phone: +82 42 860 4847 Email: mkshin@etri.re.kr Seungik Lee ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-700 Korea Phone: +82 42 860 1483 Email: seungiklee@etri.re.kr Shin et al., Expires January 2015 [Page 8]