Internet DRAFT - draft-shin-i2rs-usecases-cdni-request-routing

draft-shin-i2rs-usecases-cdni-request-routing



 



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]