Network Working Group M-K. Shin Internet-Draft S. Lee Intended status: Informational ETRI Expires: October 2013 D. Chang T. Kwon SNU February 15, 2013 CDNI Request Routing with SDN draft-shin-cdni-request-routing-sdn-01 Abstract Software-defined networking (SDN) is emerging and intensively discussed as one of the most promising technologies to provide centralized, programmable control planes for network service providers (NSPs). In this sense, SDN could be also considered as one of candidates to facilitate CDNI Request Routing. This document discusses how SDN 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 October 2013 [Page 1] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 This Internet-Draft will expire on January 1, 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SDN Overview and Assumption . . . . . . . . . . . . . . . . . 3 3. SDN within CDNI Request Routing . . . . . . . . . . . . . . . 4 4. Selection of a Downstream CDN with SDN . . . . . . . . . . . . 5 5. Example of Content Request Redirection and Path Setup for Content Delivery with SDN . . . . . . . . . . . . . . . . . . 6 6. Advantages of using SDN . . . . . . . . . . . . . . . . . . . 7 7. Further Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Shin et al., Expires October 2013 [Page 2] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 1. Introduction The CDNI PS and framework documents [RFC6707][I-D.ietf-cdni- framework] define the following four interfaces for CDNI; Request Routing Interface, Metadata Interface, Logging Interface, and CDNI Control Interface. As for the Request Routing - Redirection, HTTP and DNS are being discussed as one of candidate protocols. Recently, Software-defined networking (SDN) is emerging and intensively discussed as one of the most promising technologies to provide centralized, programmable control planes for network service providers (NSPs). In this sense, SDN could be also considered as one of candidates to facilitate CDNI Request Routing. This document discusses how OF/SDN technology can be integrated in CDNI request routing. 1.1. Terminology This document draws freely on the terminology defined in [RFC3466] and [RFC6706]. We also introduce the following terms, tentatively: CDN Frontend Server (CFS): CDN Frontend Server (CFS): It is a server which has SDN capability. A Network Service Providers (NSP) registers the address of its own CFS to DNS. In this way, a CFS can redirect "request" messages to its SDN controller. 2. SDN Overview and Assumption SDN is a new networking technology which allows centralized, programmable control planes, so that NSPs can control and manage directly their own virtualized resources and networks without recognizing detailed hardware technologies. To achieve this, with SDN, control and data planes are separated which allows control to be directly programmable and manageable in a centralized manner and data plane to be simplified and abstracted rather than specialized hardware. Since work on SDN architecture and framework is still being discussed and is not standardized yet, in this document, it is assumed that OpenFlow is as one of architectural components for SDN framework to facilitate CDNI Request Routing, as an example, but any other existing and/or possible solutions for SDN, such as I2RS and I2AEX could be also integrated without any big modifications. Most modern Ethernet switches and routers contain flowtables that run at line-rate to implement firewalls, NAT, QoS, and to collect statistics. While each vendor's flowtable is different, OpenFlow's Shin et al., Expires October 2013 [Page 3] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 basic idea composed an interesting common set of functions that run in many switches and routers. OpenFlow exploits this common set of functions. OpenFlow provides an open protocol to program the flowtable in different switches and routers. In an OpenFlow network, a central controller manages switches that support the concept of a flow, a stream of related packets that are processed in the same way. Every switch maintains a flow table containing a set of rules, where each rule includes a pattern that is the set of packets belonging to the flow, a priority that disambiguates overlapping rules, an expiration time, a list of actions to apply to the packets, and counters to measure the traffic. To process an incoming packet, the switch identifies the matching rule with the highest priority, updates the counters of the rule, and applies the actions. If no matching rule is found, the switch forwards the packet to the controllers and awaits further instructions. 3. SDN 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 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. Recently, SDN is emerging and intensively discussed as one of the most promising technologies to provide centralized, programmable control planes for network service providers (NSPs). In this sense, SDN could be also considered Shin et al., Expires October 2013 [Page 4] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 as one of candidates to facilitate CDNI Request Routing as well as HTTP and DNS. This document discusses how SDN technology can be integrated in CDNI request routing. 4. Selection of a downstream CDN with SDN SDN 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 SDN controller. 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 extension (e.g., I2AEX) provisioning prior to any content requests being redirected. 1) A content request from a user agent arrives in the CFS of uCDN. 2) The CFS at uCDN relays the message to the its SDN controller by a "Packet-In' message. 3) ALTO client at the OF controller requests the best dCDN information to ALTO server (ALTO cost map and/or other information may be used). 4) ALTO server responses and then OF controller in uCDN knows which is the best dCDN. 5) The SDN controller sends a query to the SDN controller of the best dCDN 6) (uCDN redirects the request to the best dCDN). 5. Example of Content Request Redirection and Path Setup for Content Delivery with SDN SDN 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 SDN controllers. And OF/SDN 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 Shin et al., Expires October 2013 [Page 5] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 to any content requests being redirected; that is, a controller 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 CDN frontend server (CFS) of uCDN which has SDN capability. 2) The CFS of uCDN relays this message to its own SDN controller by "Packet-In" message in SDN protocol. 3) The controller of uCDN checks content distribution metadata, and sends a query to the controller 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 SDN controller 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 controller of uCDN with these data and sets up the path for content delivery from the surrogate in dCDN to the end user. 5) The SDN controller 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. 6. Advantages of using SDN The following reasons make SDN a suitable candidate protocol for downstream CDN selection as part of CDNI request routing: o Synchronous CDNI operations o Integrated with SDN framework and architecture (e.g., OpenFlow) o Traffic isolated with desired QoS/QoE, security, etc. o More extensible (suitable for i2aex proposal) Shin et al., Expires October 2013 [Page 6] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 o More centralized, programmable (e.g., using SDN Apps for CDNI) o Mobility support 7. Further Considerations The following further issues should be also discussed on SDN architecture and framework for downstream CDN selection as part of CDNI request routing: o ALTO extension (i2aex) o Northbound interfaces of SDN controllers o Multi-controllers o East-west bound interfaces of SDN controllers 8. Security Considerations TBD 9. Acknowledgements TBD 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.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-02 (work in progress), December 2011. Shin et al., Expires October 2013 [Page 7] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 [I-D.ietf-cdni-framework] Peterson,L. and B. Davie, "Framework for CDN Interconnection", draft-ietf-cdni-framework-00 (work in progress), April 2012. [I-D.seedorf-cdni-request-routing-alto] Seedorf, J., "CDNI Request Routing with ALTO", draft-seedorf-cdni-request-routing- alto-01 (work in progress), March 2012. [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. [b-OpenFlow] OpenFlow Switch Specification 1.3, http://www.opennetworking.org/. Shin et al., Expires October 2013 [Page 8] Internet-Draft CDNI Request Routing with OF/SDN February 15, 2013 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 Dukhyun Chang Seoul National University Seoul, Korea Email: dhchang@mmlab.snu.ac.kr Ted Taekyoung Kwon Seoul National University Seoul, Korea Email: tkkwon98@gmail.com Shin et al., Expires October 2013 [Page 9]