rfc8804xml2.original.xml   rfc8804.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<?rfc tocdepth="4"?> category="std" consensus="true"
<?rfc tocindent="yes"?> docName="draft-ietf-cdni-request-routing-extensions-08" number="8804"
<?rfc symrefs="yes"?> ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
<?rfc sortrefs="yes"?> tocDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-cdni-request-routing-extensions-08" ipr=
"trust200902">
<front> <front>
<title abbrev="CDNI Request Routing Extensions">CDNI Request Routing Extensi <title abbrev="CDNI Request Routing Extensions">Content Delivery
ons</title> Network Interconnection (CDNI) Request Routing Extensions</title>
<seriesInfo name="RFC" value="8804"/>
<author fullname="Ori Finkelman" initials="O." surname="Finkelman"> <author fullname="Ori Finkelman" initials="O." surname="Finkelman">
<organization>Qwilt</organization> <organization>Qwilt</organization>
<address> <address>
<postal> <postal>
<street>6, Ha'harash</street> <street>6, Ha'harash</street>
<city>Hod HaSharon</city> <city>Hod HaSharon</city>
<region/>
<region></region>
<code>4524079</code> <code>4524079</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<phone/>
<phone></phone>
<email>ori.finkelman.ietf@gmail.com</email> <email>ori.finkelman.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Sanjay Mishra" initials="S." surname="Mishra"> <author fullname="Sanjay Mishra" initials="S." surname="Mishra">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<postal> <postal>
<street>13100 Columbia Pike</street> <street>13100 Columbia Pike</street>
<city>Silver Spring</city> <city>Silver Spring</city>
<region>MD</region> <region>MD</region>
<code>20904</code> <code>20904</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone/>
<phone></phone>
<email>sanjay.mishra@verizon.com</email> <email>sanjay.mishra@verizon.com</email>
</address> </address>
</author> </author>
<date year="2020" month="September"/>
<date/>
<abstract> <abstract>
<t>Open Caching architecture is a use case of Content Delivery Networks In <t>Open Caching architecture is a use case of Content Delivery Network
terconnection (CDNI) in which the Interconnection (CDNI) in which the commercial Content Delivery Network
commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) an (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the
d the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI
downstream CDN (dCDN). The extensions specified in this document to the Metadata Interface (MI) and the Footprint &amp; Capabilities
CDNI Metadata Interface (MI) and Advertisement interface (FCI). These extensions are derived from
the Footprint and Capabilities Interface (FCI) are derived from require requirements raised by Open Caching but are also applicable to CDNI use
ments raised by Open Caching but cases in general.
are also applicable to CDNI use cases in general.</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>The <xref target="SVA">Streaming Video Alliance</xref> is a global asso <name>Introduction</name>
ciation that works to solve <t>The Streaming Video Alliance <xref target="SVA" format="default"/> is
streaming video challenges in an effort to improve end-user experience a global association that works to solve
and adoption. streaming video challenges in an effort to improve end-user experience
The <xref target="OCWG">Open Caching Working Group</xref> of the <xref and adoption. The Open Caching Working Group <xref target="OCWG"
target="SVA">Streaming Video Alliance</xref> format="default"/> of the Streaming Video Alliance <xref target="SVA"
is focused on the delegation of video delivery requests from commercial format="default"/> is focused on the
CDNs to a caching layer at the Internet delegation of video delivery requests from commercial CDNs to a caching
Service Provider's (ISP) network. Open Caching architecture is a specif layer at the ISP's network. Open Caching
ic use case of CDNI where the commercial CDN architecture is a specific use case of CDNI where the commercial CDN is
is the upstream CDN (uCDN) and the ISP caching layer is the downstream the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN
CDN (dCDN). (dCDN). The Open Caching Request Routing Functional Specification <xref
The <xref target="OC-RR">Open Caching Request Routing Specification</xr target="OC-RR" format="default"/> defines the Request Routing process
ef> defines the Request Routing process and the
and the interfaces that are required for its provisioning. This documen interfaces that are required for its provisioning.
t defines and registers CDNI metadata
object <xref target="RFC8006"/> and CDNI Footprint and Capabilities obj
ect <xref target="RFC8008"/> that are
required for Open Caching Request Routing. For consistency with other C
DNI documents this document follows the
CDNI convention of uCDN (upstream CDN) and dCDN (downstream CDN) to rep
resent the commercial CDN and ISP caching
layer respectively.</t>
<t>This document also registers CDNI Payload Types <xref target="RFC7736"/ This document defines the CDNI metadata object <xref
> for the defined objects: target="RFC8006" format="default"/> and the CDNI Footprint and Capabilities
<list style="symbols"> object <xref target="RFC8008" format="default"/> that are required for Open
<t>Redirect Target Capability (for dCDN advertising redirect target Caching Request Routing:</t>
address)</t>
<t>Fallback Target Metadata (for uCDN configuring fallback target ad <ul spacing="normal">
dress)</t> <li>Redirect Target Capability (for dCDN advertising redirect target
</list> address)</li>
<li>Fallback Target Metadata (for uCDN configuring fallback target
address)</li>
</ul>
<t>This document also registers CDNI Payload Types <xref
target="RFC7736" format="default"/> for these defined objects.
</t> </t>
<section anchor="terminology" title="Terminology"> <t>For consistency with other CDNI documents, this
<t>The following terms are used throughout this document: document follows the CDNI convention of uCDN (upstream CDN) and dCDN
<list style="symbols"> (downstream CDN) to represent the commercial CDN and ISP caching layer,
<t>FQDN - Fully Qualified Domain Name</t> respectively.</t>
<t>CDN - Content Delivery Network</t>
</list>
</t>
<t>Additionally, this document reuses the terminology defined in <xref t
arget="RFC6707"/>,
<xref target="RFC7336"/>, <xref target="RFC8006"/>, <xref target="RFC
8007"/>, and <xref target="RFC8008"/>.
Specifically, we use the following CDNI acronyms:
<list style="symbols">
<t>FCI - Footprint and Capability Interface (see <xref target="RFC80
08"/>)</t>
<t>MI - Metadata Interface (see <xref target="RFC8006"/>)</t>
<t>uCDN, dCDN - Upstream CDN and Downstream CDN respectively (see <x
ref target="RFC7336"/>)</t>
<t>RT - Redirection Target. Endpoint for redirection from uCDN to dC
DN.</t>
<t>RR - Request Router. An element responsible for routing user requ
ests, typically using HTTP redirect
or DNS CNAME, depending on the use case.</t>
</list>
</t>
</section>
<section title="Requirements Language"> <section anchor="terminology" numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <name>Terminology</name>
OULD", <t>The following terms are used throughout this document:</t>
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i <dl newline="false" spacing="normal" indent="8">
n this <dt>FQDN</dt>
document are to be interpreted as described in BCP 14 <xref target="RFC <dd>Fully Qualified Domain Name</dd>
2119"/> <xref target="RFC8174"/> <dt>CDN</dt>
when, and only when, they appear in all capitals, as shown here.</t> <dd>Content Delivery Network</dd>
</section> </dl>
<t>Additionally, this document reuses the terminology defined in <xref
target="RFC6707" format="default"/>, <xref target="RFC7336"
format="default"/>, <xref target="RFC8006" format="default"/>, <xref
target="RFC8007" format="default"/>, and <xref target="RFC8008"
format="default"/>. Specifically, we use the following CDNI
acronyms:</t>
<dl newline="false" spacing="normal" indent="8">
<dt>FCI</dt>
<dd>Footprint &amp; Capabilities Advertisement interface (see <xref
target="RFC8008" format="default"/>)</dd>
<dt>MI</dt>
<dd>Metadata Interface (see <xref target="RFC8006"
format="default"/>)</dd>
<dt>uCDN</dt>
<dd>Upstream CDN (see
<xref target="RFC7336" format="default"/>)</dd>
<dt>dCDN</dt>
<dd>Downstream CDN (see
<xref target="RFC7336" format="default"/>)</dd>
</section> <dt>RT</dt>
<dd>Redirection Target. Endpoint for redirection from uCDN to
dCDN.</dd>
<dt>RR</dt>
<dd>Request Router. An element responsible for routing user
requests, typically using HTTP redirect or DNS CNAME, depending on
the use case.</dd>
</dl>
<section anchor="redirect-target-capability" title="Redirect Target Capabili </section>
ty"> <section numbered="true" toc="default">
<t>Iterative request redirection is defined in Section 1.1 of <xref target <name>Requirements Language</name>
="RFC7336"/> and elaborated <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
by examples in Sections 3.2 and 3.4 of <xref target="RFC7336"/>. A Red "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
irection Target (RT) is defined in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
Section 2 of <xref target="RFC7975"/> for Recursive Request Redirection "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
as: "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14 <xref
<t><list style="empty"> target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
<t> appear in all capitals, as shown here.</t>
"The endpoint to which the User Agent is redirected. In CDNI, a RT m </section>
ay point to a number of different </section>
components, some examples include a surrogate in the same CDN as the <section anchor="redirect-target-capability" numbered="true" toc="default">
request router, a request router in <name>Redirect Target Capability</name>
a dCDN, or a surrogate in a dCDN". <t>Iterative CDNI Request Redirection is defined in <xref
target="RFC7336" sectionFormat="of" section="1.1"/> and elaborated by exam
ples in
Sections <xref target="RFC7336" section="3.2"
sectionFormat="bare"/> and <xref target="RFC7336" section="3.4"
sectionFormat="bare"/> of <xref target="RFC7336" format="default"/>. A
Redirection Target (RT) is defined in <xref
target="RFC7975" sectionFormat="of" section ="2"/> for Recursive Request R
edirection
as:</t>
<blockquote>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.</blockquote>
<t>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. <xref
target="RFC7336" sectionFormat="of" section="4.3"/> suggests that it
could be one of the
roles of the FCI <xref target="RFC8008" format="default"/>. Following
this suggestion, we have therefore chosen to use the CDNI Footprint &amp;
Capabilities Advertisement interface for redirect target address advertise
ment.</t>
<t>Use cases:</t>
<ul spacing="normal">
<li>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.</li>
<li>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.</li>
</ul>
<t>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.</t>
<t>When a dCDN is attaching the redirect target to a specific uCDN host
or a list of uCDN hosts, the dCDN <bcp14>MUST</bcp14> 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.</t>
<t>If the Redirect Target capability object does not contain a target or
the target is empty, the uCDN <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> interpret it as an update that deletes the
previous redirect target.</t>
<section numbered="true" toc="default">
<name>DNS Redirect Target</name>
<t>A redirect target for DNS redirection is an FQDN used as an alias in
a CNAME record response (see <xref target="RFC1034"
format="default"/>) 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 <xref
target="RFC7871" format="default"/>). 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 <bcp14>SHOULD</bcp14> prefer
routing based on client IP subnet when the ECS option is present. A dCDN
implementation using the ECS option <bcp14>MUST</bcp14> be aware of
the privacy drawbacks listed in <xref target="RFC7871"
sectionFormat="of" section="2"/> and <bcp14>SHOULD</bcp14> follow the
guidelines provided in <xref target="RFC7871" sectionFormat="of"
section="11.1"/>.</t>
</section>
<section numbered="true" toc="default">
<name>HTTP Redirect Target</name>
<t>A 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 <xref target="RFC7231"
sectionFormat="of" section="7.1.2"/> and <xref target="RFC7231"
sectionFormat="of" section="6.4"/>).
</t> </t>
</list></t> </section>
<t> <section anchor="redirect-target-capability-properties" numbered="true" to
In this document we adopt the same definition of the RT for the Iterati c="default">
ve Request Redirect use case. <name>Properties of Redirect Target Capability Object</name>
This use case requires the provisioning of the RT address to be used by <t>The Redirect Target capability object consists of the following
the uCDN in order to redirect properties:</t>
to the dCDN. RT addresses can vary between different footprints, for ex
ample, 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 suitab
le to advertise it during bootstrap.
A more dynamic and footprint oriented interface is required. Section 4.
3 of <xref target="RFC7336"/> suggests
that it could be one of the roles of the FCI <xref target="RFC8008"/>.
Following this suggestion, we have
therefore, chosen to use the CDNI Footprint and Capabilities interface
for redirect target address advertisement.
</t>
<t>Use cases<list style="symbols">
<t>Footprint: The dCDN may want to have a different target per footprin
t.
Note that a dCDN may spread across multiple geographies. This makes
it
easier to route client requests to a nearby request router. Though t
his 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 limi
tations;
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.
</t>
<t>Scaling: The dCDN may choose to scale its request routing service by <dl newline="false" spacing="normal">
deploying more request routers
in new locations and advertise them via an updatable interface like
the FCI.</t>
</list></t> <dt>Property:</dt><dd><t>redirecting-hosts</t>
<t>The Redirect Target capability object is used to indicate the target ad
dress the uCDN should use in order
to redirect a client to the dCDN. A target may be attached to a specifi
c uCDN host, a list of uCDN hosts,
or used globally for all the hosts of the uCDN.
</t>
<t>
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 "re
directing-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.
</t>
<t> <dl newline="false" spacing="normal">
If the redirect target capability object does not contain a target or t
he 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 delet
es the previous redirect target.
</t>
<section title="DNS Redirect Target"> <dt>Description:</dt><dd>One or more uCDN hosts to which this
<t> redirect target is attached. A redirecting host
A redirect target for DNS redirection is a FQDN used as an alias in <bcp14>SHOULD</bcp14> be a host that was published in a
a CNAME record response (see <xref target="RFC1034"/>) HostMatch object by the uCDN as defined in <xref
of the uCDN DNS router. Note that DNS routers make routing decisions target="RFC8006" sectionFormat="of" section="4.1.2"/>.</dd>
based on either the DNS resolver's IP
address or the client IP subnet when EDNS0 client-subnet (ECS) is us
ed (see <xref target="RFC7871"/>).
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 a different dCDN CNAMEs according clien
t subnet or dCDN resolver IP address.
This method further allows the dCDN DNS to optimize the resolution b
y localizing the target CNAMEs.
A uCDN implementation SHOULD prefer routing based on client IP subne
t when ECS option is present.
A dCDN implementation using the ECS option MUST be aware of the priv
acy drawbacks listed in Section 2 of
<xref target="RFC7871"/> and SHOULD follow the guidelines provided i
n Section 11.1 of <xref target="RFC7871"/>.
</t>
</section>
<section title="HTTP Redirect Target">
<t>
A redirect target for HTTP redirection is the URI to be used as the
value for the Location header of a HTTP redirect
3xx response, typically a 302 (Found) (see Section 7.1.2 of <xref ta
rget="RFC7231"/> and section 6.4 of
<xref target="RFC7231"/>).
</t>
</section>
<section anchor="redirect-target-capability-properties" title="Properties <dt>Type:</dt><dd>A list of Endpoint objects (see <xref
of Redirect Target Capability Object"> target="RFC8006" sectionFormat="of" section="4.3.3"/>)</dd>
<t>The Redirect Target capability object consists of the following prop
erties:</t>
<t><list style="empty">
<t>Property: redirecting-hosts<list style="empty">
<t>Description: One or more uCDN hosts to which this redirect tar <dt>Mandatory-to-Specify:</dt><dd>No. If absent or empty, the
get is attached. A redirecting host SHOULD be a redirect target applies to all hosts of the redirecting
host that was published in a HostMatch object by the uCDN as d uCDN.</dd>
efined in Section 4.1.2 of <xref target="RFC8006"/>.</t> </dl></dd>
<t>Type: A list of Endpoint objects (see Section 4.3.3 of <xref t arget="RFC8006"/>)</t> <dt>Property:</dt><dd><t>dns-target</t>
<t>Mandatory-to-Specify: No. If not present, or empty, the redire <dl newline="true" spacing="normal">
ct target applies to all hosts of the redirecting uCDN.</t>
</list></t>
<t>Property: dns-target<list style="empty">
<t>Description: Target CNAME record for DNS redirection.</t> <dt>Description:</dt><dd>Target CNAME record for DNS
redirection.</dd>
<t>Type: DnsTarget object (see <xref target="dns-target"/>)</t> <dt>Type:</dt><dd>DnsTarget object (see <xref target="dns-target"
format="default"/>)</dd>
<t>Mandatory-to-Specify: No. If the dns-target is not present or <dt>Mandatory-to-Specify:</dt><dd>No. If the dns-target is
empty the uCDN MUST interpret it as "no dns-target available".</t> absent or empty, the uCDN <bcp14>MUST</bcp14> interpret it as
</list></t> "no dns-target available".</dd>
<t>Property: http-target<list style="empty">
<t>Description: Target URI for a HTTP redirect.</t> </dl></dd>
<t>Type: HttpTarget object (see <xref target="http-target"/>)</t> <dt>Property:</dt><dd><t>http-target</t>
<t>Mandatory-to-Specify: No. If the http-target is not present or <dl newline="true" spacing="normal">
empty the uCDN MUST interpret it as "no http-target available".</t>
</list></t>
</list></t> <dt>Description:</dt><dd>Target URI for an HTTP redirect.</dd>
<dt>Type:</dt><dd>HttpTarget object (see <xref target="http-target
"
format="default"/>)</dd>
<dt>Mandatory-to-Specify:</dt><dd>No. If the http-target is
absent or empty, the uCDN <bcp14>MUST</bcp14> interpret it as
"no http-target available".</dd>
</dl></dd>
<t>The following is an example of a Redirect Target capability object s </dl>
erialization that advertises a dCDN target address
that is attached to a specific list of uCDN "redirecting-hosts". A u
CDN host that is included in that list can redirect
to the advertised dCDN redirect target. The capabilities object is s
erialized as a JSON object as defined in Section 5.1
of <xref target="RFC8008"/>
</t>
<figure> <t>The following is an example of a Redirect Target capability object
<artwork><![CDATA[ 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 <xref target="RFC8008" sectionFormat="of"
section="5.1"/>.</t>
<sourcecode name="" type="json"><![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.RedirectTarget", "capability-type": "FCI.RedirectTarget",
"capability-value": { "capability-value": {
"redirecting-hosts": [ "redirecting-hosts": [
"a.service123.ucdn.example.com", "a.service123.ucdn.example.com",
"b.service123.ucdn.example.com" "b.service123.ucdn.example.com"
], ],
"dns-target": { "dns-target": {
skipping to change at line 261 skipping to change at line 323
"path-prefix": "/cache/1/", "path-prefix": "/cache/1/",
"include-redirecting-host": true "include-redirecting-host": true
} }
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
]]></artwork> ]]></sourcecode>
</figure>
</section>
<section anchor="dns-target" title="DnsTarget Object">
<t>The DnsTarget object gives the target address for the DNS response t
o delegate from the uCDN to the dCDN.</t>
<t><list style="empty">
<t>Property: host<list style="empty">
<t>Description: The host property is a hostname or an IP address,
without a port number.</t>
<t>Type: Endpoint object as defined in Section 4.3.3 of <xref tar
get="RFC8006"/>
with the limitation that it SHOULD NOT include a port number
and, in case a port number is present,
the uCDN MUST ignore it.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section title="DNS Target Example">
<t>The following is an example of DnsTarget object:</t>
<figure>
<artwork><![CDATA[
{
"host": "service123.ucdn.dcdn.example.com"
}
]]></artwork>
</figure>
<t>The following is an example of a DNS query for uCDN address "a.se
rvice123.ucdn.example.com" and the corresponding
CNAME redirection response:</t>
<figure>
<artwork><![CDATA[
Query:
a.service123.ucdn.example.com:
type A, class IN
Response:
NAME: a.service123.ucdn.example.com, TYPE: CNAME, CLASS: IN,
TTL: 120, RDATA: service123.ucdn.dcdn.example.com
]]></artwork>
</figure>
</section>
</section> </section>
<section anchor="dns-target" numbered="true" toc="default">
<name>DnsTarget Object</name>
<t>The DnsTarget object gives the target address for the DNS response
to delegate from the uCDN to the dCDN.</t>
<section anchor="http-target" title="HttpTarget Object"> <dl newline="false" spacing="normal">
<t>The HttpTarget object gives the necessary information to construct t
he target Location URI for HTTP redirection.</t>
<t><list style="empty">
<t>Property: host<list style="empty">
<t>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 Section 3.2 of <xref target="RFC398
6"/>.</t>
<t>Type: Endpoint object as defined in Section 4.3.3 of <xref tar
get="RFC8006"/>.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: scheme<list style="empty">
<t>Description: A URI scheme to be used in the redirect response
location construction.
When present, the uCDN MUST use the provided scheme in for HTT
P redirection to the dCDN.</t>
<t>Type: A URI scheme as defined in Section 3.1 of <xref target=" <dt>Property:</dt><dd><t>host</t>
RFC3986"/> represented as a JSON string. The scheme MUST be
either "http" or "https".</t>
<t>Mandatory-to-Specify: No. If this property is absent or empty <dl newline="false" spacing="normal">
the uCDN request router MUST use the same scheme as was <dt>Description:</dt><dd>The host property is a hostname or an IP
used in the original request before redirection.</t> address, without a port number.</dd>
</list></t> <dt>Type:</dt><dd>Endpoint object as defined in <xref
<t>Property: path-prefix<list style="empty"> target="RFC8006" sectionFormat="of" section="4.3.3"/>, with the
limitation that it <bcp14>SHOULD NOT</bcp14> include a port
number and, in case a port number is present, the uCDN
<bcp14>MUST</bcp14> ignore it.</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
</dl></dd>
</dl>
<t>Description: A path prefix for the HTTP redirect Location head <section numbered="true" toc="default">
er. The original path is appended after this prefix.</t> <name>DnsTarget Example</name>
<t>The following is an example of the DnsTarget object:</t>
<sourcecode name="" type="json"><![CDATA[
{
"host": "service123.ucdn.dcdn.example.com"
}
]]></sourcecode>
<t>The following is an example of a DNS query for uCDN address
"a.service123.ucdn.example.com" and the corresponding CNAME
redirection response:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Query:
a.service123.ucdn.example.com:
type A, class IN
<t>Type: A prefix of a path-absolute as defined in Section 3.3 of Response:
<xref target="RFC3986"/>. NAME: a.service123.ucdn.example.com, TYPE: CNAME, CLASS: IN,
The prefix MUST end with a trailing slash, to indicate the end TTL: 120, RDATA: service123.ucdn.dcdn.example.com
of the last path segment in the prefix.</t> ]]></artwork>
</section>
</section>
<section anchor="http-target" numbered="true" toc="default">
<name>HttpTarget Object</name>
<t>The HttpTarget object gives the necessary information to construct
the target Location URI for HTTP redirection.</t>
<t>Mandatory-to-Specify: No. If this property is absent or empty, <dl newline="false" spacing="normal">
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.</t>
</list></t>
<t>Property: include-redirecting-host<list style="empty"> <dt>Property:</dt><dd><t>host</t>
<dl newline="false" spacing="normal">
<dt>Description:</dt><dd>Hostname or IP address and an optional
port, i.e., the host and port of the authority component of the
URI as described in <xref target="RFC3986" sectionFormat="of"
section="3.2"/>.</dd>
<dt>Type:</dt><dd>Endpoint object as defined in <xref
target="RFC8006" sectionFormat="of" section="4.3.3"/>.</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
</dl></dd>
<t>Description: A flag indicating whether or not to include the r <dt>Property:</dt><dd><t>scheme</t>
edirecting host as the first path segment after the path-prefix. <dl newline="false" spacing="normal">
If set to true and a "path-prefix" is used, the uCDN redirecti <dt>Description:</dt><dd>A URI scheme to be used in the redirect
ng host MUST be added as a separate path segment after response location construction. When present, the uCDN
the path-prefix and before the original URL path. If set to tr <bcp14>MUST</bcp14> use the provided scheme in for HTTP
ue and there is no path-prefix, the uCDN redirecting redirection to the dCDN.</dd>
host MUST be prepended as the first path segment in the redire <dt>Type:</dt><dd>A URI scheme as defined in <xref target="RFC3986
ct URL.</t> "
sectionFormat="of" section="3.1"/>, represented as a JSON
string. The scheme <bcp14>MUST</bcp14> be either "http" or
"https".</dd>
<dt>Mandatory-to-Specify:</dt><dd>No. If this property is absent o
r
empty, the uCDN request router <bcp14>MUST</bcp14> use the same
scheme as was used in the original request before
redirection.</dd>
</dl></dd>
<t>Type: Boolean.</t> <dt>Property:</dt><dd><t>path-prefix</t>
<dl newline="false" spacing="normal">
<dt>Description:</dt><dd>A path prefix for the HTTP redirect
Location header. The original path is appended after this
prefix.</dd>
<dt>Type:</dt><dd>A prefix of a path-absolute as defined in
<xref target="RFC3986" sectionFormat="of" section="3.3"/>. The
prefix <bcp14>MUST</bcp14> end with a trailing slash to indicate
the end of the last path segment in the prefix.</dd>
<dt>Mandatory-to-Specify:</dt><dd>No. If this property is absent
or empty, the uCDN <bcp14>MUST NOT</bcp14> prepend a path-prefix
to the original content path, i.e., the original path
<bcp14>MUST</bcp14> appear in the Location URI right after the
authority component.</dd>
</dl></dd>
<t>Mandatory-to-Specify: No. Default value is False.</t> <dt>Property:</dt><dd><t>include-redirecting-host</t>
</list></t> <dl newline="false" spacing="normal">
</list></t> <dt>Description:</dt><dd>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 <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be prepended as the first
path segment in the redirect URL.</dd>
<dt>Type:</dt><dd>Boolean.</dd>
<dt>Mandatory-to-Specify:</dt><dd>No. Default value is False.</dd>
</dl></dd>
<section title="HTTP Target Example"> </dl>
<t>Example of HttpTarget object with a "scheme", a "path-prefix", an
d "include-redirecting-host" properties:</t>
<figure> <section numbered="true" toc="default">
<artwork><![CDATA[ <name>HttpTarget Example</name>
<t>The following is an example of the HttpTarget object with a "scheme
", a "path-prefix",
and "include-redirecting-host" properties:</t>
<sourcecode name="" type="json"><![CDATA[
{ {
"host": "us-east1.dcdn.example.com", "host": "us-east1.dcdn.example.com",
"scheme": "https", "scheme": "https",
"path-prefix": "/cache/1/", "path-prefix": "/cache/1/",
"include-redirecting-host": true "include-redirecting-host": true
} }
]]></artwork> ]]></sourcecode>
</figure> <t>The following is an example of an HTTP request for content at uCDN
<t>Example of a HTTP request for content at uCDN host "a.service host
123.ucdn.example.com" and the corresponding HTTP response with "a.service123.ucdn.example.com" and the corresponding HTTP response
a Location header, used for redirecting the client to the dCD with a Location header, used for redirecting the client to the dCDN,
N, constructed according to the HttpTarget object from the above example:</t> constructed according to the HttpTarget object from the above
<figure> example:</t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Request: Request:
GET /vod/1/movie.mp4 HTTP/1.1 GET /vod/1/movie.mp4 HTTP/1.1
Host: a.service123.ucdn.example.com Host: a.service123.ucdn.example.com
Response: Response:
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: https://us-east1.dcdn.example.com/cache/1/ Location: https://us-east1.dcdn.example.com/cache/1/
a.service123.ucdn.example.com/vod/1/movie.mp4 a.service123.ucdn.example.com/vod/1/movie.mp4
]]></artwork> ]]></artwork>
</figure> </section>
</section>
</section> </section>
<section anchor="redirect-target-usage-example" numbered="true" toc="defau
lt">
<name>Usage Example</name>
<t>Before 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 <xref
target="RFC8006" sectionFormat="of" section="4.1.2"/>). Using the FCI,
the dCDN advertises (also out-of-band) the redirect target address
defined in <xref target="redirect-target-capability-properties"
format="default"/> 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.</t>
<section anchor="redirect-target-usage-example" title="Usage Example"> <figure anchor="redirect">
<t> <name>Redirect Target Address Advertisement</name>
Before requests can be routed from the uCDN to the dCDN the CDNs must <artwork name="" type="" align="left" alt=""><![CDATA[
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 Section 4.1.2 of
<xref target="RFC8006"/>.
The dCDN, using the FCI, advertises, also out-of-band, the redirect t
arget address object defined in
<xref target="redirect-target-capability-properties"/> for the releva
nt uCDN hosts.
The following is a generalized example of the message flow between an
upstream CDN and a downstream dCDN.
For simplicity, we focus on the sequence of messages between the uCDN
and dCDN and not on how they are passed.
</t>
<figure>
<artwork><![CDATA[
dCDN uCDN dCDN uCDN
+ + + +
| | | |
(1) | MI: host: s123.ucdn.example.com | (1) | MI: host: s123.ucdn.example.com |
| host-metadata: < metadata > | | host-metadata: < metadata > |
<-------------------------------------------------------+ <-------------------------------------------------------+
| | | |
(2) | FCI: capability-type: FCI.RedirectTarget | (2) | FCI: capability-type: FCI.RedirectTarget |
| redirecting-hosts: s123.ucdn.example.com | | redirecting-hosts: s123.ucdn.example.com |
| target host: us-east1.dcdn.example.com | | target host: us-east1.dcdn.example.com |
+-------------------------------------------------------> +------------------------------------------------------->
| | | |
| | | |
+ + + +
]]></artwork>
</figure>
Figure 1: Redirect target address advertisement <t>Explanation:
]]></artwork> </t>
</figure> <ol spacing="normal" type="(%d)">
<t><list style="numbers"> <li>The uCDN advertises a host (s123.ucdn.example.com) with the host
<t> metadata.</li>
The uCDN advertises a host (s123.ucdn.example.com) with the host me <li>The dCDN advertises its FCI objects to the uCDN, including a
tadata. Redirect Target capability object that contains the redirect target
</t> address (us-east1.dcdn.example.com) specified for that uCDN
<t> host.</li>
The dCDN advertises its FCI objects to the uCDN including a FCI.Red </ol>
irectTarget object that contains <t>Once the redirect target has been set, the uCDN can start
the redirect target address (us-east1.dcdn.example.com) specified f redirecting user requests to the dCDN. The following is a generic
or that uCDN host. sequence of redirection using the host and redirect target that were
</t> advertised in <xref target="redirect"/>.</t>
</list></t> <figure anchor="generic">
<name>Generic Request Redirection Sequence</name>
<t> <artwork name="" type="" align="left" alt=""><![CDATA[
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 Figure 1 above.
</t>
<figure>
<artwork><![CDATA[
End User dCDN uCDN RR End User dCDN uCDN RR
+ + + + + +
| | | | | |
(1) | Request sent s123.ucdn.example.com | (1) | Request sent s123.ucdn.example.com |
+-----------------------+-----------------------> +-----------------------+----------------------->
| | | | | |
(2) | Redirect to us-east1.dcdn.example.com | (2) | Redirect to us-east1.dcdn.example.com |
<-----------------------+-----------------------+ <-----------------------+-----------------------+
| | | | | |
(3) | Request us-east1.dcdn.example.com | (3) | Request us-east1.dcdn.example.com |
+-----------------------> | +-----------------------> |
| | | | | |
(4) | Response | | (4) | Response | |
<-----------------------+ | <-----------------------+ |
| | | | | |
+ + + + + +
]]></artwork>
</figure>
Figure 2: Generic requests redirection sequence <t>Explanation:</t>
]]></artwork> <ol spacing="normal" type="(%d)">
</figure> <li>The End User sends a request (DNS or HTTP) to the uCDN Request
<t><list style="numbers"> Router (RR).</li>
<t> <li>Using the previously advertised Redirect Target, the uCDN
The End User sends a request (DNS or HTTP) to the uCDN Request Rout redirects the request to the dCDN.</li>
er (RR). <li>The End User sends a request to the dCDN.</li>
</t> <li>The dCDN either sends a response or reroutes it, for example, to
<t> a dCDN surrogate.</li>
Using the previously advertised Redirect Target, the uCDN redirects </ol>
the request to the
dCDN.
</t>
<t>
The End User sends a request to the dCDN.
</t>
<t>
The dCDN either sends a response or reroutes it, for example, to a
dCDN surrogate.
</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="fallback-target-metadata" numbered="true" toc="default">
<name>Fallback Target Server Address</name>
<t>Open 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 <bcp14>MUST</bcp14> be different from the original
uCDN address from which the client was redirected to the dCDN. The uCDN
<bcp14>MUST</bcp14> avoid further redirection when receiving the client
request at the fallback target. The Fallback Target is defined as a
generic metadata object (see <xref target="RFC8006"
sectionFormat="of" section="3.2"/>).</t>
<t>Use cases:</t>
<ul spacing="normal">
<li>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.</li>
<li>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.</li>
<li>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".</li>
</ul>
<t>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 <xref target="RFC8006" sectionFormat="of"
section="4.3.3"/>.</t>
<t>In DNS redirection, a CNAME record is used as the fallback target
address.</t>
<t>In HTTP redirection, a hostname is used as the fallback target
address.</t>
<t>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.</t>
<section anchor="fallback-target-metadata-properties" numbered="true"
toc="default">
<name>Properties of Fallback Target Generic Metadata Object</name>
<section anchor="fallback-target-metadata" title="Fallback Target Address Me <t>The MI.FallbackTarget generic metadata object consists of the followi
tadata"> ng
<t>Open Caching requires that the uCDN provides a fallback target server t two properties:</t>
o the
dCDN, to be used in cases where the dCDN cannot properly handle the req
uest.
To avoid redirect loops, the fallback target server's address at the uC
DN MUST be
different from the original uCDN address from which the client was redi
rected
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 metada
ta object
(see Section 3.2 of <xref target="RFC8006"/>)</t>
<t>Use cases<list style="symbols">
<t>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.</t>
<t>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 o
r outside the dCDN
footprint coverage. In such cases, the router may choose to redirect
the request back
to the uCDN fallback address.</t>
<t>Error: A cache may receive a request that it cannot properly serve,
for
example, some of the metadata objects for that service were not prop
erly
acquired. In this case, the cache's "default action" may be to "redi
rect back to uCDN".</t>
</list></t>
<t>The Fallback target metadata object is used to indicate the target addr
ess the dCDN should redirect
a client to when falling back to the uCDN. Fallback target address is r
epresented as an endpoint
object as defined in Section 4.3.3 of <xref target="RFC8006"/>.</t>
<t>In DNS redirection a CNAME record is used as the fallback target addres
s.</t>
<t>In HTTP redirection a hostname is used as the fallback target address.<
/t>
<t>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 orig
inal uCDN request, stripping,
if needed, the dCDN path-prefix and/or the uCDN hostname from the redir
ect URL that may have been used to
request the content from the dCDN.</t>
<section anchor="fallback-target-metadata-properties" title="Properties of
Fallback Target Address Metadata Object">
<t>The MI.FallbackTarget Metadata object consists of the following sing
le property:</t>
<t><list style="empty">
<t>Property: host<list style="empty">
<t>Description: Target address to which the dCDN can redirect the
client.</t>
<t>Type: Endpoint object as defined in Section 4.3.3 of <xref tar
get="RFC8006"/>
with the limitation that in case of DNS delegation it SHOULD N
OT include a port number and,
in case a port number is present, the dCDN MUST ignore it.</t>
<t>Mandatory-to-Specify: Yes.</t> <dl newline="false" spacing="normal">
</list></t>
<t>Property: scheme<list style="empty">
<t>Description: A URI scheme to be used in the redirect response <dt>Property:</dt><dd><t>host</t>
location construction. <dl newline="false" spacing="normal">
When present, the dCDN MUST use this scheme in case of HTTP re <dt>Description:</dt><dd>Target address to which the dCDN can
direction to the redirect the client.</dd>
uCDN fallback address.</t> <dt>Type:</dt><dd>Endpoint object as defined in <xref
target="RFC8006" sectionFormat="of" section="4.3.3"/>, with the
limitation that in case of DNS delegation, it <bcp14>SHOULD
NOT</bcp14> include a port number, and in case a port number is
present, the dCDN <bcp14>MUST</bcp14> ignore it.</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
<t>Type: A URI scheme as defined in Section 3.1 of <xref target=" </dl></dd>
RFC3986"/> represented as a JSON string. The scheme MUST be
either "http" or "https".</t>
<t>Mandatory-to-Specify: No. In case of HTTP redirection to fallb <dt>Property:</dt><dd><t>scheme</t>
ack, if this property is absent or empty, <dl newline="false" spacing="normal">
the dCDN redirecting entity MUST use the same scheme as in the <dt>Description:</dt><dd>A URI scheme to be used in the redirect
request received by the dCDN.</t> response location construction. When present, the dCDN
</list></t> <bcp14>MUST</bcp14> use this scheme in case of HTTP redirection
</list></t> to the uCDN fallback address.</dd>
<dt>Type:</dt><dd>A URI scheme as defined in <xref target="RFC3986
"
sectionFormat="of" section="3.1"/>, represented as a JSON
string. The scheme <bcp14>MUST</bcp14> be either "http" or
"https".</dd>
<dt>Mandatory-to-Specify:</dt><dd>No. In case of HTTP redirection
to
fallback, if this property is absent or empty, the dCDN
redirecting entity <bcp14>MUST</bcp14> use the same scheme as in
the request received by the dCDN.</dd>
</dl></dd>
<t>Example of a MI.FallbackTarget Metadata object that designates the h </dl>
ost address
the dCDN should use as fallback address to redirect back to the uCDN
.</t>
<figure> <t>The following is an example of an MI.FallbackTarget generic
<artwork><![CDATA[ metadata object that designates the host address the dCDN should use
as fallback address to redirect back to the uCDN:</t>
<sourcecode name="" type="json"><![CDATA[
{ {
"generic-metadata-type": "MI.FallbackTarget", "generic-metadata-type": "MI.FallbackTarget",
"generic-metadata-value": "generic-metadata-value":
{ {
"host": "fallback-a.service123.ucdn.example", "host": "fallback-a.service123.ucdn.example",
"scheme": "https" "scheme": "https"
} }
} }
]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="fallback-address-usage-example" numbered="true" toc="defa
<section anchor="fallback-address-usage-example" title="Usage Example"> ult">
<t> <name>Usage Example</name>
The uCDN advertises out-of-band the fallback target address to the dC <t>The uCDN advertises out-of-band the fallback target address to the
DN, so that the dCDN dCDN, so that the dCDN may redirect a request back to the uCDN in case
may redirect a request back to the uCDN in case the dCDN cannot serve the dCDN cannot serve it. Using the MI, the uCDN advertises its hosts
it. to the dCDN, along with their specific host metadata (see <xref
Using the MI the uCDN advertises its hosts to the dCDN, along with th target="RFC8006" sectionFormat="of" section="4.1.2"/>). The Fallback
eir specific host metadata Target generic metadata object is encapsulated within the
(see Section 4.1.2 of <xref target="RFC8006"/>. The Fallback Target g "host-metadata" property of each host. The following is an example of
eneric metadata object is a message flow between a uCDN and a dCDN. For
encapsulated within the "host-metadata" property of each host. The fo simplicity, we focus on the sequence of messages between the uCDN and
llowing is an example of dCDN, not on how they are passed.</t>
a message flow between an upstream CDN and a downstream dCDN. For si <figure anchor="fallback">
mplicity, we focus on the <name>Advertisement of Host Metadata with Fallback Target</name>
sequence of messages between the uCDN and dCDN, not on how they are p <artwork name="" type="" align="left" alt=""><![CDATA[
assed.
</t>
<figure>
<artwork><![CDATA[
dCDN uCDN dCDN uCDN
+ + + +
| | | |
(1) | MI: host: s123.ucdn.example.com | (1) | MI: host: s123.ucdn.example.com |
| host-metadata: | | host-metadata: |
| < metadata objects > | | < metadata objects > |
| < MI.FallbackTarget | | < MI.FallbackTarget |
| host: fallback-a.service123.ucdn.example > | | host: fallback-a.service123.ucdn.example > |
| < metadata objects > | | < metadata objects > |
<-------------------------------------------------------+ <-------------------------------------------------------+
| | | |
(2) | FCI: capability-type: FCI.RedirectTarget | (2) | FCI: capability-type: FCI.RedirectTarget |
| redirecting-hosts: s123.ucdn.example.com | | redirecting-hosts: s123.ucdn.example.com |
| target host: us-east1.dcdn.example.com | | target host: us-east1.dcdn.example.com |
+-------------------------------------------------------> +------------------------------------------------------->
| | | |
| | | |
+ + + +
]]></artwork>
Figure 3: Advertisement of host metadata with Fallback Target </figure>
]]></artwork> <t>Explanation:
</figure> </t>
<t><list style="numbers"> <ol spacing="normal" type="(%d)">
<t> <li>The uCDN advertises a host (s123.ucdn.example.com) with the host
The uCDN advertises a host (s123.ucdn.example.com) with the host me metadata. The host-metadata property contains an MI.FallbackTarget
tadata. The host-metadata property generic metadata object.</li>
contains a MI.FallbackTarget object. <li>The dCDN advertises its FCI objects to the uCDN, including a
</t> Redirect Target capability object that contains the redirect target
<t> address (us-east1.dcdn.example.com) specified for that uCDN
The dCDN advertises its FCI objects to the uCDN including a FCI.Red host.</li>
irectTarget object that contains </ol>
the redirect target address (us-east1.dcdn.example.com) specified f <t>The following is a generic sequence of redirection using the
or that uCDN host. configurations that were advertised in <xref target="fallback"/>. In this
</t> case,
</list></t> the dCDN redirects back to the uCDN fallback target address.</t>
<figure anchor="redirection">
<t> <name>Redirection to Fallback Target</name>
The following is a generic sequence of redirection using the configur <artwork name="" type="" align="left" alt=""><![CDATA[
ations that were advertised in
Figure 3 above. In this case the dCDN redirects back to the uCDN fall
back target address.
</t>
<figure>
<artwork><![CDATA[
End User dCDN uCDN fallback uCDN RR End User dCDN uCDN fallback uCDN RR
+ + + + + + + +
| | | | | | | |
(1) | Request sent s123.ucdn.example.com | | (1) | Request sent s123.ucdn.example.com | |
+-------------------+-------------------+-------------------> +-------------------+-------------------+------------------->
| | | | | | | |
(2) | Redirect to us-east1.dcdn.example.com | | (2) | Redirect to us-east1.dcdn.example.com | |
<-------------------+-------------------+-------------------+ <-------------------+-------------------+-------------------+
| | | | | | | |
(3) | Request us-east1.dcdn.example.com | | (3) | Request us-east1.dcdn.example.com | |
skipping to change at line 624 skipping to change at line 714
(4) | Redirect back to fallback-a.service123.ucdn.example | (4) | Redirect back to fallback-a.service123.ucdn.example |
<-------------------+ | | <-------------------+ | |
| | | | | | | |
(5) | Request fallback-a.service123.ucdn.example | (5) | Request fallback-a.service123.ucdn.example |
+---------------------------------------> | +---------------------------------------> |
| | | | | | | |
(6) | Response | | | (6) | Response | | |
<-------------------+-------------------+ | <-------------------+-------------------+ |
| | | | | | | |
+ + + + + + + +
]]></artwork>
</figure>
Figure 4: Redirection to Fallback Target <t>Explanation:
]]></artwork> </t>
</figure> <ol spacing="normal" type="(%d)">
<t><list style="numbers"> <li>The End User sends a request (DNS or HTTP) to the uCDN Request
<t> Router (RR).</li>
The End User sends a request (DNS or HTTP) to the uCDN Request Rout <li>Using the previously advertised Redirect Target, the uCDN
er (RR). redirects the request to the dCDN.</li>
</t> <li>The End User sends a request to the dCDN.</li>
<t> <li>The dCDN cannot handle the request and therefore redirects it
Using the previously advertised Redirect Target, the uCDN redirects back to the uCDN fallback target address.</li>
the request to the <li>The End User sends the request to the uCDN fallback target
dCDN. address.</li>
</t> <li>The uCDN either sends a response or reroutes it, for example, to
<t> a uCDN surrogate.</li>
The End User sends a request to the dCDN. </ol>
</t>
<t>
The dCDN cannot handled the request and, therefore, redirects it ba
ck to the uCDN fallback
target address.
</t>
<t>
The End User sends the request to the uCDN fallback target address.
</t>
<t>
The uCDN either sends a response or reroutes it, for example, to a
uCDN surrogate.
</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="uCDN addressing considerations"> <name>uCDN Addressing Considerations</name>
<t>When advertising fallback addresses to the dCDN the uCDN SHOULD consi <t>When advertising fallback addresses to the dCDN, the uCDN
der the failure use cases that may <bcp14>SHOULD</bcp14> consider the failure use cases that may lead the
lead the dCDN to route requests to uCDN fallback. In extreme dCDN net dCDN to route requests to uCDN fallback. In extreme dCDN network
work failures or under denial-of-service failures or under denial-of-service (DoS) attacks, requests coming
(DoS) attacks, requests coming from a large segment or multiple segm from a large segment or multiple segments of the dCDN may be routed
ents of the dCDN may be routed back to the uCDN. back to the uCDN. The uCDN <bcp14>SHOULD</bcp14> therefore design its
The uCDN SHOULD therefore design its fallback addressing scheme and i fallback addressing scheme and its available resources accordingly. A
ts available resources accordingly. favorable approach would be for the uCDN to use a different fallback
A favorable approach would be for the uCDN to use different fallback target address for each uCDN host, enabling it to load balance the
target address for each uCDN host, requests using the same methods as it would for its original
enabling it to load balance the requests using the same methods as it hosts. See Sections <xref target="RFC8006" section="4.1.2"
would for its original hosts. sectionFormat="bare"/> and <xref target="RFC8006" section="4.1.3"
See Sections 4.1.2 and 4.1.3 of <xref target="RFC8006"/> for a detail sectionFormat="bare"/> of <xref target="RFC8006" format="default"/> for
ed description of how to use a detailed description of how to use GenericMetadata objects within
GenericMetadata objects within the HostMatch object advertised in the the HostMatch object advertised in the HostIndex of the uCDN.</t>
HostIndex of the uCDN.
</t>
</section> </section>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA.payload" title="CDNI Payload Types">
<t>This document requests the registration of the following CDNI Payload
Types
under the IANA "CDNI Payload Types" registry defined in <xref target=
"RFC7736"/>:</t>
<texttable>
<ttcol align="left">Payload Type</ttcol>
<ttcol align="left">Specification</ttcol>
<c>FCI.RedirectTarget</c>
<c>RFCthis</c>
<c>MI.FallbackTarget</c>
<c>RFCthis</c>
</texttable> <name>IANA Considerations</name>
<section anchor="IANA.payload" numbered="true" toc="default">
<name>CDNI Payload Types</name>
<t>IANA has registered the following CDNI
Payload Types in the "CDNI Payload Types" registry defined in
<xref target="RFC7736" format="default"/>:</t>
<table align="center">
<thead>
<tr>
<th align="left">Payload Type</th>
<th align="left">Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">FCI.RedirectTarget</td>
<td align="left">RFC 8804</td>
</tr>
<tr>
<td align="left">MI.FallbackTarget</td>
<td align="left">RFC 8804</td>
</tr>
</tbody>
</table>
<section anchor="IANA.payload.RedirectTarget" numbered="true" toc="defau
lt">
<name>CDNI FCI RedirectTarget Payload Type</name>
<t>[RFC Editor: Please replace RFCthis with the published RFC <dl newline="false" spacing="normal">
number for this document.]</t> <dt>Purpose:</dt><dd>The purpose of this payload type is to
distinguish FCI advertisement objects for redirect target.</dd>
<dt>Interface:</dt><dd>FCI</dd>
<dt>Encoding:</dt><dd>See <xref
target="redirect-target-capability-properties"
format="default"/>.</dd>
</dl>
<section anchor="IANA.payload.RedirectTarget" title="CDNI FCI RedirectTa
rget Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish RedirectTarget FCI objects</t>
<t>Interface: FCI</t>
<t>Encoding: see <xref target="redirect-target-capability-properties"/
></t>
</section>
<section anchor="IANA.payload.FallbackTarget" title="CDNI MI FallbackTar
get Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish FallbackTarget MI objects (and any associated capabilit
y advertisement)</t>
<t>Interface: MI/FCI</t>
<t>Encoding: see <xref target="fallback-target-metadata-properties"/><
/t>
</section> </section>
<section anchor="IANA.payload.FallbackTarget" numbered="true" toc="defau
lt">
<name>CDNI MI FallbackTarget Payload Type</name>
</section> <dl newline="false" spacing="normal">
</section> <dt>Purpose:</dt><dd>The purpose of this payload type is to distinguis
h
<section anchor="Security" title="Security Considerations"> FallbackTarget MI objects (and any associated capability
<t>This specification is in accordance with the CDNI Metadata Interface an advertisement).</dd>
d the CDNI Request Routing: <dt>Interface:</dt><dd>MI/FCI</dd>
Footprint and Capabilities Semantics. As such, it is subject to the sec <dt>Encoding:</dt><dd>See <xref target="fallback-target-metadata-prope
urity and privacy considerations as rties"
defined in Section 8 of <xref target="RFC8006"/> and in Section 7 of <x format="default"/>.</dd>
ref target="RFC8008"/> respectively. </dl>
</t>
<section anchor="Privacy" title="Confidentiality and Privacy">
<t>The Redirect Target FCI object potentially reveals information abou
t the internal structure of the dCDN network.
A third party could intercept the FCI transactions and use the info
rmation to attack the dCDN. The same is also
true for the Fallback Target Metadata object as it may reveal infor
mation 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 Section 8.3 of <xref target="RFC8006"/>.
</t>
</section> </section>
</section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="Acknowledgements" title="Acknowledgements"> <t>This specification defines extensions to the CDNI Metadata Interface
<t>The authors thank Nir B.&nbsp;Sopher for reality checks against product (MI) and the Footprint &amp; Capabilities Advertisement interface (FCI). A
ion use cases, his contribution is significant to this document. s such,
The authors also thank Ben Niven-Jenkins for his review and feedback an it is subject to the security and privacy considerations defined in
d Kevin J.&nbsp;Ma for his guidance throughout the development <xref target="RFC8006" sectionFormat="of" section="8"/> and in
of this document including his regular reviews.</t> <xref target="RFC8008" sectionFormat="of" section="7"/>,
respectively.</t>
<section anchor="Privacy" numbered="true" toc="default">
<name>Confidentiality and Privacy</name>
<t>The 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 obje
ct, as
it may reveal information about the internal structure of the uCDN,
exposing it to external exploits. Implementations of the FCI and MI
<bcp14>MUST</bcp14> therefore use strong authentication and encryption
and strictly follow the directions for securing the interface as
defined for the Metadata Interface in <xref target="RFC8006"
sectionFormat="of" section="8.3"/>.</t>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<name>References</name>
<?rfc include="reference.RFC.1034" ?> <references>
<name>Normative References</name>
<?rfc include="reference.RFC.2119" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1034.xml"/>
<?rfc include="reference.RFC.3986" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<?rfc include="reference.RFC.6707" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<?rfc include="reference.RFC.7231" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6707.xml"/>
<?rfc include="reference.RFC.7336" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7231.xml"/>
<?rfc include="reference.RFC.7975" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7336.xml"/>
<?rfc include="reference.RFC.8006" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7975.xml"/>
<?rfc include="reference.RFC.8007" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8006.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8007.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8008.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7736.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7871.xml"/>
<?rfc include="reference.RFC.8008" ?> <reference anchor="SVA" target="https://www.streamingvideoalliance.org">
<front>
<title>Streaming Video Alliance</title>
<author/>
</front>
</reference>
<?rfc include="reference.RFC.8174" ?> <reference anchor="OCWG" target="https://www.streamingvideoalliance.org/
technical-groups/open-caching/">
<front>
<title>Open Caching</title>
<author><organization>Streaming Video Alliance</organization>
</author>
</front>
</reference>
<reference anchor="OC-RR" target="https://www.streamingvideoalliance.org
/books/open-cache-request-routing-functional-specification/">
<front>
<title>
Open Cache Request Routing Functional Specification
</title>
<seriesInfo name="Version" value="1.1"/>
<author initials="O." surname="Finkelman" fullname="Ori Finkelman" r
ole="editor">
<organization>Qwilt</organization>
</author>
<author initials="J." surname="Hofmann" fullname="Jason Hofmann">
<organization>Limelight Networks</organization>
</author>
<author initials="E." surname="Klein" fullname="Eric Klein">
<organization>Disney Streaming Services</organization>
</author>
<author initials="S." surname="Mishra" fullname="Sanjay Mishra">
<organization>Verizon</organization>
</author>
<author initials="K." surname="Ma" fullname="Kevin J. Ma">
<organization>Disney Streaming Services</organization>
</author>
<author initials="D." surname="Sahar" fullname="Dan Sahar">
<organization>Qwilt</organization>
</author>
<author initials="B." surname="Zurat" fullname="Bill Zurat">
<organization>Disney Streaming Services</organization>
</author>
<date month="November" year="2016"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Nir B. Sopher"/> for reality check
s against
production use cases; his contribution is significant to this
document. The authors also thank <contact fullname="Ben Niven-Jenkins"/> f
or his review and
feedback and <contact fullname="Kevin J. Ma"/> for his guidance throughout
the
development of this document, including his regular reviews.</t>
</section>
<references title="Informative References">
<?rfc include="reference.RFC.7736" ?>
<?rfc include="reference.RFC.7871" ?>
<reference anchor="SVA" target="https://www.streamingvideoalliance.org">
<front>
<title>Streaming Video Alliance Home Page</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="OCWG" target="https://www.streamingvideoalliance.org/t
echnical-groups/open-caching/">
<front>
<title>Open Caching Home Page</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="OC-RR" target="https://www.streamingvideoalliance.org/b
ooks/open-cache-request-routing-functional-specification/">
<front>
<title>
Open Caching - Request Routing Functional Specification
</title>
<author initials="O." surname="Finkelman" fullname="Ori Finkelman" rol
e="editor">
<organization>Qwilt</organization>
</author>
<author initials="J." surname="Hofmann" fullname="Jason Hofmann">
<organization>Limelight Networks</organization>
</author>
<author initials="E." surname="Klein" fullname="Eric Klein">
<organization>Disney Streaming Services</organization>
</author>
<author initials="S." surname="Mishra" fullname="Sanjay Mishra">
<organization>Verizon</organization>
</author>
<author initials="K." surname="Ma" fullname="Kevin J. Ma">
<organization>Disney Streaming Services</organization>
</author>
<author initials="D." surname="Sahar" fullname="Dan Sahar">
<organization>Qwilt</organization>
</author>
<author initials="B." surname="Zurat" fullname="Bill Zurat">
<organization>Disney Streaming Services</organization>
</author>
<date day="4" month="October" year="2019"/>
</front>
<seriesInfo name="Version" value="1.1"/>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 98 change blocks. 
794 lines changed or deleted 734 lines changed or added

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