ALTO extensions for CDNi
draft-stephan-cdni-alto-session-ext-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Emile Stephan , Selim Ellouze | ||
| Last updated | 2012-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-stephan-cdni-alto-session-ext-00
Network Working Group E. Stephan
Internet-Draft S. Ellouze
Intended status: Standards Track France Telecom Orange
Expires: September 6, 2012 March 05, 2012
ALTO extensions for CDNi
draft-stephan-cdni-alto-session-ext-00
Abstract
The selection of a downstream CDN by an upstream CDN is based on
multi-dimensional criteria such as the number of hops, the
performance of the connections between the user-agent and downstream
CDNs and the availability of downstream CDNs resources. Various
protocols, such as BGP or ALTO, may be used by an upstream CDN to
collect footprints and interconnection preferences of downstream
CDNs. This draft introduces several extensions to the ALTO protocol
for CDN interconnection.
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 in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Stephan & Ellouze Expires September 6, 2012 [Page 1]
Internet-Draft CDNi ALTO extensions March 2012
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Stephan & Ellouze Expires September 6, 2012 [Page 2]
Internet-Draft CDNi ALTO extensions March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. ALTO Client-Server session . . . . . . . . . . . . . . . . 5
2.2. PID Stability . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. dCDN Traffic Optimization . . . . . . . . . . . . . . . . 6
3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. CDNi ALTO Session . . . . . . . . . . . . . . . . . . . . 6
3.2. PID stability with legacy BGP . . . . . . . . . . . . . . 7
3.3. Interface Scalability . . . . . . . . . . . . . . . . . . 7
3.3.1. PIDs filters Setting . . . . . . . . . . . . . . . . . 7
3.3.2. PIDs Summary . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. PID Details . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Incremental Updates . . . . . . . . . . . . . . . . . 8
3.4. dCDN traffic Optimization . . . . . . . . . . . . . . . . 9
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Information Service Specification . . . . . . . . . . . . . . 12
6.1. Session Initialization . . . . . . . . . . . . . . . . . . 12
6.2. Update . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Information Service Call Flows . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Stephan & Ellouze Expires September 6, 2012 [Page 3]
Internet-Draft CDNi ALTO extensions March 2012
1. Introduction
The selection of a downstream CDN by an upstream CDN is based on
multi-dimensional criteria such as the number of hops, the
performance of the connections between the user-agent and downstream
CDNs and the availability of downstream CDNs resources. Various
protocols, such as BGP or ALTO, may be used by an upstream CDN to
collect footprints and interconnection preferences of downstream
CDNs. This draft introduces several extensions to the ALTO protocol
for CDN interconnection.
This draft focuses on the CDNi interconnections between an upstream
CDN and a set of downstream CDNs willing to control the exposition
and the exchange of footprint information.
It applies to CDNi use cases ([I-D.ietf-cdni-use-cases]) and CDN use
cases ( [I-D.jenkins-alto-cdn-use-cases]).
1.1. Terminology
The reader must be familiar with the terminology given by the drafts
[I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-requirements] ,
and [I-D.ietf-alto-protocol].
The following abbreviations are recalled:
- dCDN : downstream CDN;
- uCDN : upstream CDN;
- PID : Provider-defined Network Location Identifier;
- NSP : Network Service Provider (e.g. ISP connecting End User to
Internet);
ALTO Client-Server session:
The logical association between an ALTO Client and an ALTO server
which maintains the context across the connections of the client to
the server.
2. Motivations
Currently the ALTO protocol is designed for the communication of
network information to internet applications including untrusted
ones. In the context of a CDN interconnection (CDNi) there is a
certain level of trust, at least enough to mount a subset of the
Stephan & Ellouze Expires September 6, 2012 [Page 4]
Internet-Draft CDNi ALTO extensions March 2012
interfaces depicted in [I-D.ietf-cdni-problem-statement]. There are
CDNi situations like Inter-Affiliates Interconnection (see section
2.2 [I-D.ietf-cdni-use-cases] where topology hiding [RFC5693] is not
absolutely required.
2.1. ALTO Client-Server session
ALTO is a client-server protocol. Currently the ALTO specifications
do not specify the parameters of the session.
[I-D.ietf-alto-protocol] only indicates concerns for authentication,
content protection and encryption. Cookies are ignored.
The configuration of the ALTO interface between an uCDN and a dCDN
requires the exchange of session parameters between the two CDNs
operators. This can be performed either out-of-band or through the
CDNi Control interface. In both cases the setting of a CDNi ALTO
session requires an agreement between the 2 CDNs operators and a
technical description of the session configuration (addresses, URL,
authentication methods, etc.), of the information which can be
exchanged (PID filtering, level of details of the maps) and on the
way the information is exchanged (update procedure, scale of time of
the update ).
2.2. PID Stability
Currently to mitigate the risks of providing ALTO information to
untrusted ALTO clients ( [I-D.ietf-alto-protocol], section 12.1), it
is usual to ALTO servers to scramble the prefixes among the PIDs to
avoid reverse engineering. This may lead to PID content overlapping.
Such nondeterministic semantics may be unusable by a request routing
function of a uCDN, or may lead to suboptimal decision. .
2.3. Scalability
As illustrated by the figure 1 an uCDN could be interconnected with
several dCDNs. It may receive an important amount of information
leading to the uCDN failure ([I-D.ietf-alto-deployments], section
10). The CDNi ALTO interface should provide a scalable information
exchange framework to match uCDN ALTO client resources constraints.
A dCDN should be able to dimension the information resources it
dedicates to uCDNs. For instance, an uCDN may not want to receive
the very last detailed level of the network map of all the dCDNs it
is interconnected with; similarly it may not want to receive all the
update information.
This will be even worse when the maps will include multi-cost (
[I-D.randriamasy-alto-multi-cost] and [I-D.marocco-alto-next] section
3.2).
Stephan & Ellouze Expires September 6, 2012 [Page 5]
Internet-Draft CDNi ALTO extensions March 2012
------------------------
| |
| uCDN |
| ALTO Client |
------------------------
^ ^ ^
/ | \
detailed network and cost maps
/ | \
/ | \
----------- ----------- -----------
| dCDN A | | dCDN B | | dCDN C |
| ALTO | | ALTO | | ALTO |
| Server | | Server | | Server |
----------- ----------- -----------
Figure 1: uCDN ALTO interconnection
2.4. dCDN Traffic Optimization
Considering that ALTO is about traffic optimization at the
application level, in the context of a CDNi interconnection between
an uCDN and a dCDN, ALTO is capable of covering the exchange of
information from dCDN to uCDN, allowing for the optimization of the
delivery at the uCDN side only. In contrast, exchanging information
the other way around for allowing delivery optimization at the dCDN
level is not addressed yet.
Indeed a dCDN is subject to rival uCDNs requesting resources based on
information exposed by the dCDN. By exposing their constraints and
their needs, the uCDNs requirements are better addressed by dCDNs
through a smart resource provisioning and sharing.
3. Proposal
3.1. CDNi ALTO Session
The session between uCDNs and dCDNs should reflect the agreements and
expectancies between them. A minimal configuration of the session is
required for ensuring an efficient initialization of the interface,
for decreasing the service time, increasing the interoperability and
improving the security.
Interoperability:
The session configuration parameters must avoid the case allowed in
section 7.6.3 of [I-D.ietf-alto-protocol] where several entries in
Stephan & Ellouze Expires September 6, 2012 [Page 6]
Internet-Draft CDNi ALTO extensions March 2012
the directory match an Information Resource using a HTTP POST or a
HTTP GET. Additional session parameters should be specified to avoid
such situations (see section 7.6.4.1of [I-D.ietf-alto-protocol]).
One proposal consists in including PID filters in the session
parameters: The dCDN ALTO server generates an URI entry for each of
these filters in the resource directory. The uCDN ALTO client
downloads the content attached to these URIs using HTTP GET queries.
Discussion:
This work on the session configuration may be coupled with the
specification of the update service [I-D.marocco-alto-next] as both
require the memorization of session parameters like the coordinates
of the dCDN ALTO clients.
3.2. PID stability with legacy BGP
As described in section 4.1of
[I-D.previdi-cdni-footprint-advertisement] a CDN acquires most of the
footprint information from legacy BGP. The NSP may use part of the
community tags carried by its legacy internal BGP to filter and
gather the prefixes in stable groups (see section 5.1.7 of
[I-D.ietf-alto-deployments]) that may then used by its internal CDN
[I-D.jenkins-alto-cdn-use-cases] . The NSP CDN acting as a dCDN ALTO
server may filter and send these stable groups to uCDN ALTO clients
according to its policies and with respect to the peering agreement
between The NSP CDN and each uCDN.
3.3. Interface Scalability
The ALTO data must be customized to reduce the amount of exchanged
information for scalability and responsiveness.
3.3.1. PIDs filters Setting
The amount of information to be parsed impacts directly the
performance of uCDN Request Routing function. The selection of the
PIDs of interest is needed by an uCDN to limit the quantity of
information to download from each dCDN. As an example an uCDN does
not want to download all the PIDs when it needs only the PIDs managed
directly by each dCDN NSP (e.g. user-agent IPv4 on-net prefixes).
Discussion:
As given by section 7.2.2. of [I-D.ietf-alto-protocol] this can
already be achieved using POST querying the ALTO Map Filtering
Service. The drawback is that it requires carrying the filter
Stephan & Ellouze Expires September 6, 2012 [Page 7]
Internet-Draft CDNi ALTO extensions March 2012
parameters in-band in each POST query. An uCDN should be able to
configure filters that apply during all the duration of the ALTO
connection and to have the resulting information addressable directly
through a simple GET of an URI in the dCDN ALTO server.
The proposal consists in having PID filters at the session level.
There are two options:
The filters are agreed by uCDN and dCDN operators and set in the
configuration of the session;
Filters are dynamically configured during the session by an uCDN
ALTO client. It requires the creation of a 'PIDs filters Setting'
service in the dCDN ALTO server.
3.3.2. PIDs Summary
The level of information details exchanged between a dCDN ALTO server
and a uCDN ALTO client must be customizable in order to decrease the
amount of exchanged data while providing the required information.
uCDN may not need the full details of each map. It may also need to
reduce the exchange of useless information. An uCDN ALTO client
should be allowed to get only the summary of the maps. This can be
achieved by using additional session parameters giving the level of
detail of the maps.
This covers the situation where the very detail of PIDs are available
on other existing interfaces of a dCDN and where an uCDN and a dCDN
agree to not duplicate the works.
3.3.3. PID Details
An uCDN may need the detailed information of a sub set of PIDs of
interest.
An uCDN ALTO client queries the detail of a PID in dCDN ALTO server
using the ALTO Map Filtering Service [I-D.ietf-alto-protocol].
3.3.4. Incremental Updates
In a way to avoid flooding uCDN with useless information each dCDN
ALTO server should limit the incremental update according to the
session configuration and the restrictions made by each uCDN ALTO
client (filters, time scale, etc.).
Stephan & Ellouze Expires September 6, 2012 [Page 8]
Internet-Draft CDNi ALTO extensions March 2012
3.4. dCDN traffic Optimization
An uCDN may provide dCDN with high level constraints like previsions
of the amount of traffic that uCDN will or may have to deliver.
Based on the raw description of each uCDN constraints, dCDN NSPs
should be able to improve their network provisioning and optimize
resource usage while enhancing the QoS. This benefits directly to
all uCDNs because the cost map provided by dCDN will reflect uCDNs
constraints instead of providing a better-than-nothing generic cost
map agnostic to the different uCDNs constraints. To preserve its
know-how an uCDN is not entitled to expose the detail of its
constraints. The solution proposed by this draft consists in
grouping uCDN constraints information at the PID level to provide
complementary information on the PIDs provided by dCDN.
This information benefits to all interconnected CDNs as it allows for
a smarter resources utilization leading to a better QoE at comparable
costs.
This can be achieved with a new ALTO Service based on a POST request.
4. Framework
The framework is PID centric. It supports session parameters. It
reduces the number of POST messages by including fully-defined
filtered maps as URI in the resource directory and provides better
scalability regarding the amount of data to clients and servers. It
adds a first service allowing uCDN to configure filters which apply
to all uCDN queries and dCDN updates. The second service created
allows uCDNs to complement PID information with high level
constraints. The third service, already in the roadmap of ALTO,
allows the push of map updates by an ALTO server.
Following is the summary of the services.
Stephan & Ellouze Expires September 6, 2012 [Page 9]
Internet-Draft CDNi ALTO extensions March 2012
uCDN ALTO Client dCDN ALTO Server
| |
| server capabilities options |
|<--------------------------------------------------| (a)
| |
... ...
| |
| PIDs filters setting |
|-------------------------------------------------->| (b)
| |
... ...
| |
| PIDs summary |
|<--------------------------------------------------| (c)
| |
... ...
| |
| PID details |
|<--------------------------------------------------| (d)
| |
... ...
| |
|-------------------------------------------------->| (e)
| uCDN constraints on dCDN PIDs |
| |
... ...
| |
| Matrix of cost |
|<--------------------------------------------------| (f)
| |
... ...
| |
| updates |
|<--------------------------------------------------| (g)
| |
| |
Figure 2: Extension framework
(a) The uCDN ALTO client gets the dCDN ALTO server capabilities (GET
directory).
(b) The uCDN ALTO client adds PIDs filtering (e.g. IPv4 only, PID of
interest ...).
(c) The uCDN ALTO client downloads PIDs summary.
(d) The uCDN ALTO client downloads detailed information of one PID.
Stephan & Ellouze Expires September 6, 2012 [Page 10]
Internet-Draft CDNi ALTO extensions March 2012
(e) The uCDN ALTO client complements dCDN network map entries with
its constraints.
(f) The uCDN ALTO client downloads the cost map.
(g) The dCDN ALTO server updates the information. An update includes
either the information that has changed or a list of indication of
the information which has changed. The mode used is given by the
session parameters. As an example, an update of the network map may
includes only the list of the PID updated since the previous version
of the network map.
5. Requirements
This section proposes a first set of requirements.
Requirements for ALTO:
The ALTO server must indicate the support of the CDNi services in its
Information resource Directory:
- CDNi PID filtering service;
- Constraints upload service;
- Update service;
Requirements for CDNi:
A dCDN ALTO server must reject any message received from an untrusted
CDNi uCDN ALTO client.
A dCDN ALTO server must support the filter setting service when the
initialization of the session does not support PID filters
configuration.
A dCDN ALTO server must support the exchange of summarized network
maps.
A dCDN ALTO server may support the constraints upload service.
A dCDN ALTO server may support the update service.
A uCDN ALTO client may support the update service.
Stephan & Ellouze Expires September 6, 2012 [Page 11]
Internet-Draft CDNi ALTO extensions March 2012
6. Information Service Specification
This section specifies the session initialization and the additionnal
information services defined for interconnecting an uCDN ALTO client
to an dCDN ALTO server.
Each information service will be described in a next version of this
document.
6.1. Session Initialization
The agreement between uCDN and dCDN operators specifies the initial
values of the parameters of the ALTO sessions.
Following are the parameters of the session:
- PID_filters: The list of PID filters of this session (e.g. ipv4,
on-net...).
- network_map_level_of_details: The default level of details of
the network maps.
- costmap_level_of_details: The default level of details of the
cost maps.
- Update_heartbeat: The time scale of the update.
6.2. Update
This is already drafted in [I-D.pbryan-json-patch], discussed
[I-D.schwan-alto-incr-updates]and envisionned by
[I-D.marocco-alto-next] the ALTO WG.
7. Information Service Call Flows
This section describes the interworking between a dCDN ALTO server
and an uCDN ALTO client.
The call flow of each service will be described in a next version of
this document.
8. IANA Considerations
This document will request the registration of the media type
corresponding to each new information service introduced.
Stephan & Ellouze Expires September 6, 2012 [Page 12]
Internet-Draft CDNi ALTO extensions March 2012
9. Security Considerations
[Editor Note: This section needs more works]
Despite the ALTO session is set up between CDNi entities the usage of
the ALTO services by the client may stress the server. Consequently
the volume and the number of these messages may affect the
availability and the performance of the ALTO server.
An uCDN ALTO client sets up the session parameters to control the
amount of information downloaded from a dCDN ALTO server.
Nevertheless the uCDN ALTO client should protect itself from the
download of huge network map.
The new information services do not introduce deep privacy concerns
because they tend to reduce the information exchanged. Nevertheless
this point requires more investigation.
10. Acknowledgments
Part of this work is funded by the EU FP7 Envision and Ocean
projects.
The authors would like to thank Christian Jacquenet for its feedbacks
on preliminary versions of this document
11. References
11.1. Normative References
[I-D.ietf-alto-protocol]
Penno, R., Alimi, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-10 (work in progress),
October 2011.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Stephan & Ellouze Expires September 6, 2012 [Page 13]
Internet-Draft CDNi ALTO extensions March 2012
11.2. Informative References
[I-D.ietf-alto-deployments]
Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO
Deployment Considerations", draft-ietf-alto-deployments-04
(work in progress), March 2012.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-03 (work in
progress), January 2012.
[I-D.ietf-cdni-use-cases]
Gilles, B., Watson, G., Ma, K., Eardley, P., Emile, S.,
and T. Burbridge, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-03 (work in
progress), January 2012.
[I-D.jenkins-alto-cdn-use-cases]
Previdi, S., Watson, G., Medved, J., Bitar, N., and B.
Niven-Jenkins, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-02 (work in progress),
December 2011.
[I-D.marocco-alto-next]
Marocco, E. and V. Gurbani, "Extending the Application-
Layer Traffic Optimization (ALTO) Protocol",
draft-marocco-alto-next-00 (work in progress),
January 2012.
[I-D.medved-alto-svr-apis]
Medved, J., Ward, D., Peterson, J., Woundy, R., and D.
McDysan, "ALTO Network-Server and Server-Server APIs",
draft-medved-alto-svr-apis-00 (work in progress),
March 2011.
[I-D.pbryan-json-patch]
Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work
in progress), December 2011.
[I-D.penno-alto-cdn]
Penno, R., Medved, J., Alimi, R., Yang, R., and S.
Previdi, "ALTO and Content Delivery Networks",
draft-penno-alto-cdn-03 (work in progress), March 2011.
[I-D.previdi-cdni-footprint-advertisement]
Previdi, S., Faucheur, F., Faucheur, F., and J. Medved,
Stephan & Ellouze Expires September 6, 2012 [Page 14]
Internet-Draft CDNi ALTO extensions March 2012
"CDNI Footprint Advertisement",
draft-previdi-cdni-footprint-advertisement-00 (work in
progress), October 2011.
[I-D.randriamasy-alto-multi-cost]
Randriamasy, S. and N. Schwan, "Multi-Cost ALTO",
draft-randriamasy-alto-multi-cost-05 (work in progress),
October 2011.
[I-D.schwan-alto-incr-updates]
Schwan, N. and B. Roome, "ALTO Incremental Updates",
draft-schwan-alto-incr-updates-00 (work in progress),
December 2011.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Authors' Addresses
Emile Stephan
France Telecom Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange-ftgroup.com
Selim Ellouze
France Telecom Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: selim.ellouze@orange-ftgroup.com
Stephan & Ellouze Expires September 6, 2012 [Page 15]