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]