Internet DRAFT - draft-shin-cdni-request-routing-sdn

draft-shin-cdni-request-routing-sdn



 



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]