idnits 2.17.1 draft-shin-cdni-request-routing-sdn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2013) is 4081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6706' is mentioned on line 100, but not defined == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'I-D.seedorf-cdni-request-routing-alto' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC5693' is defined on line 322, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-02 == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-00 == Outdated reference: A later version (-10) exists of draft-seedorf-cdni-request-routing-alto-01 -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M-K. Shin 3 Internet-Draft S. Lee 4 Intended status: Informational ETRI 5 Expires: October 2013 D. Chang 6 T. Kwon 7 SNU 8 February 15, 2013 10 CDNI Request Routing with SDN 11 draft-shin-cdni-request-routing-sdn-01 13 Abstract 15 Software-defined networking (SDN) is emerging and intensively 16 discussed as one of the most promising technologies to provide 17 centralized, programmable control planes for network service 18 providers (NSPs). In this sense, SDN could be also considered as one 19 of candidates to facilitate CDNI Request Routing. This document 20 discusses how SDN can be used for downstream CDN selection within 21 CDNI request routing. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 1, 2013. 52 Copyright Notice 54 Copyright (c) 2012 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. SDN Overview and Assumption . . . . . . . . . . . . . . . . . 3 71 3. SDN within CDNI Request Routing . . . . . . . . . . . . . . . 4 72 4. Selection of a Downstream CDN with SDN . . . . . . . . . . . . 5 73 5. Example of Content Request Redirection and Path Setup for 74 Content Delivery with SDN . . . . . . . . . . . . . . . . . . 6 75 6. Advantages of using SDN . . . . . . . . . . . . . . . . . . . 7 76 7. Further Considerations . . . . . . . . . . . . . . . . . . . . 7 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 79 10. Informative References . . . . . . . . . . . . . . . . . . . . 7 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The CDNI PS and framework documents [RFC6707][I-D.ietf-cdni- 85 framework] define the following four interfaces for CDNI; Request 86 Routing Interface, Metadata Interface, Logging Interface, and CDNI 87 Control Interface. As for the Request Routing - Redirection, HTTP and 88 DNS are being discussed as one of candidate protocols. Recently, 89 Software-defined networking (SDN) is emerging and intensively 90 discussed as one of the most promising technologies to provide 91 centralized, programmable control planes for network service 92 providers (NSPs). In this sense, SDN could be also considered as one 93 of candidates to facilitate CDNI Request Routing. This document 94 discusses how OF/SDN technology can be integrated in CDNI request 95 routing. 97 1.1. Terminology 99 This document draws freely on the terminology defined in [RFC3466] 100 and [RFC6706]. 102 We also introduce the following terms, tentatively: 104 CDN Frontend Server (CFS): CDN Frontend Server (CFS): It is a 105 server which has SDN capability. A Network Service Providers (NSP) 106 registers the address of its own CFS to DNS. In this way, a CFS can 107 redirect "request" messages to its SDN controller. 109 2. SDN Overview and Assumption 111 SDN is a new networking technology which allows centralized, 112 programmable control planes, so that NSPs can control and manage 113 directly their own virtualized resources and networks without 114 recognizing detailed hardware technologies. To achieve this, with 115 SDN, control and data planes are separated which allows control to be 116 directly programmable and manageable in a centralized manner and data 117 plane to be simplified and abstracted rather than specialized 118 hardware. Since work on SDN architecture and framework is still being 119 discussed and is not standardized yet, in this document, it is 120 assumed that OpenFlow is as one of architectural components for SDN 121 framework to facilitate CDNI Request Routing, as an example, but any 122 other existing and/or possible solutions for SDN, such as I2RS and 123 I2AEX could be also integrated without any big modifications. 125 Most modern Ethernet switches and routers contain flowtables that run 126 at line-rate to implement firewalls, NAT, QoS, and to collect 127 statistics. While each vendor's flowtable is different, OpenFlow's 128 basic idea composed an interesting common set of functions that run 129 in many switches and routers. OpenFlow exploits this common set of 130 functions. OpenFlow provides an open protocol to program the 131 flowtable in different switches and routers. In an OpenFlow network, 132 a central controller manages switches that support the concept of a 133 flow, a stream of related packets that are processed in the same way. 134 Every switch maintains a flow table containing a set of rules, where 135 each rule includes a pattern that is the set of packets belonging to 136 the flow, a priority that disambiguates overlapping rules, an 137 expiration time, a list of actions to apply to the packets, and 138 counters to measure the traffic. To process an incoming packet, the 139 switch identifies the matching rule with the highest priority, 140 updates the counters of the rule, and applies the actions. If no 141 matching rule is found, the switch forwards the packet to the 142 controllers and awaits further instructions. 144 3. SDN within CDNI Request Routing 146 The scope of the CDNI Request Routing Interface SHOULD contain two 147 functionalities [I-D.ietf-cdni-framework] : 149 o Request Routing Interface - Footprint and Capabilities 150 Advertisement; 151 the asynchronous advertisement of footprint and capabilities by 152 a dCDN that allows a uCDN to decide whether to redirect particular 153 user requests to that dCDN; 155 o Request Routing Interface - Redirection; 156 the synchronous operation of actually redirecting a user request 158 First of all, it is assumed that ALTO is used for Request Routing 159 Interface - Footprint and Capabilities Advertisement. Details and 160 examples on how a downstream CDN can advertise its footprint and 161 other information by means of ALTO are being discussed in [I- 162 D.seedorf-cdni-request-routing-alto]. Application Layer Traffic 163 Optimization (ALTO) is an approach for guiding the resource provider 164 selection process in distributed applications that can choose among 165 several candidate resources providers to retrieve a given resource. 166 By conveying network layer (topology) information, an ALTO server can 167 provide important information to guide the resource provider 168 selection process in distributed applications. 170 As for the Request Routing - Redirection, HTTP and DNS are being 171 discussed as one of candidate protocols. Recently, SDN is emerging 172 and intensively discussed as one of the most promising technologies 173 to provide centralized, programmable control planes for network 174 service providers (NSPs). In this sense, SDN could be also considered 175 as one of candidates to facilitate CDNI Request Routing as well as 176 HTTP and DNS. This document discusses how SDN technology can be 177 integrated in CDNI request routing. 179 4. Selection of a downstream CDN with SDN 181 SDN can help the upstream CDN provider to select a proper downstream 182 CDN provider for a given end user request as follows. It is assumed 183 that each downstream CDN provider hosts SDN controller. 185 An example of operation is as follows : 187 0) dCDN advertises information relevant to its delivery capabilities 188 (e.g. content availability, geographic footprint, etc.) using ALTO 189 extension (e.g., I2AEX) provisioning prior to any content requests 190 being redirected. 192 1) A content request from a user agent arrives in the CFS of uCDN. 194 2) The CFS at uCDN relays the message to the its SDN controller by a 195 "Packet-In' message. 197 3) ALTO client at the OF controller requests the best dCDN 198 information to ALTO server (ALTO cost map and/or other information 199 may be used). 201 4) ALTO server responses and then OF controller in uCDN knows which 202 is the best dCDN. 204 5) The SDN controller sends a query to the SDN controller of the best 205 dCDN 207 6) (uCDN redirects the request to the best dCDN). 209 5. Example of Content Request Redirection and Path Setup for Content 210 Delivery with SDN 212 SDN can help the upstream CDN provider to redirect a content request 213 message to a downstream CDN provider for a given end user request as 214 follows. It is assumed that the upstream and the downstream CDN 215 providers have SDN controllers. And OF/SDN sets up the path for the 216 content delivery. 218 An example of operation is as follows : 220 0) Content distribution metadata is pre-positioned between CDNs prior 221 to any content requests being redirected; that is, a controller in 222 uCDN knows its own surrogates in other CDNs and information relevant 223 to its delivery capabilities (e.g. geo-blocking information, 224 availability windows, desired distribution policy, etc.) 226 1) An end user issues an HTTP GET message to get content. By 227 contacting DNS, this message is forwarded to the CDN frontend server 228 (CFS) of uCDN which has SDN capability. 230 2) The CFS of uCDN relays this message to its own SDN controller by 231 "Packet-In" message in SDN protocol. 233 3) The controller of uCDN checks content distribution metadata, and 234 sends a query to the controller of dCDN whether it can deliver the 235 content. In the query, the source address of the request packets 236 (i.e. the host address of the user agent) is included. Optionally, a 237 QoS requirement for the content delivery may be specified in the 238 query as well. And there can be multiple candidate dCDNs for a given 239 user request. 241 4) If the SDN controller of dCDN decides to provide content, it 242 checks the location of the content object and network traffic status. 243 And it assigns an IP address for the content delivery. The assigned 244 IP address will be used as the content identifier, which is the 245 source address of the data packets. After that, it sends a reply to 246 the controller of uCDN with these data and sets up the path for 247 content delivery from the surrogate in dCDN to the end user. 249 5) The SDN controller in uCDN informs the end user of the URL of the 250 surrogate in dCDN by sending HTTP Redirection. 252 6) The end user sends HTTP GET message to the surrogate in dCDN. 254 6. Advantages of using SDN 256 The following reasons make SDN a suitable candidate protocol for 257 downstream CDN selection as part of CDNI request routing: 259 o Synchronous CDNI operations 261 o Integrated with SDN framework and architecture (e.g., OpenFlow) 263 o Traffic isolated with desired QoS/QoE, security, etc. 265 o More extensible (suitable for i2aex proposal) 266 o More centralized, programmable (e.g., using SDN Apps for CDNI) 268 o Mobility support 270 7. Further Considerations 272 The following further issues should be also discussed on SDN 273 architecture and framework for downstream CDN selection as part of 274 CDNI request routing: 276 o ALTO extension (i2aex) 278 o Northbound interfaces of SDN controllers 280 o Multi-controllers 282 o East-west bound interfaces of SDN controllers 284 8. Security Considerations 286 TBD 288 9. Acknowledgements 290 TBD 292 10. References 294 10.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 10.2. Informative References 301 [RFC6707] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 302 Distribution Network Interconnection (CDNI) Problem 303 Statement", RFC 6706, September 2012. 305 [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content 306 Distribution Network Interconnection (CDNI) Requirements", 307 draft-ietf-cdni-requirements-02 (work in progress), 308 December 2011. 310 [I-D.ietf-cdni-framework] Peterson,L. and B. Davie, "Framework for 311 CDN Interconnection", draft-ietf-cdni-framework-00 (work 312 in progress), April 2012. 314 [I-D.seedorf-cdni-request-routing-alto] Seedorf, J., "CDNI Request 315 Routing with ALTO", draft-seedorf-cdni-request-routing- 316 alto-01 (work in progress), March 2012. 318 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 319 for Content Internetworking (CDI)", RFC 3466, February 320 2003. 322 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 323 Optimization (ALTO) Problem Statement", RFC 5693, October 324 2009. 326 [b-OpenFlow] OpenFlow Switch Specification 1.3, 327 http://www.opennetworking.org/. 329 Authors' Addresses 331 Myung-Ki Shin 332 ETRI 333 161 Gajeong-dong Yuseng-gu 334 Daejeon, 305-700 335 Korea 337 Phone: +82 42 860 4847 338 Email: mkshin@etri.re.kr 340 Seungik Lee 341 ETRI 342 161 Gajeong-dong Yuseng-gu 343 Daejeon, 305-700 344 Korea 346 Phone: +82 42 860 1483 347 Email: seungiklee@etri.re.kr 349 Dukhyun Chang 350 Seoul National University 351 Seoul, Korea 353 Email: dhchang@mmlab.snu.ac.kr 355 Ted Taekyoung Kwon 356 Seoul National University 357 Seoul, Korea 359 Email: tkkwon98@gmail.com