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]
