draft-seedorf-cdni-request-routing-alto-09.txt   draft-seedorf-cdni-request-routing-alto-10.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft HFT Stuttgart - Univ. of Applied Sciences Internet-Draft HFT Stuttgart - Univ. of Applied Sciences
Intended status: Standards Track Y. Yang Intended status: Standards Track Y. Yang
Expires: January 3, 2018 Tongji/Yale Expires: January 3, 2018 Tongji/Yale
K. Ma
Ericsson
J. Peterson J. Peterson
Neustar Neustar
July 2, 2017 July 2, 2017
Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Content Delivery Network Interconnection (CDNI) Request Routing: CDNI
Footprint and Capabilities Advertisement using ALTO Footprint and Capabilities Advertisement using ALTO
draft-seedorf-cdni-request-routing-alto-09 draft-seedorf-cdni-request-routing-alto-10
Abstract Abstract
Network Service Providers (NSPs) are currently considering to deploy The Content Delivery Networks Interconnection (CDNI) WG is defining a
Content Delivery Networks (CDNs) within their networks. As a set of protocols to inter-connect CDNs, to achieve multiple goals
consequence of this development, there is a need for interconnecting such as extending the reach of a given CDN to areas that are not
these local CDNs. The necessary interfaces for inter-connecting CDNs covered by that particular CDN. One componet that is needed to
are currently being defined in the Content Delivery Networks achieve the goal of CDNI is the CDNI Request Routing Footprint &
Interconnection (CDNI) WG. This document focuses on the CDNI Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has
Footprint & Capabilities Advertisement interface (FCI). defined precisely the semantics of FCI and provided guidelines on the
Specifically, this document specifies a new Application Layer Traffic FCI protocol, but the exact protocol is explicitly outside the scope
Optimization (ALTO) service to facilitate Footprint & Capabilities of that document. In this document, we define an FCI protocol using
Advertisement in a CDNI context. the Application Layer Traffic Optimization (ALTO) protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 18 skipping to change at page 2, line 23
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ALTO within CDNI Request Routing . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Assumptions and High-Level Design Considerations . . . . . . 4 2.1. Semantics of FCI Advertisment . . . . . . . . . . . . . . 4
3.1. General Assumptions and Considerations . . . . . . . . . 4 2.2. ALTO Background and Benefits . . . . . . . . . . . . . . 5
3.2. Semantics for Footprint/Capabilities Advertisment . . . . 5 3. CDNI FCI ALTO Service . . . . . . . . . . . . . . . . . . . . 7
3.3. Advantages of using ALTO as the CDNI FCI protocol . . . . 7 3.1. Server Response Encoding . . . . . . . . . . . . . . . . 8
3.4. Selection of a Downstream CDN with ALTO . . . . . . . . . 7 3.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 8
4. CDNI FCI ALTO Service . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Meta Information . . . . . . . . . . . . . . . . . . 8
4.1. Server Response Encoding . . . . . . . . . . . . . . . . 8 3.1.3. Data Information . . . . . . . . . . . . . . . . . . 8
4.1.1. CDNI FCI Map . . . . . . . . . . . . . . . . . . . . 8 3.2. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Meta Information . . . . . . . . . . . . . . . . . . 8 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3. Data Information . . . . . . . . . . . . . . . . . . 8 3.3.1. Basic Example . . . . . . . . . . . . . . . . . . . . 8
4.2. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Incremental FCI Update Example . . . . . . . . . . . 9
4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3. FCI Using ALTO Network Map Example . . . . . . . . . 9
5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many Network Service Providers (NSPs) are currently considering or Many Network Service Providers (NSPs) are currently considering or
have already started to deploy Content Delivery Networks (CDNs) have already started to deploy Content Delivery Networks (CDNs)
within their networks. As a consequence of this development, there within their networks. As a consequence of this development, there
is a need for interconnecting these local CDNs. Content Delivery is a need for interconnecting these local CDNs. Content Delivery
Networks Interconnection (CDNI) has the goal of standardizing Networks Interconnection (CDNI) has the goal of standardizing
protocols to enable such interconnection of CDNs [RFC6707]. protocols to enable such interconnection of CDNs [RFC6707].
The CDNI problem statement [RFC6707] envisions four interfaces to be The CDNI problem statement [RFC6707] defines four interfaces to be
standardized within the IETF for CDN interconnection: standardized within the IETF for CDN interconnection:
o CDNI Request Routing Interface o CDNI Request Routing Interface
o CDNI Metadata Interface o CDNI Metadata Interface
o CDNI Logging Interface o CDNI Logging Interface
o CDNI Control Interface o CDNI Control Interface
This document focuses solely on the CDNI Request Routing Interface,
which can be further divided into two interfaces (see [RFC6707] for a
detailed description): the CDNI Request Routing Redirection interface
(RI), and the CDNI Footprint & Capabilities Advertisement interface
(FCI). This document specifies a new Application Layer Traffic
Optimization (ALTO) [RFC7285] service called 'CDNI Footprint &
Capabilities Advertisement Service'. This service is used to
transport CDNI FCI JSON objects, which are defined in a separate
document in [RFC8008].
Throughout this document, we use the terminology for CDNI defined in
[RFC6707].
2. ALTO within CDNI Request Routing
The main purpose of the CDNI Request Routing Interface is described The main purpose of the CDNI Request Routing Interface is described
in [RFC6707] as follows: "The CDNI Request Routing interface enables in [RFC6707] as follows: "The CDNI Request Routing interface enables
a Request Routing function in an Upstream CDN to query a Request a Request Routing function in an Upstream CDN to query a Request
Routing function in a Downstream CDN to determine if the Downstream Routing function in a Downstream CDN to determine if the Downstream
CDN is able (and willing) to accept the delegated Content Request. CDN is able (and willing) to accept the delegated Content Request.
It also allows the Downstream CDN to control what should be returned It also allows the Downstream CDN to control what should be returned
to the User Agent in the redirection message by the upstream Request to the User Agent in the redirection message by the upstream Request
Routing function." On a high level, the scope of the CDNI Request Routing function." On a high level, the scope of the CDNI Request
Routing Interface therefore contains two main tasks: Routing Interface therefore contains two main tasks:
o A) Determining if the downstream CDN is willing to accept a o determining if the downstream CDN is willing to accept a delegated
delegated content request content request;
o B) Redirecting the content request coming from an upstream CDN to
the proper entry point or entity in the downstream CDN
More precisely, in [RFC7336] the request routing interface is broadly
divided into two functionalities:
o 1) the asynchronous advertisement of footprint and capabilities by
a dCDN that allows a uCDN to decide whether to redirect particular
user requests to that dCDN (the CDNI FCI)
o 2) the synchronous operation of actually redirecting a user
request (the CDNI RI)
Application Layer Traffic Optimization (ALTO) [RFC7285] is an
approach for guiding the resource provider selection process in
distributed applications that can choose among several candidate
resources providers to retrieve a given resource. By conveying
network layer (topology) information, an ALTO server can provide
important information to "guide" the resource provider selection
process in distributed applications. Usually, it is assumed that an
ALTO server conveys information these applications cannot measure
themselves [RFC5693].
Originally, ALTO was motivated by the huge amount of cross-ISP
traffic generated by P2P applications [RFC5693]. Recently, however,
ALTO is also being considered for improving the request routing in
CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also
been proposed to use ALTO for selecting an entry-point in a
downstream NSP's network (see section 3.4 "CDN delivering Over-The-
Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also,
the CDNI problem statement explicitly mentions ALTO as a candidate
protocol for "algorithms for selection of CDN or Surrogate by
Request-Routing systems" [RFC6707].
3. Assumptions and High-Level Design Considerations o redirecting the content request coming from an upstream CDN to the
proper entry point or entity in the downstream CDN.
In this section we list some assumptions and design issues to be Correspondingly, the request routing interface is broadly divided
considered when using ALTO for the CDNI Footprint and Capabilities into two functionalities:
Advertisement interface.
3.1. General Assumptions and Considerations o CDNI FCI: the advertisement from a dCDN to a uCDN or a query from
a uCDN to a dCDN for the uCDN to decide whether to redirect
particular user requests to that dCDN;
Below we list some general assumptions and considerations: o CDNI RI: the synchronous operation of actually redirecting a user
request.
o As explicitly being out-of-scope for CDNI [RFC6707], it is assumed This document focuses solely on CDNI FCI, with a goal to specify a
that ingestion of content or acquiring content across CDNs is not new Application Layer Traffic Optimization (ALTO) [RFC7285] service
part of request routing as considered within CDNI standardization called 'CDNI/FCI Service', to transport and update CDNI FCI JSON
work. The focus of using ALTO (as considered in this document) is objects, which are defined in a separate document in [RFC8008].
hence on request routing only, assuming that the content (desired
by the end user) is available in the downstream CDN (or can be
aquired by the downstream CDN by some means).
o Federation Model: "Footprint and Capabilities Advertisement" and Throughout this document, we use the terminology for CDNI defined in
in general CDN request routing depends on the federation model [RFC6707] and [RFC8008].
among the CDN providers. Designing a suitable solution thus
depends on whether a solution is needed for different settings,
where CDNs consist of both NSP CDNs (serving individual ASes) and
general, traditional CDNs (such as Akamai). We assume that CDNI
is not designed for a setting where only NSP CDNs each serve a
single AS only.
o In this document, it is assumed that the upstream CDN (uCDN) makes 2. Background
the decision on selecting a downstream CDN, based on information
that each downstream CDN has made available to the upstream CDN.
Further, we assume that in principle more than one dCDN may be
suitable for a given end-user request (i.e. different dCDNs may
claim "overlapping" footprints). The uCDN hence potentially has
to select among several candidate downstream CDNs for a given end
user request.
o It is not clear what kind(s) of business, contract, and The design of CDNI FCI transport using ALTO depends on understanding
operational relationships two peering CDNs may form. For the of both FCI semantics and ALTO. Hence, we start with a review of
Internet, we see provider-customer and peering as two main both.
relations; providers may use different charging models (e.g.,
95-percentile, total volume) and may provide different SLAs.
Given such unknown characteristics of CDN peering business
agreements, we should design the protocol to support as much
diverse potential business and operational models as possible.
3.2. Semantics for Footprint/Capabilities Advertisment 2.1. Semantics of FCI Advertisment
The CDNI document on "Footprint and Capabilities Semantics" [RFC8008] The CDNI document on "Footprint and Capabilities Semantics" [RFC8008]
defines the semantics for the CDNI FCI. It thus provides guidance on defines the semantics for the CDNI FCI. It thus provides guidance on
what Footprint and Capabilities mean in a CDNI context and how a what Footprint and Capabilities mean in a CDNI context and how a
protocol solution should in principle look like. Here we briefly protocol solution should in principle look like. The definitions in
summarize the key points of the semantics of Footprint and [RFC8008] depend on [RFC8006]. Here we briefly summarize key related
Capabilities (for a detailed discussion, the reader is referred to points of [RFC8008] and [RFC8006]. For a detailed discussion, the
[RFC8008]): reader is referred to the RFCs.
o Often, footprint and capabilities are tied together and cannot be o Footprint and capabilities are tied together and cannot be
interpreted independently from each other. In such cases, i.e. interpreted independently from each other. In such cases, i.e.
where capabilities must be expressed on a per footprint basis, it where capabilities must be expressed on a per footprint basis, it
may be beneficial to combine footprint and capabilities may be beneficial to combine footprint and capabilities
advertisement. advertisement. [RFC8008] integrates footprint and capabilities
with an approach of "capabilities with footprint restrictions".
o Given that a large part of Footprint and Capabilities o Given that a large part of Footprint and Capabilities
Advertisement will actually happen in contractual agreements, the Advertisement will actually happen in contractual agreements, the
semantics of CDNI Footprint and Capabilities advertisement refer semantics of CDNI Footprint and Capabilities advertisement refer
to answering the following question: what exactly still needs to to answering the following question: what exactly still needs to
be advertised by the CDNI FCI? For instance, updates about be advertised by the CDNI FCI? For instance, updates about
temporal failures of part of a footprint can be useful information temporal failures of part of a footprint can be useful information
to convey via the CDNI request routing interface. Such to convey via the CDNI request routing interface. Such
information would provide updates on information previously agreed information would provide updates on information previously agreed
in contracts between the participating CDNs. In other words, the in contracts between the participating CDNs. In other words, the
CDNI FCI is a means for a dCDN to provide changes/updates CDNI FCI is a means for a dCDN to provide changes/updates
regarding a footprint and/or capabilities it has prior agreed to regarding a footprint and/or capabilities it has prior agreed to
serve in a contract with a uCDN. serve in a contract with a uCDN. Hence, server push and
incremental encoding will be necessary techniques.
o It seems clear that "coverage/reachability" types of footprint o Multiple types of footprints are defined in [RFC8006]:
must be supported within CDNI. The following such types of
footprint are mandatory and must be supported by the CDNI FCI:
* List of ISO Country Codes * List of ISO Country Codes
* List of AS numbers * List of AS numbers
* Set of IP-prefixes * Set of IP-prefixes
A 'set of IP-prefixes' must be able to contain full IP addresses, A 'set of IP-prefixes' must be able to contain full IP addresses,
i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes
with an arbitrary prefix length. There must also be support for with an arbitrary prefix length. There must also be support for
skipping to change at page 6, line 38 skipping to change at page 5, line 24
respectively). The CDNI specifications do not define how a given respectively). The CDNI specifications do not define how a given
uCDN determines what address ranges are in a particular ASN. uCDN determines what address ranges are in a particular ASN.
Similarly, for country codes a uCDN should only consider the dCDN Similarly, for country codes a uCDN should only consider the dCDN
a candidate if it covers the country of the request routing a candidate if it covers the country of the request routing
source. The CDNI specifications do not define how a given uCDN source. The CDNI specifications do not define how a given uCDN
determines the country of the request routing source. Multiple determines the country of the request routing source. Multiple
footprint constraints are additive, i.e. the advertisement of footprint constraints are additive, i.e. the advertisement of
different types of footprint narrows the dCDN candidacy different types of footprint narrows the dCDN candidacy
cumulatively. cumulatively.
o The following capabilities seem useful as 'base' capabilities, o The following capabilities are defined as 'base' capabilities,
i.e. ones that are needed in any case and therefore constitute i.e. ones that are needed in any case and therefore constitute
mandatory capabilities to be supported by the CDNI FCI: mandatory capabilities to be supported by the CDNI FCI:
* Delivery Protocol (e.g., HTTP vs. RTMP) * Delivery Protocol (e.g., HTTP vs. RTMP)
* Acquisition Protocol (for aquiring content from a uCDN) * Acquisition Protocol (for acquiring content from a uCDN)
* Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [RFC7336]) discussed in [RFC7336])
* Capabilities related to CDNI Logging (e.g., supported logging * Capabilities related to CDNI Logging (e.g., supported logging
mechanisms) mechanisms)
* Capabilities related to CDNI Metadata (e.g., authorization * Capabilities related to CDNI Metadata (e.g., authorization
algorithms or support for proprietary vendor metadata) algorithms or support for proprietary vendor metadata)
3.3. Advantages of using ALTO as the CDNI FCI protocol 2.2. ALTO Background and Benefits
Application Layer Traffic Optimization (ALTO) [RFC7285] is an
approach for guiding the resource provider selection process in
distributed applications that can choose among several candidate
resources providers to retrieve a given resource. By conveying
network layer (topology) information, an ALTO server can provide
important information to "guide" the resource provider selection
process in distributed applications. Usually, it is assumed that an
ALTO server conveys information these applications cannot measure
themselves [RFC5693].
Originally, ALTO was motivated by the huge amount of cross-ISP
traffic generated by P2P applications [RFC5693]. Recently, however,
ALTO is also being considered for improving the request routing in
CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also
been proposed to use ALTO for selecting an entry-point in a
downstream NSP's network (see section 3.4 "CDN delivering Over-The-
Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also,
the CDNI problem statement explicitly mentions ALTO as a candidate
protocol for "algorithms for selection of CDN or Surrogate by
Request-Routing systems" [RFC6707].
The following reasons make ALTO a suitable candidate protocol for The following reasons make ALTO a suitable candidate protocol for
downstream CDN selection as part of CDNI request routing and in downstream CDN selection as part of CDNI request routing and in
particular for an FCI protocol: particular for an FCI protocol:
o CDN request routing is done at the application layer. ALTO is a o CDN request routing is done at the application layer. ALTO is a
protocol specifically designed to improve application layer protocol specifically designed to improve application layer
traffic (and application layer connections among hosts on the traffic (and application layer connections among hosts on the
Internet) by providing additonal information to applications that Internet) by providing additional information to applications that
these applications could not easily retrieve themselves. For these applications could not easily retrieve themselves. For
CDNI, this is exactly the case: a uCDN wants to improve CDNI, this is exactly the case: a uCDN wants to improve
application layer CDN request routing by using dedicated application layer CDN request routing by using dedicated
information (provided by a dCDN) that the uCDN could not easily information (provided by a dCDN) that the uCDN could not easily
obtain otherwise. obtain otherwise.
o The semantics of an ALTO network map are an exact match for the o The semantics of an ALTO network map are an exact match for the
needed information to convey a footprint by a downstream CDN, in needed information to convey a footprint by a downstream CDN, in
particular if such a footprint is being expressed by IP-prefix particular if such a footprint is being expressed by IP-prefix
ranges. ranges.
o Security: ALTO maps can be signed and hence provide inherent o Security: ALTO maps can be signed and hence provide inherent
integrity protection (see Section 6) integrity protection (see Section 4)
o RESTful-Design: The ALTO protocol has undergone extensive o RESTful-Design: The ALTO protocol has undergone extensive
revisions in order to provide a RESTful design regarding the revisions in order to provide a RESTful design regarding the
client-server interaction specified by the protocol. A CDNI FCI client-server interaction specified by the protocol. A CDNI FCI
interface based on ALTO would inherit this RESTful design. interface based on ALTO would inherit this RESTful design.
o Error-handling: The ALTO protocol has undergone extensive o Error-handling: The ALTO protocol has undergone extensive
revisions in order to provide sophisticated error-handling, revisions in order to provide sophisticated error-handling, in
inparticular regarding unexpected cases. A CDNI FCI interface particular regarding unexpected cases. A CDNI FCI interface based
based on ALTO would inherit this thought-through and mature error- on ALTO would inherit this thought-through and mature error-
handling. handling.
o Filtered network map: The ALTO Map Filtering Service (see o Filtered network map: The ALTO Map Filtering Service (see
[RFC7285] for details) would allow a uCDN to query only for parts [RFC7285] for details) would allow a uCDN to query only for parts
of an ALTO map. of an ALTO map.
3.4. Selection of a Downstream CDN with ALTO o Server-initiated Notifications and Incremental Updates: In case
the footprint or the capabilities of a downstream CDN change
abruptly (i.e. unexpectedly from the perspective of an upstream
CDN), server initiated notifications would enable a dCDN to
directly inform an upstream CDN about such changes. Consider the
case where - due to failure - part of the footprint of the dCDN is
not functioning, i.e. the CDN cannot serve content to such clients
with reasonable QoS. Without server-initiated notifications, the
uCDN might still use a very recent network and cost map from dCDN,
and therefore redirect request to dCDN which it cannot serve.
Similarly, the possibility for incremental updates would enable
efficient conveyance of the aforementioned (or similar) status
changes by the dCDN to the uCDN. The newest design of ALTO
supports server pushed incremental updates
[I-D.ietf-alto-incr-update-sse].
Under the considerations stated in Section 3, ALTO can help the o Content Availability on Hosts: A dCDN might want to express CDN
upstream CDN provider to select a proper downstream CDN provider for capabilities in terms of certain content types (e.g. codecs/
a given end user request as follows: Each downstream CDN provider formats, or content from certain content providers). The new
hosts an ALTO server which provides ALTO services which convey CDNI endpoint property for ALTO would enable a dCDN to make available
FCI information to an ALTO client at the upstream CDN provider. such information to an upstream CDN. This would enable a uCDN to
determine if a given dCDN actually has the capabilities for a
given request with respect to the type of content requested.
4. CDNI FCI ALTO Service o Resource Availability on Hosts or Links: The capabilities on links
(e.g. maximum bandwidth) or caches (e.g. average load) might be
useful information for an upstream CDN for optimized downstream
CDN selection. For instance, if a uCDN receives a streaming
request for content with a certain bitrate, it needs to know if it
is likely that a dCDN can fulfill such stringent application-level
requirements (i.e. can be expected to have enough consistent
bandwidth) before it redirects the request. In general, if ALTO
could convey such information via new endpoint properties, it
would enable more sophisticated means for downstream CDN selection
with ALTO.
3. CDNI FCI ALTO Service
The ALTO protocol is based on an ALTO Information Service Framework The ALTO protocol is based on an ALTO Information Service Framework
which consists of several services, where all ALTO services are which consists of several services, where all ALTO services are
'provided through a common transport protocol, messaging structure 'provided through a common transport protocol, messaging structure
and encoding, and transaction model' [RFC7285]. The ALTO protocol and encoding, and transaction model' [RFC7285]. The ALTO protocol
specification [RFC7285] defines several such services, e.g. the ALTO specification [RFC7285] defines several such services, e.g. the ALTO
map service. map service.
This document defines a new ALTO Service called 'CDNI Footprint & This document defines a new ALTO Service called 'CDNI Footprint &
Capabilities Advertisement Service' which conveys JSON objects of Capabilities Advertisement Service' which conveys JSON objects of
media type 'application/alto-fcimap+json'. This media type and JSON media type 'application/cdni'. This media type and JSON object
object format is defined in [RFC8008]; this document specifies how to format is defined in [RFC8006] and [RFC8008]; this document specifies
transport such JSON objects via the ALTO protocol with the ALTO 'CDNI how to transport such JSON objects via the ALTO protocol with the
Footprint & Capabilities Advertisement Service'. ALTO 'CDNI Footprint & Capabilities Advertisement Service'.
4.1. Server Response Encoding 3.1. Server Response Encoding
4.1.1. CDNI FCI Map 3.1.1. Media Type
The media type of the CDNI FCI Map is 'application/alto-cdni- The media type of the CDNI FCI Map is 'application/cdni'.
fcimap+json'. The HTTP Method, Accept Input Parameters,
Capabilities, Uses, and Response of the CDNI FCI Map are specified in
[I-D.ma-cdni-capabilities].
4.1.2. Meta Information 3.1.2. Meta Information
The 'meta' field of a FCIMapData response MUST include 'vtag', which The 'meta' field of a FCI response MUST include 'vtag', which is an
is an ALTO Version Tag of the retrieved FCIMapData according to ALTO Version Tag of the retrieved FCIMapData according to [RFC7285]
[RFC7285] (Section 10.3.). It thus contains a 'resource-id' (Section 10.3.). It thus contains a 'resource-id' attribute, and a
attribute, and a 'tag' is an identifier string. 'tag' is an identifier string.
4.1.3. Data Information 3.1.3. Data Information
The data component of a CDNI FCI Map resource is named 'fcimap' which The data component of a CDNI FCI resource is named 'cdni-fcimap'
is a JSON object of type FCIMapData. This JSON object of type which is a JSON object defined by [RFC8008]. This JSON object is
FCIMapData is derived from ResponseEntityBase as specified in the derived from ResponseEntityBase as specified in the ALTO protocol
ALTO protocol [RFC7285] (Section 8.4.) and specified in [RFC7285] (Section 8.4.).
[I-D.ma-cdni-capabilities].
4.2. Protocol Errors 3.2. Protocol Errors
Protocol errors are handled as specified in the ALTO protocol Protocol errors are handled as specified in the ALTO protocol
[RFC7285] (Section 8.5.). [RFC7285] (Section 8.5.).
4.3. Example 3.3. Examples
The following example shows an CDNI FCI Map as in 3.3.1. Basic Example
[I-D.ma-cdni-capabilities], however with meta-information as defined
in Section 4.1.2 of this document. The following example shows an CDNI FCI response as in [RFC8008],
however with meta-information as defined in Section 3.1.2 of this
document.
GET /fcimap HTTP/1.1 GET /fcimap HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json Accept: application/cdni,application/alto-error+json
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 439 Content-Length: 439
Content-Type: application/alto-fcimap+json Content-Type: application/cdni
{ {
"meta" : { "meta" : {
"vtag": { "vtag": {
"resource-id": "my-default-fcimap", "resource-id": "my-default-fcimap",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
} }
}, },
"fcimap": [ "cdni-fcimap": {
{ "name": "delivery_protocol", "capabilities": [
"values": [ {
"HTTP", "capability-type": "FCI.DeliveryProtocol",
"RTSP", "capability-value": {
"MMS" "delivery-protocols": [
] "http/1.1",
},
{ "name": "delivery_protocol",
"values": [
"RTMP",
"HTTPS"
],
"footprint": [
{ "type": "IPv4CIDR",
"values": [
"10.1.0.0/16",
"10.10.10.0/24"
] ]
} },
] "footprints": [
} <Footprint objects>
] ]
}
]
}
} }
5. Useful ALTO extensions for CDNI Request Routing 3.3.2. Incremental FCI Update Example
It is envisioned that yet-to-be-defined ALTO extensions will be
standardized that make the ALTO protocol more suitable and useful for
applications other than the originally considered P2P use case
[I-D.marocco-alto-next]. Some of these extensions to the ALTO
protocol would be useful for ALTO to be used as a protocol within
CDNI request routing, and in particular within the "Footprint and
Capabilities Advertisment" part of the CDNI request routing
interface.
The following proposed extensions to ALTO would be beneficial to
facilitate CDNI request routing with ALTO as outlined in Section 3.4:
o Server-initiated Notifications and Incremental Updates: In case
the footprint or the capabilities of a downstream CDN change
abruptly (i.e. unexpectedly from the perspective of an upstream
CDN), server initiated notifications would enable a dCDN to
directly inform an upstream CDN about such changes. Consider the
case where - due to failure - part of the footprint of the dCDN is
not functioning, i.e. the CDN cannot serve content to such clients
with reasonable QoS. Without server-initiated notifications, the
uCDN might still use a very recent network and cost map from dCDN,
and therefore redirect request to dCDN which it cannot serve.
Similarly, the possibility for incremental updates would enable
efficient conveyance of the aforementioned (or similar) status
changes by the dCDN to the uCDN. A proposal for server-initiated
ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion
of incremental ALTO updates can be found in
[I-D.schwan-alto-incr-updates].
o Content Availability on Hosts: A dCDN might want to express CDN
capabilties in terms of certain content types (e.g. codecs/
formats, or content from certain content providers). A new
endpoint property for ALTO that would be able to express such
"content availability" would enable a dCDN to make available such
information to an upstream CDN. This would enable a uCDN to
determine if a given dCDN actually has the capabilities for a
given request with respect to the type of content requested.
o Resource Availability on Hosts or Links: The capabilities on links 3.3.3. FCI Using ALTO Network Map Example
(e.g. maximum bandwidth) or caches (e.g. average load) might be
useful information for an upstream CDN for optimized dowmstream
CDN selection. For instance, if a uCDN receives a streaming
request for content with a certain bitrate, it needs to know if it
is likely that a dCDN can fulfill such stringent application-level
requirements (i.e. can be expected to have enough consistent
bandwidth) before it redirects the request. In general, if ALTO
could convey such information via new endpoint properties, it
would enable more sophisticated means for downstream CDN selection
with ALTO.
6. Security Considerations 4. Security Considerations
One important security consideration is the proper authentication of One important security consideration is the proper authentication of
advertisement information provided by a downstream CDN. The ALTO advertisement information provided by a downstream CDN. The ALTO
protocol provides a specification for a signature of ALTO information protocol provides a specification for a signature of ALTO information
(see 8.2.2. of [RFC7285]. ALTO thus provides a proper means for (see 8.2.2. of [RFC7285]. ALTO thus provides a proper means for
protecting the integrity of FCI information. protecting the integrity of FCI information.
More Security Considerations will be discussed in a future version of More Security Considerations will be discussed in a future version of
this document. this document.
7. Acknowledgements 5. Acknowledgements
The authors would like to thank Kevin Ma, Daryl Malas, and Matt The authors would like to thank Kevin Ma, Daryl Malas, and Matt
Caulfield for their timely reviews and invaluable comments. Caulfield for their timely reviews and invaluable comments.
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions (NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the GreenICN project, endorsements, either expressed or implied, of the GreenICN project,
the European Commission, or NICT. the European Commission, or NICT.
8. References 6. References
8.1. Normative References 6.1. Normative References
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009, DOI 10.17487/RFC5693, October 2009,
<http://www.rfc-editor.org/info/rfc5693>. <http://www.rfc-editor.org/info/rfc5693>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <http://www.rfc-editor.org/info/rfc6707>.
skipping to change at page 12, line 26 skipping to change at page 11, line 10
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>. August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337, Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <http://www.rfc-editor.org/info/rfc7337>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<http://www.rfc-editor.org/info/rfc8006>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<http://www.rfc-editor.org/info/rfc8008>. <http://www.rfc-editor.org/info/rfc8008>.
8.2. Informative References 6.2. Informative References
[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.marocco-alto-ws]
Marocco, E. and J. Seedorf, "WebSocket-based server-to-
client notifications for the Application-Layer Traffic
Optimization (ALTO) Protocol", draft-marocco-alto-ws-02
(work in progress), February 2014.
[I-D.schwan-alto-incr-updates] [I-D.ietf-alto-incr-update-sse]
Schwan, N. and B. Roome, "ALTO Incremental Updates", Roome, W. and Y. Yang, "ALTO Incremental Updates Using
draft-schwan-alto-incr-updates-02 (work in progress), July Server-Sent Events (SSE)", draft-ietf-alto-incr-update-
2012. sse-07 (work in progress), July 2017.
[I-D.jenkins-alto-cdn-use-cases] [I-D.jenkins-alto-cdn-use-cases]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs", draft- S. Previdi, "Use Cases for ALTO within CDNs", draft-
jenkins-alto-cdn-use-cases-03 (work in progress), June jenkins-alto-cdn-use-cases-03 (work in progress), June
2012. 2012.
[I-D.ma-cdni-capabilities] [I-D.ma-cdni-capabilities]
Ma, K. and J. Seedorf, "CDNI Footprint & Capabilities Ma, K. and J. Seedorf, "CDNI Footprint & Capabilities
Advertisement Interface", draft-ma-cdni-capabilities-09 Advertisement Interface", draft-ma-cdni-capabilities-09
skipping to change at page 13, line 26 skipping to change at page 12, line 4
Authors' Addresses Authors' Addresses
Jan Seedorf Jan Seedorf
HFT Stuttgart - Univ. of Applied Sciences HFT Stuttgart - Univ. of Applied Sciences
Schellingstrasse 24 Schellingstrasse 24
Stuttgart 70174 Stuttgart 70174
Germany Germany
Phone: +49-0711-8926-2801 Phone: +49-0711-8926-2801
Email: jan.seedorf@hft-stuttgart.de Email: jan.seedorf@hft-stuttgart.de
Y.R. Yang Y.R. Yang
Tongji/Yale University Tongji/Yale University
51 Prospect Street 51 Prospect Street
New Haven, CT 06511 New Haven, CT 06511
United States of America United States of America
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
URI: http://www.cs.yale.edu/~yry/ URI: http://www.cs.yale.edu/~yry/
Kevin J. Ma
Ericsson
43 Nagog Park
Acton, MA 01720
United States of America
Phone: +1-978-844-5100
Email: kevin.j.ma@ericsson.com
Jon Peterson Jon Peterson
NeuStar NeuStar
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
United States of America United States of America
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 57 change blocks. 
267 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/