| Network Working Group | K. Ma |
| Internet-Draft | Ericsson |
| Intended status: Standards Track | J. Seedorf |
| Expires: October 16, 2016 | NEC |
| April 14, 2016 |
CDNI Footprint & Capabilities Advertisement Interface
draft-ma-cdni-capabilities-08
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.
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].
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 16, 2016.
Copyright (c) 2016 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.
The need for footprint and capabilities advertisement in Content Distribution Network Interconnection (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/or 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 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 [I-D.ietf-cdni-footprint-capabilities-semantics]. 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.
This document uses the terminology defined in section 1.1 of the CDNI Framework [RFC7336] document.
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.]
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
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. [I-D.ietf-cdni-footprint-capabilities-semantics] lists mandatory capabilities types:
To be consistent with the base ALTO service definitions, we use the JSON object definition notation as specified in the ALTO protocol [RFC7285].
The media type of CDNI FCI Map is "application/alto-cdni-fcimap+json"
A CDNI FCI Map resource is requested using the HTTP GET method.
None.
None.
None.
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 {
FCICapability capabilities<1..*>;
} FCIMapData;
object {
JSONString capability-type;
JSONValue capability-value
FCIFootprint footprints<0..*>;
} FCICapability;
object {
JSONString footprint-type;
JSONString footprint-value<1..*>;
} FCIFootprint;
The FCIMapData object contains a CDNI Payload Type [RFC7736] "ptype" which identifies the capability and a "value" object containing the associated Capability Advertisement Object (e.g., delivery-protocols, acquisition-protocols, or redirection-modes, as defined in [I-D.ietf-cdni-footprint-capabilities-semantics]). The FCIMapData object may also contain an optional list of FCIFootprint objects "footprints". The FCIFootprint object specifies a "footprint-type" (as 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 "footprint-value" array.
The "footprints" list MUST NOT contain multiple FCIFootprint 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 necessary for 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 footprint-value 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.
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]) 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 following example shows two lists of delivery protocols with different footprints.
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: 627
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.DeliveryProtocol"
"capability-value": {
"delivery-protocols": [
"http1.1"
]
}
},
{ "capability-type": "FCI.DeliveryProtocol"
"capability-value": {
"delivery-protocols": [
"https1.1"
]
},
"footprints": [
{ "footprint-type": "ipv4cidr",
"footprint-value": [
"10.1.0.0/16",
"10.10.10.0/24"
]
}
]
}
]
}
}
In the above example, the HTTP/1.1 protocol is supported globally, while the HTTP/1.1 over TLS protocol is only supported in a restricted footprint (in this case, specified by IPv4 prefix).
A given protocol MUST NOT appear in multiple FCIMapData FCI.DeliveryProtocol object values.
The acquisition 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 acquisition protocol is specified in the URI scheme (as defined in [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 following example shows two lists of acquisition protocols with different footprints.
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: 620
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.AcquisitionProtocol"
"capability-value": {
"acquisition-protocols": [
"http1.1"
]
}
},
{ "capability-type": "FCI.AcquisitionProtocol"
"capability-value": {
"acquisition-protocols": [
"https1.1"
]
},
"footprints": [
{ "footprint-type": "asn",
"footprint-value": [
"AS0",
"AS65535"
]
}
]
}
]
}
}
In the above example, the HTTP/1.1 protocol is supported globally, while the HTTP/1.1 over TLS protocol is only supported in a restricted footprint (in this case, specified by Autonomous System number).
A given protocol MUST NOT appear in multiple FCIMapData FCI.AcquisitionProtocol value objects.
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:
[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 might not be a viable candidate for delegation.
The following example shows two lists of redirection modes with different footprints.
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: 767
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
},
{ "capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-R",
"HTTP-R"
]
},
"footprints": [
{ "footprint-type": "countrycode",
"footprint-value": [
"SE"
]
},
{ "footprint-type": "ipv6cidr",
"footprint-value": [
"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).
A given mode MUST NOT appear in multiple FCIMapData FCI.RedirectionMode object values.
[I-D.ietf-cdni-logging] describes the "cdni_http_request_v1" logging record-types and optional vs. mandatory-to-implement logging fields for that record-type. It also allows new logging record-types and logging fields to be defined which would 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.
The CDNI Logging capability object is used to indicate support for CDNI Logging record-types, as well as CDNI Logging fields which are marked as optional for the specified record-types [I-D.ietf-cdni-logging].
The following shows an example of CDNI Logging Capability Object Serialization, for a CDN that supports the optional Content Collection ID logging field (but not the optional Session ID logging field) for the "cdni_http_request_v1" record type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": [ "s-ccid" ]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Logging Capability Object Serialization, for a CDN that supports all optional fields for the "cdni_http_request_v1" record type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1"
},
"footprints": [
<Footprint objects>
]
}
]
}
[I-D.ietf-cdni-metadata] describes GenericMetadata types which may be optional for a dCDN to implement, but which, if present, are mandatory-to-enforce. It also allows for new GenericMetadata to be defined which would be optional for a dCDN to implement.
If a dCDN does not support certain GenericMetadata 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.
The CDNI Metadata capability object is used to indicate support for CDNI GenericMetadata types [I-D.ietf-cdni-metadata].
The following shows an example of CDNI Metadata Capability Object Serialization, for a CDN that supports only the SourceMetadata GenericMetadata type (i.e., it can acquire and deliver content, but cannot enforce and security policies, e.g., time, location, or protocol ACLs).
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": ["MI.SourceMetadata"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Metadata Capability Object Serialization, for a CDN that supports only structural metadata (i.e., it can parse metadata as a transit CDN, but cannot enforce security policies or deliver content).
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}
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).
A Filtered CDNI FCI Map is requested using the HTTP POST method.
TBD.
None.
TBD.
The format is the same as unfiltered CDNI FCI Map (see Section 3.1.6).
TBD.
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 CDNI Footprint Type (e.g., ipv4cidr, ipv6cidr, as, countrycode), a reference to an ALTO network map can be used to define an FCI footprint. To enable such referencing to ALTO network maps, a new CDNI Footprint Type "altonetworkmap" is defined (see also Section 6.3).
The first altonetworkmap entry must be a URI for accessing the ALTO server that hosts the ALTO network map (as defined in the ALTO protocol specification [RFC7285]). All subsequent altonetworkmap entries must be of type PIDName (as defined in [RFC7285], where the PIDName corresponds to a PID in the ALTO network map referenced by the preceding URI. Parsing and processing of an ALTO network map follows the ALTO protocol specification [RFC7285].
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" and "germany", and provides the corresponding IPv4 address ranges for these footprints.
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: 319
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" ]
},
"germany" : {
"ipv4" : [ "192.0.3.0/24"]
}
}
}
To reference an ALTO network map as an FCI footprint, set the footprint-type to "altonetworkmap", and set the first entry in the footprint-value to the URI of the ALTO server hosting the network map, followed by a list of PID names contained in the network map.
The following example shows two lists of delivery protocols (see Section 3.1.7.1), with the second having an ALTO network map footprint.
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: 618
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.DeliveryProtocol",
"capability-value": [
"http1.1"
]
},
{ "capability-type": "FCI.DeliveryProtocol",
"capability-value": [
"values": [
"https1.1"
],
"footprints": [
{ "footprint-type": "altonetworkmap",
"footprint-value": [
"http://alto.example.com/fcifootprint001",
"germany",
"south-france"
]
}
]
}
]
}
}
In the above example, the HTTP/1.1 protocol is supported globally, while the HTTP/1.1 over TLS protocol is only supported in a restricted footprint (in this case, specified by an ALTO network map for Germany and Southern France).
This document requests the registration of the following media types:
| Type | Subtype |
|---|---|
| application | alto-cdni-fcimap+json |
| application | alto-cdni-fcimapfilter+json |
Type name: application
Subtype name: alto-cdni-fcimap+json
Required parameters: none
Optional parameters: none
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification: RFCthis [RFC Editor: Please replace RFCthis with the published RFC number for this document.]
Applications that use this media type:
Fragment identifier considerations: N/A
Additional information: N/A
Person & email address to contact for further information:
Intended usage: LIMITED USE
Restrictions on usage:
Author: IETF CDNI working group
Change controller: IETF CDNI working group
Provisional registration: no
Type name: application
Subtype name: alto-cdni-fcimapfilter+json
Required parameters: none
Optional parameters: none
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification: RFCthis [RFC Editor: Please replace RFCthis with the published RFC number for this document.]
Applications that use this media type:
Fragment identifier considerations: N/A
Additional information: N/A
Person & email address to contact for further information:
Intended usage: LIMITED USE
Restrictions on usage:
Author: IETF CDNI working group
Change controller: IETF CDNI working group
Provisional registration: no
This document requests the registration of the following CDNI Payload Types under the IANA CDNI Payload Type registry:
| Payload Type | Specification |
|---|---|
| FCI.Logging | RFCthis |
| FCI.Metadata | RFCthis |
[RFC Editor: Please replace RFCthis with the published RFC number for this document.]
Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported CDNI Logging record-types and optional CDNI Logging Field Names.
Interface: FCI
Encoding: see Section 3.1.7.4.1 and Section 3.1.7.4.2
Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported CDNI GenericMetadata types.
Interface: FCI
Encoding: see Section 3.1.7.5.1 and Section 3.1.7.5.2
This document requests the following addition to the "CDNI Metadata Footprint Types" registry:
| Footprint Type | Description | Specification |
|---|---|---|
| altonetworkmap | URI of an ALTO Server hosting an ALTO network map, followed by a list of PID-names | RFCthis |
[RFC Editor: Please replace RFCthis with the published RFC number for this document.]
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). FCI messages may also be monitored to detect when CDN performance degrades or outages occur. Such information may be considered private by the dCDN.
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. Encryption MUST be used to ensure confidentiality of the dCDN's private messages.
An implementation of the CDNI Footprint & Capabilities Advertisement interface MUST support TLS transport as per [RFC2818] and [RFC7230]. The use of TLS for transport of the CDNI metadata interface messages allows:
and, once they have mutually authenticated each other, it allows:
In an environment where any such protection is required, TLS MUST be used (including authentication of the remote end) by the server-side (uCDN) and the client-side (dCDN) of the CDNI Footprint & Capabilities Advertisement interface unless alternate methods are used for ensuring the confidentiality of the information in the CDNI FCI messages (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity).
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be followed.
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.
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.
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
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.
,---,---,---.
,-' `-.
( 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
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.
,---,---,---.
,-' `-.
( 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:
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.