Internet DRAFT - draft-lelouedec-cdni-request-routing
draft-lelouedec-cdni-request-routing
Internet Engineering Task Force Y. Le Louedec
Internet-Draft A. Marrec
Intended status: Informational G. Bertrand
Expires: January 10, 2013 France Telecom - Orange
M. Pilarski
Orange Polska / WUT
July 9, 2012
CDNI Request Routing
draft-lelouedec-cdni-request-routing-00
Abstract
The present document proposes to clarify the CDNI Request Routing
interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-
problem-statement], as well as related terminology.
In particular the present document proposes to split the CDNI Request
Routing interface into two separate interfaces with clearer roles,
named respectively CDNI Routing interface and CDNI Downstream
Resource Identifier Signaling interface (CDNI DRIS interface).
This part of the CDN interconnection framework the IETF has been
referring to so far with the term "CDNI Request Routing" is just
another routing, signaling and forwarding problem in a long series of
the telecommunication history. For example, one can draw a direct
analogy between the IP/MPLS-TE framework and the CDN interconnection
framework.
In addition, this document recommends that the specification of ALL
CDN interconnection interfaces in the scope of the CDNI IETF WG
relies on the equivalent concept to IP prefix for CDN
interconnection, named 'contentRequestScope'. This highly useful and
powerful concept SHALL be used to simplify the specification of ALL
CDN interconnection interfaces, as well as to ensure performance and
scalability in CDN interconnection.
All these proposals can be smoothly integrated in the WG drafts,
especially [I-D.ietf-cdni-framework] and
[I-D.ietf-cdni-requirements], as they essentially propose (useful)
clarifications of the existing framework.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Le Louedec, et al. Expires January 10, 2013 [Page 1]
Internet-Draft CDNI Request Routing July 2012
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Le Louedec, et al. Expires January 10, 2013 [Page 2]
Internet-Draft CDNI Request Routing July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivations and Terminology Clarifications . . . . . . . . . . 4
2.1. The CDNI Request Routing interface should be split . . . . 5
2.2. The routing function of the CDNI Request Routing
interface should be clarified . . . . . . . . . . . . . . 6
2.3. CDNI request redirection strategies . . . . . . . . . . . 7
3. Overview of the CDNI Routing interface . . . . . . . . . . . . 8
4. The CDNI Downstream Resource Identifier Signaling (DRIS)
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Overview of the CDNI DRIS interface . . . . . . . . . . . 11
4.2. Overview of CDNI DRIS operations . . . . . . . . . . . . . 15
4.2.1. Case of iterative CDNI request redirection . . . . . . 16
4.2.2. Case of recursive CDNI request redirection . . . . . . 18
4.3. Key points to note about the CDNI DRIS interface . . . . . 23
5. CDNI request routing is just another routing and signaling
problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Conclusion and recommendations . . . . . . . . . . . . . . . . 26
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. Informative References . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Proposal for Section 4.2 of CDNI framework draft . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Le Louedec, et al. Expires January 10, 2013 [Page 3]
Internet-Draft CDNI Request Routing July 2012
1. Introduction
The present document proposes to clarify the CDNI Request Routing
interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-
problem-statement], as well as the related terminology.
In particular the present document proposes to split the CDNI Request
Routing interface into two separate interfaces with clearer roles,
named respectively CDNI Routing interface and CDNI Downstream
Resource Identifier Signaling interface (CDNI DRIS interface).
Section 2 presents the motivations for splitting the CDNI Request
Routing interface. It also proposes to review and to expand the
terminology about the terms iterative request routing and recursive
request routing.
Section 3 and Section 4 provide a short overview respectively of the
CDNI Routing interface and of the CDNI DRIS interface. The detailed
specifications of each of these interfaces will be made public
shortly by the authors in dedicated IETF drafts.
Section 5 provides an analogy with IP/MPLS-TE framework. This just
aims at helping readers to understand the proposals and
recommendations in this document.
Section 6 concludes this draft with recommendations for the IETF CDNI
WG. This includes recommendations about the CDNI WG charter, as well
as about [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-requirements].
Appendix A proposes a text to replace Section 4.2 of
[I-D.ietf-cdni-framework].
2. Motivations and Terminology Clarifications
Section 2.1 and Section 2.2 present the motivations for splitting and
clarifying the CDNI Request Routing interface.
This document adopts the terminology described in [I-D.ietf-cdni-
problem-statement] and [I-D.ietf-cdni-framework], except for the
terms 'iterative request routing' and 'recursive request routing'.
Section 2.3 proposes to review and to expand the terminology about
these two terms.
In addition this document extends this terminology with the terms
'CDNI routing interface', 'CDNI DRIS interface' and
'contentRequestScope' introduced and illustrated respectively in
Sections 3, 4, and 5. It also introduces the term 'delivery
Le Louedec, et al. Expires January 10, 2013 [Page 4]
Internet-Draft CDNI Request Routing July 2012
resource'. From the perspective of the uCDN, a delivery resource is
a delivery node or a request routing system towards which a content
request may be redirected: either a delivery node inside the uCDN, or
the request routing system of a CDN different from the uCDN, or a
delivery node within a CDN different from the upstream CDN.
2.1. The CDNI Request Routing interface should be split
One key message of the present document is that the term "CDNI
Request Routing" is confusing as it makes a mix-up of two clearly
different sets of processes and interfaces.
As described in [I-D.ietf-cdni-problem-statement], the CDNI Request
Routing interface's role is twofold:
1. "To enable a downstream CDN to provide to the upstream CDN
(static or dynamic) information (e.g., resources, footprint,
load) to facilitate selection of the downstream CDN by the
upstream CDN request routing system when processing subsequent
content requests from User Agents."
2. "To allow the downstream CDN to control what the upstream Request
Routing function should return to the User Agent in the
redirection message."
These two functions are fundamentally different. Besides, depending
on the considered use cases, described in [I-D.ietf-cdni-use-cases],
they could be implemented differently (e.g., the first function could
be implemented manually while the second function would be
implemented with a network protocol, or vice versa, or they could
rely on different network protocols, etc.).
This idea that the request routing interface comprises two parts has
started to be visible in the latest version of the Section 4.2 in
[I-D.ietf-cdni-framework]. We think that it is a good first step
that requires clarifications. Indeed, [I-D.ietf-cdni-framework]
mentions a 'synchronous part' that makes again a mix-up between
operations involving communications with the user agent and
operations only between the CDNs. And the latter ones can be purely
asynchronous operations in some cases, as illustrated in Section 4 of
the present memo.
Therefore, in order to simplify and accelerate the specification of
the CDNI interfaces, the present document proposes to split the
current CDNI Request Routing interface into two separate interfaces
with clearer roles, further detailed in Section 3 and Section 4
respectively:
Le Louedec, et al. Expires January 10, 2013 [Page 5]
Internet-Draft CDNI Request Routing July 2012
1. The CDNI Routing Interface
2. The CDNI Downstream Resource Identifier Signaling (DRIS)
Interface.
2.2. The routing function of the CDNI Request Routing interface should
be clarified
Quoting [I-D.ietf-cdni-problem-statement], "The CDNI Request Routing
interface enables a Request Routing function in an upstream CDN to
query a Request Routing function in a downstream CDN to determine if
the downstream CDN is able (and willing) to accept the delegated
content request".
The "ability" and the "willingness" of the downstream CDN to accept
the delegated content request match two fully different processes in
CDN interconnection. And the description of both these processes
should be reviewed and clarified for the following reasons:
o Regarding the former process, i.e. related to the "ability"
("enables a Request Routing function in an upstream CDN to query a
Request Routing function in a downstream CDN to determine if the
downstream CDN is able (...) to accept the delegated content
request"), a routing protocol is used to achieve such a process,
called routing process, in many other technologies and networks
(IP, ATM, etc.). In all these technologies, it is the downstream
entity that provides routing information to the upstream entity.
The same approach should be applied to CDN interconnection. The
reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2,
dCDN 3, and then it selects one of them based on their responses")
would suffer from latency, signaling overhead and/or lack of
reactivity to events that impact the ability of the downstream
CDNs to accept delegated content requests.
o Regarding the latter process, i.e. related to the "willingness"
("enables a Request Routing function in an upstream CDN to query a
Request Routing function in a downstream CDN to determine if the
downstream CDN (...) is willing (...)to accept the delegated
content request"), it is to be noted that the relationship between
a uCDN and a dCDN is always in the frame of a contractual
agreement between the administrative entity owning the uCDN,
acting as the customer, and the administrative entity owning the
dCDN, acting as the service provider. Therefore, consider a case
where
* the uCDN has a content request to redirect which is in full
conformance with the terms of this contractual agreement, and
Le Louedec, et al. Expires January 10, 2013 [Page 6]
Internet-Draft CDNI Request Routing July 2012
* the uCDN has selected this dCDN.
As the uCDN knows, thanks to the routing information exchanged via
the aforementioned routing process, that the dCDN is able to
accept this content request, the uCDN MAY redirect the content
request to the dCDN and the dCDN MUST accept the content request.
Exchanging over the CDNI Request Routing interface information
about the "willingness" of the dCDN to accept the content request
is not relevant.
2.3. CDNI request redirection strategies
The terms "Iterative CDNI request routing" and "Recursive CDNI
request routing" are defined in [I-D.ietf-cdni-framework]. As
explained above the term "CDNI request routing" is confusing,
therefore, the present document proposes to use the terms "Iterative
CDNI request redirection" and "Recursive CDNI request redirection"
instead. We consider that these new terms are more appropriate than
the definitions provided in [I-D.ietf-cdni-framework].
The definition of "Recursive CDNI request routing" given in
[I-D.ietf-cdni-framework] indicates "...that the Downstream CDN may
elect to have the request redirected directly to a delivery node
inside the Downstream CDN, to the Request-Routing System of the
Downstream CDN, to another CDN, or to any other system that the
Downstream CDN sees as fit for handling the redirected request."
In order to clarify this point, and for the purpose of Section 3 to
Section 6, the present document introduces the terms "full-recursive
CDNI request redirection" and "semi-recursive CDNI request
redirection".
Full-recursive CDNI request redirection and semi-recursive CDNI
request redirection are two subtypes of recursive CDNI request
redirection. A recursive CDNI request redirection is either a full-
recursive CDNI request redirection or a semi-recursive request
redirection.
"Full-recursive CDNI request redirection" refers to the case where
the considered CDN redirects the content request directly to a
delivery node of another CDN, as illustrated in Figure 4. It means
the content request is redirected:
o either directly to a delivery node inside the Downstream CDN,
o or directly to a delivery node inside a downstream CDN of the
downstream CDN,
Le Louedec, et al. Expires January 10, 2013 [Page 7]
Internet-Draft CDNI Request Routing July 2012
o or directly to a delivery node inside a downstream CDN of a
downstream CDN of the downstream CDN,
o etc. (anyway directly to a delivery node).
In contrast, "semi-recursive CDNI request redirection" refers to the
case, illustrated on Figure 5, where the considered CDN does not
directly redirect the content request to a delivery node. It means
the request is redirected:
o either to the request routing system of the Downstream CDN that
will deliver the content
o or to the request routing system of another CDN that will deliver
the content and that is a downstream CDN of the downstream CDN,
o or to the request routing system of another CDN that will deliver
the content and that is a downstream CDN of a downstream CDN of
the downstream CDN,
o etc. (anyway not directly to a delivery node).
Full-recursive redirection has the advantage over semi-recursive
redirection of being more transparent from the user agent's
perspective, but the disadvantage of the downstream CDN exposing more
of its internal structure (in particular, the addresses of delivery
nodes) to the upstream CDN (and possibly to the upstream CDN(s) of
its upstream CDN, etc.). By contrast, semi-recursive redirection
does not require dCDN to expose the addresses of its delivery nodes
to uCDN. The specifications for the CDNI interfaces elaborated
within the IETF CDNI WG MUST allow to support both these recursive
CDNI request redirection strategies.
3. Overview of the CDNI Routing interface
The CDNI routing interface is dedicated to the CDNI routing process.
The CDNI routing process consists in the advertisement of CDNI
routing information from the downstream CDN to the upstream CDN.
Note: The upstream CDN never provides the downstream CDN with any
CDNI routing information.
CDNI routing information details "capabilities" of the downstream CDN
that the upstream CDN must take into account in its CDN selection
process. The CDN selection process consists for the upstream CDN to
select the CDN (either the upstream CDN or one of its downstream
CDN(s)) that should handle the content request the upstream CDN
Le Louedec, et al. Expires January 10, 2013 [Page 8]
Internet-Draft CDNI Request Routing July 2012
receives from the user agent.
Note: The term "capabilities" refer to the capacity of the downstream
CDN to handle correctly content requests from user agents. It does
not necessarily mean that the downstream CDN will satisfy (alone) all
these content requests by delivering the requested content to the
user agent. Indeed the downstream CDN may have its own downstream
CDN(s) and may decide that some or all of these content requests will
be handled by its own downstream CDN(s).
Figure 1 provides a short illustration of the CDNI routing interface.
The upstream CDN on Figure 1 has two downstream CDNs: CDN1 and CDN2.
Via their respective CDNI routing interfaces established with the
upstream CDN, CDN1 and CDN2 provide the upstream CDN with CDNI
routing information about the capabilities that they offer to the
upstream CDN in the frame of their respective CDNI agreements
contracted with the upstream CDN.
The inner architecture of the upstream CDN is beyond the scope of the
current charter of the IETF CDNI WG. Figure 1 provides a high level
representation of a possible implementation just in order to ease
understanding of the global picture.
Basically and typically, the CDNI routing information received from
CDN1 and CDN2 will feed a CDNI routing table controlled by a routing
module in the upstream CDN. And every time the upstream CDN receives
a content request from a user agent (either a DNS request in case of
DNS based request redirection, or an HTTP request in case of HTTP
based request redirection, etc.), its CDN selection module (in charge
of the CDN selection process) will consult this CDNI routing module
to decide about which CDN will handle this request (the upstream CDN,
CDN1, or CDN2). In the example on Figure 1, the upstream CDN selects
CDN 2 for the considered content request.
Le Louedec, et al. Expires January 10, 2013 [Page 9]
Internet-Draft CDNI Request Routing July 2012
+-----+ +------------------------------------------------+
| | | Upstream CDN |
| | | |
| | | (1) Content request +----------------------+ |
| |-------------------------->| | |
| | | | CDN selection | |
| | | (2) | Module | |
| | | +--------->| | |
| | | | | (Selection of CDN2) | |
| | | | +----------------------+ |
|User | | | |
|Agent| | | |
| | | | |
| | | V |
| | | +--------------------------------------------+ |
| | | | | |
| | | | CDNI Routing Module | |
| | | | | |
| | | +--------------------------------------------+ |
| | | ^ ^ |
| | | | | |
| | +-----------|----------------------|-------------+
| | |(A) CDNI Routing (A)|
| | | Interfaces |
| | +-------+-------+ +-------+-------+
| | |Downstream CDN1| |Downstream CDN2|
+-----+ +---------------+ +---------------+
Figure 1: CDNI routing interface
The operations shown on Figure 1 are as follows:
1. A content request from a user agent (and/or from an intermediate
local DNS in case it is a DNS request) arrives at the upstream
CDN.
2. Within the upstream CDN, the CDN selection module consults the
routing module to decide which CDN will handle this content
request (i.e. whether it will be the upstream CDN or one of its
downstream CDNs). The interface between these internal modules
is out of standardization scope.
A. The operations achieved over the CDNI Routing interfaces aim at
providing all information about the capabilities offered by the
downstream CDNs to the upstream CDN in the frame of their respective
CDNI agreements contracted with the upstream CDN.
Le Louedec, et al. Expires January 10, 2013 [Page 10]
Internet-Draft CDNI Request Routing July 2012
The operations referenced with numeric indexes on Figure 1 ("1", "2")
show a time dependency: every time the upstream CDN receives a
content request ("1") its CDN selection process consults the routing
table ("2").
In contrast, Routing information is to be exchanged continuously,
with keep alive and update messages. There is no time dependency
between the content requests received by the upstream CDN and the
operations over the CDNI routing interfaces. By reference to the
terminology used in [I-D.ietf-cdni-framework], CDNI Routing
operations are asynchronous. The CDNI routing interfaces are
referenced with an alphabetic index ("A") on Figure 1 to reflect this
point.
4. The CDNI Downstream Resource Identifier Signaling (DRIS) Interface
4.1. Overview of the CDNI DRIS interface
AFTER the CDN selection process is achieved by the upstream CDN for a
given content request (see Section 3), the upstream CDN MUST generate
a response redirecting that content request towards the selected
delivery resource by using in this response an identifier of that
selected delivery resource.
The selected delivery resource can be:
1. Either a delivery node within the upstream CDN
This corresponds to the case where the CDN selection process of the
upstream CDN selects the upstream CDN for that content request. In
this case, the upstream CDN delivers the requested content to the
client through one of its delivery nodes. The selected delivery
resource is the upstream CDN's delivery node.
2. Or the request routing system of a CDN different from the
upstream CDN
This corresponds to the case where the upstream CDN did select a
downstream CDN for that content request, and where the CDNI request
redirection strategy between the upstream CDN and this downstream CDN
is based either on the iterative mode or on the semi-recursive mode.
If the CDNI request redirection strategy between the uCDN and the
dCDN is based on the iterative mode, the CDN to which the request
routing system belongs is the downstream CDN selected by the upstream
CDN for that content request (see Figure 3: Iterative CDNI request
redirection). If the CDNI request redirection strategy between the
uCDN and the dCDN is based on the semi-recursive mode, the CDN to
Le Louedec, et al. Expires January 10, 2013 [Page 11]
Internet-Draft CDNI Request Routing July 2012
which that request routing system belongs can possibly be
o the downstream CDN selected by the upstream CDN for that content
request, or
o a downstream CDN of that downstream CDN, or
o a downstream CDN of a downstream CDN of that downstream CDN,
o etc.,
due to the recursive nature of this mode (see Figure 5).
3. Or a delivery node within a CDN different from the upstream CDN
This corresponds to the case where the upstream CDN did select a
downstream CDN for that content request, and where the CDNI request
redirection strategy between the upstream CDN and this downstream CDN
is based on the full-recursive mode.
The CDN to which the selected delivery node belongs can possibly be a
delivery node within the downstream CDN selected by the upstream CDN
for that content request, or a delivery node within a downstream CDN
of that downstream CDN, or a delivery node within a downstream CDN of
a downstream CDN of that downstream CDN, etc., due to the recursive
nature of this mode (see Figure 4: Full-recursive CDNI request
redirection).
In the cases "2." and "3.", the downstream CDN MUST provide the
identifier of the selected delivery resource to the upstream CDN.
The downstream CDN uses the CDNI DRIS interface to provide the
upstream CDN with this identifier called "Downstream Resource
Identifier" (DRI).
Note. In the recursive modes (full-recursive and semi-recursive) the
upstream CDN does not need to know if the selected delivery resource
belongs to the downstream CDN that the uCDN selected for that content
request or to another CDN (i.e. to one downstream CDN of this
downstream CDN, or to one downstream CDN of one downstream CDN of
this downstream CDN, etc.). The upstream CDN just needs to get from
the selected downstream CDN the "Downstream Resource Identifier"
(DRI) of the selected delivery resource, so as to generate with this
identifier a response redirecting that content request towards that
selected delivery resource.
Le Louedec, et al. Expires January 10, 2013 [Page 12]
Internet-Draft CDNI Request Routing July 2012
+-----+ +-------------------------------------------------+
| |(1) Content | |
| | request | Upstream CDN |
| |----------------+ |
| | | | |
| | | | (5) Content request response |
| |<---------------|---------------------------------+ |
| | | | | |
| | | +-V--------------+ +--------+---------+ |
| | | | CDN selection | | Content request | |
| | | | Module |(3) | response | |
| | | | |-------->| generation | |
| | | | (Selection |Internal | Module | |
|User | | | of CDN2) |Interface| | |
|Agent| | +----------------+ +------------------+ |
| | | ^ ^ |
| | | (2)|Internal (4)|Internal |
| | | |interface |interface |
| | | V V |
| | | +-------------+ +-----------+ |
| | | |CDNI Routing | |DRI | |
| | | |Module | |Module | |
| | | +-------------+ +-----------+ |
| | | ^ ^ ^ ^ |
| | +----------|---|-----------------|---|------------+
| | CDNI Routing|(A)+--------------+ |(B)|CDNI DRIS
| | Interfaces | +------------|--+ |Interfaces
| | | | | |
| | +------+-----v--+ +-+------v------+
| | |Downstream CDN1| |Downstream CDN2|
+-----+ +---------------+ +---------------+
Figure 2: CDNI DRIS interface
Figure 2 is an extension of Figure 1. Again, the inner architecture
of the CDN is beyond the scope of the IETF CDNI WG charter; Figure 2
provides a high level representation of a possible implementation
just in order to ease the understanding of the global picture.
The operations shown on Figure 2 are as follows:
1. A content request from a user agent (and/or from an intermediate
local DNS in case it is a DNS request) arrives at the upstream
CDN.
2. Within the upstream CDN, the CDN selection Module consults the
routing module to decide which CDN will handle this content
Le Louedec, et al. Expires January 10, 2013 [Page 13]
Internet-Draft CDNI Request Routing July 2012
request (i.e. whether it will be the upstream CDN or one of its
downstream CDNs). The interface between these internal modules
is out of standardization scope. Let us consider that the CDN
selection module selected the downstream CDN2 for that content
request (so as to continue with the illustrating example
introduced in Section 3).
3. Once this CDN selection is achieved, the module in charge of
generating the response to the content request ('Content request
response generation Module' on Figure 2) is called. The
interface between these internal modules is out of
standardization scope. In order to generate the response, the
Content request response generation module needs to get the
identifier of the selected delivery resource (DRI) to where the
content request must be redirected.
4. The Content request response generation module consults the DRI
module to get this adequate DRI. The interface between these
internal modules is out of standardization scope. The DRI module
is in charge of getting and storing the DRI(s) provided by each
downstream CDN over their CDNI DRIS interfaces with the upstream
CDN.
5. Once the Content request response generation module has this
adequate DRI, it generates the response to the content request so
as to the request be redirected towards the selected delivery
resource.
A. The operations achieved over the CDNI Routing interfaces aim at
providing all information about the capabilities offered by the
downstream CDNs to the upstream CDN in the frame of their respective
CDNI agreements contracted with the upstream CDN.
B. The operations achieved over the CDNI DRIS Interface with the
downstream CDN2 aim at providing the upstream CDN with the DRI, i.e.
the identifier of the selected delivery resource.
The operations referenced with numeric indexes on Figure 2 ("1", "2",
"3", "4", "5") show a strict time dependency. In particular, it is
to be highlighted that the CDN selection process of the upstream CDN
does not take the DRI information into account. This identifier is
used by the content request response generation module only after the
CDN selection process is achieved.
As explained in Section 3, the CDNI routing interfaces are referenced
with an alphabetic index ("A") to indicate that the CDNI routing
information are exchanged asynchronously and continuously, with keep
alive and update messages.
Le Louedec, et al. Expires January 10, 2013 [Page 14]
Internet-Draft CDNI Request Routing July 2012
The CDNI DRIS interfaces are also referenced with an alphabetic index
("B") to indicate there is not always a systematic time dependency
between the content requests received by the upstream CDN and the
operations occurring over the CDNI DRIS interfaces. This depends,
among others, on the CDNI request redirection strategy enforced
between the CDNs (recursive or iterative). This means that the
specification of the CDNI DRIS interface MUST enable synchronous and
asynchronous operations, as illustrated in the next Section 4.2.
4.2. Overview of CDNI DRIS operations
This section gives an overview of operations over the CDNI DRIS
interfaces for each CDNI request redirection strategy (iterative,
full-recursive and semi-recursive).
All the figures present the same network topology with three cascaded
CDNs so as to show very clearly the difference between the full-
recursive and semi-recursive modes. The case where only two CDNs are
involved can be straightforwardly deduced. In addition, the CDNI
request redirection strategy applied between the first CDN and the
second CDN (e.g., iterative) could differ from the strategy applied
between the second CDN and the third CDN (e.g., semi- recursive).
The three figures are for illustration purpose only; they do not aim
at reflecting exhaustively the full flexibility that the CDN service
providers have when choosing their CDNI request redirection
strategies.
The same situation and content request are considered in all the
three figures:
o There is one CDNI agreement and one CDN interconnection between
CDN-a and CDN-b for the considered request. CDN-b is a downstream
CDN of CDN-a. And there is one CDNI DRIS interface between CDN-a
and CDN-b, bootstrapped with configuration information exchanged
over the CDNI control interface during the initial CDN
interconnection activation process (see
[I-D.ietf-cdni-framework]).
o In the same way there is one CDNI agreement, one CDN
interconnection and one CDNI DRIS interface between CDN-b and
CDN-c. CDN-c is a downstream CDN of CDN-b for the considered
request.
o CDN-a receives a content request and decides CDN-b will handle it.
CDN-b decides the content request will be handled by CDN-c. CDN-c
delivers the content to the user agent from one of its delivery
nodes (cache hit).
Le Louedec, et al. Expires January 10, 2013 [Page 15]
Internet-Draft CDNI Request Routing July 2012
4.2.1. Case of iterative CDNI request redirection
Figure 3 presents the case where the iterative CDNI request
redirection mode is applied between CDN-a and CDN-b, and between
CDN-b and CDN-c.
+-----+ +------------------+
| | |CDN-a |
| | 1 | (uCDN for CDN-b) |
| |-------------------------------------->| |
| | 2 | |
| |<--------------------------------------| |
| | +------------------+ | +--------+ |
| | |CDN-b | | | | |
| | 3 | (uCDN for CDN-c) | | |DRI | |
| |----->| | +------------->|Module | |
| | 4 | +--------+ | 0 | | | | |
| |<-----| | |--------+ | +--------+ |
| | | | | | +------------------+
|User | | |DRI | |
|Agent| | |Module | |
| | | | | |
| | | | | | 0
| | | | |<-------+
| | | +--------+ | |
| | +------------------+ | +------------------+
| | | |CDN-c |
| | | | +--------+ |
| | | | | | |
| | +--------------|DRI | |
| | | |Module | |
| | | | | |
| | 5 | +--------+ |
| |-------------------------------------->| |
| | 6 | |
| |<--------------------------------------| |
| | 7 | +--------+ |
| |------------------------------------------->| | |
| | 8 | |Delivery| |
| |<-------------------------------------------|Node | |
| | | | | |
| | | +--------+ |
+-----+ +------------------+
Figure 3: Iterative CDNI request redirection
Le Louedec, et al. Expires January 10, 2013 [Page 16]
Internet-Draft CDNI Request Routing July 2012
The operations shown in Figure 3 are as follows:
0. CDN-a gets from CDN-b, over the CDNI DRIS interface between CDN-a
and CDN-b, a DRI valid for any content request within their mutual
CDNI agreement, and possibly before any user agent content request is
received by CDN-a.
In the iterative case, the CDNI DRIS interface may indeed provide the
upstream CDN with a unique DRI valid in the frame of their mutual
CDNI agreement for any content request received by the upstream CDN.
Basically, it means that the downstream CDN informs the upstream CDN
that, when the upstream CDN decides to redirect a content request to
this downstream CDN in the frame of their mutual CDNI agreement, the
upstream CDN just has to use systematically that DRI to forge the
response sent by the upstream CDN to redirect the content request to
that downstream CDN.
For example, in case the CDNI request redirection mechanism is based
on HTTP 302 redirect messages, this DRI includes a distinguished CDN-
domain, which is to be "stacked" in front of the original URL to
construct the new URL to redirect the content request to the request
routing system of the downstream CDN, as detailed in
[I-D.ietf-cdni-framework].
This static and unique DRI for a CDNI agreement set between CDN-a and
CDN-b can be exchanged even before the first content request received
by CDN-a. This is an example of asynchronous operation over the CDNI
DRIS interface. And this is one case where it may be relevant to
implement the CDNI DRIS interface "manually"; for example the DRI can
be exchanged on the phone or by email simply and only once for the
whole duration of the CDNI agreement between CDN-a and CDN-b.
We describe the other operations of Figure 3 below.
0. The same way, CDN-b gets from CDN-c, over the CDNI DRIS interface
between CDN-b and CDN-c, a DRI valid for any content request within
their mutualCDNI agreement, and possibly before any user agent
content request is received by CDN-b.
1. The considered content request, sent by a user agent (and/or by
an intermediate local DNS in case it is a DNS request), arrives at
CDN-a.
2. CDN-a decides this content request is to be best handled by
CDN-b. Therefore, CDN-a sends a response to the content request,
forged with the DRI provided by CDN-b.
Le Louedec, et al. Expires January 10, 2013 [Page 17]
Internet-Draft CDNI Request Routing July 2012
3. A request is thus sent by the user agent (and/or by an
intermediate local DNS in case it is a DNS request) to CDN-b.
4. CDN-b decides this content request is to be best handled by
CDN-c. Thus, CDN-b sends a response to the content request forged
with the DRI provided by CDN-c.
5. A request is sent by the user agent (and/or by an intermediate
local DNS in case it is a DNS request) to CDN-c.
6. CDN-c decides it will handle the request, i.e. it will be the one
to deliver the content to the user agent. CDN-c selects one of its
delivery nodes to handle that content request. CDN-c generates a
response redirecting the content request to this delivery node.
7. The user agent emits a content request to the selected delivery
node.
8. The selected delivery node from CDN-c delivers the requested
content to the user agent.
4.2.2. Case of recursive CDNI request redirection
Figure 4 presents the case where the full-recursive CDNI request
redirection mode is applied between CDN-a and CDN-b, and between
CDN-b and CDN-c.
Le Louedec, et al. Expires January 10, 2013 [Page 18]
Internet-Draft CDNI Request Routing July 2012
+-----+ +------------------+
| | |CDN-a |
| | 1 | (uCDN for CDN-b) |
| |-------------------------------------->| |
| | 6 | |
| |<--------------------------------------| |
| | +------------------+ | +--------+ |
| | |CDN-b | +--------------| | |
| | | (uCDN for CDN-c) | | | |DRI | |
| | | | | +-------->|Module | |
| | | +--------+ | 2 | | | | | |
| | | | |<-------+ | | +--------+ |
| | | | | | 5 | +------------------+
|User | | |DRI |-------------+
|Agent| | |Module | | 3
| | | | |-------------+
| | | | | | 4 |
| | | | |<-------+ |
| | | +--------+ | | |
| | +------------------+ | | +------------------+
| | | | |CDN-c |
| | | | | +--------+ |
| | | +-------->| | |
| | | | |DRI | |
| | +--------------|Module | |
| | | | | |
| | | +--------+ |
| | 7 | +--------+ |
| |------------------------------------------->| | |
| | 8 | |Delivery| |
| |<-------------------------------------------|Node | |
| | | | | |
| | | +--------+ |
+-----+ +------------------+
Figure 4: Full-recursive CDNI request redirection
The operations shown in Figure 4 are as follows:
1. The considered content request, sent by a user agent (and/or by
an intermediate local DNS in case it is a DNS request), arrives at
CDN-a.
2. CDN-a decides this content request is to be best handled by
CDN-b. CDN-a sends a request to CDN-b over the CDNI DRIS interface
set up between CDN-a and CDN-b. The request includes all information
about the content request CDN-b needs in order to select the most
Le Louedec, et al. Expires January 10, 2013 [Page 19]
Internet-Draft CDNI Request Routing July 2012
appropriate delivery resource and to response to CDN-a with the
corresponding adequate DRI.
3. CDN-b decides this content request is to be best handled by
CDN-c. CDN-b sends a request to CDN-c over the CDNI DRIS interface
set up between CDN-b and CDN-c. The request includes all information
about the content request CDN-c needs in order to select the most
appropriate delivery resource and to response to CDN-b with the
corresponding adequate DRI.
4. CDN-c decides it will handle the content request, i.e. it will be
the one to deliver the content to the user agent. CDN-c selects one
of its delivery nodes to handle that content request. CDN-c sends a
response to CDN-b, over the CDNI DRIS interface between CDN-b and
CDN-c, with a DRI corresponding to that delivery node.
5. CDN-b sends a response to CDN-a, over the CDNI DRIS interface
between CDN-a and CDN-b, with a DRI corresponding to the selected
delivery node from CDN-c. This DRI is based on the DRI provided by
CDN-c. Details about the manipulations achieved by CDN-b over the
DRI received from CDN-c to generate the DRI sent to CDN-a are to be
provided in the dedicated specification of the CDNI DRIS interface.
6. CDN-a sends a response to the content request, forged with the
DRI provided by CDN-b.
7. The user agent emits a content request directly to the selected
delivery node from CDN-c.
8. The selected delivery node from CDN-c delivers the requested
content to the user agent.
The Figure 5 below presents the case where the semi-recursive CDNI
request redirection mode is applied between CDN-a and CDN-b, and
between CDN-b and CDN-c.
Le Louedec, et al. Expires January 10, 2013 [Page 20]
Internet-Draft CDNI Request Routing July 2012
+-----+ +------------------+
| | |CDN-a |
| | 1 | (uCDN for CDN-b) |
| |-------------------------------------->| |
| | 6 | |
| |<--------------------------------------| |
| | +------------------+ | +--------+ |
| | |CDN-b | +--------------| | |
| | | (uCDN for CDN-c) | | | |DRI | |
| | | | | +-------->|Module | |
| | | +--------+ | 2 | | | | | |
| | | | |<-------+ | | +--------+ |
| | | | | | 5 | +------------------+
|User | | |DRI |-------------+
|Agent| | |Module | | 3
| | | | |-------------+
| | | | | | 4 |
| | | | |<-------+ |
| | | +--------+ | | |
| | +------------------+ | | +------------------+
| | | | |CDN-c |
| | | | | +--------+ |
| | | +-------->| | |
| | | | |DRI | |
| | +--------------|Module | |
| | | | | |
| | 7 | +--------+ |
| |-------------------------------------->| |
| | 8 | |
| |<--------------------------------------| |
| | 9 | +--------+ |
| |------------------------------------------->| | |
| | 10 | |Delivery| |
| |<-------------------------------------------|Node | |
| | | | | |
| | | +--------+ |
+-----+ +------------------+
Figure 5: Semi-recursive CDNI request redirection
The operations shown in Figure 5 are as follows:
1. The considered content request, sent by a user agent (and/or by
an intermediate local DNS in case it is a DNS request), arrives at
CDN-a.
2. CDN-a decides this content request is to be best handled by
Le Louedec, et al. Expires January 10, 2013 [Page 21]
Internet-Draft CDNI Request Routing July 2012
CDN-b. CDN-a sends a request to CDN-b over the CDNI DRIS interface
set up between CDN-a and CDN-b. The request includes all information
about the content request CDN-b needs in order to select the most
appropriate delivery resource and to response to CDN-a with the
corresponding adequate DRI.
3. CDN-b decides this content request is to be best handled by
CDN-c. CDN-b sends a request to CDN-c over the CDNI DRIS interface
set up between CDN-b and CDN-c. The request includes all information
about the content request CDN-c needs in order to select the most
appropriate delivery resource and to response to CDN-b with the
corresponding adequate DRI.
4. CDN-c decides it will handle the content request, i.e. it will be
the one to deliver the content to the user agent. CDN-c sends a
response to CDN-b, over the CDNI DRIS interface between CDN-b and
CDN-c, with a DRI corresponding to its request routing system.
5. CDN-b sends a response to CDN-a, over the CDNI DRIS interface
between CDN-a and CDN-b, with a DRI corresponding to the selected
delivery resource (i.e. to the request routing system of CDN-c).
This DRI is based on the DRI provided by CDN-c. Details about the
manipulations achieved by CDN-b over the DRI received from CDN-c to
generate the DRI sent to CDN-a are to be provided in the dedicated
specification of the CDNI DRIS interface.
6. CDN-a sends a response to the content request, forged with the
DRI provided by CDN-b.
7. The content request is redirected by the user agent (and/or by an
intermediate local DNS in case it is a DNS request) to the selected
delivery resource, i.e. to CDN-c.
8. CDN-c decides it will handle the content request, i.e. it will be
the one to deliver the content to the user agent. CDN-c selects one
of its delivery nodes to handle that content request. CDN-c
generates a response redirecting the content request to this delivery
node.
9. The user agent emits a content request to the selected delivery
node.
10. The selected delivery node from CDN-c delivers the requested
content to the user agent.
As shown on Figure 4 and 5, when the recursive mode is applied, the
upstream CDN may have to send a request over a CDNI DRIS interface
every time it receives a content request. This is an example of
Le Louedec, et al. Expires January 10, 2013 [Page 22]
Internet-Draft CDNI Request Routing July 2012
synchronous operations over the CDNI DRIS interface. Having one CDNI
DRIS request per content request may lead to scalability issues, even
if the CDNI DRIS interface is implemented with a network protocol
rather than "manually". Yet these issues can be solved. This is to
be documented in the dedicated specification of the CDNI DRIS
interface.
4.3. Key points to note about the CDNI DRIS interface
To conclude this section, the key points to note about the CDNI DRIS
interface are the following:
o The CDNI DRIS interface MUST always exist between two
interconnected CDNs. Whatever the CDNI request redirection
strategy applied (recursive or iterative), the CDNI DRIS interface
exists, even if it is implemented "manually" in some cases, as
suggested in the example of Figure 3 above.
o Moreover the CDNI DRIS interface MUST be unique from a functional
perspective. Another way to say this is that, from a functional
perspective, this is the exact same CDNI DRIS interface that is
used, and the exact same type of information that are exchanged
over this interface, whatever the CDNI request redirection
strategy applied (recursive or iterative).
o The specification of the CDNI DRIS interface MUST enable
synchronous and asynchronous CDNI DRIS operations: operations
possibly triggered by the CDN selection process for a given
content request (as shown on Figure 4 and 5), as well as
operations achieved independently of any content request (as shown
on Figure 3).
o The specification of the CDNI DRIS interface MUST enable
operations initiated by uCDN (as shown on Figure 4 and 5) or by
dCDN (as shown on Figure 3).
o The specification of the CDNI DRIS interface MUST be compatible
with "automatic" (i.e. "with a specific network protocol") and
"manual" implementations, as discussed in Section 4.2. The
specification of the CDNI DRIS interface SHALL include a
description for each of these implementation options.
o The CDNI routing and CDNI DRIS interfaces MUST be independent.
Le Louedec, et al. Expires January 10, 2013 [Page 23]
Internet-Draft CDNI Request Routing July 2012
5. CDNI request routing is just another routing and signaling problem
This part of the CDN interconnection framework the IETF has been
referring to so far with the term "CDNI Request Routing" is just
another routing, signaling and forwarding problem in a long series of
the telecommunication history.
For example one can draw an analogy with the IP/MPLS-TE framework,
notably, as shown on Figure 6 and below, between:
o the CDNI routing interface and any IP routing protocol/interface
(such as BGP/IGP IP routing protocols),
o the CDNI DRIS interface and a signaling protocol such as RSVP-TE.
It is to be noted that such an analogy must be considered with care
because the context and objectives of CDN interconnection are
different from IP routing, signaling and forwarding. In particular,
the type of information exchanged via the CDNI DRIS interface is
totally different from the information exchanged by protocols like
RSVP-TE in IP/MPLS networks. Anyway this analogy may ease to
understand the role of the CDNI DRIS interface in the CDNI framework.
Another key point to note in this analogy is that IP prefix is one of
the most important concepts in IP networks. It is used in most IP
processes (IP routing, packet filtering, MPLS-TE signaling, etc.).
It has been a highly useful and powerful concept to simplify the
specification of TCP/IP protocols as well as to ensure performance
and scalability of IP networks. For example exchanging IP routing
information per IP prefix has been a MUST to ensure IP routing
performance and scalability.
The equivalent concept to IP prefix has the same importance in the
CDN interconnection framework. The concept is named
"contentRequestScope" in Figure 6. A contentRequestScope designates
a class of content requests sharing common properties (e.g., "all the
HTTP requests", or "all HTTP requests issued by French users", or
"all RTSP and HTTP requests with signed URL", etc.).
In the same way as IP prefix is a key concept for specifying TCP/IP
protocols, "contentRequestScope" is THE main concept for the CDN
interconnection framework. This highly useful and powerful concept
SHALL be used to simplify the specification of ALL CDN
interconnection interfaces, as well as to ensure performance and
scalability in CDN interconnection.
Le Louedec, et al. Expires January 10, 2013 [Page 24]
Internet-Draft CDNI Request Routing July 2012
+--------------------------------+----------------------------------+
| IP/MPLS-TE concepts | CDN Interconnection concepts |
+--------------------------------+----------------------------------+
| IP packet Forwarding | Content request redirection |
+--------------------------------+----------------------------------+
| IP prefix | ContentRequestScope |
| (correspond to a class of IP | (correspond to a class of |
| addresses sharing the same | content requests sharing |
| prefix) | common properties) |
+--------------------------------+----------------------------------+
| Ingress Provider Edge Router | upstream CDN (uCDN) |
| (ILSR) | |
+--------------------------------+----------------------------------+
| Egress Provider Edge Router | Delivery resource (delivery node |
| (ELSR) | or downstream CDN) |
+--------------------------------+----------------------------------+
| IP routing interfaces (running | CDNI routing interface |
| IGP/BGP IP routing protocols) | |
+--------------------------------+----------------------------------+
| IP routing information | CDNI routing information |
| (IP prefix <-> Next Hop) | (ContentRequestScope <-> dCDN) |
+--------------------------------+----------------------------------+
| IP FEC table construction | Redirection table construction |
| (IP prefix <-> ELSR) | (ContentRequestScope <-> delivery|
| | resource) |
+--------------------------------+----------------------------------+
| Signaling information provided | Signaling information provided |
| by the RSVP-TE protocol | by the CDNI DRIS interface |
| (MPLS label <-> ELSR) | (DRI <-> delivery resource) |
+--------------------------------+----------------------------------+
| To encapsulate an IP packet in | To generate a redirected content |
| an MPLS frame (using an MPLS | request (using a DRI) |
| Label) | |
+--------------------------------+----------------------------------+
| To forward a packet out of the | To redirect a content request |
| nominal route based on IGP | out of the authoritative CDN, |
| and BGP routing information, | to another CDN, thanks to CDN |
| thanks to MPLS Traffic | interconnection technologies |
| Engineering technologies | |
+--------------------------------+----------------------------------+
| To forward an IP packet | To redirect a content request to |
| encapsulated in an MPLS frame | to the selected downstream CDN |
| via - or to - the destination | - or to the selected delivery |
| ELSR thanks to the MPLS | node - thanks to the |
| header of the MPLS frame | Downtream Resource Identifier |
| | (DRI) used to forge the response |
| | to the initial content request |
+--------------------------------+----------------------------------+
Le Louedec, et al. Expires January 10, 2013 [Page 25]
Internet-Draft CDNI Request Routing July 2012
Figure 6: Analogy between IP/MPLS-TE and CDNI concepts
CDNI Routing interfaces exchanges CDNI routing information per
contentRequestScope, i.e. per class of content requests sharing
common properties.
Analogically: IP routing protocols like IGP/BGP exchange routing
information per IP prefix, i.e. per class of IP addresses sharing
common properties.
The upstream CDN builds its redirection table with information
provided by the CDNI Routing interface and the CDNI DRIS interface.
Analogically: The Ingress Provider Edge Router (ILSR) builds its
forwarding table with information provided by the IP routing and
MPLS-TE signaling protocols.
When receiving a content request, which has possibly been already
redirected by some upstream CDNs, a CDN consults its forwarding table
to generate a response using the adequate DRI, provided by the CDNI
DRIS interface, which redirects the content request to the selected
delivery resource (which is a CDN or a node downstream).
Analogically: When receiving an IP packet, possibly encapsulated in
an MPLS frame, an Ingress Provider Edge Router (ILSR) consults its
forwarding table to manipulate it adequately. This manipulation may
include to encapsulate it in an MPLS frame, based on the signaling
information provided by the RSVP-TE protocol, which makes it being
then forwarded to the right Egress Provider Edge router (ELSR).
6. Conclusion and recommendations
A first key message of this document is that the term "CDNI request
routing" is confusing as it makes a mix-up of clearly different set
of processes and interfaces.
A second key message of this document is that this part of the CDN
interconnection framework the IETF has been referring to so far with
the term "CDNI Request Routing" is just another routing, signaling
and forwarding problem in a long series of the telecommunication
history. For example, one can draw a direct analogy between the IP/
MPLS-TE framework and the CDN interconnection framework.
Thus one can directly be inspired by the best practices and results
of the efforts invested over years, even decades, to develop
technologies in the past, such as IP/MPLS-TE, to specify adequately
CDN interconnection interfaces.
Le Louedec, et al. Expires January 10, 2013 [Page 26]
Internet-Draft CDNI Request Routing July 2012
The proposals from the current document can be smoothly integrated in
the WG drafts, especially [I-D.ietf-cdni-framework] and
[I-D.ietf-cdni-requirements], as they essentially propose (useful)
clarifications of the existing framework.
We recommend to review [I-D.ietf-cdni-framework], at least its
section 4.2. Appendix A provides a proposal to replace the current
Section 4.2 of [I-D.ietf-cdni-framework].
We recommend to review [I-D.ietf-cdni-requirements], to clearly
distinguish the requirements specific to the CDNI routing interface
from the requirements specific to the CDNI DRIS interface.
We also recommend to review the charter of the CDNI WG, in particular
to replace the following objective:
o "WG Creation + 18 months: Submit specification of the CDNI Request
Routing protocol to IESG as Proposed Standard"
by the two following objectives:
o "WG Creation + 18 months: Submit specification of the CDNI Routing
interface to IESG as Proposed Standard"
o "WG Creation + 18 months: Submit specification of the CDNI
Downstream Resource Identifier Signaling (DRIS) Interface to IESG
as Proposed Standard"
Last but not least, we recommend that the specification of ALL CDN
interconnection interfaces, including the CDNI routing interface and
the CDNI DRIS interface, rely on the "contentRequestScope" concept,
i.e. the equivalent concept to IP prefix for CDN interconnection. In
the same way as IP prefix is a key concept for specifying TCP/IP
protocols, "contentRequestScope" is THE main concept for the CDN
interconnection framework. This highly useful and powerful concept
SHALL be used to simplify the specification of ALL CDN
interconnection interfaces, as well as to ensure performance and
scalability in CDN interconnection.
7. Acknowledgments
The authors would like to thank Chris Hawinkel, Larry Peterson, Yvan
Massot, Ali Gouta, Emile Stephan, and Patrick Fleming for their
inputs and comments.
They also thank the contributors of the EU FP7 OCEAN project in the
frame of which these proposals have been elaborated.
Le Louedec, et al. Expires January 10, 2013 [Page 27]
Internet-Draft CDNI Request Routing July 2012
The work leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) in OCEAN
project (FP7-ICT-248775; http://www.ict-ocean.eu/).
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
Those are discussed in [I-D.ietf-cdni-problem-statement].
10. Informative References
[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-00 (work in
progress), April 2012.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), June 2012.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-03 (work in progress),
June 2012.
[I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-08 (work in
progress), June 2012.
Appendix A. Proposal for Section 4.2 of CDNI framework draft
"4.2. Request Routing Interface
The request routing interface is not a single interface, it
corresponds to two separate interfaces with clear roles:
Le Louedec, et al. Expires January 10, 2013 [Page 28]
Internet-Draft CDNI Request Routing July 2012
1) The CDNI Routing Interface
The CDNI routing interface is dedicated to the CDNI routing process.
The CDNI routing process consists in the advertisement of CDNI
routing information from the downstream CDN to the upstream CDN (the
upstream CDN never provides the downstream CDN with any CDNI routing
information). CDNI routing information details capabilities of the
downstream CDN that the upstream CDN must take into account in its
dCDN selection process.
2) The CDNI Downstream resource Identifier Signaling (DRIS) Interface
AFTER the CDN selection process is achieved by the upstream CDN for a
given content request, the upstream CDN MUST generate a response
redirecting that request towards the selected delivery resource by
inserting in this response an identifier of that selected delivery
resource.
This selected delivery resource can be:
1. a delivery node within the upstream CDN,
2. a downstream CDN (i.e. the request routing system of that
downstream CDN), or
3. a delivery node within a downstream CDN.
In the cases "2." and "3." , the identifier of that selected delivery
resource MUST be provided by the downstream CDN to the upstream CDN.
The downstream CDN uses the CDNI DRIS interface to provide the
upstream CDN with this identifier called "Downstream resource
Identifier" (DRI).
Authors' Addresses
Yannick Le Louedec
France Telecom - Orange
2 avenue Pierre Marzin
Lannion, 22307
France
Phone: +33 2 96 05 17 64
Email: yannick.lelouedec@orange.com
Le Louedec, et al. Expires January 10, 2013 [Page 29]
Internet-Draft CDNI Request Routing July 2012
Anne Marrec
France Telecom - Orange
2 avenue Pierre Marzin
Lannion, 22307
France
Phone: +33 2 96 05 18 71
Email: anne.marrec@orange.com
Gilles Bertrand
France Telecom - Orange
38-40 rue du General Leclerc
Issy les Moulineaux, 92130
France
Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com
Marcin Pilarski
Orange Polska / WUT
ul. Obrzezna 7 / ul. Koszykowa 75
Warsaw, Mazowieckie 02-691 / 00-662
Poland
Email: marcin.pilarski@orange.com / marcin.pilarski@mini.pw.edu.pl
Le Louedec, et al. Expires January 10, 2013 [Page 30]
