Internet DRAFT - draft-stephan-cdni-alto-session-ext
draft-stephan-cdni-alto-session-ext
Network Working Group E. Stephan
Internet-Draft Orange
Intended status: Standards Track S. Ellouze
Expires: October 19, 2014 H-log
April 17, 2014
ALTO session for CDN Interconnection
draft-stephan-cdni-alto-session-ext-05
Abstract
The selection of a downstream CDN by an upstream CDN is based on
multi-dimensional criteria. 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. The selection of
such a protocol is premature as the WG, and especially the Footprint/
Capabilities Design Team, is currently working on this topic. So
this draft does not promote the usage of the ALTO protocol for CDN
interconnection. It presents the limitations of the current ALTO
protocol in the case it would be selected for CDN interconnection.
It specifies the mechanism for controlling the session initialization
and for limiting the information exchanged. Then it discusses the
need of incremental update and proposes to study the usage of Netconf
/Yang to provide ALTO server with notifications.
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 October 19, 2014.
Stephan & Ellouze Expires October 19, 2014 [Page 1]
Internet-Draft CDNi ALTO session April 2014
Copyright Notice
Copyright (c) 2014 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.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 download with HTTP GET . . . . . . . . . . . . . . . 10
3.3. Initialization of the Session . . . . . . . . . . . . . . 10
3.4. Server Discovery . . . . . . . . . . . . . . . . . . . . 10
3.5. Asynchronous Maps Update . . . . . . . . . . . . . . . . 11
3.6. Information Resource Directory . . . . . . . . . . . . . 11
3.7. PID Stability . . . . . . . . . . . . . . . . . . . . . . 11
3.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
3.9. Performance . . . . . . . . . . . . . . . . . . . . . . . 12
3.10. dCDN Traffic Optimization . . . . . . . . . . . . . . . . 12
4. Specification of the ALTO Session for CDNi . . . . . . . . . 13
4.1. CDNi ALTO session Framework . . . . . . . . . . . . . . . 13
Stephan & Ellouze Expires October 19, 2014 [Page 2]
Internet-Draft CDNi ALTO session April 2014
4.2. View Configuration . . . . . . . . . . . . . . . . . . . 14
4.2.1. PoINT . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. View Configuration Examples . . . . . . . . . . . . . 15
4.3. Session Configuration Parameters . . . . . . . . . . . . 16
4.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
5. Expected Enhancements . . . . . . . . . . . . . . . . . . . . 16
5.1. Asynchronous Updates . . . . . . . . . . . . . . . . . . 16
5.2. Incremental Download of the Updates . . . . . . . . . . . 16
5.2.1. Level of Details of a Map . . . . . . . . . . . . . . 17
5.3. Bi-directional Exchange of Information . . . . . . . . . 17
6. Extension for Asynchronous update . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The selection of a downstream CDN by an upstream CDN is based on
multi-dimensional criteria. 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. The selection of
such a protocol is premature as the WG, and especially the Footprint/
Capabilities Design Team, is currently working on this topic. So
this draft does not promote the usage of the ALTO protocol for CDN
interconnection. It presents the limitations of the current ALTO
protocol in the case it would be selected for CDN interconnection.
It specifies the mechanism for controlling the session initialization
and for limiting the information exchanged. Then it discusses the
need of incremental update and proposes to study the usage of Netconf
/Yang to provide ALTO server with notifications.
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 [RFC6707]. 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 [RFC6770]).
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.
Stephan & Ellouze Expires October 19, 2014 [Page 3]
Internet-Draft CDNi ALTO session April 2014
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. Then in section 5 it discusses different
enhancements of interest to a CDNi ALTO session. Finally in the
section it studies the usage of Netconf/Yang works to provide ALTO
with server notifications.
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
[RFC6707], 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;
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;
Stephan & Ellouze Expires October 19, 2014 [Page 4]
Internet-Draft CDNi ALTO session April 2014
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.
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).
Stephan & Ellouze Expires October 19, 2014 [Page 5]
Internet-Draft CDNi ALTO session April 2014
+----------------------------------+
| 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 October 19, 2014 [Page 6]
Internet-Draft CDNi ALTO session April 2014
+-----------------------------------------+
| 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 October 19, 2014 [Page 7]
Internet-Draft CDNi ALTO session April 2014
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.
Stephan & Ellouze Expires October 19, 2014 [Page 8]
Internet-Draft CDNi ALTO session April 2014
The second Network Map, exposed in the figure 6, is downloadable by
auCDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/
IPv6'.
"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
Stephan & Ellouze Expires October 19, 2014 [Page 9]
Internet-Draft CDNi ALTO session April 2014
of the information received by avoiding downloading unwanted
information in order to enhance the performance of the processing of
the received data.
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 download with HTTP GET
Currently [I-D.ietf-alto-protocol] (section 7.6.2 and 7.6.4.1) allows
two 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].
Stephan & Ellouze Expires October 19, 2014 [Page 10]
Internet-Draft CDNi ALTO session April 2014
3.5. Asynchronous Maps Update
The way the update is implemented is under discussion in the ALTO WG
because there is a strong need to optimize the volume of information
exchanged during the update and the processing of the information.
[I-D.schwan-alto-incr-updates] presents solutions for incremental
download where the auCDN download the diff of the Maps.
Incremental download does not resolve the case where auCDN require to
be informed in real time each time an information changes. In this
case, the adCDN must push the updates on the fly in notifications
towards the auCDN.
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. 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).
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].
Stephan & Ellouze Expires October 19, 2014 [Page 11]
Internet-Draft CDNi ALTO session April 2014
3.8. Scalability
The routing function of an uCDN might not require all the information
that an ALTO server of an dCDN might expose. Furthermore, as per
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
uCDNs 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.9. 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
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.10. 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
Stephan & Ellouze Expires October 19, 2014 [Page 12]
Internet-Draft CDNi ALTO session April 2014
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. CDNi ALTO session Framework
The figure 7 presents the Framework of the ALTO Session for CDN
interconnection:
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 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 session
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.
Stephan & Ellouze Expires October 19, 2014 [Page 13]
Internet-Draft CDNi ALTO session April 2014
The Map Filtering logic and the sessions handler are similar to
the Map Filtering service of the current version of the ALTO
protocol.
.-------------------------------.
| |
| .-----------. .-----------. |
| | Network | | Cost | |
| | Map | | Map | |
| | | | | |
| `-----------' `-----------' |
| |
| .-----------. .-----------. |
| | Sessions | | Map | |
| | Handler | | Filtering | |
| | | | logic | |
| `-----------' `-----------' |
| |
`-------------------------------'
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 a 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.
Stephan & Ellouze Expires October 19, 2014 [Page 14]
Internet-Draft CDNi ALTO session April 2014
This filter produces pre-generated maps. The output of the filter is
a pre-generated network map and an optionnal pre-generated Network
Map Status. The Network Map Status will be specified in a future
version of the document.
4.2.2. View Configuration Examples
Following are the views corresponding to the use case of the section
2.
{
"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
Stephan & Ellouze Expires October 19, 2014 [Page 15]
Internet-Draft CDNi ALTO session April 2014
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 (by phone call, etc) 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 (Server 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, etc).
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;
4.4. Error Handling
Errors are reported using legacy ALTO and HTTP errors.
5. Expected Enhancements
This section discussed enhancements which might be required to
improve a CDNi ALTO session.
5.1. Asynchronous Updates
In the CDNi context, there are tied interactions between an uCDN and
a dCDN interconnected. It requires generally a high level of
synchronization of the Maps of the dCDN and of the uCDN. The update
mechanism based on HTTP download is sub-optimal when the uCDN
requires a real time propagation of the updates. To meet this
requirement the adCDN must notify the update to adCDN.
5.2. Incremental Download of the Updates
Incremental download reduces the volume of the information exchanged.
An update based on the diff of JSON file entries is useful but not
optimized because it requires the re-processing of the whole map from
scratch after each upload. A better approach might consist in
Stephan & Ellouze Expires October 19, 2014 [Page 16]
Internet-Draft CDNi ALTO session April 2014
defining an update mechanism providing the diff for a grouping of
entries such as PIDs. T
The drawback is that incremental download does not provide a high
level of synchronization of the Maps of the dCDN and of the uCDN.
5.2.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 or it may need
the details later.
Furthermore there are cases where an uCDN needs only the list of the
PIDs of dCDN (e.g. 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 configuration
parameters which set the level of detail of the maps.
5.3. Bi-directional Exchange of Information
As Discussed in section 3, there are different aspects requiring a
Bi-directionnal exchange of information including:
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.
6. Extension for Asynchronous update
There are many ways to address the enhancements expected in the
section 5.
One solution consists in upgrading the HTTP session to a bi-
directional protocol and in specifying an asynchronous update
mechanism. Netconf [RFC6241] and YANG [RFC6020] works fill this gap.
Netconf already include the specification of notifications [RFC6470]
Stephan & Ellouze Expires October 19, 2014 [Page 17]
Internet-Draft CDNi ALTO session April 2014
based on subscriptions [RFC5277]. Maps update information can be
inserted into NETCONF notifications or updated as YANG or JSON patch
using the method being specified by the NETCONF WG in the draft
[I-D.ietf-netconf-yang-patch].
7. IANA Considerations
none.
8. 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.
9. Acknowledgments
The authors would like to thank Christian Jacquenet for its feedbacks
on preliminary versions of this document.
10. References
10.1. Normative References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-27 (work in progress), March 2014.
Stephan & Ellouze Expires October 19, 2014 [Page 18]
Internet-Draft CDNi ALTO session April 2014
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012.
10.2. Informative References
[I-D.ietf-alto-deployments]
Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf,
"ALTO Deployment Considerations", draft-ietf-alto-
deployments-09 (work in progress), February 2014.
[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-10 (work in progress), September 2013.
[I-D.ietf-appsawg-json-patch]
Bryan, P. and M. Nottingham, "JSON Patch", draft-ietf-
appsawg-json-patch-10 (work in progress), January 2013.
[I-D.ietf-netconf-yang-patch]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"YANG Patch Media Type", draft-ietf-netconf-yang-patch-00
(work in progress), March 2014.
[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]
Marocco, E. and V. Gurbani, "Extending the Application-
Layer Traffic Optimization (ALTO) Protocol", draft-
marocco-alto-next-00 (work in progress), January 2012.
Stephan & Ellouze Expires October 19, 2014 [Page 19]
Internet-Draft CDNi ALTO session April 2014
[I-D.previdi-cdni-footprint-advertisement]
Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
L. Faucheur, "CDNI Footprint Advertisement", draft-
previdi-cdni-footprint-advertisement-02 (work in
progress), September 2012.
[I-D.randriamasy-alto-multi-cost]
Randriamasy, S., Roome, B., and N. Schwan, "Multi-Cost
ALTO", draft-randriamasy-alto-multi-cost-07 (work in
progress), October 2012.
[I-D.schwan-alto-incr-updates]
Schwan, N. and B. Roome, "ALTO Incremental Updates",
draft-schwan-alto-incr-updates-02 (work in progress), July
2012.
[NETCONF_YANG_TUT]
"Network Conguration Management with NETCONF and YANG",
<http://cnds.eecs.jacobs-university.de/slides/
2012-ietf-84-netconf-yang.pdf>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6244] Shafer, P., "An Architecture for Network Management Using
NETCONF and YANG", RFC 6244, June 2011.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, February 2012.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
Stephan & Ellouze Expires October 19, 2014 [Page 20]
Internet-Draft CDNi ALTO session April 2014
Authors' Addresses
Emile Stephan
Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange.com
Selim Ellouze
H-log
5 rue Guy Moquet
Orsay F-91400
France
Email: selim.ellouze@h-log.fr
Stephan & Ellouze Expires October 19, 2014 [Page 21]
