Network Working Group E. Stephan
Internet-Draft S. Ellouze
Intended status: Standards Track France Telecom - Orange
Expires: January 10, 2013 July 09, 2012
ALTO session for CDN Interconnection
draft-stephan-cdni-alto-session-ext-01
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, the availability of downstream CDNs resources and business
policies. Various protocols, such as BGP or ALTO, may be used by a
downstream CDN to expose content routing information and
interconnection preferences to an upstream CDN. This draft specifies
the parameters of an ALTO session between two interconnected CDNs.
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 January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Stephan & Ellouze Expires January 10, 2013 [Page 1]
Internet-Draft CDNi ALTO session July 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 January 10, 2013 [Page 2]
Internet-Draft CDNi ALTO session July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. CDN1 views . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. CDN2 views . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Map Maintenance . . . . . . . . . . . . . . . . . . . . . 9
3. Requirements for an ALTO Session for CDNi . . . . . . . . . . 9
3.1. ALTO Information Customization . . . . . . . . . . . . . . 9
3.2. View HTTP GET . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Initialization of the Session . . . . . . . . . . . . . . 10
3.4. Server Discovery . . . . . . . . . . . . . . . . . . . . . 10
3.5. Maps Update . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Information Resource Directory . . . . . . . . . . . . . . 11
3.7. Redistribution . . . . . . . . . . . . . . . . . . . . . . 11
3.8. PID Stability . . . . . . . . . . . . . . . . . . . . . . 11
3.9. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
3.10. Performance . . . . . . . . . . . . . . . . . . . . . . . 12
3.11. Heart Beat . . . . . . . . . . . . . . . . . . . . . . . . 13
3.12. dCDN Traffic Optimization . . . . . . . . . . . . . . . . 13
4. Specification of the ALTO Session for CDNi . . . . . . . . . . 13
4.1. ALTO session Framework . . . . . . . . . . . . . . . . . . 13
4.2. View Configuration . . . . . . . . . . . . . . . . . . . . 15
4.2.1. PoINT . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. View Configuration Examples . . . . . . . . . . . . . 15
4.3. Session Configuration Parameters . . . . . . . . . . . . . 16
4.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 17
5. Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Incremental Update . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Level of Details of a Map . . . . . . . . . . . . . . 18
5.2. Bi-directional Exchange of Information . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Stephan & Ellouze Expires January 10, 2013 [Page 3]
Internet-Draft CDNi ALTO session July 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, the availability of downstream CDNs resources and business
policies. Various protocols, such as BGP or ALTO, may be used by a
downstream CDN to expose content routing information and
interconnection preferences to an upstream CDN. This draft specifies
the parameters of an ALTO session between two interconnected CDNs.
Currently the ALTO protocol is designed for the communication of
network information to untrusted internet applications. In the
context of a CDN interconnection (CDNi) there is a certain level of
trust, at least enough to mount a subset of the interfaces depicted
in [I-D.ietf-cdni-problem-statement]. In practice the level of trust
differs with each interconnection. There are situations where a CDNi
ALTO server has to exchange information with an ALTO client of an
affiliate and with an ALTO client of a competitor (see
[I-D.ietf-cdni-use-cases]).
In the first case topology hiding [RFC5693] may not be required. In
the second case the operator of a dCDN may consider a fine control of
the exposed information. Consequently the ALTO server of a dCDN
operator must be able to adapt the information exposed to each uCDN.
The document discusses firstly the insightful aspects of such a use
cases in section 2. Then in section 3 it presents the motivations
for specifying an ALTO session to customize the information exposed
in each CDN interconnection. In section 4, it provides a proposal
for an appropriate specification of an ALTO session for a CDN
interconnection. Finally it discusses different enhancements of
interest to a CDNi ALTO session.
N.B.: this version of the memo covers only the Network Map.
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: The CDN which provide the delivery
resource;
Stephan & Ellouze Expires January 10, 2013 [Page 4]
Internet-Draft CDNi ALTO session July 2012
uCDN : upstream CDN: The CDN which may rely on dCDN server to
deliver contents;
PID : Provider-defined Network Location Identifier;
NSP : Network Service Provider (e.g. ISP connecting End User to
Internet);
ALTO Information Resource Directory: (Directory): The Information
Resource Directory indicates to ALTO Clients which Information
Resources are made available by an ALTO Server (section 7.6
[I-D.ietf-alto-protocol] ).
Following are terms and abbreviations introduced in the document:
adCDN: ALTO downstream CDN server;
auCDN: ALTO upstream CDN client;
PIDs of Interest (PoINT) : The PIDs which are in the scope of an
ALTO session or of a view. They may be defined as a list or by a
XSLT-like statement (e.g. 'map/*/ipv6');
Costs of Interest (CoINT) : The Costs which are in the scope of an
ALTO session or of a view;
ALTO Client-Server session: The logical association between an CDNi
ALTO Client and an CDNi ALTO server which maintains the context
across the ALTO HTTP connections made by the client to the server.
View: A view is the set of URIs which provide an auCDN with a mean
for downloading the maps reflecting an agreement between an uCDN and
a dCDN. A view is defined by PIDs of Interest (PoINT) and Costs of
Interest (CoINT).
2. Use Cases
This section depicts a situation where a dCDN exposes information
according to the agreements of each CDN interconnection. The
infomation is exposed within an ALTO session based on the current
ALTO protocol version. There is not time dependency between the
content requests received by the upstream CDN and the information
exchanged over the CDNi ALTO interface.
To ease the reading, the content of the Network Maps is intentionally
limited with regards to real situation.
Stephan & Ellouze Expires January 10, 2013 [Page 5]
Internet-Draft CDNi ALTO session July 2012
The use case is about a NSP which deployed a CDN named CDN0 over its
network and where CDN0 acts as a downstream CDN for two CDNs named
CDN1 and CDN2. CDN1 is an affiliate of CDN0.
In the figure 1, the network of NSP provides CDN0 with an aggregated
view of the routing information. The grouping of the routing
information results from the processing of information provided by
BGP according to various policies of the NSP (network, content
distribution, etc).
+----------------------------------+
| NSP |
| |
| |
| +---------+ |
| | Network | |
| +---------+ |
| | |
| | |
| BGP|Info |
| | |
| | |
| +-------V---------+ |
| | Community Tags, | |
| |Grouping Policies| |
| +-----------------+ |
| | |
| | |
| Routing Information |
| | |
| | |
| +---------V---------+ |
| | | |
| | CDN0 CDN | |
| | | |
| +-------------------+ |
+----------------------------------+
Figure 1: Internal Routing Information
The Figure 2 shows CDN0 acting as a dCDN for CDN1 and CDN2. CDN0
ALTO server (adCDN0) filters and sends stable Network and Cost Maps
to the uCDN ALTO clients according to its policies and with respect
to the peering agreement between the NSP and the operators of CDN1
and CDN2. adCDN0 is connected to 2 CDNi ALTO clients named auCDN1 and
auCDN2.
Stephan & Ellouze Expires January 10, 2013 [Page 6]
Internet-Draft CDNi ALTO session July 2012
+-------------------------------------------+
| NSP |
| |
| |
| |
+-----------+ |+---------------------+ +---------------+ |
| | Cost Map || dCDN ALTO server | | CDN0 | |
| uCDN1 |<--------------- adCDN0 | | | |
| | || | | | |
| ALTO | network Map || | | +----------+ | |
| Client |<--------------- +---------------+ | | |Monitoring| | |
| | || | | |<----| info | | |
+-----------+ || |Interconnection| | | +----------+ | |
|| | Policies | | | +----------+ | |
+-----------+ || | | |<----| | | |
| | Cost Map || +---------------+ | | | Routing | | |
| uCDN2 |<--------------- | | | Info | | |
| | || | | +----------+ | |
| ALTO | network Map || | | | |
| Client |<--------------- | | | |
| | |+---------------------+ +---------------+ |
+-----------+ +-------------------------------------------+
Figure 2: CDNs interconnection
The Figure 3 presents the internal representation of the Network Map
computed by CDN0 ALTO server.
"map" : {
"PID_DSL" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6": [
"2001:db8:0:1::/64",
]
},
"PID_FTTH" : {
"ipv4" : [
"198.51.100.128/25"
],
"ipv6": [
"2001:db8:0:2::/64"
]
}
}
Stephan & Ellouze Expires January 10, 2013 [Page 7]
Internet-Draft CDNi ALTO session July 2012
Figure 3: CDN0 internal Network Map
2.1. CDN1 views
CDN0 and CDN1 agreed that CDN1 needs only the IPv4 view of the
Network Map. The Network Map, presented in figure 4, is downloadable
by CDN1 at the URI
'http://cdni.alto.example.com/CDN1/networkmap/ipv4'.
"map" : {
"PID_DSL" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID_FTTH" : {
"ipv4" : [
"198.51.100.128/25"
]
}
}
Figure 4: CDN1 IPv4 Network Map view
2.2. CDN2 views
CDN0 and CDN2 have 2 separate agreements. Both are relative to the
geographical extension of CDN2 coverage . The first agreement
concerns the exposition of FFTH customers only. The second one
covers IPv6 customers only. They are reflected as separated Network
Maps. The first Network Map, exposed in figure 5, is downloadable by
CDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/FTTH'.
"map" : {
"PID_FTTH" : {
"ipv4" : [
"198.51.100.128/25"
],
"ipv6": [
"2001:db8:0:2::/64"
]
}
}
Figure 5: CDN2 FTTH Network Map.
The second Network Map, exposed in the figure 6, is downloadable by
auCDN2 at the URI
'http://cdni.alto.example.com/CDN2/networkmap/IPv6'.
Stephan & Ellouze Expires January 10, 2013 [Page 8]
Internet-Draft CDNi ALTO session July 2012
"map" : {
"PID_DSL" : {
"ipv6": [
"2001:db8:0:1::/64",
]
},
"PID_FTTH" : {
"ipv6": [
"2001:db8:0:2::/64"
]
}
}
Figure 6: CDN2 IPv6 Network Map
2.3. Map Maintenance
auCDN1 and auCDN2 need a mean for maintaining the content of the
maps. The ALTO server of CDN0 provides each view with an URI towards
a list of the PIDs which were really modified in the last update.
Each dCDN can download this information and determine whenever or not
it have to update the Network Map of this view again.
This is not optimal. Nevertheless it provides an update mechanism
based on HTTP GET which contribute to the reduction of both the
volume of information exchanged and the processing on each side.
3. Requirements for an ALTO Session for CDNi
This section motivates the necessity of specifying an ALTO session
between a dCDN and a uCDN with adequate features for addressing CDN
interconnection requirements.
3.1. ALTO Information Customization
The current ALTO approach excludes that the Maps exposed by the ALTO
server differ according to the client . This is enforced by section
7.2.6 of [I-D.ietf-alto-protocol] which recommends ignoring HTTP
session parameters and HTTP cookies.
CDNi widely differs in such aspects because a dCDN operator must be
able to adapt the information exposed to each uCDN according first to
its policies and second to its agreements with uCDN. Moreover it is
important for a uCDN client to optimize the volume and the relevance
of the information received by avoiding downloading unwanted
information in order to enhance the performance of the processing of
the received data.
Stephan & Ellouze Expires January 10, 2013 [Page 9]
Internet-Draft CDNi ALTO session July 2012
Consequently the customization of the ALTO interface between an uCDN
and a dCDN requires the specification of a minimal set of session
parameters. This must be specified inside the CDNi WG to provide a
minimal level of interoperabilty amongst CDNs.
3.2. View HTTP GET
Currently [I-D.ietf-alto-protocol] (section 7.6.2 and 7.6.4.1) allows
2 Information Resources of the Information Resource Directory to
match the same view of a map and to be downloadable using either an
HTTP POST or a HTTP GET.
In the context of ALTO session for CDNi this is not allowed. An view
of a map is accessible by an unique URI using HTTP GET request only.
The session configuration defines all the information resources that
an auCDN can download.
3.3. Initialization of the Session
The setting of the session between an uCDN and a dCDN reflects their
agreements and expectancies. 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.
The exchange of the session configuration parameters can be performed
either out-of-band (human settings) 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 (ALTO server and client addresses, URL,
authentication methods, etc.), of the information which can be
exchanged (PID of Interest, Cost of interest, level of details of the
maps, etc) and of the way the information is exchanged (update
method, time-scale for updates, etc ).
3.4. Server Discovery
The discovery of a dCDN server by a uCDN relies on parameters
exchanged out-of-band or on the CDNi Control interface. Consequenty
a CDN interconnection does not require any discovery mechanisms like
described in [I-D.ietf-alto-server-discovery].
3.5. Maps Update
Maps update is under discussion in the ALTO WG as there is a strong
need to optimize the volume of exchanged information and to reduce
the duration of the acquisition of the updates. ,
[I-D.schwan-alto-incr-updates] presents solutions for incremental
Stephan & Ellouze Expires January 10, 2013 [Page 10]
Internet-Draft CDNi ALTO session July 2012
update (download of update by the client). Another possibility is
the specification of a synchronous update procedure where the server
pushes the updates on the fly towards the client.
Incremental update and synchronous update may not be required for CDN
interconnection when the customization of the session leads to a
limited amount of information to be exchanged. Nevertheless, the
adCDN server must at least provide hints to each auCDN for reducing
the volume of exchanged information.
If no update mechanism is implemented, each view must include a
information resource exposing a summary of the map updates (the list
or the number of PIDs which were updated, etc). This approach
provides the client logic with enough information to decide whether
to re-download the whole map or not (e.g. depending on the importance
of the PIDs which were updated).
3.6. Information Resource Directory
Section 7.6 of [I-D.ietf-alto-protocol] requires the availability of
Information Resource Directory for exposing the Information Resources
(i.e. URIs of the maps).
In a CDNi interconnection it is not necessary to provide such
directory as the two interconnected CDNs previously agreed on the URI
names. Besided, avoiding the exposition of URIs enhances the
security of the system (see section 11.5. [I-D.ietf-alto-protocol]
).
3.7. Redistribution
Redistribution of network Map and Cost Map by an uCDN is forbidden
because first it results on the exposition of information exclusively
destined to a well defined entity and second others uCDNs must not be
flooded with unwished information.
The information exposed by dCDN to uCDN reflects only the agreement
between the operators of these 2 CDNs only. Hence, redistributing
maps content will lead to inconsistency because the semantic of the
information differs with the session. As an example a PID name may
cover different meaning or content.
3.8. PID Stability
Currently ALTO servers scramble the prefixes among the PIDs to
prevent reverse engineering by ALTO clients (
[I-D.ietf-alto-protocol], section 12.1).
Stephan & Ellouze Expires January 10, 2013 [Page 11]
Internet-Draft CDNi ALTO session July 2012
CDNi situations differ widely in such aspects. Such nondeterministic
semantics is totally unusable by a request routing function of a
uCDN, or may lead to suboptimal decision. The dCDN must expose
meaningful information to uCDN. Consequently the meaning of the PIDs
must not change during the session duration.
As described in section 4.1 of
[I-D.previdi-cdni-footprint-advertisement] a CDN acquires part of the
content routing information from legacy BGP. As given by figure 1,
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 by used
by its internal CDN [I-D.jenkins-alto-cdn-use-cases].
3.9. Scalability
The routing function of an uCDN might not require all the information
that an ALTO server of an dCDN might expose. Furthermore, as by
nature an uCDN interconnects with several dCDNs this volume might
harm its performance and its reliability [I-D.ietf-alto-deployments].
The same applies for dCDN ALTO server. It must not be overloaded by
dCDNs requests.
Consequently the CDNi ALTO session will provide dCDN and uCDN with a
mean to shape the information to exchange in an interoperable manner.
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;
it may not want to receive each update; it may be interested only by
one cost type attribute of the Cost Map service, etc.
N.B.: The situation will be even worse when the maps will include
multi-cost as proposed by ( [I-D.randriamasy-alto-multi-cost] and
[I-D.marocco-alto-next] section 3.2) because the size of the maps
will increase.
3.10. Performance
The amount of information to be processed impacts directly the
performance of an auCDN. As an example an uCDN does not want to
download all the PIDs when it needs only the PIDs of the Endpoints
managed directly by each dCDN. Currently, as given by section 7.2.2.
of [I-D.ietf-alto-protocol] , this is achieved using HTTP POST
querying the ALTO Map Filtering Service or by HTTP GET of pre-
generated maps.
To optimize the performance the ALTO Map Filtering Service is not
exposed. Map filtering is accessible only throught HTTP GET toward
Stephan & Ellouze Expires January 10, 2013 [Page 12]
Internet-Draft CDNi ALTO session July 2012
pre-generated maps according to the configuration of the session
agreed by the CDNs. Consequently the ALTO session configuration must
include must include filters (PIDs, cost, etc) to reduce the volume
of information exchanged about to the PIDs of Interest (PoINT) and to
the Cost of Interest (CoINT) agreed by uCDN and dCDN operators.
These filters apply during all the duration of the ALTO session.
3.11. Heart Beat
Neither the ALTO server nor the ALTO client want the session to be
overflooded. A heart beat parameter is needed to control the
intensity of the communication for exchanging information over the
ALTO session. It provides a hint of the periodicity of the download
of the maps by the client (e.g. every minute, hour, day, week, etc).
As an example to avoid useless maps download auCDN and adCDN might
agreed to set the value of the heart beat to the period of
refreshment of the considered maps.
3.12. 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.
A uCDN should be able to provide dCDN with information that may help
dCDN to optimize it resources.
4. Specification of the ALTO Session for CDNi
This section specifies the ALTO session for CDNi.
4.1. ALTO session Framework
The figure 7 presents the Framework of the ALTO Session for CDN
interconnection:
Stephan & Ellouze Expires January 10, 2013 [Page 13]
Internet-Draft CDNi ALTO session July 2012
The Map filtering logic is represented to reflect the
customization of the content of the internal maps to the server
according to the scope of the sessions with uCDNs.
There are PID and Cost filters to limit the scope of the session
with regard to the content of the internal maps content of the
server.
Network Map and Cost Map are unchanged. Nevertheless the session
PIDs and Cost filtering applies to all the information exchanged;
It does not require the support of the End point Information
Services because an uCDN does not request individual endpoints
information to a dCDN.
The Sessions Handler maintains the logical association between an
uCDN and a dCDN. It controls the session according to the session
parameters: It handles the filtering of the network Map and of the
Cost Map according the PoINTs and of the CoINTs of the session.
The Sessions Handler handles the views given by the configuration
of the session.
Information Services are accessible through HTTP GET messages
only.
A dCDN ALTO server does not expose the URIs nor provides an
Information Resource Directory.
The Map Filtering logic and the sessions handler replace the Map
Filtering service of the current version of the ALTO protocol.
.-------------------------------.
| |
| .-----------. .-----------. |
| | Network | | Cost | |
| | Map | | Map | |
| | | | | |
| `-----------' `-----------' |
| |
| .-----------. .-----------. |
| | Sessions | | Map | |
| | Handler | | Filtering | |
| | | | logic | |
| `-----------' `-----------' |
| |
`-------------------------------'
Stephan & Ellouze Expires January 10, 2013 [Page 14]
Internet-Draft CDNi ALTO session July 2012
Figure 5: ALTO Protocol for CDN interconnection
4.2. View Configuration
Views are similar to pre-generated maps presented in the section
7.6.3. of [I-D.ietf-alto-protocol]. Their configurations are local
to the ALTO server.
The configuration includes a name, a PoINT and a CoINT. A view
provides an ALTO CLient with at least 2 Information Resources: the
network map associated with the PoINT and the cost map associated
with the CoINT.
Its definition includes the setting of the URIs towards these pre-
generated maps.
N.B.: Cost of Interest (CoINT) will be defined in the next version fo
the document.
4.2.1. PoINT
A PoINT applies at the view level. It specifies a local filter tied
to an URI which provides the ALTO client with a link to download the
ouput of this filter (see examples in section 4.2.2). It applies
during all the duration of the session.
This filter produces pre-generated maps. The output of the filter is
a pre-generated network map and a optionnal pre-generated Network Map
Status. The Network Map Status will be specified in the next version
of the document.
Note: Filters value are not exchanged over the network.
Nevertheless, as ALTO Maps are JSON documents it is desirable to
write the filter using JSON document filtering mechanisms like JSON
pointer [I-D.pbryan-zyp-json-pointer]. In this memo the filters are
defined using a syntax similar to JSON pointer but allowing wildcard
(like W3C XPATH does).
4.2.2. View Configuration Examples
Following are the PoINT corresponding to the use case of the section
2.
Note: View Configurations are internal to an ALTO Server. They are
not exchanged between the ALTO server and the ALTO Client. In this
section the View Configurations are writen in JSON to ease the
reading only.
Stephan & Ellouze Expires January 10, 2013 [Page 15]
Internet-Draft CDNi ALTO session July 2012
{
"view" : "ipv4",
"point" : {
"filter": "map/PID_*/ipv4" ,
"map" : "http://cdni.alto.example.com/CDN1/networkmap/ipv4"
"map_status" : "http://cdni.alto.example.com/CDN1/networkmap/ipv4/status"
}
"coint" : []
}
CDN1 IPv4 view
{
"view" : "FTTH",
"point" : {
"filter": "map/PID_FTTH" ,
"map" : "http://cdni.alto.example.com/CDN2/networkmap/FTTH"
"map_status" : "http://cdni.alto.example.com/CDN2/networkmap/FTTH/status"
}
"coint" : []
}
CDN2 FTTH view
{
"view" : "IPv6",
"point" : {
"filter": "map/PID_*/IPv6" ,
"map" : "http://cdni.alto.example.com/CDN2/networkmap/IPv6"
"map_status" : "http://cdni.alto.example.com/CDN2/networkmap/ipv6/status"
}
"coint" : []
}
CDN2 IPv6 view
4.3. Session Configuration Parameters
The agreement between uCDN and dCDN operators defines the
configuration set of the ALTO session.
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 of the
way the information is exchanged (update procedure, time scale of
updates ).
Stephan & Ellouze Expires January 10, 2013 [Page 16]
Internet-Draft CDNi ALTO session July 2012
The session configuration relies on the following parameters:
connection: server and client addresses, URL base, authentication
methods, etc.;
session_filter: The PIDs which are in the scope of the session.
The Cost parameters which are in the scope of the session;
views: a list of views;
PoINTs;
CoINTs;
nmap_heartbeat: Order of magnitude of the periodicity of the
download of the Network Maps by the client (e.g. every minute or
every week);
cmap_heartbeat: Order of magnitude of the periodicity of the
download of the Cost Maps by the client (e.g. every minute or
every week);
4.4. Error Handling
Errors are reported using legacy ALTO and HTTP errors.
5. Enhancements
The ALTO session presented in this memo relies on basic ALTO services
to permit a good level of interoperability, performance and security
and to help preserving individual CDN know-how. This section
discussed enhancements to a CDNi ALTO session.
5.1. Incremental Update
There are different ways to implement maps update
[I-D.schwan-alto-incr-updates]. Two important aspects are to be
considered: Improving the processing time in the ALTO client and
providing auCDN with relevant updates. An update based on the diff
of JSON file entries is useful but not optimized with regard to the
uCDN processing because it requires the re-processing of the whole
map from scratch after each upload. A better approach consists in
defining an update mechanism providing the diff for a grouping of
entries such as PIDs.
The approach proposed in section 4.2.1 does not optimize the protocol
but provide additionnal Information Resources to let the uCDN
Stephan & Ellouze Expires January 10, 2013 [Page 17]
Internet-Draft CDNi ALTO session July 2012
optimizes it exchanges according to its logic.
5.1.1. Level of Details of a Map
The level of information 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 entry map. It may need
the details later.
Furthermore there are cases where an uCDN needs only the list of the
PIDs of dCDN. This covers situations where the very detail of each
PID of a Network Map is available over existing interfaces like BGP.
For these reasons an uCDN ALTO client should be allowed to get only
the summary of the maps (e.g. the list of the PIDs of a Network Map).
This can be achieved by defining additional session parameters which
set the level of detail of the maps.
5.2. Bi-directional Exchange of Information
In the CDNi context, tied interactions between an uCDN and a dCDN may
be required. As Discussed in section 3, there are different aspects
requiring a Bi-directionnal exchange of information including:
Network Map Update Notifications: The update mechanism based on
HTTP download is sub-optimal when the uCDN requires a real time
propagation of the updates. Bi-directional interactions allow
adCDN to notify auCDN with Network Map updates;
Exposition of uCDN constraints: Allowing an uCDN to inform dCDN
about its high level constraints like forecast indications
provides dCDN with valuable information for optimizing its
resources provisioning;
Session Customization: There are situations where an uCDN may
require other Views or modify existing Views and where there is a
high level of trust between the two CDNs. Consequently the ALTO
session might support the modification of the Views by the auCDN.
One solution consists in upgrading the HTTP session to a bi
directional protocol. WebSocket Protocol [RFC6455] is one potential
candidate.
Stephan & Ellouze Expires January 10, 2013 [Page 18]
Internet-Draft CDNi ALTO session July 2012
6. IANA Considerations
This document will request the registration of the media type
corresponding to new information services introduced, if any.
7. Security Considerations
This memo defines an ALTO session for CDN interconnection. It
specifies a mean to manage finely the information exchanged over the
ALTO protocol. By reducing the information exposed it increase the
security in general.
Performance:
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.
Despite the information services provide an uCDN ALTO client with
means to control the amount of information downloaded from a dCDN
ALTO server it should protect itself from the download of huge
network map.
Privacy:
The extension has less privacy concerns than the current ALTO
specification because it does not require the support of the End
point Information Services.
Know-how protection: unlike section 8 of [I-D.ietf-alto-protocol], an
ALTO client is not allowed to redistribute information received from
a ALTO server.
8. Acknowledgments
Part of this work is funded by the EU FP7 Envision project.
The authors would like to thank Christian Jacquenet for its feedbacks
on preliminary versions of this document.
9. References
Stephan & Ellouze Expires January 10, 2013 [Page 19]
Internet-Draft CDNi ALTO session July 2012
9.1. Normative References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-11 (work in progress),
March 2012.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-03 (work in progress),
June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.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-alto-server-discovery]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
S. Yongchao, "ALTO Server Discovery",
draft-ietf-alto-server-discovery-03 (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-08 (work in
progress), June 2012.
[I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-08 (work in
progress), June 2012.
[I-D.jenkins-alto-cdn-use-cases]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-03 (work in progress),
June 2012.
[I-D.marocco-alto-next]
Stephan & Ellouze Expires January 10, 2013 [Page 20]
Internet-Draft CDNi ALTO session July 2012
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.pbryan-zyp-json-pointer]
Bryan, P. and K. Zyp, "JSON Pointer",
draft-pbryan-zyp-json-pointer-02 (work in progress),
October 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.
[]
Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
L. Faucheur, "CDNI Footprint Advertisement",
draft-previdi-cdni-footprint-advertisement-01 (work in
progress), March 2012.
[I-D.randriamasy-alto-multi-cost]
Randriamasy, S. and N. Schwan, "Multi-Cost ALTO",
draft-randriamasy-alto-multi-cost-06 (work in progress),
March 2012.
[I-D.schwan-alto-incr-updates]
Schwan, N. and B. Roome, "ALTO Incremental Updates",
draft-schwan-alto-incr-updates-01 (work in progress),
March 2012.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011.
Stephan & Ellouze Expires January 10, 2013 [Page 21]
Internet-Draft CDNi ALTO session July 2012
Authors' Addresses
Emile Stephan
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange.com
Selim Ellouze
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: selim.ellouze@orange.com
Stephan & Ellouze Expires January 10, 2013 [Page 22]