Network Working Group K. Ma
Internet-Draft Ericsson
Intended status: Standards Track J. Seedorf
Expires: September 9, 2015 NEC
March 8, 2015
CDNI Footprint & Capabilities Advertisement Interface
draft-ma-cdni-capabilities-07
Abstract
Content Distribution Network Interconnection (CDNI) is predicated on
the ability of downstream CDNs (dCDNs) to handle end-user requests in
a functionally equivalent manner to the upstream CDN (uCDN). The
uCDN must be able to assess the ability of the dCDN to handle
individual requests. The CDNI Footprint & Capabilities Advertisement
interface (FCI) is provided for the advertisement of capabilities and
the footprints to which they apply by the dCDN to the uCDN. This
document describes an approach to implementing the CDNI FCI.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2015.
Ma & Seedorf Expires September 9, 2015 [Page 1]
Internet-Draft CDNI FCI March 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDNI FCI Capability Advertisement . . . . . . . . . . . . . . 4
2.1. CDNI FCI Capability Initialization . . . . . . . . . . . 5
3. CDNI FCI Capabilities Service . . . . . . . . . . . . . . . . 5
3.1. CDNI FCI Map . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 6
3.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 6
3.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 6
3.1.7. CDNI FCI Capabilities . . . . . . . . . . . . . . . . 7
3.1.7.1. Delivery Protocol . . . . . . . . . . . . . . . . 7
3.1.7.2. Acquisition Protocol . . . . . . . . . . . . . . 8
3.1.7.3. Redirection Mode . . . . . . . . . . . . . . . . 10
3.1.7.4. Logging Capabilities . . . . . . . . . . . . . . 13
3.1.7.5. Metadata Capabilities . . . . . . . . . . . . . . 13
4. CDNI FCI Capabilities Filtering Service . . . . . . . . . . . 13
4.1. Filtered CDNI FCI Map . . . . . . . . . . . . . . . . . . 13
4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13
4.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 13
4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 13
4.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 14
4.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 14
5. Footprint via ALTO Network Map . . . . . . . . . . . . . . . 14
5.1. ALTO Network Maps . . . . . . . . . . . . . . . . . . . . 14
5.2. Example ALTO Network Map for CDNI FCI Footprint . . . . . 14
5.3. Example of ALTO Network Map Footprint in FCI Map . . . . 15
Ma & Seedorf Expires September 9, 2015 [Page 2]
Internet-Draft CDNI FCI March 2015
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 19
A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 19
A.2. Internal Request Router Aggregation . . . . . . . . . . . 20
A.3. Internal Capability Aggregation . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
The need for footprint and capabilities advertisement in CDNI is
described in the CDNI requirements document [RFC7337]. Requirements
FCI-1 and FCI-2 describe the need to allow dCDNs to communicate
capabilities to the uCDN. Requirement FCI-3 describes how a uCDN may
aggregate the footprint and capabilities information for all cascaded
dCDNs and use the aggregated information in advertisements to CDNs
further upstream. This concept of aggregation can apply to both
organizationally different dCDNs (e.g., other CDN providers, or
different business units within a larger organization) or logical
entities within the same CDN (e.g., using multiple request routers
for scalability reasons, to segregate surrogates based on specific
protocol support, or to segregate surrogates based on software
version or feature level, etc.).
Appendix A contains more detailed descriptions of different footprint
and capabilities management scenarios, but it is important to note
that it is the ability of the dCDN to service each request in a
functionally equivalent manner as the uCDN that is important, not the
physical layout of resources through which it services the request.
The aggregation of resource knowledge by the dCDN into a simple set
of capabilities and their affective footprints, that is then
advertised to the uCDN, enables efficient decision making at each
delegation point in the CDN interconnection hierarchy.
It is assumed that an authoritative request router in each CDN will
be responsible for aggregating and advertising capabilities
information in a dCDN, and receiving and aggregating capabilities
information in the uCDN. The CDNI Footprint & Capabilities
Advertisement interface (FCI) along with the CDNI Request Routing
Redirection interface (RI) [I-D.ietf-cdni-redirection] make up the
CDNI Request Routing Interface. As there is no other centralized
CDNI controller, the authoritative request router seems the most
logical place for capabilities aggregation to occur, as it is the
request router that needs such information to make delegation
Ma & Seedorf Expires September 9, 2015 [Page 3]
Internet-Draft CDNI FCI March 2015
decisions. The protocol defined herein may be implemented as part of
an entity other than an authoritative request router, but for the
purposes of this discussion, the authoritative request router is
assumed to be the centralized capabilities aggregation point.
Though there is an obvious need for the ability to exchange and
update footprint and capability information in real-time, it is
assumed that capabilities do not change very often. It is also
assumed that the capabilities are not by themselves useful for making
delegation decisions. Capability information is assumed to be input
into business logic. It is the business logic which provides the
algorithms for delegation decision making. The definition of
business logic occurs outside the scope of CDNI and outside the
timescale of footprint and capability advertisement. It may be the
case that the business logic anticipates and reacts to changes in
dCDN capabilities. However, it may also be the case that business
logic is tailored through offline processes as dCDN capabilities
change. The FCI is agnostic to the business processes employed by
any given uCDN. The footprints and capabilities that are advertised
over the FCI may be used by the uCDN at its discretion to implement
delegation rules. Setting proper defaults in the business logic
should prevent any unwanted delegation from occurring when dCDN
capabilities change, however, that is beyond the scope of this
discussion.
1.1. Terminology
This document uses the terminology defined in section 1.1 of the CDNI
Framework [RFC7336] document.
2. CDNI FCI Capability Advertisement
The FCI is implemented as an ALTO [RFC7285] Service. The ALTO
protocol defines an HTTP-based transport through which ALTO service
information may be retrieved using either a GET or POST method. The
uCDN request router may at any time query the dCDN ALTO FCI Service
for the full set of dCDN capability information. The uCDN may use a
separate FCI Filter Service to retrieve a subset of the dCDN
capability information.
[Ed.: Need to update this with ALTO asynchronous update support.]
[Ed.: Need to update this with ALTO incremental update support.]
Ma & Seedorf Expires September 9, 2015 [Page 4]
Internet-Draft CDNI FCI March 2015
2.1. CDNI FCI Capability Initialization
In lieu of any out-of-band pre-configured capability information,
when the FCI is first brought up between a uCDN and a dCDN, the uCDN
SHOULD assume that the dCDN has no CDNI capabilities. If an out-of-
band capability baseline has been exchanged, the uCDN MAY use that
information to initialize its capabilities database. In either case,
the uCDN SHOULD verify the initial state of the dCDN (as a temporary
outage may affect availability in the dCDN).
The dCDN MUST support sending its entire set of capabilities to the
uCDN through the ALTO service interface
[Ed.: The alternative to using a pull from the uCDN is to use the
triggers interface for a triggered push, however, this would not be
triggering a CDN function, it would be triggering an FCI function, so
given that there is no asynchronous action required by the dCDN, it
seems that reducing inter-dependency on other CDNI interfaces makes
the most sense in this case.]
3. CDNI FCI Capabilities Service
As described in Requirement FCI-2, there is a basic set of
capabilities that must be supported by the FCI for the uCDN to be
able to determine if the dCDN is functionally able to handle a given
request. The CDNI Footprint and Capabilities Semantics
[I-D.ietf-cdni-footprint-capabilities-semantics] document lists
mandatory capabilities types:
o Delivery Protocol
o Acquisition Protocol
o Redirection Mode
o CDNI Logging Capabilities
o CDNI Metadata Capabilities
To be consistent with the base ALTO service definitions, we use the
JSON object definition notation as specified in the ALTO [RFC7285]
protocol RFC.
3.1. CDNI FCI Map
Ma & Seedorf Expires September 9, 2015 [Page 5]
Internet-Draft CDNI FCI March 2015
3.1.1. Media Type
The media type of CDNI FCI Map is "application/alto-cdni-fcimap+json"
3.1.2. HTTP Method
A CDNI FCI Map resource is requested using the HTTP GET method.
3.1.3. Accept Input Parameters
None.
3.1.4. Capabilities
None.
3.1.5. Uses
None.
3.1.6. Response
The data component of a CDNI FCI Map resource is named "fcimap" which
is a JSON object of type FCIMapData:
object {
FCIMapData fcimap<0..*>;
} InfoResourceFCIMap : ResponseEntityBase;
object {
JSONString type;
JSONValue value;
FCIFootprint footprint<0..*>;
} FCIMapData;
object {
JSONString type;
JSONString values<1..*>;
} FCIFootprint;
The FCIMapData object contains a capability name which identifies the
capability, a value object containing the associated Capability
Advertisement Object (e.g., delivery-protocols, acquisition-
protocols, or redirection-modes, as defined in the CDNI Footprint and
Capabilities Semantics
[I-D.ietf-cdni-footprint-capabilities-semantics] document). The
FCIMapData object may also contain an optional list of FCIFootprint
objects. The FCIFootprint object specifies a footprint type (as
Ma & Seedorf Expires September 9, 2015 [Page 6]
Internet-Draft CDNI FCI March 2015
defined by the CDNI Metadata Footprint Types registry, e.g.,
IPv4CIDR, IPv6CIDR, ASN, or CountryCode [I-D.ietf-cdni-metadata])
which identifies the contents and encoding of the individual
footprint entries contained in the associated values array.
The footprint restriction list MUST NOT contain multiple footprint
objects of the same type. Footprint restriction information MAY be
specified using multiple different footprint types. If no footprint
restriction list is specified (or an empty list is specified), it
SHALL be understood that all footprint types MUST be reset to
"global" coverage.
Note: Further optimization of the footprint object to provide quality
information for a given footprint is certainly possible, however, it
is not critical to the basic interconnection of CDNs. The ability to
transfer quality information in capabilities advertisements may be
desirable and is noted here for completeness, however, the specifics
of such mechanisms are outside the scope of this document.
Multiple FCIMapData objects with the same capability type are allowed
within a given CDNI FCI Map response as long as the capability option
values do not overlap, i.e., a given capability option value MUST NOT
show up in multiple FCIMapData objects within a single CDNI FCI Map
response. If multiple FCIMapData objects for a given capability type
exist, those capability objects MUST have different footprint
restrictions; capability objects of a given capability type with
identical footprint restrictions MUST be combined into a single
capability object.
3.1.7. CDNI FCI Capabilities
3.1.7.1. Delivery Protocol
The delivery protocol refers to the protocol over which an end user
(EU) has requested content. If a dCDN does not support the protocol
requested by the client, then the dCDN is not a viable candidate for
delegation.
Though the delivery protocol is specified in the URI scheme (as
defined in RFC3986 [RFC3986]) of the client request URL, protocol
feature subsets or augmented protocol feature sets MAY be defined and
SHOULD correspond with the protocols listed in the CDNI Metadata
Protocol Types registry, e.g., HTTP1.1 or HTTPS1.1
[I-D.ietf-cdni-metadata].
The delivery protocol capability SHOULD support optional footprint
restriction information. The following example shows two lists of
protocols with different footprints.
Ma & Seedorf Expires September 9, 2015 [Page 7]
Internet-Draft CDNI FCI March 2015
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 623
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": [
{ "type": "application/cdni.FCI.DeliveryProtocol.v1+json"
"value": {
"delivery-protocols": [
"HTTP1.1"
]
}
},
{ "type": "application/cdni.FCI.DeliveryProtocol.v1+json"
"value": {
"delivery-protocols": [
"HTTPS1.1"
]
},
"footprint": [
{ "type": "IPv4CIDR",
"values": [
"10.1.0.0/16",
"10.10.10.0/24"
]
}
]
}
]
}
In the above example, the HTTP1.1 protocol is supported globally,
while the HTTPS1.1 protocol is only supported in a restricted
footprint (in this case, specified by IPv4 prefix).
A given protocol MUST NOT appear in multiple FCIMapData application/
cdni.FCI.DeliveryProtocol.v1+json object values.
3.1.7.2. Acquisition Protocol
The acquisition protocol refers to the protocol over which an end
user (EU) has requested content. If a dCDN does not support the
Ma & Seedorf Expires September 9, 2015 [Page 8]
Internet-Draft CDNI FCI March 2015
protocol requested by the client, then the dCDN is not a viable
candidate for delegation.
Though the acquisition protocol is specified in the URI scheme (as
defined in RFC3986 [RFC3986]) of the client request URL, protocol
feature subsets or augmented protocol feature sets MAY be defined and
SHOULD correspond with the protocols listed in the CDNI Metadata
Protocol Types registry, e.g., HTTP1.1 or HTTPS1.1
[I-D.ietf-cdni-metadata].
The acquisition protocol capability SHOULD support optional footprint
restriction information. The following example shows two lists of
protocols with different footprints.
Ma & Seedorf Expires September 9, 2015 [Page 9]
Internet-Draft CDNI FCI March 2015
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 616
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": [
{ "type": "application/cdni.FCI.AcquisitionProtocol.v1+json"
"value": {
"acquisition-protocols": [
"HTTP1.1"
]
}
},
{ "type": "application/cdni.FCI.AcquisitionProtocol.v1+json"
"value": {
"acquisition-protocols": [
"HTTPS1.1"
]
},
"footprint": [
{ "type": "ASN",
"values": [
"AS0",
"AS65535"
]
}
]
}
]
}
In the above example, the HTTP1.1 protocol is supported globally,
while the HTTPS1.1 protocol is only supported in a restricted
footprint (in this case, specified by IPv4 prefix).
A given protocol MUST NOT appear in multiple FCIMapData application/
cdni.FCI.AcquisitionProtocol.v1+json value objects.
3.1.7.3. Redirection Mode
The redirection mode refers to the method(s) employed by request
routers to perform request redirection. The CDNI framework [RFC7336]
document describes four possible request routing modes:
Ma & Seedorf Expires September 9, 2015 [Page 10]
Internet-Draft CDNI FCI March 2015
o DNS iterative (DNS-I)
o DNS recursive (DNS-R)
o HTTP iterative (HTTP-I)
o HTTP recursive (HTTP-R)
The CDNI Footprint and Capabilities Semantics
[I-D.ietf-cdni-footprint-capabilities-semantics] defines the "CDNI
Capabilities Redirection Modes" registry and the initial supported
redirection mode values shown in parentheses above.
If a dCDN supports only a specific mode or subset of modes that does
not overlap with the modes supported by the uCDN, then the dCDN is
not a viable candidate for delegation.
The redirection mode capability SHOULD support optional footprint
restriction information. The following XML-encoded example shows two
lists of modes with different footprints.
Ma & Seedorf Expires September 9, 2015 [Page 11]
Internet-Draft CDNI FCI March 2015
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 750
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": [
{ "name": "application/cdni.FCI.RedirectionMode.v1+json",
"value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
},
{ "name": "application/cdni.FCI.RedirectionMode.v1+json",
"value": {
"redirection-modes": [
"DNS-R",
"HTTP-R"
]
},
"footprint": [
{ "type": "CountryCode",
"values": [
"SE"
]
},
{ "type": "IPv6CIDR",
"values": [
"9876:5432::1/36"
]
}
]
}
]
}
In the above example, iterative redirection is supported globally,
while recursive redirection is only supported in a restricted
footprint (in this case, specified by both Country Code and IPv6
prefix).
Ma & Seedorf Expires September 9, 2015 [Page 12]
Internet-Draft CDNI FCI March 2015
A given mode MUST NOT appear in multiple FCIMapData application/
cdni.FCI.RedirectionMode.v1+json object values.
3.1.7.4. Logging Capabilities
The CDNI Logging interface [I-D.ietf-cdni-logging] document describes
optional logging fields and functionality which may be optional for a
dCDN to implement. If a dCDN does not support certain logging
parameters which may affect billing agreements or legal requirements
of the uCDN, then the dCDN is not a viable candidate for delegation.
3.1.7.5. Metadata Capabilities
The CDNI Metadata interface [I-D.ietf-cdni-metadata] document
describes generic metadata types which may be optional for a dCDN to
implement, but which, if present, are mandatory-to-enforce. If a
dCDN does not support certain metadata types which are designated
mandatory-to-enforce and may affect the correctness or security of
the content being delivered, then the dCDN is not a viable candidate
for delegation.
4. CDNI FCI Capabilities Filtering Service
4.1. Filtered CDNI FCI Map
4.1.1. Media Type
Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it uses the
media type defined for CDNI FCI Map (see Section 3.1.1).
4.1.2. HTTP Method
A Filtered CDNI FCI Map is requested using the HTTP POST method.
4.1.3. Accept Input Parameters
TBD.
4.1.4. Capabilities
None.
4.1.5. Uses
TBD.
Ma & Seedorf Expires September 9, 2015 [Page 13]
Internet-Draft CDNI FCI March 2015
4.1.6. Response
The format is the same as unfiltered CDNI FCI Map (see
Section 3.1.6).
4.1.7. Example
TBD.
5. Footprint via ALTO Network Map
5.1. ALTO Network Maps
The ALTO Protocol offers an information service "ALTO map service"
that provides information to ALTO clients in the form of Network Map
and Cost Map [RFC7285]. As an alternative to the explicit definition
of a footprint (e.g. with type "IPv4CIDR", see examples above), a
reference to an ALTO network map can be used to define an FCI
footprint. To enable such referencing to ALTO network maps from
within an CDNI FCI Map JSON object, a new optional footprint type
'altonetworkmap' is defined (see also Section 6) which has as values
a URI to an ALTO server that host an ALTO network map of media type
'application/alto-networkmap+json' (as defined in the ALTO protocol
specification [RFC7285]), followed by a list of PIDs [RFC7285] within
that network map. Parsing and processing of such an ALTO network map
that expresses an FCI footprint follows the ALTO protocol
specification [RFC7285].
5.2. Example ALTO Network Map for CDNI FCI Footprint
An ALTO client can retrieve a network map of media type 'application/
alto-networkmap+json' under a given URI (e.g.
'http://alto.example.com/fcifootprint001') with a GET request for a
network map as specified in the ALTO protocol [RFC7285]. The
following network map would convey to a uCDN that the given dCDN
(which would provide the map) has three footprints called ''south-
france'', ''germany'', and ''rest'', and provide the corresponding
IPv4 address ranges for these footprints. The entry ''cdni-fruit'' :
[''orange''] in the ''south-france'' footprint is an example of how
new endpoint types (e.g. proprietary ones that are defined outside
the CDNI FCI among certain CDNs) could be used in an ALTO network
map.
Ma & Seedorf Expires September 9, 2015 [Page 14]
Internet-Draft CDNI FCI March 2015
GET /networkmap HTTP/1.1
Host: http://alto.example.com/fcifootprint001
Accept: application/alto-networkmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag": [
{"resource-id": "my-eu-netmap",
"tag": "1266506139"
}
]
},
"network-map" : {
"south-france" : {
"ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ], "cdni-fruit" : ["orange"]
},
"germany" : {
"ipv4" : [ "192.0.3.0/24"]
},
"rest" : { "ipv4": [0.0.0.0/0], "ipv6"; [::/0] }
}
}
}
5.3. Example of ALTO Network Map Footprint in FCI Map
To reference to an ALTO network map as an FCI footprint, the
FCIFootprint JSON object must be of type 'altonetworkmap' with values
containing the URI of the ALTO server hosting the network map and a
list of PID names contained in the network map. The following
example shows the CDNI FCI map on delivery protocol capabilities from
Section 3.1.7.1, with the difference that the footprint for the FCI
delivery protocol capabilities 'RTMP' and 'HTTPS' is given via a
reference to an ALTO network map and corresponding PID names.
Ma & Seedorf Expires September 9, 2015 [Page 15]
Internet-Draft CDNI FCI March 2015
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 439
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": [
{ "name": "delivery_protocol",
"values": [
"HTTP",
"RTSP",
"MMS"
]
},
{ "name": "delivery_protocol",
"values": [
"RTMP",
"HTTPS"
],
"footprint": [
{ "type": "altonetworkmap",
"values": [
"http://alto.example.com/fcifootprint001",
"germany",
"south-france",
]
}
]
}
]
}
6. IANA Considerations
This document requests the registration of two new media types:
+-------------+-----------------------------+
| Type | Subtype |
+-------------+-----------------------------+
| application | alto-cdni-fcimap+json |
| application | alto-cdni-fcimapfilter+json |
+-------------+-----------------------------+
Ma & Seedorf Expires September 9, 2015 [Page 16]
Internet-Draft CDNI FCI March 2015
This document requests the following addition to the CDNI Footprint
type namespace which is defined in the CDNI Metadata Interface
[I-D.ietf-cdni-metadata] specification:
+----------------+----------------------------------+---------------+
| Type name | Description | Specification |
+----------------+----------------------------------+---------------+
| altonetworkmap | URI of an ALTO Server hosting an | RFCthis |
| | ALTO network map, followed by a | |
| | comma-seperated list of PID- | |
| | names | |
+----------------+----------------------------------+---------------+
7. Security Considerations
There are a number of security concerns associated with the FCI. The
FCI essentially provides configuration information which the uCDN
uses to make request routing decisions. Injection of fake capability
advertisement messages or the interception and discard of real
capability advertisement messages may be used for denial of service
(e.g., by falsely advertising or deleting capabilities or preventing
capability advertisements from reaching the uCDN). dCDN capability
advertisements MUST be authenticated by the uCDN to prevent
unauthorized capability injection. uCDN FCI servers MUST be
authenticated by the dCDN to prevent unauthorized interception of
ALTO messages. TLS with client authentication SHOULD be used for all
FCI implementations. Deployments in controlled environments where
physical security and IP address white-listing is employed MAY choose
not to use TLS.
8. Acknowledgements
The authors would like to thank Jon Peterson, Ray van Brandenburg,
Gilles Bertrand, and Scott Wainner for their timely reviews and
invaluable comments.
Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the GreenICN project,
the European Commission, or NICT.
Ma & Seedorf Expires September 9, 2015 [Page 17]
Internet-Draft CDNI FCI March 2015
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, September
2014.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August
2014.
9.2. Informative References
[]
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
and K. Ma, "CDNI Request Routing: Footprint and
Capabilities Semantics", draft-ietf-cdni-footprint-
capabilities-semantics-05 (work in progress), March 2015.
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-15 (work in progress), February 2015.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-09 (work in progress), March 2015.
[I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft-
ietf-cdni-redirection-08 (work in progress), February
2015.
Ma & Seedorf Expires September 9, 2015 [Page 18]
Internet-Draft CDNI FCI March 2015
Appendix A. Capability Aggregation
The following sections show examples of three aggregation scenarios.
In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate
CDN which must perform capabilities aggregation.
A.1. Downstream CDN Aggregation
Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P,
and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated.
Given the setup shown in Figure A1, we can construct a number of use
cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B,
and C). Note: In all cases, the reachability of the uCDN (i.e., CDN-
U) is a don't care as it is assumed that the uCDN knows its own
coverage area and is likely to favor itself in most situations, and
if it has decided that it needs to delegate to a dCDN, then the only
relevant question is if the dCDN can handle the request.
,---,---,---.
,-' `-.
( rr0.u.example.com )
`-. CDN-U ,-'
`---'-+-'- --'
|
,---,-+-,---.
,-' `-.
( rr0.p.example.com )
`-. CDN-P ,-'
`---'-+-'---'
|
+---------------------+---------------------+
/ | \
,---,-+-,---. ,---,-+-,---. ,---,-+-,---.
,-' `-. ,-' `-. ,-' `-.
( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com )
`-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-'
`---'---'---' `---'---'---' `---'---'---'
Figure A1: CDNI dCDN Request Router Aggregation
o None of the four dCDNs (CDNs P, A, B, and C) have global
reachability. In this case, each CDN is likely to advertise
footprint information with its capabilities, specifying its
reachability. When CDN-P advertises capabilities to CDN-U, it may
advertise the aggregate footprint of itself and CDNs A, B, and C.
Note: CDN-P MAY exclude any dCDN, and consequently its footprint,
per its own internal aggregation decision criteria.
Ma & Seedorf Expires September 9, 2015 [Page 19]
Internet-Draft CDNI FCI March 2015
o All four dCDNs (CDNs P, A, B, and C) have global reachability. In
this case, none of the CDNs is likely to advertise any footprint
information as none have any footprint restrictions. When CDN-P
advertises capabilities to CDN-U, the aggregate of all global
reachability is global reachability.
o Some of the four dCDNs (CDNs P, A, B, and C) have global
reachability and some do not. In this case, even though some
dCDNs do not have global reachability, the aggregate of some dCDNs
having global reachability and some not should still be global
reachability (for the given capability). When CDN-P advertises
capabilities to CDN-U, CDN-P may advertise capabilities for which
at least one dCDN has global reach as being supported with global
reachability. It is up to the CDN-P request router to properly
select a dCDN to process individual client requests and not choose
a dCDN whose restricted footprint makes it unsuitable for
delivering the requested content.
A.2. Internal Request Router Aggregation
Figure A2 shows CDN-U and CDN-P where CDN-P internally has four
request routers: the authoritative request router rr0, and three
other request routers rr1, rr2, and rr3. The use of multiple request
routers may be used to distribute request routing load across
resources, possibly in different geographic regions covered by CDN-P.
Similar to Figure A1, the setup shown in Figure A2 requires the
authoritative request router rr0 in CDN-P to aggregate capabilities
information from downstream request routers rr1, rr2, and rr3. The
primary difference between the scenario is that the request routers
in Figure A2 are logically within the same CDN-P organization. The
same reachability scenarios apply to Figure A2 as with Figure A1.
Ma & Seedorf Expires September 9, 2015 [Page 20]
Internet-Draft CDNI FCI March 2015
,---,---,---.
,-' `-.
( rr0.u.example.com )
`-. CDN-U ,-'
`---'-+-'---'
|
,---,---,---,--,-+-,--,---,---,---.
( )
,-' +-------------------+ `-.
( | rr0.p.example.com | )
,-' +---------+---------+ `-.
( | )
,-' +----------+----------+ `-.
( / | \ )
) +---------+---------+ | +---------+---------+ (
( | rr1.p.example.com | | | rr3.p.example.com | )
`. +-------------------+ | +-------------------+ ,'
( | )
`-. +---------+---------+ ,-'
( | rr2.p.example.com | )
`-. +-------------------+ ,-'
( CDN-P )
`---'---'---'---'---'---'---'---'---'
Figure A2: Local CDN Request Router Aggregation
o None of the four CDN-P request routers have global reachability.
In this case, each request router is likely to advertise footprint
information with its capabilities, specifying its reachability.
When rr0 advertises capabilities to CDN-U, it may advertise the
aggregate footprint of itself and rr1, rr2, and rr3.
o All four CDN-P request routers have global reachability. In this
case, none of the request routers is likely to advertise any
footprint information as none has any footprint restrictions.
When rr0 advertises capabilities to CDN-U, the aggregate of all
global reachability is global reachability.
o Some of the four CDN-P request routers have global reachability
and some do not. In this case, even though some request routers
do not have global reachability, the aggregate of some request
routers having global reachability and some not should still be
global reachability (for the given capability). When rr0
advertises capabilities to CDN-U, CDN-P may advertise capabilities
for which at least one request router has global reach as being
supported with global reachability. It is up to the authoritative
request router rr0 to properly select from the other request
routers for any given request, and not choose a request router
Ma & Seedorf Expires September 9, 2015 [Page 21]
Internet-Draft CDNI FCI March 2015
whose restricted footprint makes it unsuitable for delivering the
requested content.
A.3. Internal Capability Aggregation
Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P
is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP).
Figure A3 differs from Figures A1 and A2 in that request router rr0
of CDN-P is not aggregating the capabilities advertisements of
multiple other downstream request routers, but rather it is managing
the disparate capabilities across resources within its own local CDN.
Though not every delivery node has the same protocol capabilities,
the aggregate delivery protocol capabilities advertised by CDN-A may
include all delivery protocols. Note, Figure A3 should not be
construed to imply anything about the coverage areas for each
delivery protocol. They may all support the same delivery footprint,
or they may have different delivery footprints. It is the
responsibility of the request router rr0 to properly assign protocol-
appropriate delivery nodes to individual content requests. If
certain protocols have limited reachability, CDN-P may advertise
footprint restrictions for each protocol.
It should be noted that though the delivery protocol capability was
selected for this example, the concept of internal capability
aggregation applies to all capabilities as discussed below.
Ma & Seedorf Expires September 9, 2015 [Page 22]
Internet-Draft CDNI FCI March 2015
,---,---,---.
,-' `-.
( rr0.u.example.com )
`-. CDN-U ,-'
`---'-+-'---'
|
,---,---,---,--,-+-,--,---,---,---.
( )
,-' +-------------------+ `-.
( | rr0.p.example.com | )
,-' +---------+---------+ `-.
( . )
,-' ....................... `-.
( . . . )
) +-------------------+ . +-------------------+ (
( |rtsp.p.example.com | . |rtmp.p.example.com | )
`. +-------------------+ . +-------------------+ ,'
( . )
`-. +-------------------+ ,-'
( |http.p.example.com | )
`-. +-------------------+ ,-'
( CDN-A )
`---'---'---'---'---'---'---'---'---'
Figure A3: Local CDN Capability Segregation
Another situation in which physical footprint may not matter in an
aggregated view has to do with feature support (e.g., new CDNI
metadata features or new redirection modes). Situations often arise
when phased roll-out of software upgrades, or staging network
segregation result in only certain portions of a CDN's resources
supporting the new feature set. The dCDN has a few options in this
case:
o Enforce atomic update: The dCDN does not advertise support for the
new capability until all resources have been upgraded to support
the new capability.
o Transparent segregation: The dCDN advertises support for the new
capability, and when requests are received that require the new
capability, the dCDN request router properly selects a resource
which supports that capability.
o Advertised segregation: The dCDN advertises support for the new
capability with a footprint restriction allowing the uCDN to make
delegation decisions based on the dCDN's limit support.
Ma & Seedorf Expires September 9, 2015 [Page 23]
Internet-Draft CDNI FCI March 2015
The level of aggregation employed by the dCDN is likely to vary as
business relationships dictate, however, the FCI should support all
possible modes of operation.
Authors' Addresses
Kevin J. Ma
Ericsson
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978-844-5100
Email: kevin.j.ma@ericsson.com
Jan Seedorf
NEC
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 221
Fax: +49 6221 4342 155
Email: seedorf@neclab.eu
Ma & Seedorf Expires September 9, 2015 [Page 24]