summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8804.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8804.txt')
-rw-r--r--doc/rfc/rfc8804.txt871
1 files changed, 871 insertions, 0 deletions
diff --git a/doc/rfc/rfc8804.txt b/doc/rfc/rfc8804.txt
new file mode 100644
index 0000000..39bf258
--- /dev/null
+++ b/doc/rfc/rfc8804.txt
@@ -0,0 +1,871 @@
+
+
+
+
+Internet Engineering Task Force (IETF) O. Finkelman
+Request for Comments: 8804 Qwilt
+Category: Standards Track S. Mishra
+ISSN: 2070-1721 Verizon
+ September 2020
+
+
+ Content Delivery Network Interconnection (CDNI) Request Routing
+ Extensions
+
+Abstract
+
+ Open 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8804.
+
+Copyright Notice
+
+ Copyright (c) 2020 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
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Terminology
+ 1.2. Requirements Language
+ 2. Redirect Target Capability
+ 2.1. DNS Redirect Target
+ 2.2. HTTP Redirect Target
+ 2.3. Properties of Redirect Target Capability Object
+ 2.4. DnsTarget Object
+ 2.4.1. DnsTarget Example
+ 2.5. HttpTarget Object
+ 2.5.1. HttpTarget Example
+ 2.6. Usage Example
+ 3. Fallback Target Server Address
+ 3.1. Properties of Fallback Target Generic Metadata Object
+ 3.2. Usage Example
+ 3.3. uCDN Addressing Considerations
+ 4. IANA Considerations
+ 4.1. CDNI Payload Types
+ 4.1.1. CDNI FCI RedirectTarget Payload Type
+ 4.1.2. CDNI MI FallbackTarget Payload Type
+ 5. Security Considerations
+ 5.1. Confidentiality and Privacy
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ Acknowledgements
+ Authors' Addresses
+
+1. Introduction
+
+ The Streaming Video Alliance [SVA] 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 [OCWG] of
+ the Streaming Video Alliance [SVA] 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 [OC-RR] defines the Request
+ Routing process and the interfaces that are required for its
+ provisioning. This document defines the CDNI metadata object
+ [RFC8006] and the CDNI Footprint and Capabilities object [RFC8008]
+ that are required for Open Caching Request Routing:
+
+ * Redirect Target Capability (for dCDN advertising redirect target
+ address)
+
+ * Fallback Target Metadata (for uCDN configuring fallback target
+ address)
+
+ This document also registers CDNI Payload Types [RFC7736] 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.
+
+1.1. Terminology
+
+ The following terms are used throughout this document:
+
+ FQDN Fully Qualified Domain Name
+
+ CDN Content Delivery Network
+
+ Additionally, this document reuses the terminology defined in
+ [RFC6707], [RFC7336], [RFC8006], [RFC8007], and [RFC8008].
+ Specifically, we use the following CDNI acronyms:
+
+ FCI Footprint & Capabilities Advertisement interface (see
+ [RFC8008])
+
+ MI Metadata Interface (see [RFC8006])
+
+ uCDN Upstream CDN (see [RFC7336])
+
+ dCDN Downstream CDN (see [RFC7336])
+
+ 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.
+
+1.2. Requirements Language
+
+ The 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 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. Redirect Target Capability
+
+ Iterative CDNI Request Redirection is defined in Section 1.1 of
+ [RFC7336] and elaborated by examples in Sections 3.2 and 3.4 of
+ [RFC7336]. A Redirection Target (RT) is defined in Section 2 of
+ [RFC7975] 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.
+ Section 4.3 of [RFC7336] suggests that it could be one of the roles
+ of the FCI [RFC8008]. 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.
+
+2.1. DNS Redirect Target
+
+ A redirect target for DNS redirection is an FQDN used as an alias in
+ a CNAME record response (see [RFC1034]) 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 [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 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 Section 2 of [RFC7871] and SHOULD follow the
+ guidelines provided in Section 11.1 of [RFC7871].
+
+2.2. HTTP Redirect Target
+
+ 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 Section 7.1.2 of [RFC7231] and
+ Section 6.4 of [RFC7231]).
+
+2.3. Properties of Redirect Target Capability Object
+
+ The 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
+ Section 4.1.2 of [RFC8006].
+
+ Type: A list of Endpoint objects (see Section 4.3.3 of [RFC8006])
+
+ 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 Section 2.4)
+
+ 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 Section 2.5)
+
+ 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 Section 5.1 of [RFC8008].
+
+ {
+ "capabilities": [
+ {
+ "capability-type": "FCI.RedirectTarget",
+ "capability-value": {
+ "redirecting-hosts": [
+ "a.service123.ucdn.example.com",
+ "b.service123.ucdn.example.com"
+ ],
+ "dns-target": {
+ "host": "service123.ucdn.dcdn.example.com"
+ },
+ "http-target": {
+ "host": "us-east1.dcdn.example.com",
+ "path-prefix": "/cache/1/",
+ "include-redirecting-host": true
+ }
+ },
+ "footprints": [
+ <Footprint objects>
+ ]
+ }
+ ]
+ }
+
+2.4. DnsTarget Object
+
+ The 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 Section 4.3.3 of [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.
+
+ Mandatory-to-Specify: Yes.
+
+2.4.1. DnsTarget Example
+
+ The following is an example of the DnsTarget object:
+
+ {
+ "host": "service123.ucdn.dcdn.example.com"
+ }
+
+ The following is an example of a DNS query for uCDN address
+ "a.service123.ucdn.example.com" and the corresponding CNAME
+ redirection response:
+
+ 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
+
+2.5. HttpTarget Object
+
+ The 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 Section 3.2 of [RFC3986].
+
+ Type: Endpoint object as defined in Section 4.3.3 of [RFC8006].
+
+ 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 Section 3.1 of [RFC3986],
+ 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 Section 3.3 of
+ [RFC3986]. 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.
+
+2.5.1. HttpTarget Example
+
+ The following is an example of the HttpTarget object with a "scheme",
+ a "path-prefix", and "include-redirecting-host" properties:
+
+ {
+ "host": "us-east1.dcdn.example.com",
+ "scheme": "https",
+ "path-prefix": "/cache/1/",
+ "include-redirecting-host": true
+ }
+
+ 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:
+
+ Request:
+ GET /vod/1/movie.mp4 HTTP/1.1
+ Host: a.service123.ucdn.example.com
+
+ Response:
+ HTTP/1.1 302 Found
+ Location: https://us-east1.dcdn.example.com/cache/1/
+ a.service123.ucdn.example.com/vod/1/movie.mp4
+
+2.6. Usage Example
+
+ 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
+ Section 4.1.2 of [RFC8006]). Using the FCI, the dCDN advertises
+ (also out-of-band) the redirect target address defined in Section 2.3
+ 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.
+
+ dCDN uCDN
+ + +
+ | |
+ (1) | MI: host: s123.ucdn.example.com |
+ | host-metadata: < metadata > |
+ <-------------------------------------------------------+
+ | |
+ (2) | FCI: capability-type: FCI.RedirectTarget |
+ | redirecting-hosts: s123.ucdn.example.com |
+ | target host: us-east1.dcdn.example.com |
+ +------------------------------------------------------->
+ | |
+ | |
+ + +
+
+ Figure 1: Redirect Target Address Advertisement
+
+ Explanation:
+
+ (1) The uCDN advertises a host (s123.ucdn.example.com) with the host
+ metadata.
+
+ (2) 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 Figure 1.
+
+ End User dCDN uCDN RR
+ + + +
+ | | |
+ (1) | Request sent s123.ucdn.example.com |
+ +-----------------------+----------------------->
+ | | |
+ (2) | Redirect to us-east1.dcdn.example.com |
+ <-----------------------+-----------------------+
+ | | |
+ (3) | Request us-east1.dcdn.example.com |
+ +-----------------------> |
+ | | |
+ (4) | Response | |
+ <-----------------------+ |
+ | | |
+ + + +
+
+ Figure 2: Generic Request Redirection Sequence
+
+ Explanation:
+
+ (1) The End User sends a request (DNS or HTTP) to the uCDN Request
+ Router (RR).
+
+ (2) Using the previously advertised Redirect Target, the uCDN
+ redirects the request to the dCDN.
+
+ (3) The End User sends a request to the dCDN.
+
+ (4) The dCDN either sends a response or reroutes it, for example, to
+ a dCDN surrogate.
+
+3. Fallback Target Server Address
+
+ 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 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 Section 3.2 of [RFC8006]).
+
+ 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 Section 4.3.3 of [RFC8006].
+
+ 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.
+
+3.1. Properties of Fallback Target Generic Metadata Object
+
+ The 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 Section 4.3.3 of [RFC8006],
+ 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 Section 3.1 of [RFC3986],
+ 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:
+
+ {
+ "generic-metadata-type": "MI.FallbackTarget",
+ "generic-metadata-value":
+ {
+ "host": "fallback-a.service123.ucdn.example",
+ "scheme": "https"
+ }
+ }
+
+3.2. Usage Example
+
+ The 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
+ Section 4.1.2 of [RFC8006]). 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.
+
+ dCDN uCDN
+ + +
+ | |
+ (1) | MI: host: s123.ucdn.example.com |
+ | host-metadata: |
+ | < metadata objects > |
+ | < MI.FallbackTarget |
+ | host: fallback-a.service123.ucdn.example > |
+ | < metadata objects > |
+ <-------------------------------------------------------+
+ | |
+ (2) | FCI: capability-type: FCI.RedirectTarget |
+ | redirecting-hosts: s123.ucdn.example.com |
+ | target host: us-east1.dcdn.example.com |
+ +------------------------------------------------------->
+ | |
+ | |
+ + +
+
+ Figure 3: Advertisement of Host Metadata with Fallback Target
+
+ Explanation:
+
+ (1) The uCDN advertises a host (s123.ucdn.example.com) with the host
+ metadata. The host-metadata property contains an
+ MI.FallbackTarget generic metadata object.
+
+ (2) 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 Figure 3. In this case, the
+ dCDN redirects back to the uCDN fallback target address.
+
+ End User dCDN uCDN fallback uCDN RR
+ + + + +
+ | | | |
+ (1) | Request sent s123.ucdn.example.com | |
+ +-------------------+-------------------+------------------->
+ | | | |
+ (2) | Redirect to us-east1.dcdn.example.com | |
+ <-------------------+-------------------+-------------------+
+ | | | |
+ (3) | Request us-east1.dcdn.example.com | |
+ +-------------------> | |
+ | | | |
+ (4) | Redirect back to fallback-a.service123.ucdn.example |
+ <-------------------+ | |
+ | | | |
+ (5) | Request fallback-a.service123.ucdn.example |
+ +---------------------------------------> |
+ | | | |
+ (6) | Response | | |
+ <-------------------+-------------------+ |
+ | | | |
+ + + + +
+
+ Figure 4: Redirection to Fallback Target
+
+ Explanation:
+
+ (1) The End User sends a request (DNS or HTTP) to the uCDN Request
+ Router (RR).
+
+ (2) Using the previously advertised Redirect Target, the uCDN
+ redirects the request to the dCDN.
+
+ (3) The End User sends a request to the dCDN.
+
+ (4) The dCDN cannot handle the request and therefore redirects it
+ back to the uCDN fallback target address.
+
+ (5) The End User sends the request to the uCDN fallback target
+ address.
+
+ (6) The uCDN either sends a response or reroutes it, for example, to
+ a uCDN surrogate.
+
+3.3. uCDN Addressing Considerations
+
+ When 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 4.1.2 and 4.1.3 of
+ [RFC8006] for a detailed description of how to use GenericMetadata
+ objects within the HostMatch object advertised in the HostIndex of
+ the uCDN.
+
+4. IANA Considerations
+
+4.1. CDNI Payload Types
+
+ IANA has registered the following CDNI Payload Types in the "CDNI
+ Payload Types" registry defined in [RFC7736]:
+
+ +====================+===============+
+ | Payload Type | Specification |
+ +====================+===============+
+ | FCI.RedirectTarget | RFC 8804 |
+ +--------------------+---------------+
+ | MI.FallbackTarget | RFC 8804 |
+ +--------------------+---------------+
+
+ Table 1
+
+4.1.1. 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 Section 2.3.
+
+4.1.2. 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 Section 3.1.
+
+5. Security Considerations
+
+ This 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 Section 8 of [RFC8006] and in Section 7 of [RFC8008],
+ respectively.
+
+5.1. Confidentiality and Privacy
+
+ 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 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
+ Section 8.3 of [RFC8006].
+
+6. References
+
+6.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+ <https://www.rfc-editor.org/info/rfc1034>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <https://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
+ Distribution Network Interconnection (CDNI) Problem
+ Statement", RFC 6707, DOI 10.17487/RFC6707, September
+ 2012, <https://www.rfc-editor.org/info/rfc6707>.
+
+ [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+ DOI 10.17487/RFC7231, June 2014,
+ <https://www.rfc-editor.org/info/rfc7231>.
+
+ [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
+ "Framework for Content Distribution Network
+ Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
+ August 2014, <https://www.rfc-editor.org/info/rfc7336>.
+
+ [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed.,
+ "Request Routing Redirection Interface for Content
+ Delivery Network (CDN) Interconnection", RFC 7975,
+ DOI 10.17487/RFC7975, October 2016,
+ <https://www.rfc-editor.org/info/rfc7975>.
+
+ [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
+ "Content Delivery Network Interconnection (CDNI)
+ Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
+ <https://www.rfc-editor.org/info/rfc8006>.
+
+ [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network
+ Interconnection (CDNI) Control Interface / Triggers",
+ RFC 8007, DOI 10.17487/RFC8007, December 2016,
+ <https://www.rfc-editor.org/info/rfc8007>.
+
+ [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
+ R., and K. Ma, "Content Delivery Network Interconnection
+ (CDNI) Request Routing: Footprint and Capabilities
+ Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
+ <https://www.rfc-editor.org/info/rfc8008>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+6.2. Informative References
+
+ [OC-RR] Finkelman, O., Ed., Hofmann, J., Klein, E., Mishra, S.,
+ Ma, K., Sahar, D., and B. Zurat, "Open Cache Request
+ Routing Functional Specification", Version 1.1, November
+ 2016, <https://www.streamingvideoalliance.org/books/open-
+ cache-request-routing-functional-specification/>.
+
+ [OCWG] Streaming Video Alliance, "Open Caching",
+ <https://www.streamingvideoalliance.org/technical-groups/
+ open-caching/>.
+
+ [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
+ Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
+ December 2015, <https://www.rfc-editor.org/info/rfc7736>.
+
+ [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
+ Kumari, "Client Subnet in DNS Queries", RFC 7871,
+ DOI 10.17487/RFC7871, May 2016,
+ <https://www.rfc-editor.org/info/rfc7871>.
+
+ [SVA] "Streaming Video Alliance",
+ <https://www.streamingvideoalliance.org>.
+
+Acknowledgements
+
+ The authors thank Nir B. Sopher for reality checks against production
+ use cases; his contribution is significant to this document. The
+ authors also thank Ben Niven-Jenkins for his review and feedback and
+ Kevin J. Ma for his guidance throughout the development of this
+ document, including his regular reviews.
+
+Authors' Addresses
+
+ Ori Finkelman
+ Qwilt
+ 6, Ha'harash
+ Hod HaSharon 4524079
+ Israel
+
+ Email: ori.finkelman.ietf@gmail.com
+
+
+ Sanjay Mishra
+ Verizon
+ 13100 Columbia Pike
+ Silver Spring, MD 20904
+ United States of America
+
+ Email: sanjay.mishra@verizon.com