One document matched: draft-ietf-cdni-redirection-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6707 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6707.xml">
<!ENTITY rfc7159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY rfc7336 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7336.xml">
<!ENTITY rfc7337 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7337.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY rfc5952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY rfc7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY rfc6895 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
<!ENTITY rfc2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc5288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5288.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-cdni-redirection-08" ipr="trust200902">
<front>
<title abbrev="Request Routing Redirection">Request Routing Redirection
Interface for CDN Interconnection</title>
<author fullname="Ben Niven-Jenkins" initials="B." role="editor"
surname="Niven-Jenkins">
<organization>Velocix (Alcatel-Lucent)</organization>
<address>
<postal>
<street>3 Ely Road</street>
<city>Milton</city>
<region>Cambridge</region>
<code>CB24 6DD</code>
<country>UK</country>
</postal>
<email>ben.niven-jenkins@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Ray van Brandenburg" initials="R." role="editor"
surname="van Brandenburg">
<organization>TNO</organization>
<address>
<postal>
<street>Brassersplein 2</street>
<city>Delft</city>
<region/>
<code>2612CT</code>
<country>the Netherlands</country>
</postal>
<phone>+31-88-866-7000</phone>
<facsimile/>
<email>ray.vanbrandenburg@tno.nl</email>
<uri/>
</address>
</author>
<date day="" month="" year=""/>
<abstract>
<t>The Request Routing Interface comprises of (1) the asynchronous
advertisement of footprint and capabilities by a downstream CDN that
allows an upstream CDN to decide whether to redirect particular user
requests to that downstream CDN; and (2) the synchronous operation of an
upstream CDN requesting whether a downstream CDN is prepared to accept a
user request and of a downstream CDN responding with how to actually
redirect the user request. This document describes an interface for the
latter part, i.e. the CDNI Request Routing Redirection interface.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>A Content Delivery Network (CDN) is a system built on an existing IP
network which is used for large scale content delivery, via prefetching
or dynamically caching content on its distributed surrogates (caching
servers). <xref target="RFC6707"/> describes the problem area of
interconnecting CDNs.</t>
<t>The CDNI Request Routing interface outlined in <xref
target="RFC7336"/> comprises of:</t>
<t><list style="numbers">
<t>The asynchronous advertisement of footprint and capabilities by a
downstream CDN (dCDN) that allows an upstream CDN (uCDN) to decide
whether to redirect particular user requests to that dCDN.</t>
<t>The synchronous operation of a uCDN requesting whether a dCDN is
prepared to accept a user request and of a dCDN responding with how
to actually redirect the user request.</t>
</list></t>
<t>This document describes an interface for the latter part, i.e. the
CDNI Request Routing Redirection interface (RI).</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>This document reuses the terminology defined in <xref
target="RFC6707"/>.</t>
<t>The following additional terms are introduced by this document:</t>
<t>Application Level Redirection: The act of using an application
specific redirection mechanism for the request routing process of a CDN.
The Redirection Target (RT) is the result of the routing decision of a
CDN at the time it receives a content request via an application
specific protocol response. Examples of an application level redirection
are HTTP 302 Redirection and RTMP 302 Redirection.</t>
<t>DNS Redirection: The act of using DNS name resolution for the request
routing process of a CDN. In DNS Redirection, the DNS name server of the
CDN makes the routing decision based on a local policy and selects one
or more Redirection Targets (RTs) and redirects the user agent to the
RT(s) by returning the details of the RT(s) in response to the DNS query
request from the user agent's DNS resolver.</t>
<t>HTTP Redirection: The act of using an HTTP redirection response for
the request routing process of a CDN. The Redirection Target (RT) is the
result of the routing decision of a CDN at the time it receives a
content request via HTTP. HTTP Redirection is a particular case of
Application Level Redirection.</t>
<t>Redirection Target (RT): A Redirection Target is the endpoint to
which the user agent is redirected. In CDNI, a 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, etc.</t>
</section>
<section title="Interface function and operation overview">
<t>The main function of the CDNI Redirection interface (RI) is to allow
the request routing systems in interconnected CDNs to communicate to
facilitate the redirection of User Agent requests between interconnected
CDNs.</t>
<t>The detailed requirements for the Redirection Interface and their
relative priorities are described in section 5 of <xref
target="RFC7337"/>.</t>
<t>The User Agent will make a request to a request router in the uCDN
using one of either DNS or HTTP. The RI is used between the uCDN and one
or more dCDNs. The dCDN's RI response may contain a Redirection Target
with a type that is compatible with the protocol used between User Agent
and uCDN request router. The dCDN has control over the Redirection
Target it provides. Depending on the returned Redirection Target, the
User Agent's request may be redirected to:</t>
<t><list style="symbols">
<t>The final Surrogate, which may be in the dCDN that returned the
RI response to the uCDN, or another CDN (if the dCDN delegates the
delivery to another CDN).</t>
<t>A request router (in the dCDN or another CDN), which may use a
different redirection protocol (DNS or HTTP) than the one included
in the RI request.</t>
</list></t>
<t>The Redirection interface operates between the request routing
systems of a pair of interconnected CDNs. To enable communication over
the Redirection Interface, the uCDN needs to know the URI (end point) in
the dCDN to send CDNI request routing queries.</t>
<t>The Redirection Interface URI may be statically pre-configured,
dynamically discovered via the CDNI Control interface, or discovered via
other means. However, such discovery mechanisms are not specified in
this document, as they are considered out of the scope of the
Redirection Interface specification.</t>
<t>The Redirection Interface is only relevant in the case of Recursive
Request Redirection, as Iterative Request Redirection does not invoke
any interaction over the Redirection Interface between interconnected
CDNs. Therefore the scope of this document is limited to Recursive
Request Redirection.</t>
<t>In the case of Recursive Request Redirection, in order to perform
redirection of a request received from a User Agent, the uCDN queries
the dCDN so that the dCDN can select and provide a Redirection Target.
In cases where a uCDN has a choice of dCDNs it is up to the uCDN to
decide (for example via configured policies) which dCDN(s) to query and
in which order to query them. A number of strategies are possible
including selecting a preferred dCDN based on local policy, possibly
falling back to querying an alternative dCDN(s) if the first dCDN does
not return a Redirection Target or otherwise rejects the uCDN's RI
request. A more complex strategy could be to query multiple dCDNs in
parallel before selecting one and using the Redirection Target provided
by that dCDN.</t>
<t>The uCDN->User Agent redirection protocols addressed in this draft
are: DNS redirection and HTTP redirection. Other types of application
level redirection will not be discussed further in this document.
However, the Redirection Interface is designed to be extensible and
could be extended to support additional application level redirection
protocols.</t>
<t>This document also defines an RI loop prevention and detection
mechanism as part of the Redirection Interface.</t>
</section>
<section title="HTTP based interface for the Redirection Interface">
<t>This document defines a simple interface for the Redirection
Interface based on HTTP 1.1 <xref target="RFC7230"/>, where the
attributes of a User Agent's requests are encapsulated along with any
other data that can aid the dCDN in processing the requests. The RI
response encapsulates the attributes of the RT(s) that the uCDN should
return to the User Agent (if it decides to utilize the dCDN for
delivery) along with the policy for how the response can be reused. The
examples of RI requests and responses below do not contain a complete
set of HTTP headers for brevity; only the pertinent HTTP headers are
shown.</t>
<t>The same HTTP interface is used for both DNS and HTTP redirection of
User Agent requests, although the contents of the RI requests/responses
contain data specific to either DNS or HTTP redirection.</t>
<t>This approach has been chosen because it enables CDN operators to
only have to deploy a single interface for the RI between their CDNs,
regardless of the User Agent redirection method. In this way, from an
operational point of view there is only one interface to monitor,
manage, develop troubleshooting tools for, etc.</t>
<t>In addition, having a single RI where the attributes of the User
Agent's DNS or HTTP request are encapsulated along with the other data
required for the dCDN to make a request routing decision, avoids having
to try and encapsulate or proxy DNS/HTTP/RTMP/etc requests and find ways
to somehow embed the additional CDNI Request Routing Redirection
interface properties/data within those End User DNS/HTTP/RTMP/etc
requests.</t>
<t>Finally, the RI is easily extendable to support other User Agent
request redirection methods (e.g. RTMP 302 redirection).</t>
<t>The generic Recursive Request Redirection message flow between
Request Routing systems in a pair of interconnected CDNs is as
follows:</t>
<t/>
<figure anchor="generic-message-flow"
title="Generic Recursive Request Redirection message flow">
<artwork><![CDATA[User Agent CDN B RR CDN A RR
|UA Request (DNS or HTTP) | |
|-------------------------------------------------->| (1)
| | |
| |HTTP POST to CDN B's RI |
| |URI encapsulating UA |
| |request attributes |
| |<------------------------| (2)
| | |
| |HTTP Response with body |
| |containing RT attributes |
| |of the protocol specific |
| |response to return to UA |
| |------------------------>| (3)
| | |
| Protocol specific response (redirection)|
|<--------------------------------------------------| (4)
| | |]]></artwork>
</figure>
<t/>
<t><list style="numbers">
<t>The User Agent sends its (DNS or HTTP) request to CDN A. The
Request Routing System of CDN A processes the request and, through
local policy, recognizes that the request is best served by another
CDN, specifically CDN B (or that CDN B may be one of a number of
candidate dCDNs it could use).</t>
<t>The Request Routing System of CDN A sends an HTTP POST to CDN B's
RI URI containing the attributes of the User Agent's request.</t>
<t>The Request Routing System of CDN B processes the RI request and
assuming the request is well formed, responds with an HTTP "200"
response with a message body containing the RT(s) to return to the
User Agent as well as parameters that indicate the properties of the
response (cacheability and scope).</t>
<t>The Request Routing System of CDN A sends a protocol specific
response (containing the returned attributes) to the User Agent, so
that the User Agent's request will be redirected to the RT(s)
returned by CDN B.</t>
</list></t>
<section title="Information passed in RI requests & responses">
<t>The information passed in RI requests splits into two basic
categories:</t>
<t><list style="numbers">
<t>The attributes of the User Agent's request to the uCDN.</t>
<t>Properties/parameters that the uCDN can use to control the
dCDN’s response or that can help the dCDN make its
decision.</t>
</list></t>
<t>To assist the routing decision of a dCDN, the uCDN SHOULD convey as
much information as possible to the dCDN, for example the URI of the
requested content and the User Agent's IP address or subnet, when
those are known by the uCDN Request Routing system.</t>
<t>In order for the dCDN to determine whether it is capable of
delivering any requested content, it requires CDNI metadata related to
the content the User Agent is requesting. That metadata will describe
the content and any policies associated with it. It is expected that
the RI request contains sufficient information for the Request Router
in the dCDN to be able to retrieve the required CDNI Metadata via the
CDNI Metadata interface.</t>
<t>The information passed in RI responses splits into two basic
categories:</t>
<t><list style="numbers">
<t>The attributes of the RT to return to the User Agent in the DNS
response or HTTP response.</t>
<t>Parameters/policies that indicate the properties of the
response, such as, whether it is cacheable, the scope of the
response, etc.</t>
</list></t>
<t>In addition to details of how to redirect the User Agent, the dCDN
may wish to return additional policy information to the uCDN to it
with future RI requests. For example the dCDN may wish to return a
policy that expresses “this response can be reused without
requiring an RI request for 60 seconds provided the User Agent's IP
address is in the range 198.51.100.0 - 198.51.100.255”.</t>
<t>These additional policies split into two basic categories:</t>
<t><list style="symbols">
<t>Cacheability information signaled via the HTTP response headers
of the RI response (to reduce the number of subsequent RI requests
the uCDN needs to make).</t>
<t>The scope of the response (if it is cacheable) signaled the
HTTP response body of the RI response. For example whether the
response applies to a wider range of IP addresses than what was
included in the RI request.</t>
</list></t>
<t>The cacheability of the response is indicated using the standard
HTTP Cache-Control mechanisms.</t>
</section>
<section title="JSON encoding of RI requests & responses">
<t>The body of RI requests and responses is a JSON object <xref
target="RFC7159"/> containing a dictionary of key:value pairs.</t>
<t>The following additional rules apply to all keys in RI requests and
responses (whether in the top level object or in sub-objects):</t>
<t><list style="symbols">
<t>Keys MUST always be encoded in lowercase.</t>
<t>Requests and responses MUST NOT contain duplicate keys.</t>
<t>Unknown keys MUST be ignored but the request or response MUST
NOT be considered invalid unless the syntax of the request or
response is invalid (i.e. an RI request or response MUST NOT be
considered invalid on the basis that it contains unknown
keys).</t>
<t>Requests or responses containing duplicate keys or containing
keys that are not all lowercase MUST be considered syntactically
invalid.</t>
</list></t>
<t>The following top level keys are defined along with whether they
are applicable to RI requests, RI responses or both:</t>
<texttable title="Top-Level keys in RI requests/responses">
<ttcol>Key</ttcol>
<ttcol>Request/Response</ttcol>
<ttcol>Description</ttcol>
<c>dns</c>
<c>Both</c>
<c>The attributes of the UA's DNS request or the attributes of the
RT(s) to return in a DNS response.</c>
<c>http</c>
<c>Both</c>
<c>The attributes of the UA's HTTP request or the attributes of the
RT to return in a HTTP response.</c>
<c>scope</c>
<c>Response</c>
<c>The scope of the response (if it is cacheable). For example
whether the response applies to a wider range of IP addresses than
what was included in the RI request.</c>
<c>error</c>
<c>Response</c>
<c>Additional details if the response is an error response.</c>
<c>cdn-path</c>
<c>Both</c>
<c>A List of Strings. Contains a list of the CDN Provider IDs of
previous CDNs that have participated in the request routing for the
associated User Agent request. On RI requests it contains the list
of previous CDNs that this RI request has passed through. On RI
responses it contains the list of CDNs that were involved in
obtaining the final redirection included in the RI response.</c>
<c>max-hops</c>
<c>Request</c>
<c>Integer specifying the maximum number of hops (CDN Provider IDs)
this request is allowed to be propagated along. This allows the uCDN
to coarsely constrain the latency of the request routing chain.</c>
</texttable>
<t>A single request or response MUST contain only one of the dns or
http keys. Requests MUST contain a cdn-path key and responses MAY
contain a cdn-path key. If the max-hops key is not present then there
is no limit on the number of CDN hops that the RI request can be
propagated along. If the first uCDN does not wish the RI request to be
propagated beyond the dCDN it is making the request to, then the uCDN
MUST set max-hops to 1.</t>
<t>When cascading an RI request, a transit CDN MUST append its own CDN
Provider ID to the list in cdn-path so that dCDNs can detect loops in
the RI request chain. Transit CDNs MUST check the cdn-path and MUST
NOT cascade the RI request to dCDNs that are already listed in
cdn-path. Transit CDNs MUST NOT modify the cdn-path when cascading an
RI request, except to append its own CDN Provider ID.</t>
<t>The cdn-path MAY be reflected back in RI responses, although doing
so could expose information to the uCDN that a dCDN may not wish to
expose (for example, the existence of business relationships between a
dCDN and other CDNs).</t>
<t>If the cdn-path is reflected back in the RI response it MUST
contain the value of cdn-path received in the associated RI request
with the final dCDN's CDN Provider ID appended. Transit CDNs MAY
remove the cdn-path from RI responses but MUST NOT modify the cdn-path
in other ways.</t>
<t>The presence of an error key within a response that also contains
either a dns or http key does not automatically indicate that the RI
request was unsuccessful as the error key MAY be used for
communicating additional (e.g. debugging) information. When a response
contains an error key as well as either a dns or http key, the
error-code SHOULD be 1xx (e.g. 100). See <xref target="error"/> for
more details of encoding error information in RI responses.</t>
<t>Note: All implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of <xref
target="RFC3986"/> and MUST support all IPv6 address formats specified
in <xref target="RFC4291"/>. Server implementations SHOULD use IPv6
address formats specified in <xref target="RFC5952"/>.</t>
</section>
<section title="MIME Media Types used by the RI interface">
<t>RI requests MUST use a MIME Media Type of
application/cdni.redirectionrequest+json.</t>
<t>RI responses MUST use a MIME Media Type of
application/cdni.redirectionresponse+json.</t>
</section>
<section title="DNS redirection">
<t>The following sections provide detailed descriptions of the
information that should be passed in RI requests and responses for DNS
redirection.</t>
<section title="DNS Redirection requests">
<t>For DNS based redirection the uCDN needs to pass the following
information to the dCDN in the RI request:</t>
<t><list style="symbols">
<t>The IP address of the DNS resolver that made the DNS request
to the uCDN.</t>
<t>The type of DNS query made (usually either A or AAAA).</t>
<t>The class of DNS query made (usually IN).</t>
<t>The fully qualified domain name for which DNS redirection is
being requested.</t>
<t>The IP address or prefix of the User Agent (if known to the
uCDN).</t>
</list></t>
<t>The information above is encoded as a set of key:value pairs
within the dns dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>resolver-ip</c>
<c>String</c>
<c>Yes</c>
<c>The IP address of the UA's DNS resolver.</c>
<c>qtype</c>
<c>String</c>
<c>Yes</c>
<c>The type of DNS query made by the UA's DNS resolvers in
uppercase (A, AAAA, etc.).</c>
<c>qclass</c>
<c>String</c>
<c>Yes</c>
<c>The class of DNS query made in uppercase (IN, etc.).</c>
<c>qname</c>
<c>String</c>
<c>Yes</c>
<c>The fully qualified domain name being queried.</c>
<c>c-subnet</c>
<c>String</c>
<c>No</c>
<c>The IP address (or prefix) of the UA in CIDR format.</c>
<c>dns-only</c>
<c>Boolean</c>
<c>No</c>
<c>If True then dCDN MUST only use DNS redirection and MUST
include RTs to one or more surrogates in its RI response. CDNs
MUST include the dns-only property set to True on any cascaded RI
requests. Defaults to False.</c>
</texttable>
<t>An RI request for DNS-based redirection MUST include a dns
dictionary. This dns dictionary MUST contain the following keys:
resolver-ip, qtype, qclass, qname and the value of each MUST be the
value of the appropriate part of the User Agent's DNS
query/request.</t>
<t>An example RI request (uCDN->dCDN) for DNS based
redirection:</t>
<t/>
<figure>
<artwork><![CDATA[POST /dcdn/ri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni.redirectionrequest+json
Accept: application/cdni.redirectionresponse+json
{
"dns" : {
"resolver-ip" : "192.0.2.1",
"c-subnet" : "198.51.100.0/24",
"qtype" : "A",
"qclass" : "IN",
"qname" : "www.example.com"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
]]></artwork>
</figure>
</section>
<section anchor="dns-redirection-response"
title="DNS Redirection responses">
<t>For a successful DNS based redirection, the dCDN needs to return
one of the following to the uCDN in the RI response:</t>
<t><list style="symbols">
<t>The IP address(es) of (or the CNAME of) RTs that are dCDN
surrogates (if the dCDN is performing DNS based redirection
directly to a surrogate); or</t>
<t>The IP address(es) of (or the CNAME of) RTs that are Request
Routers (if the dCDN will perform request redirection itself). A
dCDN MUST NOT return a RT which is a Request Router if the
dns-only key is set to True in the RI request.</t>
</list></t>
<t>The information above is encoded as a set of key:value pairs
within the dns dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>rcode</c>
<c>Integer</c>
<c>Yes</c>
<c>DNS response code (see <xref target="RFC6895"/>).</c>
<c>name</c>
<c>String</c>
<c>Yes</c>
<c>The fully qualified domain name the response relates to.</c>
<c>a</c>
<c>List of String</c>
<c>No</c>
<c>Set of IPv4 Addresses of RT(s).</c>
<c>aaaa</c>
<c>List of String</c>
<c>No</c>
<c>Set of IPv6 Addresses of RT(s).</c>
<c>cname</c>
<c>List of String</c>
<c>No</c>
<c>Set of fully qualified domain names of RT(s).</c>
<c>ttl</c>
<c>Integer</c>
<c>No</c>
<c>TTL in seconds of DNS response. Default is 0.</c>
</texttable>
<t>A successful RI response for DNS-based redirection MUST include a
dns dictionary and MAY include an error dictionary (see <xref
target="error"/>). An unsuccessful RI response for DNS-based
redirection MUST include an error dictionary. If a dns dictionary is
included in the RI response, it MUST include at least one of the
following keys: a, aaaa, cname. The dns dictionary MAY include both
'a' and 'aaaa' keys. If the dns dictionary contains a cname key it
MUST NOT contain either an a or aaaa key.</t>
<t>An example of a successful RI response (dCDN->uCDN) for DNS
based redirection with both a and aaaa keys is listed below :</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}
]]></artwork>
</figure>
<t/>
<t>A further example of a successful RI response (dCDN->uCDN) for
DNS based redirection is listed below, in this case with a cname key
containing the FQDN of the RT.</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"cname" : ["rr1.dcdn.example"],
"ttl" : 20
}
}]]></artwork>
</figure>
<t/>
</section>
</section>
<section title="HTTP Redirection">
<t>The following sections provide detailed descriptions of the
information that should be passed in RI requests and responses for
HTTP redirection.</t>
<t>The dictionary keys used in HTTP Redirection requests and responses
use the following conventions for their prefixes:</t>
<t><list style="symbols">
<t>c- is prefixed to keys for information related to the Client
(User Agent).</t>
<t>cs- is prefixed to keys for information passed by the Client
(User Agent) to the Server (uCDN).</t>
<t>sc- is prefixed to keys for information to be passed by the
Server (uCDN) to the Client (User Agent).</t>
</list></t>
<section title="HTTP Redirection requests">
<t>For HTTP-based redirection the uCDN needs to pass the following
information to the dCDN in the RI request:</t>
<t><list style="symbols">
<t>The IP address of the User Agent.</t>
<t>The URI requested by the User Agent.</t>
<t>The HTTP method requested by the User Agent</t>
<t>The HTTP version number requested by the User Agent.</t>
</list></t>
<t>The uCDN may also decide to pass the presence and value of
particular HTTP headers included in the User Agent request to the
dCDN.</t>
<t>The information above is encoded as a set of key:value pairs
within the http dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>c-ip</c>
<c>String</c>
<c>Yes</c>
<c>The IP address of the UA.</c>
<c>cs-uri</c>
<c>String</c>
<c>Yes</c>
<c>The Effective Request URI <xref target="RFC7230"/> requested by
the UA.</c>
<c>cs-method</c>
<c>String</c>
<c>Yes</c>
<c>The method part of the request-line as defined in <xref
target="RFC7230">Section 3.1.1 of</xref>.</c>
<c>cs-version</c>
<c>String</c>
<c>Yes</c>
<c>The HTTP-version part of the request-line as defined in <xref
target="RFC7230">Section 3.1.1 of</xref>.</c>
<c>cs(<headername>)</c>
<c>String</c>
<c>No</c>
<c>The field-value of the HTTP header field named
<HeaderName> as a string, for example cs(cookie) would
contain the value of the HTTP Cookie header.</c>
</texttable>
<t>An RI request for HTTP-based redirection MUST include an http
dictionary. This http dictionary MUST contain the following keys:
c-ip, cs-method, cs-version and cs-uri and the value of each MUST be
the value of the appropriate part of the User Agent's HTTP
request.</t>
<t>The http dictionary of an RI request MUST contain a maximum of
one cs(<headername>) key for each unique header field-name
(HTTP header field). <headername> MUST be identical to the
equivalent HTTP header field-name encoded in all lowercase.</t>
<t>In the case where the User Agent request includes multiple HTTP
header fields with the same field-name, it is RECOMMENDED that the
uCDN combines these different HTTP headers into a single value
according to <xref target="RFC7230">Section 3.2.2 of</xref>.
However, because of the plurality of already defined HTTP header
fields, and inconsistency of some of these header fields concerning
the combination mechanism defined in RFC 7230, the uCDN MAY have to
deviate from using the combination mechanism where appropriate. For
example, it MAY only send the contents of the first occurrence of
the HTTP Headers instead.</t>
<t>An example RI request (uCDN->dCDN) for HTTP based
redirection:</t>
<t/>
<figure>
<artwork><![CDATA[POST /dcdn/rrri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni.redirectionrequest+json
Accept: application/cdni.redirectionresponse+json
{
"http": {
"c-ip": "198.51.100.1",
"cs-uri": "http://www.example.com",
"cs-version": "HTTP/1.1",
"cs-method": "GET"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
]]></artwork>
</figure>
</section>
<section anchor="http-redirection-response"
title="HTTP Redirection responses">
<t/>
<t>For a successful HTTP based redirection, the dCDN needs to return
one of the following to the uCDN in the RI response:<list
style="symbols">
<t>A URI pointing to an RT that is the selected dCDN
surrogate(s) (if the dCDN is performing HTTP based redirection
directly to a surrogate); or</t>
<t>A URI pointing to an RT that is a Request Router (if the dCDN
will perform request redirection itself).</t>
</list></t>
<t/>
<t>The information above is encoded as a set of key:value pairs
within the http dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>sc-status</c>
<c>Integer</c>
<c>Yes</c>
<c>The status-code part of the status-line as defined in <xref
target="RFC7230">Section 3.1.2 of</xref> to return to the UA
(usually set to 302).</c>
<c>sc-version</c>
<c>String</c>
<c>Yes</c>
<c>The HTTP-version part of the status-line as defined in <xref
target="RFC7230">Section 3.1.2 of</xref> to return to the UA.</c>
<c>sc-reason</c>
<c>String</c>
<c>Yes</c>
<c>The reason-phrase part of the status-line as defined in <xref
target="RFC7230">Section 3.1.2 of</xref> to return to the UA.</c>
<c>cs-uri</c>
<c>String</c>
<c>Yes</c>
<c>The URI requested by the UA/client.</c>
<c>sc(location)</c>
<c>String</c>
<c>Yes</c>
<c>The contents of the Location header to return to the UA (i.e. a
URI pointing to the RT(s)).</c>
<c>sc(cache-control)</c>
<c>String</c>
<c>No</c>
<c>The contents of the Cache-Control header to return to the
UA.</c>
<c>sc(<headername>)</c>
<c>String</c>
<c>No</c>
<c>The field-value of the HTTP header field named
<HeaderName> to return to the UA. For example, sc(expires)
would contain the value of the HTTP Expires header.</c>
</texttable>
<t>A successful RI response for HTTP-based redirection MUST include
an http dictionary and MAY include an error dictionary (see <xref
target="error"/>). An unsuccessful RI response for HTTP-based
redirection MUST include an error dictionary. If an http dictionary
is included in the RI response, it MUST include at least the
following keys: sc-status, sc-version, sc-reason, cs-uri,
sc(location).</t>
<t>The http dictionary of an RI response MUST contain a maximum of
one sc(<headername>) key for each unique header field-name
(HTTP header field). <headername> MUST be identical to the
equivalent HTTP header field-name encoded in all lowercase.</t>
<t>The uCDN MAY decide to not return, override or alter any or all
of the HTTP headers defined by sc(<headername>) keys before
sending the HTTP response to the UA. It should be noted that in some
cases, sending the HTTP Headers indicated by the dCDN transparently
on to the UA might result in, for the uCDN, undesired behaviour. As
an example, the dCDN might include sc(last-modified) and sc(expires)
keys in the http dictionary, through which the dCDN may try to
influence the cacheability of the response by the UA. If the uCDN
would pass these HTTP headers on to the UA, this could mean that
further requests from the uCDN would go directly to the dCDN,
bypassing the uCDN and any logging it may perform on incoming
requests. The uCDN is therefore recommended to carefully consider
which HTTP headers to pass on, and which to either override or not
pass on at all.</t>
<t>An example of a successful RI response (dCDN->uCDN) for HTTP
based redirection:</t>
<t/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc(cache-control)" : "public, max-age=30"
}
}
]]></artwork>
</figure>
</section>
</section>
<section title="Cacheability and scope of responses">
<t>RI responses may be cacheable. As long as a cached RI response is
not stale according to standard HTTP Cache-Control or other applicable
mechanisms, it may be reused by the uCDN in response to User Agent
requests without sending another RI request to the dCDN.</t>
<t>An RI response MUST NOT be reused unless the request from the User
Agent would generate an identical RI request to the dCDN as the one
that resulted in the cached RI response (except for the c-ip field
provided that the User Agent's c-ip is covered by the scope in the
original RI response, as elaborated upon below).</t>
<t>Additionally, although RI requests only encode a single User Agent
request to be redirected there may be cases where a dCDN wishes to
indicate to the uCDN that the RI response can be reused for other User
Agent requests without the uCDN having to make another request via the
RI. For example a dCDN may know that it will always select the same
Surrogates for a given set of User Agent IP addresses and in order to
reduce request volume across the RI or to remove the additional
latency associated with an RI request, the dCDN may wish to indicate
that set of User Agent IP addresses to the uCDN in the initial RI
response. This is achieved by including an optional scope dictionary
in the RI response.</t>
<t>Scope is encoded as a set of key:value pairs within the scope
dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>iprange</c>
<c>List of String</c>
<c>No</c>
<c>A List of IP subnets in CIDR notation that this RI response can
be reused for, provided the RI response is still considered
fresh.</c>
</texttable>
<t>If a uCDN has multiple cached responses with overlapping scopes and
a UA request comes in for which the User Agent's IP matches with the
IP subnets in multiple of these cached responses, the uCDN SHOULD use
the most recent cached response when determining the approriate RI
response to use.</t>
<t>The following is an example of a DNS redirection response from
<xref target="dns-redirection-response"/> that is cacheable by the
uCDN for 30 seconds and can be returned to any User Agent with an IPv4
address in 198.51.100.0/24.</t>
<t/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
Cache-Control: public, max-age=30
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
]]></artwork>
</figure>
<t/>
<t>Example of HTTP redirection response from <xref
target="http-redirection-response"/> that is cacheable by the uCDN for
60 seconds and can be returned to any User Agent with an IPv4 address
in 198.51.100.0/24.</t>
<t>Note: The response to the UA is only valid for 30 seconds, whereas
the uCDN can cache the RI response for 60 seconds.</t>
<t/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
Cache-Control: public, max-age=60
{
"http": {
"sc-status": 302,
"cs-uri": "http://www.example.com"
"sc(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc(cache-control)" : "public, max-age=30"
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
]]></artwork>
</figure>
<t/>
</section>
<section anchor="error" title="Error responses">
<t>From a uCDN perspective, there are two types of errors that can be
the result of the transmission of an RI request to a dCDN:</t>
<t><list style="numbers">
<t>An HTTP protocol error signaled via an HTTP status code,
indicating a problem with the reception or parsing of the RI
request or the generation of the RI response by the dCDN, and</t>
<t>An RI-level error specified in an RI response message</t>
</list></t>
<t>This section deals with the latter type. The former type is outside
the scope of this document.</t>
<t>There are numerous reasons for a dCDN to be unable to return an
affirmative RI response to a uCDN. Reasons may include both dCDN
internal issues such as capacity problems, as well as reasons outside
the influence of the dCDN, such as a malformed RI request. To aid with
diagnosing the cause of errors, RI responses SHOULD include an error
dictionary to provide additional information to the uCDN as to the
reason/cause of the error. The intention behind the error dictionary
is to aid with either manual or automatic diagnosis of issues. The
resolution of such issues is outside the scope of this document; this
document does not specify any consequent actions a uCDN should take
upon receiving a particular error code.</t>
<t>Error information (if present) is encoded as a set of key:value
pairs within a JSON-encoded error dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>error-code</c>
<c>Integer</c>
<c>No</c>
<c>A three-digit numeric code defined by the server to indicate the
error(s) that occurred.</c>
<c>reason</c>
<c>String</c>
<c>No</c>
<c>A string providing further information related to the error.</c>
</texttable>
<t>The first digit of the error-code defines the class of error. There
are 5 classes of error distinguished by the first digit of the
error-code:</t>
<t><list style="empty">
<t>1xx: Informational (no error): The response should not be
considered an error by the uCDN, which may proceed by redirecting
the UA according to the values in the RI response. The error code
and accompanying description may be used for informational
purposes, e.g. for logging.</t>
<t>2xx: Reserved.</t>
<t>3xx: Reserved.</t>
<t>4xx: uCDN error: The dCDN can not or will not process the
request due to something that is perceived to be a uCDN error, for
example the RI request could not be parsed succesfully by the
dCDN. The last two-digits may be used to more specifically
indicate the source of the problem.</t>
<t>5xx: dCDN error: Indicates that the dCDN is aware that it has
erred or is incapable of satisfying the RI request for some
reason, for example the dCDN was able to parse the RI request but
encountered an error for some reason. Examples include the dCDN
not being able to retrieve the associated metadata or the dCDN
being out of capacity.</t>
</list></t>
<t>The following error codes are defined and maintained by IANA (see
<xref target="iana_section"/>):</t>
<t>Error codes with a "Reason" of "<reason>" do not have a
defined value for their 'reason'-key. Depending on the error-code
semantics, the value of this field may be determined dynamically.</t>
<texttable anchor="error_codes">
<ttcol>Code</ttcol>
<ttcol>Reason</ttcol>
<ttcol>Description</ttcol>
<c>100</c>
<c><reason> (see Description)</c>
<c>Generic informational error-code meant for carrying a
human-readable string</c>
<c>400</c>
<c><reason> (see Description)</c>
<c>Generic error-code for uCDN errors where the dCDN can not or will
not process the request due to something that is perceived to be a
uCDN error. The reason field may be used to provide more details
about the source of the error.</c>
<c>500</c>
<c><reason> (see Description)</c>
<c>Generic error-code for dCDN errors where the dCDN is aware that
it has erred or is incapable of satisfying the RI request for some
reason. The reason field may be used to provide more details about
the source of the error.</c>
<c>501</c>
<c>Unable to retrieve metadata</c>
<c>The dCDN is unable to retrieve the metadata associated with the
content requested by the UA. This may indicate a configuration error
or the content requested by the UA not existing.</c>
<c>502</c>
<c>Loop detected</c>
<c>The dCDN detected a redirection loop (see <xref
target="loop_detection"/>).</c>
<c>503</c>
<c>Maximum hops exceeded</c>
<c>The dCDN detected the maximum number of redirection hops
exceeding max-hops (see <xref target="loop_detection"/>).</c>
<c>504</c>
<c>Out of capacity</c>
<c>The dCDN does not currently have sufficient capacity to handle
the UA request.</c>
<c>505</c>
<c>Delivery protocol not supported</c>
<c>The dCDN does not support the (set of) delivery protocols
indicated in the CDNI Metadata of the content requested content by
the UA.</c>
<c>506</c>
<c>Redirection protocol not supported</c>
<c>The dCDN does not support the requested redirection protocol.
This error-code is also used when the RI request has the dns-only
flag set to True and the dCDN is not support or is not prepared to
return a RT of a surrogate directly.</c>
</texttable>
<t>The following is an example of an unsuccessful RI response
(dCDN->uCDN) for a DNS based User Agent request:</t>
<figure>
<artwork><![CDATA[HTTP/1.1 500 Internal Server Error
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
Cache-Control: private, no-cache
{
"error" : {
"code" : 504,
"description" : "Out of capacity"
}
}
]]></artwork>
</figure>
<t/>
<t>The following is an example of a successful RI response
(dCDN->uCDN) for a HTTP based User Agent request containing an
error dictionary for informational purposes:</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
Cache-Control: private, no-cache
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc(cache-control)" : "public, max-age=30"
},
"error" : {
"code" : 100,
"description" :
"This is a human-readable message meant for debugging purposes"
}
}
]]></artwork>
</figure>
</section>
<section anchor="loop_detection" title="Loop detection & prevention">
<t>In order to prevent and detect RI request loops, each CDN MUST
insert its CDN Provider ID into the cdn-path key of every RI request
it originates or cascades. When receiving RI requests a dCDN MUST
check the cdn-path and reject any RI requests which already contain
the dCDN's Provider ID in the cdn-path. Transit CDNs MUST check the
cdn-path and not cascade the RI request to dCDNs that are already
listed in cdn-path. Transit CDNs MUST NOT propagate to any downstream
CDNs if the number of CDN Provider IDs in cdn-path (before adding its
own Provider ID) is equal to or greater than max-hops.</t>
<t>The CDN Provider ID uniquely identifies each CDN provider during
the course of request routing redirection. It consists of the
characters AS followed by the CDN Provider's AS number, then a colon
(':') and an additional qualifier that is used to guarantee uniqueness
in case a particular AS has multiple independent CDNs deployed. For
example "AS64496:0".</t>
<t>If a dCDN receives an RI request whose cdn-path already contains
that dCDN's Provider ID the dCDN SHOULD send an RI response with an
error code of 502.</t>
<t>If a dCDN receives an RI request where the number of CDN Provider
IDs in cdn-path is greater than max-hops, the dCDN SHOULD send an RI
response with an error code of 503.</t>
<t>It should be noted that the loop detection & prevention
mechanisms described above only cover preventing and detecting loops
within the RI itself. As well as loops within the RI itself, there is
also the possibility of loops in the data plane, for example if the IP
address(es) or URI(s) returned in RI responses do not resolve directly
to a surrogate in the final dCDN there is the possibility that a User
Agent may be continuosly redirected through a loop of CDNs. The
specification of solutions to address data plane request redirection
loops between CDNs is outside of the scope of this document.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Information passed over the RI could be considered personal or
sensitive, for example RI requests contain parts of a User Agent's
original request and RI responses reveal information about the dCDN's
policy for which surrogates should serve which content/user
locations.</t>
<t>The RI interface also provides a mechanism whereby a uCDN could probe
a dCDN and infer the dCDN's edge topology by making repeated RI requests
for different content and/or UA IP addresses and correlating the
responses from the dCDN. Additionally the ability for a dCDN to indicate
that an RI response applies more widely than the original request (via
the scope dictionary) may significantly reduce the number of RI requests
required to probe and infer the dCDN's edge topology.</t>
<t>The same information could be obtained in the absence of the RI
interface, but it could be more difficult to gather as it would require
a distributed set of machines with a range of different IP addresses
each making requests directly to the dCDN. However, the RI facilitates
easier collection of such information as it enables a single client to
query the dCDN for a redirection/surrogate selection on behalf of any UA
IP address.</t>
<t>An implementation of the CDNI Redirection interface MUST support TLS
transport as per <xref target="RFC2818"/> and <xref target="RFC7230"/>.
The use of TLS for transport of the CDNI Redirection interface messages
allows:</t>
<t><list style="symbols">
<t>The dCDN and uCDN to authenticate each other (to ensure they are
transmitting/receiving CDNI Redirection minterface messages from an
authenticated CDN).</t>
<t>CDNI Redirection interface messages to be transmitted with
confidentiality.</t>
<t>The integrity of the CDNI Redirection interface messages to be
protected during the exchange.</t>
</list></t>
<t>In an environment where any such protection is required, TLS SHOULD
be used (including authentication of the remote end) by the server-side
(dCDN) and the client-side (uCDN) of the CDNI Redirection interface
unless alternate methods are used for ensuring the confidentiality of
the information in the CDNI Redirection interface messages (such as
setting up an IPsec tunnel between the two CDNs or using a physically
secured internal network between two CDNs that are owned by the same
corporate entity).</t>
<t>An implementation of the CDNI Redirection interface MUST support the
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite (<xref
target="RFC5288"/>). An implementation of the CDNI Redirection interface
SHOULD prefer cipher suites which support perfect forward secrecy over
cipher suites that don't.</t>
</section>
<section anchor="iana_section" title="IANA Considerations">
<section title="Media type registrations">
<t/>
<section title="CDNI RI requests">
<t>The MIME media type for CDNI RI requests is
application/cdni.redirectionrequest+json.</t>
<t>Type Name: application</t>
<t>Subtype name: cdni.redirectionrequest+json</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: binary</t>
<t>Security Considerations: See [RFCthis], <xref
target="security"/></t>
<t>Interoperability Considerations: Described in [RFCthis]</t>
<t>Published Specification: [RFCthis]</t>
<t>Applications that use this media type: No known applications
currently use this media type.</t>
<t>Additional Information:</t>
<t><list style="empty">
<t>Deprecated alias names for this type: N/A</t>
<t>Magic number(s): N/A</t>
<t>File Extensions: N/A</t>
<t>Macintosh file type code(s): TEXT</t>
</list></t>
<t>Person & email address to contact for further information:
IESG <iesg@ietf.org></t>
<t>Intended Useage: COMMON</t>
<t>Restrictions on usage: None</t>
<t>Author: Ben Niven-Jenkins
<ben.niven-jenkins@alcatel-lucent.com></t>
<t>Change controller: IESG <iesg@ietf.org></t>
<t>Note: No "charset" parameter is defined for this registration
because a charset parameter is not defined for application/json
<xref target="RFC7159"/>.</t>
</section>
<section title="CDNI RI responses">
<t>The MIME media type for CDNI RI responses is
application/cdni.redirectionresponse+json.</t>
<t>Type Name: application</t>
<t>Subtype name: cdni.redirectionresponse+json</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: binary</t>
<t>Security Considerations: See [RFCthis], <xref
target="security"/></t>
<t>Interoperability Considerations: Described in [RFCthis]</t>
<t>Published Specification: [RFCthis]</t>
<t>Applications that use this media type: No known applications
currently use this media type.</t>
<t>Additional Information:</t>
<t><list style="empty">
<t>Deprecated alias names for this type: N/A</t>
<t>Magic number(s): N/A</t>
<t>File Extensions: N/A</t>
<t>Macintosh file type code(s): TEXT</t>
</list></t>
<t>Person & email address to contact for further information:
IESG <iesg@ietf.org></t>
<t>Intended Useage: COMMON</t>
<t>Restrictions on usage: None</t>
<t>Author: Ben Niven-Jenkins
<ben.niven-jenkins@alcatel-lucent.com></t>
<t>Change controller: IESG <iesg@ietf.org></t>
<t>Note: No "charset" parameter is defined for this registration
because a charset parameter is not defined for application/json
<xref target="RFC7159"/>.</t>
</section>
</section>
<section title="RI Error response registry">
<t>This document establishes a new IANA registry for CDNI RI Error
response codes.</t>
<t>An expert reviewer is advised to examine new registrations for
possible duplication with existing error codes and to ensure that the
new code is in accordance with the error classes defined in section
<xref target="error"/> of this document.</t>
<t>New registrations are required to provide the following
information:</t>
<t><list style="empty">
<t>Code: A three-digit numeric error-code, in accordance with the
error classes defined in section <xref target="error"/> of this
document.</t>
<t>Reason: A string that provides further information related to
the error that will be included in the JSON error dictionary with
the 'reason'-key. Depending on the error-code semantics, the value
of this field may be determined dynamically. In that case, the
registration should set this value to '<reason>' and define
its semantics in the description field.</t>
<t>Description: A brief description of the error code
semantics.</t>
<t>Specification: An optional reference to a specification that
defines in the error code in more detail.</t>
</list></t>
<t>The entries in <xref target="error_codes"/> are registered by this
document.</t>
</section>
</section>
<section title="Contributors">
<t>[RFC Editor Note: Please move the contents of this section to the
Authors' Addresses section prior to publication as an RFC.]</t>
<t>The following persons have participated as co-authors to this
document:</t>
<t><list style="empty">
<t>Wang Danhua, Huawei, Email: wangdanhua@huawei.com</t>
<t>He Xiaoyan, Huawi, Email: hexiaoyan@huawei.com</t>
<t>Ge Chen, China Telecom, Email: cheng@gsta.com</t>
<t>Ni Wei, China Mobile, Email: niwei@chinamobile.com</t>
<t>Yunfei Zhang, Email:hishigh@gmail.com</t>
<t>Spencer Dawkins, Huawei, Email: spencer@wonderhamster.org</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Taesang Choi, Francois le Faucheur
and Scott Wainner for their valuable comments and input to this
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3986;
&rfc4291;
&rfc5952;
&rfc7230;
&rfc7159;
&rfc6895;
&rfc5288;
</references>
<references title="Informative References">
&rfc6707;
&rfc7336;
&rfc7337;
&rfc2818;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:50:55 |