Content Delivery
Network Interconnection (CDNI) Request Routing ExtensionsQwilt6, Ha'harashHod HaSharon4524079Israelori.finkelman.ietf@gmail.comVerizon13100 Columbia PikeSilver SpringMD20904United States of Americasanjay.mishra@verizon.comOpen Caching architecture is a use case of Content Delivery Network
Interconnection (CDNI) in which the commercial Content Delivery Network
(CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the
downstream CDN (dCDN). This document defines extensions to the CDNI
Metadata Interface (MI) and the Footprint & Capabilities
Advertisement interface (FCI). These extensions are derived from
requirements raised by Open Caching but are also applicable to CDNI use
cases in general.
IntroductionThe Streaming Video Alliance is
a global association that works to solve
streaming video challenges in an effort to improve end-user experience
and adoption. The Open Caching Working Group of the Streaming Video Alliance is focused on the
delegation of video delivery requests from commercial CDNs to a caching
layer at the ISP's network. Open Caching
architecture is a specific use case of CDNI where the commercial CDN is
the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN
(dCDN). The Open Caching Request Routing Functional Specification defines the Request Routing process
and the
interfaces that are required for its provisioning.
This document defines the CDNI metadata object and the CDNI Footprint and Capabilities
object that are required for Open
Caching Request Routing:
This document also registers CDNI Payload Types for these defined objects.
For consistency with other CDNI documents, this
document follows the CDNI convention of uCDN (upstream CDN) and dCDN
(downstream CDN) to represent the commercial CDN and ISP caching layer,
respectively.TerminologyThe following terms are used throughout this document:
FQDN
Fully Qualified Domain Name
CDN
Content Delivery Network
Additionally, this document reuses the terminology defined in , , , , and . Specifically, we use the following CDNI
acronyms:
FCI
Footprint & Capabilities Advertisement interface (see )
MI
Metadata Interface (see )
uCDN
Upstream CDN (see
)
dCDN
Downstream CDN (see
)
RT
Redirection Target. Endpoint for redirection from uCDN to
dCDN.
RR
Request Router. An element responsible for routing user
requests, typically using HTTP redirect or DNS CNAME, depending on
the use case.
Requirements LanguageThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 when, and only when, they
appear in all capitals, as shown here.Redirect Target CapabilityIterative CDNI Request Redirection is defined in and elaborated by examples in
Sections and of . A
Redirection Target (RT) is defined in for Recursive Request Redirection
as:
The endpoint to which the User Agent is redirected. In
CDNI, an RT may point to a number of different components, some examples
include a surrogate in the same CDN as the request router, a request
router in a dCDN, or a surrogate in a dCDN.
In this document, we adopt the same definition of the RT for the
Iterative Request Redirect use case. This use case requires the
provisioning of the RT address to be used by the uCDN in order to
redirect to the dCDN. RT addresses can vary between different
footprints (for example, between different regions), and they may also
change over time (for example, as a result of network problems). Given
this variable and dynamic nature of the redirect target address, it may
not be suitable to advertise it during bootstrap. A more dynamic and
footprint-oriented interface is required. suggests that it
could be one of the
roles of the FCI . Following
this suggestion, we have therefore chosen to use the CDNI Footprint &
Capabilities Advertisement interface for redirect target address advertisement.Use cases:
Footprint: The dCDN may want to have a different target per
footprint. Note that a dCDN may spread across multiple
geographies. This makes it easier to route client requests to a nearby
request router. Though this can be achieved using a single canonical
name and "Geo DNS", such that in different geographies the same
hostname is resolved to different IP address, that approach has
limitations; for example, a client may be using a third-party DNS
resolver, making it impossible for the redirector to detect where the
client is located, or Geo DNS granularity may be too rough for the
requirement of the application.
Scaling: The dCDN may choose to scale its Request Routing service
by deploying more request routers in new locations and advertise them
via an updatable interface like the FCI.
The Redirect Target capability object is used to indicate the target
address the uCDN should use in order to redirect a client to the dCDN. A
target may be attached to a specific uCDN host, attached to a list of
uCDN hosts, or used globally for all the hosts of the uCDN.When a dCDN is attaching the redirect target to a specific uCDN host
or a list of uCDN hosts, the dCDN MUST advertise the
hosts within the Redirect Target capability object as
"redirecting-hosts". In this case, the uCDN can redirect to that dCDN
address, only if the User Agent request was to one of these uCDN
hosts.If the Redirect Target capability object does not contain a target or
the target is empty, the uCDN MUST interpret it as "no
target available for these uCDN hosts for the specified footprint". In
case such a target was already advertised in a previous FCI object, the
uCDN MUST interpret it as an update that deletes the
previous redirect target.DNS Redirect TargetA redirect target for DNS redirection is an FQDN used as an alias in
a CNAME record response (see ) of the uCDN DNS router.
Note that DNS routers make
routing decisions based on either the DNS resolver's IP address or the
client IP subnet when EDNS0 client-subnet (ECS) is used (see ). The dCDN may choose to advertise
redirect targets and footprints to cover both cases, such that the
uCDN resolution would route the DNS query to different dCDN CNAMEs
according to client subnet or dCDN resolver IP address. This method
further allows the dCDN DNS to optimize the resolution by localizing
the target CNAMEs. A uCDN implementation SHOULD prefer
routing based on client IP subnet when the ECS option is present. A dCDN
implementation using the ECS option MUST be aware of
the privacy drawbacks listed in and SHOULD follow the
guidelines provided in .HTTP Redirect TargetA redirect target for HTTP redirection is the URI to be used as the
value for the Location header of an HTTP redirect 3xx response,
typically a 302 (Found) (see and ).
Properties of Redirect Target Capability ObjectThe Redirect Target capability object consists of the following
properties:
Property:
redirecting-hosts
Description:
One or more uCDN hosts to which this
redirect target is attached. A redirecting host
SHOULD be a host that was published in a
HostMatch object by the uCDN as defined in .
Type:
A list of Endpoint objects (see )
Mandatory-to-Specify:
No. If absent or empty, the
redirect target applies to all hosts of the redirecting
uCDN.
Property:
dns-target
Description:
Target CNAME record for DNS
redirection.
Type:
DnsTarget object (see )
Mandatory-to-Specify:
No. If the dns-target is
absent or empty, the uCDN MUST interpret it as
"no dns-target available".
Property:
http-target
Description:
Target URI for an HTTP redirect.
Type:
HttpTarget object (see )
Mandatory-to-Specify:
No. If the http-target is
absent or empty, the uCDN MUST interpret it as
"no http-target available".
The following is an example of a Redirect Target capability object
serialization that advertises a dCDN target address that is attached
to a specific list of uCDN "redirecting-hosts". A uCDN host that is
included in that list can redirect to the advertised dCDN redirect
target. The capabilities object is serialized as a JSON object as
defined in .
]
}
]
}
]]>DnsTarget ObjectThe DnsTarget object gives the target address for the DNS response
to delegate from the uCDN to the dCDN.
Property:
host
Description:
The host property is a hostname or an IP
address, without a port number.
Type:
Endpoint object as defined in , with the
limitation that it SHOULD NOT include a port
number and, in case a port number is present, the uCDN
MUST ignore it.
Mandatory-to-Specify:
Yes.
DnsTarget ExampleThe following is an example of the DnsTarget object:The following is an example of a DNS query for uCDN address
"a.service123.ucdn.example.com" and the corresponding CNAME
redirection response:HttpTarget ObjectThe HttpTarget object gives the necessary information to construct
the target Location URI for HTTP redirection.
Property:
host
Description:
Hostname or IP address and an optional
port, i.e., the host and port of the authority component of the
URI as described in .
Type:
Endpoint object as defined in .
Mandatory-to-Specify:
Yes.
Property:
scheme
Description:
A URI scheme to be used in the redirect
response location construction. When present, the uCDN
MUST use the provided scheme in for HTTP
redirection to the dCDN.
Type:
A URI scheme as defined in , represented as a JSON
string. The scheme MUST be either "http" or
"https".
Mandatory-to-Specify:
No. If this property is absent or
empty, the uCDN request router MUST use the same
scheme as was used in the original request before
redirection.
Property:
path-prefix
Description:
A path prefix for the HTTP redirect
Location header. The original path is appended after this
prefix.
Type:
A prefix of a path-absolute as defined in
. The
prefix MUST end with a trailing slash to indicate
the end of the last path segment in the prefix.
Mandatory-to-Specify:
No. If this property is absent
or empty, the uCDN MUST NOT prepend a path-prefix
to the original content path, i.e., the original path
MUST appear in the Location URI right after the
authority component.
Property:
include-redirecting-host
Description:
A flag indicating whether or not to
include the redirecting host as the first path segment after the
path-prefix. If set to true and a "path-prefix" is used, the
uCDN redirecting host MUST be added as a separate
path segment after the path-prefix and before the original URL
path. If set to true and there is no path-prefix, the uCDN
redirecting host MUST be prepended as the first
path segment in the redirect URL.
Type:
Boolean.
Mandatory-to-Specify:
No. Default value is False.
HttpTarget ExampleThe following is an example of the HttpTarget object with a "scheme", a "path-prefix",
and "include-redirecting-host" properties:The following is an example of an HTTP request for content at uCDN host
"a.service123.ucdn.example.com" and the corresponding HTTP response
with a Location header, used for redirecting the client to the dCDN,
constructed according to the HttpTarget object from the above
example:Usage ExampleBefore requests can be routed from the uCDN to the dCDN, the CDNs
must exchange service configurations between them. Using the MI, the
uCDN advertises out-of-band its hosts to the dCDN; each host is
designated by a hostname and has its own specific metadata (see ). Using the FCI,
the dCDN advertises (also out-of-band) the redirect target address
defined in for the relevant uCDN hosts. The following is a
generalized example of the message flow between a uCDN and a dCDN. For
simplicity, we focus on the sequence of messages between the uCDN and
dCDN and not on how they are passed.Explanation:
The uCDN advertises a host (s123.ucdn.example.com) with the host
metadata.
The dCDN advertises its FCI objects to the uCDN, including a
Redirect Target capability object that contains the redirect target
address (us-east1.dcdn.example.com) specified for that uCDN
host.
Once the redirect target has been set, the uCDN can start
redirecting user requests to the dCDN. The following is a generic
sequence of redirection using the host and redirect target that were
advertised in .Explanation:
The End User sends a request (DNS or HTTP) to the uCDN Request
Router (RR).
Using the previously advertised Redirect Target, the uCDN
redirects the request to the dCDN.
The End User sends a request to the dCDN.
The dCDN either sends a response or reroutes it, for example, to
a dCDN surrogate.
Fallback Target Server AddressOpen Caching requires that the uCDN provides a fallback target server
to the dCDN to be used in cases where the dCDN cannot properly handle
the request. To avoid redirect loops, the fallback target server's
address at the uCDN MUST be different from the original
uCDN address from which the client was redirected to the dCDN. The uCDN
MUST avoid further redirection when receiving the client
request at the fallback target. The Fallback Target is defined as a
generic metadata object (see ).Use cases:
Failover: A dCDN request router receives a request but has no
caches to which it can route the request. This can happen in the case
of failures or temporary network overload.
No coverage: A dCDN request router receives a request from a
client located in an area inside the footprint but not covered by the
dCDN caches or outside the dCDN footprint coverage. In such cases,
the router may choose to redirect the request back to the uCDN
fallback address.
Error: A cache may receive a request that it cannot properly
serve, for example, some of the metadata objects for that service were
not properly acquired. In this case, the cache's "default action" may
be to "redirect back to uCDN".
The Fallback Target metadata object is used to indicate the target
address the dCDN should redirect a client to when falling back to the
uCDN. The fallback target address is represented as an Endpoint object as
defined in .In DNS redirection, a CNAME record is used as the fallback target
address.In HTTP redirection, a hostname is used as the fallback target
address.When using HTTP redirect to route a client request back to the uCDN,
it is the dCDN's responsibility to use the original URL path as the
client would have used for the original uCDN request, stripping, if
needed, the dCDN path-prefix and/or the uCDN hostname from the redirect
URL that may have been used to request the content from the dCDN.Properties of Fallback Target Generic Metadata ObjectThe MI.FallbackTarget generic metadata object consists of the following
two properties:
Property:
host
Description:
Target address to which the dCDN can
redirect the client.
Type:
Endpoint object as defined in , with the
limitation that in case of DNS delegation, it SHOULD
NOT include a port number, and in case a port number is
present, the dCDN MUST ignore it.
Mandatory-to-Specify:
Yes.
Property:
scheme
Description:
A URI scheme to be used in the redirect
response location construction. When present, the dCDN
MUST use this scheme in case of HTTP redirection
to the uCDN fallback address.
Type:
A URI scheme as defined in , represented as a JSON
string. The scheme MUST be either "http" or
"https".
Mandatory-to-Specify:
No. In case of HTTP redirection to
fallback, if this property is absent or empty, the dCDN
redirecting entity MUST use the same scheme as in
the request received by the dCDN.
The following is an example of an MI.FallbackTarget generic
metadata object that designates the host address the dCDN should use
as fallback address to redirect back to the uCDN:Usage ExampleThe uCDN advertises out-of-band the fallback target address to the
dCDN, so that the dCDN may redirect a request back to the uCDN in case
the dCDN cannot serve it. Using the MI, the uCDN advertises its hosts
to the dCDN, along with their specific host metadata (see ). The Fallback
Target generic metadata object is encapsulated within the
"host-metadata" property of each host. The following is an example of
a message flow between a uCDN and a dCDN. For
simplicity, we focus on the sequence of messages between the uCDN and
dCDN, not on how they are passed.Explanation:
The uCDN advertises a host (s123.ucdn.example.com) with the host
metadata. The host-metadata property contains an MI.FallbackTarget
generic metadata object.
The dCDN advertises its FCI objects to the uCDN, including a
Redirect Target capability object that contains the redirect target
address (us-east1.dcdn.example.com) specified for that uCDN
host.
The following is a generic sequence of redirection using the
configurations that were advertised in . In this case,
the dCDN redirects back to the uCDN fallback target address.Explanation:
The End User sends a request (DNS or HTTP) to the uCDN Request
Router (RR).
Using the previously advertised Redirect Target, the uCDN
redirects the request to the dCDN.
The End User sends a request to the dCDN.
The dCDN cannot handle the request and therefore redirects it
back to the uCDN fallback target address.
The End User sends the request to the uCDN fallback target
address.
The uCDN either sends a response or reroutes it, for example, to
a uCDN surrogate.
uCDN Addressing ConsiderationsWhen advertising fallback addresses to the dCDN, the uCDN
SHOULD consider the failure use cases that may lead the
dCDN to route requests to uCDN fallback. In extreme dCDN network
failures or under denial-of-service (DoS) attacks, requests coming
from a large segment or multiple segments of the dCDN may be routed
back to the uCDN. The uCDN SHOULD therefore design its
fallback addressing scheme and its available resources accordingly. A
favorable approach would be for the uCDN to use a different fallback
target address for each uCDN host, enabling it to load balance the
requests using the same methods as it would for its original
hosts. See Sections and of for
a detailed description of how to use GenericMetadata objects within
the HostMatch object advertised in the HostIndex of the uCDN.IANA ConsiderationsCDNI Payload TypesIANA has registered the following CDNI
Payload Types in the "CDNI Payload Types" registry defined in
:
Payload Type
Specification
FCI.RedirectTarget
RFC 8804
MI.FallbackTarget
RFC 8804
CDNI FCI RedirectTarget Payload Type
Purpose:
The purpose of this payload type is to
distinguish FCI advertisement objects for redirect target.
Interface:
FCI
Encoding:
See .
CDNI MI FallbackTarget Payload Type
Purpose:
The purpose of this payload type is to distinguish
FallbackTarget MI objects (and any associated capability
advertisement).
Interface:
MI/FCI
Encoding:
See .
Security ConsiderationsThis specification defines extensions to the CDNI Metadata Interface
(MI) and the Footprint & Capabilities Advertisement interface (FCI). As such,
it is subject to the security and privacy considerations defined in
and in
,
respectively.Confidentiality and PrivacyThe Redirect Target capability object potentially reveals information
about the internal structure of the dCDN network. A third party could
intercept the FCI transactions and use the information to attack the
dCDN. The same is also true for the Fallback Target generic metadata object, as
it may reveal information about the internal structure of the uCDN,
exposing it to external exploits. Implementations of the FCI and MI
MUST therefore use strong authentication and encryption
and strictly follow the directions for securing the interface as
defined for the Metadata Interface in .ReferencesNormative ReferencesInformative ReferencesStreaming Video AllianceOpen CachingStreaming Video Alliance
Open Cache Request Routing Functional Specification
QwiltLimelight NetworksDisney Streaming ServicesVerizonDisney Streaming ServicesQwiltDisney Streaming ServicesAcknowledgementsThe authors thank for reality checks against
production use cases; his contribution is significant to this
document. The authors also thank for his review and
feedback and for his guidance throughout the
development of this document, including his regular reviews.